- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Wed, 16 Feb 2011 08:16:10 -0800
- 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 UTC