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

On Wed, Apr 30, 2014 at 4:07 AM, Brad Kemper <brad.kemper@gmail.com> wrote:
>
>> 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'.

Maybe we can recommend authors to add underline in their custom-idents
to avoid collisions, since keywords seem to never include an
underline. However, I'd prefer a new syntax like backquote to quote
the custom-idents.

There is another potential problem I am aware of is that, what should
happen if one day we may support more than one type of custom-ident in
one property? For example, if one day we decide to make
timing-function a custom-ident as well so that author could use
at-rules to define more complex ones, how can we distinguish
custom-ident for different purpose? Whatever, that is problem in the
future, so we may not need to worry a lot about it now. Same with this
problem.

- Xidorn

Received on Tuesday, 29 April 2014 23:44:16 UTC