-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Should LI under OL respect style containment. #4808
Comments
I mean, that's technically not even valid code. List elements can only have list items as direct descendants. |
That's not relevant here. HTML validity aside, it still produces a document tree as one would expect, and CSS applies to that regardless. |
I think the most important fact is that in fact the HTML @vmpstr provided does currently generate a list that looks like:
in Chrome and Firefox. Changing the HTML parser to not do that would break content. If the HTML spec says otherwise, then it would need to be adjusted. |
Proposal: change the algorithm for determining the list owner [1] of a list item as follows: Add a new sentence: The ordinal value producing ancestor of an element is the closest ancestor of the element which is an ol, ul, menu, or has a computed value of 'contain' which contains 'style'. Change step 3 to: "If the element has an ol, ul, or menu ancestor, set ancestor to the ordinal value producing ancestor." |
I think that's generally what I was thinking too. One problem is that under On the other hand (and to the first comment's point), the first paragraph under https://html.spec.whatwg.org/#the-li-element says
If it has no defined list-related relationship to anything, then strictly speaking any behavior is spec compliant. |
Only if there is currently content depending on style containment of |
Oh I was just referring to the point about
|
I don't have too much expertise here, but in general I support tweaking the definition of how ordinal values are determined in weird cases in order to support better performance possibilities and harmonize with CSS concepts like I'll CC @emilio and @matspalmgreen because I believe they were involved in Gecko's recent work on list counters, and I still find the spec/implementation situation confusing: 1, 2, 3. Given that confusion, I'm not sure how to approach this from a spec editor perspective, but I welcome suggestions. |
Ah, you were agreeing with me, I see. ^_^ |
Is the list-owner concept (and all the ordinal value stuff) necessary at all if you use CSS counters? If html deferred to the CSS lists in this sense, then style containment and co would automatically apply. That way the "list owner" concept is implemented is just via I think spec-wise we should make HTML point to CSS lists, and move https://drafts.csswg.org/css-lists/#ua-stylesheet to HTML, fixed to account for |
That's the confusion I refer to. It seems some people (unsure if Gecko in particular, or CSSWG in general) want to make such a change. So I'm not sure how to proceed with updating the HTML spec in light of such conflict. Note that the example appendix UA stylesheet does not cover browsers' behaviors, e.g. as noted in https://groups.google.com/d/msg/mozilla.dev.platform/5V37Xg997Mg/Ei-2XJNJAwAJ by @MatsPalmgren, or the explicit |
Small hiccup with implementing this as counters is that because of counter scoping, I think each ol would have to have its own counter. (It also needs counter-set to mimic li's value attribute, but that's a working draft right now so presumably we can use it). Consider: <!doctype html>
<style>
.li:before {
content: counter(c) ".";
counter-increment: c;
}
.ol {
counter-reset: c;
}
.value5:before {
counter-set: c 5;
}
.value10:before {
counter-set: c 10;
}
</style>
<p>OL and LI</p>
<ol>
<li></li>
<li value=5></li>
<ol>
<li></li>
<li value=10></li>
<li></li>
</ol>
<li></li>
<li></li>
</ol>
<p>DIVs</p>
<div class=ol>
<div class=li></div>
<div class="li value5"></div>
<div class=ol>
<div class=li></div>
<div class="li value10"></div>
<div class=li></div>
</div>
<div class=li></div>
<div class=li></div>
</div> In Chrome (which doesn't have counter-set implemented), OL and LIs produces
which I think is correct. DIVs produces (indentation added by me)
First, obviously it ignores the counter-set, but also "4." is referencing a counter "c" which is defined by the outer .ol, but was reset by the inner .ol. In Firefox, LIs and DIVs produce the same result, but I don't think the LI version is correct:
The 12 and 13 are being affected by the inner OL it seems, for likely the same reason as counters I might be missing some trick, but I couldn't figure this out with just a single counter. Overall, I think the spirit of using the counters is correct, but we need to be careful with the details |
That's correct behavior, due to your weird markup. Note that the "inner" If you correctly nest the inner |
I'm open to whatever. To the extent that HTML's lists need magic, I'm happy to spec magic, or allow HTML to spec magic. I'd prefer that we get as far as possible with CSS functionality, just because it makes things simpler. Firefox has been using actual CSS for its counters for a while, and apparently hasn't seen any complaints. That suggests we can do away with a lot of magic; currently we're only left with the starting value of a |
Hmm, it's a bit disappointing that counter and non-counter implementations of ol/li would differ on the output of the markup that I have. TBH, I still fail to see how "12." is a correct value in the current li's spec. That being said, since it's incorrect markup, I'm guessing all bets are off. |
Is it that surprising that an impl using totally different tech would produce different results?
No, again, it being incorrect markup is irrelevant. It's a perfectly reasonable DOM tree; the only thing that it being invalid HTML does it mean that some of your naive (but normally reasonable!) assumptions about how counters work don't apply. In particular:
If you'd written valid HTML and nested the second |
Counter behavior is a bit complex, but it follows from attempting to make two use-cases work:
|
In a CSS rendering engine, the ordinal value is the built-in CSS Containment defines how the The one HTML thing I'm aware of that has an "action-at-a-distance" effect is (FYI, |
(And in general I'm skeptic about implementing it allowing any sound optimization, see w3c/csswg-drafts#3280, so should we implement it it'd be purely for the rendering effect / isolation, I think, unlike the other kinds of containment which do add optimization opportunities) |
Map `<ol start reversed>` and `<li value>` to `counter-reset` and `counter-set` properties as presentational hints. For reversed lists, use the CSS `reversed()` function added in w3c/csswg-drafts#6096. Tests: web-platform-tests/wpt#28040 & web-platform-tests/wpt#28453. Helps with #4808. Co-authored-by: Simon Pieters <zcorpan@gmail.com>
With this change #4816 -- this issue should be fully dealt with by CSS Containment and CSS Counters. Including reversed lists. Correct, @vmpstr @MatsPalmgren ? |
Currently, with CSS counters, elements that are underneath a "contain: style" element do not consider counter values above such elements. In other words the counters are contained to the subtree of the "contain: style" element.
This, however, currently does not apply to LIs under OL, since they are not using CSS counters and are defined (as far as I can tell) in terms of DOM structure.
Should those also respect style containment and not consider LI counts outside of a style contained elements?
For instance,
This is currently
If style containment is respected, then presumably these counts would be
One issue is that the LIs under a style contained elements should still be aware that they are descendants of an OL element, as opposed a UL element, which peeks outside of the style contained element, but I think that's acceptable.
Without containment considerations, it may be difficult for UAs to skip some optimizations that would otherwise not be user visible. As an example, the layout or maybe even DOM manipulations of an offscreen element, with "sufficient" containment, can normally be skipped if the UA can prove that this work will not affect the visual output of the page. If LIs are present though under an OL element, we can't satisfy this guarantee since the counts outside of the contained elements consider counts inside the contained element, so work can't be skipped.
/cc @annevk @chrishtr @domenic
The text was updated successfully, but these errors were encountered: