W3C home > Mailing lists > Public > www-style@w3.org > February 2012

Re: [css3-gcpm] Various issues

From: Håkon Wium Lie <howcome@opera.com>
Date: Mon, 6 Feb 2012 06:17:00 +0100
Message-ID: <20271.25164.202451.132671@gargle.gargle.HOWL>
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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:50 GMT