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

Re: CSS Variables Draft Proposal

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>
Message-ID: <20110210210631.GA26095@pickering.dbaron.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 GMT

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