W3C home > Mailing lists > Public > public-houdini@w3.org > April 2015

Re: [parser-api] Polyfilling CSS

From: Boris Zbarsky <bzbarsky@mit.edu>
Date: Tue, 07 Apr 2015 20:39:45 -0400
Message-ID: <552478D1.7080208@mit.edu>
To: public-houdini@w3.org
On 4/7/15 8:26 PM, Rick Byers wrote:
> Can someone explain why CSS needs a stronger guarantee here than
> JavaScript?  I.e. why don't we make the same argument to say that all
> 'custom' variables in JavaScript must have a prefix (or namespace)
> because we need the ability to 'innovate' in names on the global object?

We've had a lot of trouble introducing new name on the global object in 
JS, precisely because of name collisions.  They've been dealt with in 
the following ways:

1)  Some of them we've managed to make replaceable, which means you can 
define a variable with the same name and it will nuke the browser thing 
from existence.  Too bad for you if some library you're using wanted the 
browser thing.

2)  Some of them we've dealt with by giving things defined in specs 
suboptimal names.

3)  Some of them have been dealt with by simply not adding stuff on the 
global object at all but putting it somewhere else; there's a lot of 
pushback any time someone suggests that.

It helps, also, that JS is case-sensitive and that most things people 
want to add on the global are new class names, which start with capital 
letters, while most script variables are not named with initial caps.

And it helps, that using global variables in scripts is considered bad 
form (and in particular that libraries almost never do this nowadays).

Even given all that, any time we add a property on the global there's a 
lot of angst, browser use counters, some broken pages, and so forth.

> I.e. why can't custom CSS properties just shadow built-in ones

Shadow in what sense?  How is a browser supposed to tell whether it's 
dealing with a "custom" property or not when parsing?  At least in JS 
there are clear indications of when the page is writing a variable (so 
you might want to nuke the browser-default thing) as opposed to reading 
it; that distinction doesn't even make sense for CSS.

> and developers can cope with name conflicts exactly as they have been
> (seemingly without total disaster) in JS for ages?

I disagree with the "without total disaster" characterization given 
items #2 and #3 above.  But also, note that #3 (and the common library 
pattern of not using globals in JS) is not even an option for CSS 
because we're talking about a single flat namespace here....

So in summary, I think you're severely underestimating the magnitude of 
the problems that JS has had here, and the CSS situation is more 
difficult than the JS one for several reasons.

Received on Wednesday, 8 April 2015 00:40:14 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:53:23 UTC