- 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