Re: [css3-conditional] navigator.supportsCSS rather than window.supportsCSS

On Wed, Aug 8, 2012 at 10:40 AM, Tab Atkins Jr. <jackalmage@gmail.com>wrote:

> So, based on the discussions on this thread, what does the group feel
> about defining a new global named "CSS", which we use to hang new
> css-related things off of that may not be worth polluting the global
> object with (or that would require a cumbersome name if they were put
> on the global).
>

Sounds fine to me.


>
> In this case, the function would just be called "supports()", hung off
> of CSS.  This is a single character longer than "supportsCSS()", which
> is currently the shortest clear name we've come up with (and thus very
> attractive to me).
>
> The main benefit of starting this now is that we'll have the precedent
> already established in the future, so that we can, for example, hang
> all the new CSS value constructors off of it (I'd much rather type
> "new CSS.px()" than "new CSSPixelComponentValue(5)".


I'm not sure we want to wait for nested interfaces to do this. At present,
WebIDL requires a binding at the global object for all interfaces declared
with Constructor or NamedConstructor extended attribute. We could leave
that in place and, in addition, *explicitly* define a binding on the CSS
interface object, e.g., "CSS.px is set to the value obtained by evaluating
CSSPixelComponentValue.prototype.constructor".


> (Officially, the
> interface will still hang off of the global object with the dumb long
> name, but there would be an additional function that acts as a
> constructor hung off of the CSS object.  However, heycam is amenable
> to amending WebIDL to actually allow nested interfaces so we don't
> have this cruft, if we decide that would be a good idea.)
>
> ~TJ
>

Received on Wednesday, 8 August 2012 16:55:33 UTC