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

Re: CSS Variables Draft Proposal

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Wed, 16 Feb 2011 08:16:10 -0800
Message-ID: <AANLkTi=pWb4iA3NLKbVnMxhm1W-fMdJvrWfDCi4ZUSUc@mail.gmail.com>
To: Daniel Glazman <daniel.glazman@disruptive-innovations.com>
Cc: David Singer <singer@apple.com>, Christoph Päper <christoph.paeper@crissov.de>, www-style list <www-style@w3.org>
On Wed, Feb 16, 2011 at 4:24 AM, Daniel Glazman
<daniel.glazman@disruptive-innovations.com> wrote:
> Le 16/02/11 08:26, David Singer a écrit :
>
>> Is it harmful to have variables textually local to the document in which
>> they occur?
>
> Assuming your "document" above means "stylesheet", my answer is yes.
>
>
>  <link rel="stylesheet" type="text/css" href="corporate.css"/>
>  <style type="text/css">
>    .logo { content: $logoUrl; }
>  </style>
>
> The above - a real test case real users have been asking for more than a
> decade - is possible only because variables cross stylesheet boundaries.
> If the logoUrl is changed by the corporate stylesheet, the web page is
> visually updated w/o any action from the page author.

Precisely.

One *could* argue that a sheet just for corporate variables could be
created and separately imported everywhere it's needed, but that's an
unnatural coding pattern for authors.

As well, several use-cases do *not* lend themselves to the "import the
variables sheet" approach.  For example, take skinning, the opposite
of corporate theming, where the website provides the HTML and the
users provide the variables.  There's no natural way to make the main
sheet include the specific user's variable sheet without using
server-side languages to generate the sheet with an appropriate
@import in it, which is more work than should be necessary.

For another example, there is *no way* to import a variables sheet
into a @style attribute value, so this would prevent authors from ever
using vars in @style.  Considering that setting @style is the most
common method for altering CSS on individual elements, this seems like
a pretty substantial hit.

Finally, if vars are sheet-scoped, it prevents us from offering the
simplest interface for scripting variables directly.  Instead of
putting a vars map on the document, which is simple and easy to reach,
we'd have to put it on the individual stylesheet, containing only the
vars that are defined in that sheet.  Authors then have to loop over
document.stylesheets, checking each one, to find a variable to alter.

We do need to solve the problem of global name collisions,
particularly between page authors and library/component authors, but
restricting variable scope is the wrong way to go about this.  I
believe the correct way is a simple, light-weight module/namespacing
system, similar to what languages like Python use.  Practice shows
that these are easy and intuitive to use, and successfully reduce name
conflicts.

~TJ
Received on Wednesday, 16 February 2011 16:17:08 GMT

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