- 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