W3C home > Mailing lists > Public > www-style@w3.org > April 2016

Re: [css-lists][html] <summary> and ::marker

From: Ting-Yu Lin <tlin@mozilla.com>
Date: Fri, 29 Apr 2016 23:08:51 +0800
Message-ID: <CALa=iqty0_xNkBXf9n8S+FYLm5VD26+_qsvM3MPBRaAwmnzt3Q@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: fantasai <fantasai.lists@inkedblade.net>, www-style list <www-style@w3.org>
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

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:02 UTC