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

Re: [css-counter-styles] position keywords in list-style

From: Brad Kemper <brad.kemper@gmail.com>
Date: Tue, 29 Apr 2014 11:07:20 -0700
Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, "L. David Baron" <dbaron@dbaron.org>, Simon Sapin <simon.sapin@exyr.org>, www-style list <www-style@w3.org>
Message-Id: <A741F361-50FE-4B2B-B4E4-0A3BF08F5984@gmail.com>
To: Xidorn Quan <quanxunzhen@gmail.com>

> On Apr 29, 2014, at 6:01 AM, Xidorn Quan <quanxunzhen@gmail.com> wrote:
>> On Tue, Apr 15, 2014 at 8:51 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>>> On Thu, Apr 3, 2014 at 3:58 PM, Xidorn Quan <quanxunzhen@gmail.com> wrote:
>>> So how can we keep the compatibility? It seems to be nearly impossible now
>>> if new keyword could be introduced.
>> So this still isn't resolved.  As currently written, between Counter
>> Styles and V&U, a <counter-style-name> is allowed to be "inside", but
>> then you can't specify it in 'list-style' due to the collision.
>> David suggests that we could allow it, if we adopt rules similar to
>> 'animation', where the 'animation-name' is taken as the first
>> unrecognized keyword, or the last keyword if they're all recognized.
>> I and Xidorn both think this is probably harmful to spread further, as
>> it's hard to serialize correctly, and is somewhat hostile to future
>> expansion.
>> A third opinion comes from fantasai, which is that
>> <counter-style-name> is assumed to often show up in a 'list-style'
>> context, and so it should exclude the 'list-style' keywords as well at
>> all times.  This also has compat problems, as it means that any
>> keywords we introduce to any of list-style's longhands become
>> disallowed, which could damage existing content.  I think this also
>> shouldn't be used.
>> Thoughts?
> I found that both Gecko and WebKit/Blink have been using the behavior
> suggested by David on animation. Though I think this behavior is
> harmful, all three methods mentioned here are in fact equally harmful
> for list-style. Whatever rule is applied, there will be a compat
> problem when we want to introduce any keyword to the longhands,
> because we have accepted position keywords to be put as the first
> subvalue. Hence, for list-style, I think it might be acceptable to
> follow the behavior UAs currently use to parse animation property, and
> leave the potential problem there until we actually want to introduce
> new keywords in the future.
> - Xidorn

We could add a note to the spec to encourage authors to namespace their custom-idents to avoid collisions with future keywords. For instance, 'bkstart' may be less likely to create a collision with a future keyword than just 'start'. 
Received on Tuesday, 29 April 2014 18:07:51 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:51:23 UTC