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. <[email protected]>
wrote:
On Mon, Aug 13, 2012 at 4:42 PM, Ian Hickson <[email protected]> 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
