Romaric Pascal (c337e2b1) at 30 Jun 22:37

... and 11 more commits

If you're up for publishing a release, that would be much appreciated, thanks 😊

The element-permitted-content rule treats elements inside a <template> as if they were descendants of that element. This leads to errors when the <template> contains elements that are not permitted by one of its ancestors.

The rule should not fail when content in a <template> element is not permitted by one of the ancestor of the <template>, as the HTML specifications mention that "The template contents of a template element are not children of the element itself."

Reduced test-case

<a> tags are not allowed <a> tags as their descendant so the following code will trigger the error when it shouldn't as the second <a> is inside a <template>.

<a href="">
  Some content
  <template>
    <a href="">Other content</a>
  </template>
</a>

Configuration

{
  "extends": ["html-validate:recommended"]
}

Expected result

No errors

Actual result

html-validate outputs the following error:

4:6  error  <a> element is not permitted as a descendant of <a>  element-permitted-content

Version

• html-validate: 9.5.2

@extsidvind I see three options for fixing this one but I'm not familiar enough with the codebase to pick one, would you be able to advise between:

1. Adding a template to each element in the list within html5.ts that has a requiredAncestors property
2. Have the rule inject a template selector to the list of required ancestors before calling Validator.validateAncestors
3. Have Validator.validateAncestors add a template selector to non-empty list of rules it receives

2 or 3 seem equivalent to me, but they may not be (3 may make easier tests?), and I'm also worried there may be unforeseen side effects. Do you have any view on the matter, I'd be happy to provide a patch if any of these routes are suitable 😊

Unless I'm the one getting confused. Could you let me know if there's any further action I need to take? I got worried by the log of my last force push (after rebasing on master ) talking about adding 2 commits, but the 'Commits' tab only shows the commit for fixing that PR, so maybe everything is OK (a local git log looks alright on my machine)?

Argh, looks like I messed things up using GitLab's UI to update my fork and it introduced a merge commit 😥 I'll rebase properly over this repo's master branch for a clean history.

Romaric Pascal (6a0d48a1) at 20 May 18:24

... and 1 more commit

Romaric Pascal (502c15ea) at 20 May 18:23

Separate issue created for element-required-ancestor: #307 (closed)

Romaric Pascal (cb71cef8) at 20 May 18:08

After giving a stab at fixing the issue for element-permitted-content, I think the fix for element-required-ancestor is different so I'll open a different issue for it shortly 😊

Romaric Pascal (185fa69e) at 20 May 18:01

Elements within a <template> tag are not children of the <template> according to the HTML specifications.

When checking if a node is a valid descendant of a ancestor, element-permitted-content now stops as soon as it encounters a <template> tag when going up the node's parent list. This means ancestors of the <template> tag are now rightfully ignored when deciding if a node is permitted as a descendant.

Fixes #305

Romaric Pascal (6daf7aad) at 20 May 17:48

Occured to me that the <template> element may also get in the way of other rules. Looks like element-required-ancestor errors with the following code when it shouldn't:

<dl href="">
</dl>
<template>
  <dt></dt>
  <dd></dd>
</template>

I'm not familiar with the code enough to see if it's one piece of work (make the <template> element work OK with the rules) or separate pieces of work for each rule so I'm just commenting on here.