- From: Håkon Wium Lie <howcome@opera.com>
- Date: Tue, 15 Nov 2011 01:16:02 +0100
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- Cc: www-style list <www-style@w3.org>
Tab wrote: > In the definitions for 'bookmark-label' and 'bookmark-target', the > property definition line explicitly talks about the attr() function. > There's no need to do so - attr() resolves to a particular type based > on its type argument. Right, we no longer need to do what CSS 2.1 does -- e.g., here: http://www.w3.org/TR/CSS2/generate.html#propdef-content A relief. I've removed it from the editor's draft: > So bookmark-label, for example, only needs to > say that it accepts <string>, and then any use of "attr(foo as > string)" or "attr(foo)" will be valid, but "attr(foo as color)" won't > be. A similar consideration applies for bookmark-target and the <url> > type. I can see that the cue-based approach to functional arguments make some sense; replacing "," with " as " could possible make things more readable. Taking the type out of the parethesis may be even better: bookmark-label: attr(title) as string I'm not sure it scales, though. Consider this example, which people have been writing for some years: a::after { content: "(see page " target-counter(attr(href, url), page, decimal) ")" } which could become: a::after { content: "(see page " target-counter(attr(href as url) of page as decimal) ")" } or perhaps: a::after { content: "(see page " target-counter(attr(href) as url, of (page) as decimal) ")" } It suddenly doesn't look as good anymore. Hmm. -h&kon Håkon Wium Lie CTO °þe®ª howcome@opera.com http://people.opera.com/howcome
Received on Tuesday, 15 November 2011 00:16:39 UTC