- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 14 Aug 2019 16:58:42 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `Should automatic list-item increment adjust for ol[reversed]?`.
<details><summary>The full IRC log of that discussion</summary>
<dael> Topic: Should automatic list-item increment adjust for ol[reversed]?<br>
<dael> github: https://github.com/w3c/csswg-drafts/issues/4181<br>
<dael> TabAtkins: If we can achieve through UA stylesheet or do magic. Magic to host language or in css<br>
<dael> TabAtkins: emilio points out [missed]<br>
<dbaron> q+<br>
<dael> fantasai: We have normal lists, they're great. We have reversed lists where increment is -1. Where you start is sept. Each li decrements counter needs to be implement. Only magic is that it's incremented by 1 on list item box<br>
<fantasai> ol[reversed] > li { counter-increment: list-item -1; }<br>
<dael> fantasai: Put in spec you can do on UA stylesheet. Works in general easy case. HTML spec includes any box with display of list-item in the numbering and excluses non-list-items. If you put a div in the li and give that a display: list-item it increments. THe list relies on the CSS<br>
<dael> fantasai: You can't reflect the current behavior. I can try and share a test case<br>
<TabAtkins> aka the [reversed] behavior is *literally* just "do normal list item numbering, then reverse all the numbers"<br>
<dael> fantasai: 3 things we can do. 1) use UA stylesheet and get impl to do something different that doesn't account for display value of boxes. 2) have magic and host lang can change magic. 3) create css property that says what magic increment is<br>
<fantasai> Behavior of li counting in HTML https://html.spec.whatwg.org/multipage/grouping-content.html#the-li-element<br>
<dael> dbaron: I think there are a bunch of edge cases that suggest modeling this as a decrement is wrong approach. 2 ways to model. starting value is magic, items decremenet, counter goes forward. Other is counter counts from end to beginning. This is different results at times, like if you change counter in the middle<br>
<fantasai> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Col%20reversed%3E%0A%3Cli%20style%3D%22border%3A%20solid%22%3E%20x%3Cdiv%20style%3D%22display%3A%20list-item%22%3ETest%3C%2Fdiv%3E%0A%3Cli%3E%20y%0A%3Cli%3E%20z%0A%3C%2Fol%3E%0A<br>
<dael> dbaron: Tend to think modeling this as magic to get the beginning and then decrements will get wrong result in a bunch of cases<br>
<dael> TabAtkins: You think counting backwards and interacting with counter-set is good?<br>
<dael> dbaron: I'm looking at browser behavior and actual behavior of value attribute with reverse is not sensible or interop<br>
<dael> dbaron: Maybe value is already broken and other way is right<br>
<dael> TabAtkins: Something odd in FF. FF and Chrome agree value effects following things and not proceeding. Differences in what number the very first item starts in. They agree it's count forward<br>
<dael> dbaron: Maybe stuck with wrong model<br>
<dael> TabAtkins: Both models have arguments. Fine with either<br>
<dael> fantasai: Did run a test with decrement as -2 and it starts counting into negative numbers. Start number was no adjusted to account for that<br>
<fantasai> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cstyle%3Eli%20%7B%20counter-increment%3A%20list-item%20-2%3B%20%7D%3C%2Fstyle%3E%0A%3Col%20reversed%3E%0A%3Cli%20style%3D%22border%3A%20solid%22%3E%20x%3Cdiv%20style%3D%22display%3A%20list-item%22%3ETest%3C%2Fdiv%3E%0A%3Cli%3E%20y%0A%3Cli%3E%20z%0A%3C%2Fol%3E%0A<br>
<TabAtkins> http://software.hixie.ch/utilities/js/live-dom-viewer/saved/7121<br>
<TabAtkins> Dunno why Firefox starts numbering at 7 even tho there are only six items.<br>
<dael> Rossen_: From the 3 choices at the beginning seems like we're getting to none of them?<br>
<dael> TabAtkins: Aside from that my test shows a weird start number, browsers seem consistent in how they treat things<br>
<dael> TabAtkins: Figure out value of last item that would incremement, use that as the first value. Figure out magic value where if nothing screws with numbering gets you to 1 and then start at that ind do minus 1<br>
<dael> TabAtkins: I'm on side of UA magic so there's interop I don't believe css needs to control on it's own.<br>
<dael> dbaron: html editors might be unhappy. html editors seem unhappy that css claims their stylesheets are doing wrong thing<br>
<dael> TabAtkins: [missed] reverse engineering at the time and we're saying do this with css now. Seeing you got no bugs I think we're fine and we can do this<br>
<dael> fantasai: Still not clear on how reverse is supposed to work.<br>
<dael> fantasai: Would liek to get updated draft published b/c cleaned up counters section substanitally. WE should publish and mark reverse lists as an open issue.<br>
<dael> fantasai: Should we publish draft with previous state or should we publish with the concept of the magic increment? SHould leave issue open, but what to publish with<br>
<dael> fantasai: Inclination is publish no change from previous b/c that's clear we have not solved and update later after we conclude<br>
<dael> Rossen_: Do you want to discuss next before publish?<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4181#issuecomment-521330256 using your GitHub account
Received on Wednesday, 14 August 2019 16:58:44 UTC