- From: L. David Baron <dbaron@dbaron.org>
- Date: Thu, 10 Feb 2011 13:06:31 -0800
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- Cc: "Linss, Peter" <peter.linss@hp.com>, www-style list <www-style@w3.org>
On Thursday 2011-02-10 12:44 -0800, Tab Atkins Jr. wrote: > On Wed, Feb 9, 2011 at 6:56 PM, Linss, Peter <peter.linss@hp.com> wrote: > > On 2/9/11 5:22 PM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote: > > "A token stream" is really dangerous (or exceptionally powerful, depending > > on your point of view). You're definitely going to have to tighten this > > up. > > Yeah, "token" isn't the word I want here. More like "component > value". I've edited the language in the draft, but this needs some > thought to capture the right concept. I think this change makes the proposal much harder to implement, since it requires implementations to enforce that there's never a situation where part of a component value comes from a variable and part doesn't (or comes from a different variable). Since there's nothing close to a definition of what a component value is, it's hard to know how much work enforcing that is, but it could be substantial. (If we go down this road, I think we're likely to end up with the rule that variables are not permitted in values of 'font-family', for example.) > > Consider: > > > > @var $foo bar, baz / 100px ; > > > > Does that simply get dropped into place macro style? Including the leading > > and trailing whitespace? > > @var is not a character macro (shudder). This gets parsed into three > component values and two separators, and gets substituted in as such. There are cases in CSS where whitespace is substantive. Consider: p.foo p .foo font-family: Times New Roman; font-family: TimesNew Roman; > > Do we really want that? > > > > How about: > > @var $foo url(; > > @var $bar ); > > > > p { content: $foo http://example.com/yikes.gif $bar } > > Oh jeezus no. I don't know the precise details of url() parsing, but > either that is parsed into a single $foo variable containing > "url(;\n@var $bar )", or they're both invalid. Either way works for > me. Even if variables represent a token-stream, we should require that they be (), {}, and [] -balanced. -David -- L. David Baron http://dbaron.org/ Mozilla Corporation http://www.mozilla.com/
Received on Thursday, 10 February 2011 21:07:03 UTC