- From: Daniel Glazman <daniel.glazman@disruptive-innovations.com>
- Date: Sun, 24 Apr 2016 16:32:08 +0200
- To: www-style@w3.org
On 21/04/2016 20:24, Tab Atkins Jr. wrote:
> * display:list-item also automatically increments the list-item
> counter, which is used by HTML's <ol> element. This meant that using
> a <details> inside of an <ol> would cause the next <li> to jump ahead
> by 2.
Excellent catch.
> * <summary> uses list-style-position:inside, and list-style-*
> properties inherit, so if you use an HTML list inside of a <summary>,
> its markers will be "inside" position as well. (HTML purposely
> doesn't set list-style-position, so that if you make an outer list
> "inside" the nested lists will be too. By default, tho, they use the
> initial "outside" value, and that's the expected way for them to
> display.)
Right. I said list-style-position was an issue.
> Both of these have fixes - the first by setting "summary {
> counter-increment: list-item 0; }", the second by setting "summary > *
> { list-style-position: initial; }" - but they still make things
> messier than they have to.
The two issues above prove using 'display: list-item' was indeed
a hack.
> I propose a simple solution: rather than having "display:list-item"
> cause the ::marker to be generated, as is specced today, we make
> ::marker *always* exist, identical to ::before. For normal elements
> you have to explicitly give it a 'content' value, just like ::before.
> "display:list-item" then just makes the ::marker pay attention to the
> list-style-* properties.
THAT, I can live with. Much, much better. As Brad said, I would
certainly prefer a way to deal with multiple ::before and ::after
pseudos but that's a workable compromise to me.
> fantasai offers an alternate proposal: leave <summary> as is, leave
> the hack for the first problem, but make the list-style-* properties
> actually only apply to the ::marker pseudo, rather than to list items.
> Inheritance ensures that we maintain today's behavior, but HTML can
> then set list-style-position:inside directly on the summary::marker,
> and avoid the second problem entirely.
This paragraph contains the word "hack", it perfectly represents
that proposal and that's enough for me to say no. The other proposal
above is way cleaner.
</Daniel>
Received on Sunday, 24 April 2016 14:32:34 UTC