[css-values] Relaxing <custom-ident> restrictions when unambiguous

Hi,

CSS Values and Units currently defines:

http://dev.w3.org/csswg/css-values/#custom-idents
> Some properties accept arbitrary author-defined identifiers as a
> component value. This generic data type is denoted by <custom-ident>,
> and represents any valid CSS identifier that does not otherwise
> appear as a pre-defined keyword in that property's value definition.
> [...]
>
> The CSS-wide keywords are not valid <custom-ident>s. The ‘default’
> keyword is reserved and is also not a valid <custom-ident>s.

This is more restrictive than it needs to be. For example, in CSS Grid:

http://dev.w3.org/csswg/css-grid/#track-sizing
> grid-template-columns, grid-template-rows
> Value: none | <track-list> | subgrid <line-name-list>?
> <track-list>  = [ <line-names>? [ <track-size> | <repeat()> ] ]+
>                 <line-names>?
> <line-names>  = ( <custom-ident>* )

'initial' and 'subgrid' are not valid line names, even though the 
parentheses make parsing completely unambiguous.


So I’d like to relax these restrictions to only exclude keywords that 
can appear at the same "nesting level" as the <custom-ident>. 
Declarations, simple blocks and functions (as defined by CSS Syntax) all 
introduce a new nesting level for their value/content/arguments. 
CSS-wide keywords (and 'default', which seems reserved as a potential 
future CSS-wide keyword) are only disallowed at the "top-level" of a 
property value.

http://dev.w3.org/csswg/css-syntax/#parsing


This still leaves a restriction in some cases that would not actually be 
ambiguous, but "nesting level" is easier to define than full unambiguity 
and covers the most obvious cases.


For <line-names>, this essentially means that any identifier is a valid 
<custom-ident>.

-- 
Simon Sapin

Received on Tuesday, 4 March 2014 23:22:41 UTC