- From: H�kon Wium Lie <howcome@opera.com>
- Date: Mon, 6 Feb 2012 06:17:00 +0100
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- Cc: www-style list <www-style@w3.org>
Tab Atkins Jr. wrote: > While reviewing several specs today, fantasai and I noted several > issues with some of the functions defined in GCPM: > > We suggest changing 'string-set' from a ''content()'' function (that > accepts some keywords for control) to just a set of keywords: > ''contents'', ''content-element'', ''content-before'', > ''content-after'', ''content-first-letter''. This avoids nested > functions in ''target-text()'', and it's a fixed set of values anyway > so the functional notation doesn't add anything - it only complicates > the syntax. I agree with this proposal -- the list of arguments to the function is fixed, so we might as well use keywords. I've updated the editor's draft to use the new syntax. > 'target-text' should use the same set of keywords that 'string-set' does. You mean a subset, I presume; 'string-set' uses counter(), counters(), and env() -- I don't see a need for these in 'target-text(). > We agree with the note in the spec about abolishing ''link-rel()'', > and instead using ''go()'' with the rel keywords as additional valid > values. Good. I've made the change. But I'm hesitant to mix the namespace from the link element (index, previous, next) with 'back'. So I ended up with: @navigation { nav-up: go(index); nav-left: go(previous); nav-right: go(next); nav-down: back; } > ''url-doc()'' needs to be specific that it is parsed in the same way > as ''url()'', as a special token I've updated the description to say that "url-doc() is identical to url(), except for ..." > It appears that ''target-pull()'' is completely undefined. It's > mentioned once and then used in one example, and that's it. But it's self-evident, no? :) I've added an issue to define it. > In general, it would be nice if all of these functions had their > grammar defined in a grammar block, rather than solely in a paragraph > of prose. It's much eaiser to see at a glance what a function should > look like with a grammar block. Depend who you are and how damaged your brain is. Personally, I prefer to learn from sample code. But I agree that a grammar is helpful for implementors, issue added. Cheers, -h&kon H�kon Wium Lie CTO ��e�� [email protected] http://people.opera.com/howcome
Received on Monday, 6 February 2012 05:17:44 UTC