- 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®ª
howcome@opera.com http://people.opera.com/howcome
Received on Monday, 6 February 2012 05:17:44 UTC