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

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 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.

The Conway's Law concern is reasonable, though minor.  Noted.


>> (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).

@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.  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).

This is why we didn't provide a simple form that just lets you ask for
a property name - you have to give a full value, presumably something
that you're actually using in the code.


> 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).

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.

> 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).

This is no different than today - badly-written "testing" sites
sometimes use the mere presence of an unprefixed property as a
guarantee of conformance.  Using @supports to test for that is merely
a slightly easier way to do that kind of "test".  We don't seem to
have problem with unprefixing and pressure due to this today.

> 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.

The failure of hasFeature() greatly informed the design of this feature. ^_^

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.

~TJ

Received on Tuesday, 14 August 2012 00:00:22 UTC