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

> 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