<ol>/<li> behavior and shadow DOM #2432

domenic · 2017-03-13T16:50:40Z

Via https://bugs.chromium.org/p/chromium/issues/detail?id=700785. Given the code

```html
<!DOCTYPE html>
<script>
  customElements.define('my-list', class extends HTMLElement {
  constructor() {
    super();
    let shadowRoot = this.attachShadow({mode: 'open'});
    shadowRoot.innerHTML = `
      <ol><slot></slot></ol>`;
  }})
</script>
<my-list>
    <li>Thing
        <my-list>
            <li>another</li>
            <li>and another</li>
        </my-list>
    </li>
</my-list>

should the resulting list be nested or not? Currently Chrome treats it as

Thing
another
and another

But it seems like a reasonable author expectation for this to be

Thing
1. another
2. and another

This has something to do with flat trees vs. not and so on, but I'm not familiar with the details. @hayatoito @rniwa @kochi @smaug---- @annevk?

The current spec for the ol/li part of this is the definitions of list owner and ordinal value. I'm not sure how those would be updated. Currently they use the term "parent", "ancestor", "closest inclusive ancestor", and "tree order"; maybe they should be using more shadow DOM-related versions of those?

annevk · 2017-03-13T17:13:23Z

What if you replace <my-list> with <div> elements and leave shadow trees out of this?

domenic · 2017-03-13T17:16:09Z

In that case it's indeed 1-2-3. The question is should distributing the <li>s into a nested <ol>-in-a-shadow-tree change the situation.

annevk · 2017-03-13T17:32:37Z

Ah, I had missed the <ol>. I wonder if this makes the shadow tree observable to CSS, though I guess it is already in many cases?

Overall it seems reasonable to make this work though.

tomberek · 2017-03-13T21:22:43Z

Also created an issue here.

rniwa · 2017-03-14T04:10:39Z

There's a bit of issue with the markup itself. The HTML parser would automatically yank the second and the third li elements out of the outer li because nested li isn't allowed by the parser unless there is a special element between them.

See the section "A start tag whose tag name is 'li'"

I don't know how you'd fix this short of modifying the parser itself.

hayatoito · 2017-03-14T06:31:51Z

See also WICG/webcomponents#404. This issue is not specific to <ol><li>.

I don't think the current behavior of Blink is intentional one. I guess that we had implemented these without any clear idea or standards.

domenic · 2017-03-14T15:06:17Z

There's a bit of issue with the markup itself. ... I don't know how you'd fix this short of modifying the parser itself.

That's a good point. (Here's a quick repro that makes it easy to visually see: http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=4944 .) So in this example <my-list> has no <li> children at all to put into the slot. As @annevk said we'd need template-like parsing for custom elements for this to work.

Given that I am now less optimistic about fixing this, since we decided against such parsing in WICG/webcomponents#59 (which despite its title eventually extended to both slot and template).

I guess <template is="my-list"> could still work for this use case.

tomberek · 2017-03-14T22:01:54Z

@rniwa That seems like surprising behavior. Were did that historically come from?

Is it from the desire to allow <li> tags with no closing tag?

rniwa · 2017-03-14T22:32:51Z

Yes, using <li> start tag without a corresponding closing tag is extremely common on the Web.

I agree with @domenic that fixing this won't be useful / possible without modifying the parser. I'm open to the idea of adding special token or special parser behavior in a limited case to address that though since the HTML parser seems to be causing a lot of pains for custom element use cases.

tomberek · 2017-03-15T03:31:42Z

I'm interested in both sides:

Pragmatic - solve the problem with special behavior for custom elements.
Backwards incompatible - fix the wart in the standard

domenic · 2017-03-15T03:45:34Z

I don't think there's any wart in the standard here. Can you clarify what you're referring to?

tomberek · 2017-03-15T03:58:22Z

@domenic Of course. I was referring to usage of the <li> start tag without the corresponding </li> tag and the spec allowing for this. Adding more special tokens/behavior may solve some issues, but if backwards compatibility/inertia/2 decades of history was not a problem, I'd suspect a clean rewrite of the standard wouldn't behave this way.

domenic · 2017-03-15T04:00:19Z

Oh, no, that's a feature; we use it within most WHATWG specs in fact. The Google style guide even mandates it. Tag omission (not just <li>, but <p> and many others) is part of what makes HTML good and useful and more successful than XHTML!

We have no intention of ever removing or changing such a useful feature.

(Another example: the Google HTML style guide used to explicitly recommend it, and now doesn't do that but does give an example of best practices that omits end tags.)

tomberek · 2017-03-15T04:11:38Z

@domenic I can see why tag omission should be ok, but the rules for <li> seem to have been developed before custom elements existed. I don't know enough to know the right solution. I would be curious what the spec would look like with more development. (I'm not involved with HTML6 or anything, but I guess now I'm interested.)

domenic · 2017-03-15T04:12:46Z

Well, it would probably involve changes to custom element parsing, as has been discussed in WICG/webcomponents#59, WICG/webcomponents#113, and WICG/webcomponents#624.

annevk · 2017-03-15T07:37:05Z

@tomberek we don't do backwards incompatible changes. Breaking the web is not an option. (We also don't do versioning. The HTML Standard just keeps getting new features and you're participating in its development right here.)

tomberek · 2017-03-15T08:05:54Z

@annevk I'm still working my way through the spec, learning about how things are done. Thanks.

I agree with @domenic that fixing this won't be useful / possible without modifying the parser. I'm open to the idea of adding special token or special parser behavior in a limited case to address that though since the HTML parser seems to be causing a lot of pains for custom element use cases.

@rniwa Would a way ahead be to use the override target mentioned in https://html.spec.whatwg.org/#creating-and-inserting-nodes ?

rniwa · 2017-03-15T09:10:36Z

@rniwa Would a way ahead be to use the override target mentioned in https://html.spec.whatwg.org/#creating-and-inserting-nodes ?

The issue is more fundamental than that. The HTML parser needs to be modified for this to work, and a naive approach won't be backwards compatible.

tabatkins · 2017-03-15T18:37:52Z

I can see why tag omission should be ok, but the rules for <li> seem to have been developed before custom elements existed.

A little bit earlier, yes ^_^ - tag omission dates back to very early HTML, in the mid-90s, while custom elements are only a few years old, beginning around 2011 or so.

domenic · 2018-09-01T15:04:39Z

Closing as this isn't fixable without parser changes, which isn't worth it.

domenic added topic: rendering topic: shadow Relates to shadow trees (as defined in DOM) labels Mar 13, 2017

hayatoito mentioned this issue Mar 14, 2017

HTML parser: align custom elements with the template element WICG/webcomponents#630

Closed

domenic added the topic: parser label Mar 14, 2017

domenic closed this as completed Sep 1, 2018

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

<ol>/<li> behavior and shadow DOM #2432

<ol>/<li> behavior and shadow DOM #2432

domenic commented Mar 13, 2017

annevk commented Mar 13, 2017

domenic commented Mar 13, 2017

annevk commented Mar 13, 2017

tomberek commented Mar 13, 2017

rniwa commented Mar 14, 2017 •

edited

Loading

hayatoito commented Mar 14, 2017

domenic commented Mar 14, 2017

tomberek commented Mar 14, 2017 •

edited

Loading

rniwa commented Mar 14, 2017 •

edited

Loading

tomberek commented Mar 15, 2017

domenic commented Mar 15, 2017

tomberek commented Mar 15, 2017

domenic commented Mar 15, 2017 •

edited

Loading

tomberek commented Mar 15, 2017

domenic commented Mar 15, 2017

annevk commented Mar 15, 2017

tomberek commented Mar 15, 2017

rniwa commented Mar 15, 2017

tabatkins commented Mar 15, 2017

domenic commented Sep 1, 2018

<ol>/<li> behavior and shadow DOM #2432

<ol>/<li> behavior and shadow DOM #2432

Comments

domenic commented Mar 13, 2017

annevk commented Mar 13, 2017

domenic commented Mar 13, 2017

annevk commented Mar 13, 2017

tomberek commented Mar 13, 2017

rniwa commented Mar 14, 2017 • edited Loading

hayatoito commented Mar 14, 2017

domenic commented Mar 14, 2017

tomberek commented Mar 14, 2017 • edited Loading

rniwa commented Mar 14, 2017 • edited Loading

tomberek commented Mar 15, 2017

domenic commented Mar 15, 2017

tomberek commented Mar 15, 2017

domenic commented Mar 15, 2017 • edited Loading

tomberek commented Mar 15, 2017

domenic commented Mar 15, 2017

annevk commented Mar 15, 2017

tomberek commented Mar 15, 2017

rniwa commented Mar 15, 2017

tabatkins commented Mar 15, 2017

domenic commented Sep 1, 2018

rniwa commented Mar 14, 2017 •

edited

Loading

tomberek commented Mar 14, 2017 •

edited

Loading

rniwa commented Mar 14, 2017 •

edited

Loading

domenic commented Mar 15, 2017 •

edited

Loading