[css3-gcpm] [css3-values] attr() and target-counter()

So last month Tab and I went through all our functional notation and
suggested some principles for designing their syntax. As part of that
we recommended some changes to proposed features, one of them the
extended attr() syntax in CSS3 Values and Units:

>   Before
>     ''attr(<name>[, <type> [, <default>]?]?)''
>   After
>     ''attr(<name> <type>? [, <default>]?)''
>   Rationale
>     The comma between the name and type was not necessary for
>     disambiguation or grouping.  Removing it more closely represents
>     the association between the name and the type, and lets the comma
>     operate in its traditional role as a fallback operator (Principle
>     2).  Finally, it lets the author omit type but specify default,
>     which was not possible in the old grammar due to ambiguity.

[ Another point brought up later in favor of this change: due to commas
being valid in CSS property values, a parser would have to read from
the comma after the type straight through to the closing parenthesis
in order  to handle all possible fallback arguments. Thus if another
argument to attr() was needed in the future, it could not be added as
a fourth comma-separated argument. But it could be added as a space-
separated addition to the first argument. ]

The most significant use of the extended attr() syntax so far seems
to be the target-counter() syntax proposed in GCPM:

   target-counter(attr(href, url), ...)

This syntax is a little awkward to write, on account of the nested
functional notation. The extra 'url' parameter to attr() also isn't
adding anything--target-counter() needs to accept a URL, it's clear.

So I'd like to propose just allowing target-counter to take the
attribute name directly.

   target-counter(href, ...)

This would simplify the syntax quite a bit for authors, and if we
want literal URLs, the url() function is easily distinguishable
from an attribute name: they parse as different tokens.

Also, if we take the proposed fix to attr() syntax in CSS3 Values
and Units and this change together, a parser required to handle any
existing target-counter() content out there could throw a switch into
the old syntax for attr(), since it would know that attr() inside
target-counter() uses the old attr() syntax.

Thoughts?

~fantasai

Received on Thursday, 16 February 2012 16:05:35 UTC