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

TL;DR: Conway's law is already validated in this instance, but maybe  
there's no real harm, and stuff to like about the proposal anyway. On  
balance I think it is a good idea. (Plus a lot of stuff about @supports  
...)

On Tue, 14 Aug 2012 01:59:28 +0200, Tab Atkins Jr. <jackalmage@gmail.com>  
wrote:
> On Mon, Aug 13, 2012 at 4:42 PM, Ian Hickson <ian@hixie.ch> wrote:
>> 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 [...]
>
> The Conway's Law concern is reasonable, though minor.  Noted.

Hmm. I am not sure if it is minor or not. Depends how important you think  
clean architecture is - personally I think it is lovely but not something  
the Web has or relies on so I can live with what I think is a high  
probability of an API that reflects the CSS group more than anything  
else...

>>> (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 [...])
>>
>> As a general rule, @supports and supports() sound like they're run into
>> the antipattern [of hasFeature() returning useless information]
>
> @supports was designed very specifically to make this as small of a
> problem as possible.
>
> If a browser supports "foo: bar;" well enough to actually parse it and
> keep it around, it's - by definition - good enough for authors to use
> it.

Maybe (but I am unconvinced). But when a browser just *says* it can handle  
it, that is not good enough on its own.

> While it's theoretically possible that a particular browser's
> implementation is really shitty so that you don't want to use it, in
> practice I don't think that's ever been a problem (or if it has, it's
> been rare enough that I don't remember it).

Too make the thing useless for authors there doesn't have to be a terrible  
implementation, just different ones in different browsers. And browsers  
have differently implemented pretty basic parts of CSS before, unless my  
memory is playing tricks.

>> There's also a granularity issue. [...]
>
> Valid in principle, but I don't think it's a big deal.  There are some
> issues like that, but authors can know about them and work around
> them.

Actually, this is the crux of the issue. Anything that relies on authors  
knowing the issues is something that makes the proposed use case for  
supports less interesting.

On the other hand, it doesn't have to work perfectly to be useful, it just  
has to work well enough often enough to make using it worthwhile.

[...]
> The failure of hasFeature() greatly informed the design of this feature.

And yet the technical design boils down to the same thing - asking the  
browser a question about whether it can do something, where there is a  
penalty for answering "I can't".

The penalty, quite often, is being told to advertise a rival product to  
the user. Without wanting to anthopomorphise companies, and still less  
software, this is something that hurts both the dignity and actual  
well-being of the browser, so the motivation to stretch the truth (an in  
equal measure distort what this feature tries to do) is pretty strong.

The issue is social - if it were worse to lie in hasFeature than not  
having the feature requested, there would be no need for supports() since  
we could just add the CSS tests to hasFeature.

Frankly, I am deeply sceptical that the CSS group has managed to solve the  
social problem sufficiently well to make the technical solution noticeably  
different from hasFeature.

Which leads me to the conclusion that "Conway's Law" has already been  
borne out here.

However...

> If you'd like to discuss the supports() function further, could you do
> it on www-style?  I'd prefer this thread to stay on the original
> subject.

Right.

As Odin said, window.* is a pretty big collection, and being able to  
simplify CSS-specific stuff is probably going to bring more value than  
problems. Overall, I think the idea is reasonable.

cheers

Chaals

-- 
Chaals - standards declaimer

Received on Tuesday, 14 August 2012 11:43:46 UTC