Re: Intent to implement and ship: built-in CSS counter 'list-item'
On 3/27/19 5:19 AM, L. David Baron wrote: On Wednesday 2019-03-27 01:42 +0100, Mats Palmgren wrote: FYI, the CSS Lists spec isn't very well maintained, sadly, so it's not up-to-date with recent resolutions. So, some of the finer details in there might be wrong, but I think most of it regarding counters is correct. If you've been implementing based off of resolutions that aren't in the spec, it's probably worth submitting PRs to the spec so that other future implementors are aware of those resolutions and you don't have to later go and undo the effects of those resolutions for compatibility. Since I just ran across this thread, current status of the spec is a lot better: https://lists.w3.org/Archives/Public/www-style/2019Apr/0024.html ~fantasai ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: built-in CSS counter 'list-item'
On Wednesday 2019-03-27 01:42 +0100, Mats Palmgren wrote: > FYI, the CSS Lists spec isn't very well maintained, sadly, > so it's not up-to-date with recent resolutions. So, some > of the finer details in there might be wrong, but I think > most of it regarding counters is correct. If you've been implementing based off of resolutions that aren't in the spec, it's probably worth submitting PRs to the spec so that other future implementors are aware of those resolutions and you don't have to later go and undo the effects of those resolutions for compatibility. -David -- π L. David Baron http://dbaron.org/ π π’ Mozilla https://www.mozilla.org/ π Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914) signature.asc Description: PGP signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: built-in CSS counter 'list-item'
On 3/27/19 12:30 AM, Domenic Denicola wrote: (On-list this time) However, the actual semantics for how list items work are exclusively defined by CSS ([css-lists], [css-pseudo]). The above mentioned HTML elements/attributes simply maps to the relevant CSS properties, using a built-in 'list-item' counter. Where does [css-lists] and [css-pseudo] define this? From CSS Lists, Introduction: https://drafts.csswg.org/css-lists-3/#intro "It also defines _counters_, which are special numerical objects often used to generate the default contents of markers." where _counters_ links to: https://drafts.csswg.org/css-lists-3/#counter Pretty much all of CSS Lists is about how these generic counters work. The built-in 'list-item' is such a counter. The only thing special about it is that it's automatically incremented for any element that has 'display:list-item'. https://drafts.csswg.org/css-lists-3/#declaring-a-list-item Other than that, it works exactly like a counter an author can introduce themselves. FYI, the CSS Lists spec isn't very well maintained, sadly, so it's not up-to-date with recent resolutions. So, some of the finer details in there might be wrong, but I think most of it regarding counters is correct. /Mats ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: built-in CSS counter 'list-item'
(On-list this time) > However, the actual semantics for how list items work are exclusively defined > by CSS ([css-lists], [css-pseudo]). > The above mentioned HTML elements/attributes simply maps to the relevant CSS > properties, using a built-in 'list-item' counter. Where does [css-lists] and [css-pseudo] define this? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: built-in CSS counter 'list-item'
On 3/25/19 6:21 AM, Domenic Denicola wrote: > The spec at https://drafts.csswg.org/css-lists/#declaring-a-list-item > seems to contradict that hard-fought consensus. It seems like a > regression to implement list item numbering according to that spec, > instead of according to HTML. As others have clarified, there are zero regressions from these changes (that we know of) and **a lot** of bugs fixed. The compatibility with other UAs and web content is now greatly improved. You seem to think that HTML is the authoritative specification for how list items work. That's only partly true. HTML specifies the part where certain elements opens a list item scope (ol/ul/menu), have a default 'display:list-item' value (li) and that sets the value of the counter, etc. However, the actual semantics for how list items work are exclusively defined by CSS ([css-lists], [css-pseudo]). The above mentioned HTML elements/attributes simply maps to the relevant CSS properties, using a built-in 'list-item' counter. Most importantly: this counter behaves **exactly** the same as any other CSS counter would for a given set of style values. We're simply not going to add a parallel "HTML counter" implementation that is incompatible with CSS counters just to implement these HTML elements (in fact, we've just removed the special counting we had). Mapping HTML lists to CSS has **major** benefits for authors and implementors alike. I'd be happy to elaborate on that if you wish. > This omits all the details at [...], e.g. reversed="", the collection > of owned list items, value="" attribute parsing, etc. is mapped to the 'counter-set' property. is the one thing that isn't yet defined fully in a CSS spec. We have implemented it using an internal (not exposed to web content) inherited CSS property, and then map the attribute to that. So, what our new implementation proves is that all of HTML's funky list items can be fully and exclusively implemented using CSS concepts. Well, we hope so anyway. We'll know after it hits the release channel :-) > An important thing to test here is the result of getComputedStyle on > list items as a result of this change. HTML specifies that ordinal > values are displayed on list items without any counter CSS properties > involved Emilio filed https://github.com/w3c/csswg-drafts/issues/3769 about this. I disagree that getComputedStyle should lie about the actual value of any of the counter-* properties. I see no benefit to anyone in doing that and I also don't think it's needed for web-compatibility. Regards, Mats [css-lists] https://drafts.csswg.org/css-lists/ [css-pseudo] https://drafts.csswg.org/css-pseudo/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: built-in CSS counter 'list-item'
Note that the spec does not yet reflect the decisions made at the last F2F, or the subsequent decisions from Issues. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: built-in CSS counter 'list-item'
On Tuesday 2019-03-26 14:25 -0700, Domenic Denicola wrote: > It's great to hear that this isn't a regression in the way I expected. I > think I was thrown off by the phrasing of the OP, which implied to me a > switch from following the HTML spec to following the CSS lists spec. As I > noted, the CSS lists spec contradicts the HTML spec, e.g. disallowing > reversed="" from affecting the counter values. But it sounds like you're > ignoring that part of the CSS spec, and instead incrementing (setting?) the > list-item counter according to the HTML spec's rules. I don't think there's an actual contradiction. The spec describes the default behavior of list items, but then specifies that other things happen through the values of CSS properties that are in the UA stylesheet. This is the normal way that things evolve when CSS adds a CSS explanation for an existing feature and part of that CSS explanation lives in the UA stylesheet. This has been under discussion in the CSS working group for... over a decade now, so I wouldn't say that there hasn't been any cross-browser discussion of it. That said, the specs could certainly coordinate better. -David -- π L. David Baron http://dbaron.org/ π π’ Mozilla https://www.mozilla.org/ π Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914) signature.asc Description: PGP signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: built-in CSS counter 'list-item'
It's great to hear that this isn't a regression in the way I expected. I think I was thrown off by the phrasing of the OP, which implied to me a switch from following the HTML spec to following the CSS lists spec. As I noted, the CSS lists spec contradicts the HTML spec, e.g. disallowing reversed="" from affecting the counter values. But it sounds like you're ignoring that part of the CSS spec, and instead incrementing (setting?) the list-item counter according to the HTML spec's rules. I remain a bit concerned that the behavior you're implementing here is not reflected in any spec at all. This would not matter if this were just internal implementation refactoring. However, it's observable to the web via getComputedStyle(). Note that the complete list of allowed-per-spec default style changes for li elements is given by https://html.spec.whatwg.org/multipage/rendering.html#lists , and per https://github.com/web-platform-tests/wpt/issues/5625 the CSSWG declared the intent to test these requirements via web platform tests. Introducing new observable behavior with no spec backing, or even opening an issue on the relevant specs, seems bad. Reading between the lines, it seems to be Mozilla's position that HTML should change to add some CSS rule to the user agent stylesheet which modifies counter-set, but not counter-increment. If so it'd be much appreciated if folks would open an issue on whatwg/html for public standards discussion and work toward cross-browser consensus. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: built-in CSS counter 'list-item'
On Sunday 2019-03-24 22:21 -0700, Domenic Denicola wrote: > Some time ago we spent some effort documenting a cross-browser > mostly-interoperable behavior for list-item-like behaviors, in > https://github.com/whatwg/html/pull/2002 and linked threads. The result is > the spec at > https://html.spec.whatwg.org/multipage/grouping-content.html#list-owner and > the tests at > https://github.com/web-platform-tests/wpt/tree/master/html/semantics/grouping-content/the-ol-element > . > > The spec at https://drafts.csswg.org/css-lists/#declaring-a-list-item seems > to contradict that hard-fought consensus. It states simply that > > > Additionally, list items automatically increment the special list-item > > counter. Unless the counter-increment property manually specifies a > > different increment for the list-item counter, it must be incremented by 1 > > on every list item, at the same time that counters are normally incremented. > > This omits all the details at > https://html.spec.whatwg.org/multipage/grouping-content.html#ordinal-value , > e.g. reversed="", the collection of owned list items, value="" attribute > parsing, etc. > > It seems like a regression to implement list item numbering according to that > spec, instead of according to HTML. I wouldn't expect any of these features or tests to regress as a result of this. (That said, I think it may be worth considering behavior changes to edge cases, if such changes are needed, particularly where browsers aren't currently interoperable, in order to move towards the idea of list numbering being implemented with CSS counters underneath.) I'd note that the sample style sheet for HTML in CSS Lists does attempt to describe what is needed for HTML: https://drafts.csswg.org/css-lists/#ua-stylesheet although it admits that the CSS counter model on its own can't describe reversed. The web-platform-test test expectation changes in https://hg.mozilla.org/mozilla-central/rev/ae4e4daebdc4 are (except for a single test) in the direction of improvement. -David -- π L. David Baron http://dbaron.org/ π π’ Mozilla https://www.mozilla.org/ π Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914) signature.asc Description: PGP signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: built-in CSS counter 'list-item'
On 25/03/2019 06:21, Domenic Denicola wrote: > Some time ago we spent some effort documenting a cross-browser > mostly-interoperable behavior for list-item-like behaviors, in > https://github.com/whatwg/html/pull/2002 and linked threads. The result is > the spec at > https://html.spec.whatwg.org/multipage/grouping-content.html#list-owner and > the tests at > https://github.com/web-platform-tests/wpt/tree/master/html/semantics/grouping-content/the-ol-element > . > > The spec at https://drafts.csswg.org/css-lists/#declaring-a-list-item seems > to contradict that hard-fought consensus. It states simply that > >> Additionally, list items automatically increment the special list-item >> counter. Unless the counter-increment property manually specifies a >> different increment for the list-item counter, it must be incremented by 1 >> on every list item, at the same time that counters are normally incremented. > > This omits all the details at > https://html.spec.whatwg.org/multipage/grouping-content.html#ordinal-value , > e.g. reversed="", the collection of owned list items, value="" attribute > parsing, etc. > > It seems like a regression to implement list item numbering according to that > spec, instead of according to HTML. FWIW, the check-in fixing this[1] fixed multiple WPT tests related to this, and regressed none, see the .ini file changes. >> web-platform-tests: > > An important thing to test here is the result of getComputedStyle on list > items as a result of this change. HTML specifies that ordinal values are > displayed on list items without any counter CSS properties involved, and from > what I can tell, https://drafts.csswg.org/css-lists/ does not change that. > (The appendix at https://drafts.csswg.org/css-lists/#ua-stylesheet is > informative, not normative.) So, including tests that getComputedStyle > continues to return no results for the counter-related properties or > pseudo-elements seems important to maintaining interop on this front. I agree that testing this seems useful, but I disagree on it being ignored in computed style serialization of all counter-* properties, that feels rather magical. I agree that the counter-increment should be ignored in computed style serialization (I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1539171 to fix that). Note that attribute parsing hasn't changed, and it's just a mapped attribute mapping to counter-set. I don't think this conflicts with the HTML spec, and I think that we should keep serializing counter-set in getComputedStyle. I don't think there are interop concerns for counter-set since counter-set is not implemented in other engines, but attribute mapping is straight-forward and works similarly everywhere. -- Emilio [1]: https://hg.mozilla.org/mozilla-central/rev/ae4e4daebdc4 > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: built-in CSS counter 'list-item'
On Sunday, March 24, 2019 at 10:21:10 PM UTC-7, Domenic Denicola wrote: > the tests at > https://github.com/web-platform-tests/wpt/tree/master/html/semantics/grouping-content/the-ol-element correction, https://github.com/web-platform-tests/wpt/tree/master/html/semantics/grouping-content/the-li-element is where most of the tests landed. The pull request was https://github.com/web-platform-tests/wpt/pull/4169 . ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: built-in CSS counter 'list-item'
Some time ago we spent some effort documenting a cross-browser mostly-interoperable behavior for list-item-like behaviors, in https://github.com/whatwg/html/pull/2002 and linked threads. The result is the spec at https://html.spec.whatwg.org/multipage/grouping-content.html#list-owner and the tests at https://github.com/web-platform-tests/wpt/tree/master/html/semantics/grouping-content/the-ol-element . The spec at https://drafts.csswg.org/css-lists/#declaring-a-list-item seems to contradict that hard-fought consensus. It states simply that > Additionally, list items automatically increment the special list-item > counter. Unless the counter-increment property manually specifies a different > increment for the list-item counter, it must be incremented by 1 on every > list item, at the same time that counters are normally incremented. This omits all the details at https://html.spec.whatwg.org/multipage/grouping-content.html#ordinal-value , e.g. reversed="", the collection of owned list items, value="" attribute parsing, etc. It seems like a regression to implement list item numbering according to that spec, instead of according to HTML. > web-platform-tests: An important thing to test here is the result of getComputedStyle on list items as a result of this change. HTML specifies that ordinal values are displayed on list items without any counter CSS properties involved, and from what I can tell, https://drafts.csswg.org/css-lists/ does not change that. (The appendix at https://drafts.csswg.org/css-lists/#ua-stylesheet is informative, not normative.) So, including tests that getComputedStyle continues to return no results for the counter-related properties or pseudo-elements seems important to maintaining interop on this front. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
