- From: Ting-Yu Lin <tlin@mozilla.com>
- Date: Fri, 29 Apr 2016 23:08:51 +0800
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- Cc: fantasai <fantasai.lists@inkedblade.net>, www-style list <www-style@w3.org>
- Message-ID: <CALa=iqty0_xNkBXf9n8S+FYLm5VD26+_qsvM3MPBRaAwmnzt3Q@mail.gmail.com>
On Thu, Apr 28, 2016 at 1:18 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote: > On Tue, Apr 26, 2016 at 11:45 PM, Ting-Yu Lin <tlin@mozilla.com> wrote: > > On Tue, Apr 26, 2016 at 4:16 AM, fantasai <fantasai.lists@inkedblade.net > > > > wrote: > >> On 04/21/2016 09:24 PM, Tab Atkins Jr. wrote: > >> Full alternate proposal: > >> > >> * 'display: list-item' does not magically set a 'list-item' > >> counter-increment; this is handled by the HTML UA style sheet > >> > >> * 'list-style-*' apply to ::marker, not to list item elements; > >> since they inherit setting them on the list item will continue > >> to work as expected > >> > >> This proposal has two advantages: > >> * avoids the creation of a universal ::marker element > >> * maintains application of 'list-style' properties to styling > >> markers, for which these properties are very useful and usable. > > > > I feel this proposal is easier to implement. For Firefox, we'll need to > > convert the built-in magic counter to use css counter and use the > > counter for <ol> in UA style sheet. > > This does have the potential for compat problems - if <ol> numbering > switches to being handled by a "counter-increment: list-item 1;" on > <li> in the UA stylesheet, then it will be overridden by author-level > 'counter-increment'. I suspect the compat impact is *low*, but it's > not zero. > > I definitely agree that it's *easier*, tho, and I'm happy with it if > we're willing to accept the chance of compat impact. > > I'm also fine with just doing the second part (which should have > *zero* impact) and leaving the counter-increment hack in HTML, tho > that's obviously less good. > Agree. Unless other implementations are willing to accept the risk of any compat issue, the safest approach is just doing the second part.
Received on Friday, 29 April 2016 15:09:39 UTC