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

TL;DR: I disagree with the reasoning but I reach the same conclusion:
  window.CSS is worth trying.

On Sun, 19 Aug 2012 17:57:01 +0200, Tab Atkins Jr. <jackalmage@gmail.com>
wrote:

> On Sun, Aug 19, 2012 at 3:59 AM, Chaals McCathieNevile <w3b@chaals.com>
>> On Sun, 19 Aug 2012 03:03:19 +0200, Cameron McCormack <cam@mcc.id.au>

>>> Chaals McCathieNevile:
>>>> 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.
>>>
>>> I think the biggest difference between hasFeature and supportsCSS is  
>>> that the implementation of the former, for a given feature string,
>>> would be completely independent of the feature it is testing for.
...
>> Until some important site starts to use this to differentiate between
>> browsers. Since the primary job of a browser maker is to render the web  
>> for users, when a site blocks them for no real technical reason

>> I honestly hope supports works out - and believe it can. But that  
>> belief is not based on the idea that it is somehow fundamentally
>> different technically, but that it can combine something of a clean
>> slate, a slightly different implementation, and happening today and not
>> five years ago. So despite my concerns about how it works out with e.g.
>> "-webkit-*" I think it's worth trying.
>>
>> But then, I am an eternal optimist.
>
> While Opera has a history of lying to sites for compatibility reasons,
> most other browsers do not.

Hmm. Modulo user agent strings that are all historic lies, and "most"
being the most popular rather than necessarily the greater proportion of
browsers, fair enough.

> Even within practices such as Opera's, it's always limited to
> particular sites which are problematic, rather than being a generic
> lie to the web as a whole

No, that is not necessarily the case.

> (which, in @supports's case, would almost certainly *break* plenty
> of sites who *are* depending on that property being supported
> properly).

Right. This is the potential concern that we all want to kep as a
potential rather than a real problem.

My rationale is that it is still easy to implement partial support (e.g.
get the CSS parser right, without getting everything else right). And real
motivations to do this exist, in the form of popular content that doesn't
work across browsers well because of coding issues rather than any real
technical difference.

There are plenty of examples of high-profile sites arbitrarily blocking
browsers, and of browsers providing workarounds. But there are also
examples of browsers simply hacking support for benchmarks (for the
logical reason that people read the top line but not the analysis).

The practice of serving "you should be using Netscape 3" (or the modern
equivalent) is still "widespread" - although I haven't done research to
get serious numbers, it is something that people seem happy to paste into
their code from some half-baked example.

> Finally, the CSSWG's own practices of mandating prefixes before
> compatibility is established means that it's unlikely that someone
> will claim to support an unprefixed property before it's actually
> ready.

I'm less convinced that the prefixing system is a success - and despite
thinking that it isn't stupid for DOM attributes as well, I think its
lifespan there is limited and the day will come when people start lying on
a fairly general basis about some properties because some popular site
didn't match their expectations to reality.

Hopefully, we can minimise this effect by maintaining social pressure on
developers to use such tools as these for "good" (enhancing users'
experience) rather than to "do evil" (discriminating by the colour of your
browser logo).

> This sort of thing can still fail, of course. But it fixes several of
> the problems that dragged hasFeature() down.

I'm unconvinced. I think that it tilts the cost/benefit ratio slightly in
favour of doing The Right Thing™ compared to hasFeature() and I think
people

> In any case, it sounds like no one knows of any problems off the top
> of their head with adding a new "window.CSS" object.

There is no concrete problem I can point to. I am nervous about the CSS
community slowly building an entire parallel universe that starts to
introduce real forks in the way things have to work, and ends up causing
some long-term major headache. That is just a worst-case scenario, but if
we get there we'll make a whole world of pain for a few years while we
figure out how to fix it.

> Pending any compatibility studies showing problems,

We're flying by the seat of our pants here. If we discover compatibility
problems, it is reasonably likely that we lost the opportunity to fix them
without more pain than the industry will bear.

> we'll go ahead and move forward with it.

'I'd like to say "Damn the torpedoes"' (The hunters and collectors already  
sang that line).

Yeah, despite the minor reservations, I think it is worth going ahead.

cheers

-- 
Chaals - standards declaimer

Received on Wednesday, 22 August 2012 18:35:55 UTC