- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 28 Feb 2019 01:20:40 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `counter-increment initial value`. <details><summary>The full IRC log of that discussion</summary> <fantasai> Topic: counter-increment initial value<br> <emilio_> github: https://github.com/w3c/csswg-drafts/issues/3686<br> <fantasai> github: https://github.com/w3c/csswg-drafts/issues/3686<br> <emilio_> fantasai: so there's a plan to use lists use css counters for lists<br> <emilio_> fantasai: looks like Gecko is on the process of implementing it<br> <TabAtkins> Today: <ol><li>one<li style="display:block">two<li>three</ol> results in "1. one\ntwo\n2. three"<br> <fantasai> fantasai: They're blocked on an issue about the initial value of counter-increment<br> <heycam> emilio_: the issue is not that we need it to implement this behavior, but we need it to allow the author to say counter-style:none on a list<br> <fantasai> fantasai_: Basically by default we need to increment list-item<br> <heycam> s/counter-style/counter-increment/<br> <heycam> dbaron: and does that style go on the list item or the marker pseudo?<br> <heycam> emilio_: the list item<br> <heycam> florian: this is not just for markup lists, because if it was we can do it in the UA sheet, but it's also when you create list items through the display property<br> <heycam> emilio_: the computed value of counter-increment needs to depend on display<br> <heycam> ... it's not a huge issue<br> <heycam> ... we have this kind of relationship for fonts and other properties<br> <heycam> ... the issue is that the author specified value gets lost<br> <heycam> TabAtkins: sure<br> <heycam> dbaron: so auto would mean list item 1 if your display is list-item, and none for anything else?<br> <fremy> q+<br> <heycam> emilio_: yes<br> <heycam> ... and the computed value wouldn't include "auto"<br> <heycam> emilio_: otherwise you get into trouble with gCS, checking it against none or something<br> <heycam> fremy: what if on a list item currently you do counter-set: my-list-item 5<br> <xfq> ack fremy<br> <heycam> TabAtkins: counter-set or counter-increment?<br> <heycam> emilio_: if you set counter-increment to something else you will lose the auto increment<br> <heycam> ... Edge does something like this<br> <heycam> AmeliaBR: you have a todo list, and you're kepeing your own track of how many items in the list are completed or ont, don't want to muck up the existing list counters<br> <heycam> fantasai: we discussed something similar to this ~12 years ago<br> <heycam> ... from what I recall, the conclusion we ended up with was that the magic counter would be implied no matter what the value of the counter property was<br> <heycam> ... if you want to override that implied behavior, you could call it out explicitly<br> <heycam> ... none would not turn off increments for list-item<br> <heycam> ... neither would 0<br> <heycam> ... but 'list-item 0' would<br> <fremy> +1<br> <heycam> emilio_: ok<br> <dbaron> s/neither would 0/neither would 'foo 0'/<br> <heycam> ... then we don't need this, but we should change the spec to say that the only way you can reset list-item is this way<br> <heycam> TabAtkins: happy with that, then the spec doesn't have to disagree with implementations now<br> <TabAtkins> s/now/as much/<br> <heycam> Rossen: the issue about the initial value of counter-increment<br> <heycam> ... being something different from none<br> <heycam> emilio_: one annoying thing is that counter-increment is the only weirdo property that depends on display<br> <heycam> ... you can explain counter-set for <li value=foo> using attribute mapping<br> <heycam> ... if you define that to be magical and non-overridable, then it becomes more complicated to implement<br> <heycam> fantasai: you run into the same issue if people are using counters already and are clobbered<br> <heycam> emilio_: for li items inside an ol with the value attribute<br> <heycam> ... I'm fine restricting this solution to counter-increment<br> <heycam> ... or maybe counter-reset too?<br> <heycam> TabAtkins: we already need magic for these things because of reversed<br> <heycam> AmeliaBR: it sounds like in addition to having the list-item is always auto incremented unless explicitly told, we also need a way to say increment if displayed versus always increment<br> <heycam> emilio_: that is the magic that counter-increment needs for list-item<br> <heycam> ... we don't need that magic for counter-set or counter-reset for lists<br> <heycam> dbaron: there's one other thing that makes me uncomfrtable, but leads to an alterntaive<br> <heycam> ... right now if you say counter-increment: foo 1, foo 1; you increment the counter by 2<br> <heycam> fantasai: there's no comma<br> <heycam> dbaron: saying that if you say list-item at all anywhere then it overrides the implicit "list-item 1" feels weird to me<br> <heycam> ... another way to do it is that display:list-item implicitly have a "list-item 1" in there. but you can add "list-item -1" in there to undo that effect<br> <heycam> [general groans]<br> <TabAtkins> [collective groan]<br> <TabAtkins> everyone: ðŸ˜ðŸ˜ðŸ˜<br> <fantasai> emilio_: So you say display: list-item has a magic list-item 1 increment<br> <fantasai> emilio_: and you can specify another one to cancel it<br> <fantasai> dbaron: you say list-item -1<br> <heycam> fantasai: one of authors' goals is to expose counters to do interesting thing swith them<br> <heycam> ... I think this makes it very confusing<br> <heycam> AmeliaBR: if you hide a list item then the next one would jump down a number<br> <heycam> fantasai: I would rather it be an override<br> <heycam> dbaron: I don't understand the hiding thing<br> <heycam> ... it feels inconsistent that counter:foo 1 doesn't change it, but if you put list-item into that list that the other one disappears<br> <heycam> fremy: if you do a set and don't do the increment, it's wrong?<br> <heycam> ... if you have <li value=4> you do'nt increment<br> <heycam> ... it sets to that value<br> <heycam> dbaron: how you implement <li value> is another question<br> <AmeliaBR> if you have `counter-increment: list-item -1`, that wouldn't have the magical dependence on display. So now hidden elements would reduce your overall counter, wouldn't they?<br> <heycam> emilio_: the way the spec defines it is mapping the attribute to counter-set property<br> <heycam> ... and then to counter-increment: none too<br> <AmeliaBR> q+<br> <heycam> dbaron: if we change it this way, we have to chnage hte mapping of the value attribute to counter-increment: list-item 0<br> <heycam> ... to expliitly suppress the incrementing<br> <heycam> ... and then if the author sets some other counter, it would break their value attribute<br> <heycam> dbaron: if the UA sheet for <li value=5> counter-set: list-item 5; counter-increment: list-item 0; then the author sets counter-increment explicitly<br> <heycam> ... it would lose the 'list-item 0' counteraction<br> <heycam> fremy: does anybody use the value attribute?<br> <heycam> AmeliaBR: yes, commonly with pages of lists<br> <heycam> ack AmeliaBR<br> <heycam> AmeliaBR: has anyone thought for the issue of having the list-item counter depend on display, is that something we're ok with exposing to user counters as well?<br> <heycam> emilio_: no<br> <heycam> AmeliaBR: definitely a no?<br> <heycam> ... that only list-item has that?<br> <heycam> TabAtkins: we do have the case that counters only increment on things that have counters<br> <heycam> ... but that's different from what list-item wants to do, which is depend on display:list-item explicitly<br> <heycam> AmeliaBR: so regular counters turn off with display:none, but the list-item counter turns off for anything other than display:list-item<br> <heycam> TabAtkins: ye<br> <heycam> s/ye/yes<br> <TabAtkins> s/have counters/generate boxes/<br> <heycam> emilio_: so there are 2 proposals<br> <heycam> ... one is that list-item is magically appended to counter-increment for list items<br> <heycam> fantasai: unconditionally<br> <heycam> ... that's dbaron's proposal<br> <heycam> ... the alternative, the earlier discussed one, is that it's only added the the list-item counter is not mentioned in that list<br> <heycam> ... so if the author doesn't have to think about what the UA is doing<br> <heycam> s/if //<br> <heycam> fremy: I was thinking about dbaron's issue -- there is a way of extending this<br> <heycam> ... you could stop the magical behavior if list-item appears explicitly in any of the counter properties<br> <heycam> ... then you can map value="" into counter-set without worrying about counter-increment being clobbered by the author<br> <heycam> fantasai: I don't think you want to do that<br> <heycam> ... having property interactions like this makes it mor edifficult to implement<br> <heycam> ... we want authors to be able to manipulate the list-item counter in a straightforwad manner<br> <heycam> ... looking at other properties is more confusing<br> <heycam> ... the author wants to set the counter to something, or change hte increment, or both -- but if mentioning list-item in one changes how the other behaves, that's confusing<br> <heycam> fremy: <li value="5"> maps to counter-set: list-item 5; and the counter-increment won't use the implied list-item because it appears in counter-set<br> <heycam> fantasai: why wouldn't you have this behavior for other counters?<br> <dbaron> "Inheriting counters must be done before resetting counters, which must be done before setting counters, which must be done before incrementing counters, which must be done before using counters (for example, in the content property)."<br> <heycam> ... if it's useful we can do it for other counters<br> <heycam> emilio_: resets are applied before increments<br> <heycam> dbaron: reset, then sets, then increments<br> <heycam> emilio_: so the increment will always be applied unless you suppress it<br> <heycam> fremy: either you set the list-item value, and not do the automatica increment<br> <heycam> emilio_: if you do what dbaron says, you could map the li value to counter-set, then counter-increment: list-item -1<br> <heycam> fantasai: if we're cringing in there there will be a lot of cringing in the world<br> <fantasai> s/in there/in here/<br> <fremy> so counter-increment has "listitem 1" implied except if you "counter-set: listitem 5" or "counter-increment: listitem 0"<br> <heycam> TabAtkins: I suggest figuring out the technical issues in the GH issue itself<br> <heycam> dbaron: I think I'm OK with Elika's proposal<br> <heycam> ... mine has the disadvantage [...]<br> <heycam> AmeliaBR: I am voting for fremy's proposal<br> <heycam> Rossen: it sounds like the leading one for a resolution would be fantasai's<br> <heycam> dbaron: I will write the 3 alternatives in the issue<br> <heycam> emilio_: we could look at the code to understand the weirdness and report back<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3686#issuecomment-468097478 using your GitHub account
Received on Thursday, 28 February 2019 01:20:43 UTC