Re: Acceptable for CSS to add a "window.CSS" global?

On Mon, 13 Aug 2012, Tab Atkins Jr. wrote:
>
> The CSSWG would like to add a new top-level object called "CSS" that we 
> can hang several functions and constructors off of, so that we can avoid 
> the excessive verbosity that's probably required if we just put 
> everything on window. [...]
> 
> Does anyone see any problems with this?  Do we think there's a 
> significant compat risk to claiming an all-caps "CSS" variable?

Seems reasonable in principle, but there's a risk of running into Conway's 
law if we decide what goes into this object based on which working group 
devlops it rather than on what makes sense to go there from the author 
perspective. So it's hard to answer the question without specific details 
of what APIs are intended for such an object.


> (Right now, the only thing we want to add is a "supports()" function, 
> which is the API version of the upcoming @supports rule.  In the future, 
> we'd like to add things like the CSSOM Value API constructors to it, so 
> authors can do a simple "new CSS.px(5)" rather than "new 
> CSSPixelComponentValue(5)".)

As a general rule, @supports and supports() sound like they're run into 
the antipattern where browsers with poor testing return true (despite 
having bad implementations -- the implementor just doesn't realise it), 
browsers with rigoroush but conservative developers return false (despite 
having good implementations -- the implementator doesn't want to say "yes" 
until they can avoid poisoning the value, but they end up waiting longer 
than necessary), and browsers with poor code review and lots of 
enthusiastic contributors return true (despite having no implementation at 
all -- I've often seen people start off by implementing the feature test 
and only looking at doing the feature later). There's also a granularity 
issue. In the olden days it was common for browsers to support 'display: 
inline' and it was common for browsers to support 'border', they just 
didn't support them together. It was common for years for browsers to 
support 'position:absolute' and to support ':before', but for years they 
didn't support them together (at first because the spec said not to; later 
because they hadn't caught up). And finally there's the issue of browser 
testing sites using the feature test as a proxy for conformance testing, 
with all the resulting pressures (e.g. browsers with lower resolve get 
pressured into returning true while browsers with higher standards end up 
dinged in the reviews).

We saw this a lot with the equivalent DOM APIs like hasFeature(). In 
practice, they became completely useless and Anne worked hard to sunset 
them in DOM Core.

I would recommend and urge great caution. There be dragons on this path.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Monday, 13 August 2012 23:43:09 UTC