mail archive www-style.w3.org
(List home) (Recent threads) (197 other W3C lists)
Subscription Options
- RSS or Atom: Read-only subscription using a browser or aggregator. This is the recommended way if you don't need to send messages to the list. You can learn more about feed syndication and clients here.
- Conventional: All messages are delivered to your mail address, and you can reply. To subscribe, send an email to the list's subscribe (we seem to have lost it) address with "subscribe" in the subject line.
- Moderate traffic list: up to 30 messages per day
- This list contains about 20,573 messages, beginning Mar 2011
- 6 messages added yesterday
Report the Spam
This button sends a spam report to the moderator. Please use it sparingly. For other removal requests, read this.
Are you sure? yes no
navigator.supportsCSS rather than window.supportsCSS
Ad
The global object ('window') of the DOM is already quite crowded.
Attaching supportsCSS to the 'navigator' object instead makes sense
semantically, and would avoid adding even more to the global object.
- Florian
I remember I once proposed to use CSSDeclaration instead of the global
object.
if(CSSDeclaration.isValid("color","red")) {
...
}
or
if(CSSDeclaration.isValid("color: red")) {
...
}
-----Message d'origine-----
From: Florian Rivoal
Sent: Friday, August 03, 2012 2:35 PM
To:
Subject: [css3-conditional] navigator.supportsCSS rather than
window.supportsCSS
The global object ('window') of the DOM is already quite crowded.
Attaching supportsCSS to the 'navigator' object instead makes sense
semantically, and would avoid adding even more to the global object.
- Florian
On Fri, 03 Aug 2012 16:03:19 +0200, Daniel Glazman
wrote:
> Le 03/08/12 14:44, François REMY a écrit :
>> I remember I once proposed to use CSSDeclaration instead of the global
>> object.
>>
>> if(CSSDeclaration.isValid("color","red")) {
>> ...
>> }
>>
>> or
>>
>> if(CSSDeclaration.isValid("color: red")) {
>> ...
>> }
>
> That does make a lot of sense, indeed!I assume you mean CSSStyleDeclaration rather than CSSDeclaration.
This makes some sense, but I am only moderately comfortable having it
attached to every instance of a CSSStyleDeclaration
in the document, despite the fact that the result does not depend on which
one you call it on.
- Florian
It would be a static property. As far as I know, static properties are not
put on the prototype but on the constructor.
BTW, now that I accidentally used isValid using one argument, I wonder about
:
if(CSSStyleDeclaration.isValid("a: value1; b: value2;")) {
...
}
On Fri, Aug 3, 2012 at 7:40 AM, François REMY wrote:
> BTW, now that I accidentally used isValid using one argument, I wonder about
> :
>
> if(CSSStyleDeclaration.isValid("a: value1; b: value2;")) {
> ...
> }No, we went with the two-arg version on purpose. The only reason to
accept multiples is to use the and/or/not, and JS already has those
built in.
~TJ
> BTW, now that I accidentally used isValid using one argument, I wonder
> about :
>
> if(CSSStyleDeclaration.isValid("a: value1; b: value2;")) {
> ...
> }I wouldn't go there. Javascript has everything that's needed for doing
conjunctions and disjunctions, so this adds no new capability.
The semantics are not even obvious:
CSSStyleDeclaration.isValid("background: double-rainbow(center);
background: radial-gradient(circle at center, red, yellow, green, blue,
violet);")
Should this return true if there is no parsing error at all, or if it
results into background being assigned at least one value? The fact that
the parser can recover from errors complicate things.
All in all, I think we should stick to the simpler version, and leave it
to javascript to build combined boolean expressions.
- Florian
| The semantics are not even obvious Granted.
On Fri, Aug 3, 2012 at 8:15 AM, Florian Rivoal wrote:
> I assume you mean CSSStyleDeclaration rather than CSSDeclaration.
>
> This makes some sense, but I am only moderately comfortable having it
> attached to every instance of a CSSStyleDeclaration
> in the document, despite the fact that the result does not depend on which
> one you call it on.It could be defined on the prototype, i.e.,
CSSStyleDeclaration.prototype.supportsCSS(...). Of course, this also means
binding global.CSSStyleDeclaration (which at present isn't specified; i.e.,
no constructor is spec'd).
On Fri, Aug 3, 2012 at 8:40 AM, Glenn Adams wrote:
>
> On Fri, Aug 3, 2012 at 8:15 AM, Florian Rivoal wrote:
>
>> I assume you mean CSSStyleDeclaration rather than CSSDeclaration.
>>
>> This makes some sense, but I am only moderately comfortable having it
>> attached to every instance of a CSSStyleDeclaration
>> in the document, despite the fact that the result does not depend on
>> which one you call it on.
>
>
> It could be defined on the prototype, i.e.,
> CSSStyleDeclaration.prototype.supportsCSS(...). Of course, this also means
> binding global.CSSStyleDeclaration (which at present isn't specified; i.e.,
> no constructor is spec'd).
>correction: what François just said
On 08/03/2012 04:40 PM, Glenn Adams wrote:
> On Fri, Aug 3, 2012 at 8:15 AM, Florian Rivoal wrote:
>
>> I assume you mean CSSStyleDeclaration rather than CSSDeclaration.
>>
>> This makes some sense, but I am only moderately comfortable having it
>> attached to every instance of a CSSStyleDeclaration
>> in the document, despite the fact that the result does not depend on which
>> one you call it on.
>
>
> It could be defined on the prototype, i.e.,
> CSSStyleDeclaration.prototype.supportsCSS(...). Of course, this also means
> binding global.CSSStyleDeclaration (which at present isn't specified; i.e.,
> no constructor is spec'd).Note that global.CSSStyleDeclaration exists regardless of whether the
interface has a constructor.
HTH
Ms2ger
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). 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)". (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
On Wed, Aug 8, 2012 at 10:40 AM, Tab Atkins Jr. 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 >
On Wed, Aug 8, 2012 at 9:54 AM, Glenn Adams wrote:
> On Wed, Aug 8, 2012 at 10:40 AM, Tab Atkins Jr.
> wrote:
>> 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".Yes, that's what I was trying to write. I was probably unclear. ^_^
~TJ
I'm obviously OK with this but I'm not a member of the group :-) However, I
don't like the 'supports' name.
if(CSS.supports("@keyframes")) { ... }
seems legit but don't work. The function name doesn't express correctly what
the function does.
-----Message d'origine-----
From: Tab Atkins Jr.
Sent: Wednesday, August 08, 2012 6:40 PM
To: Boris Zbarsky
Cc: Glenn Adams ; www-style list
Subject: Re: [css3-conditional] navigator.supportsCSS rather than
window.supportsCSS
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).
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)". (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
On Wed, Aug 8, 2012 at 12:21 PM, François REMY
wrote:
> I'm obviously OK with this but I'm not a member of the group :-) However, I
> don't like the 'supports' name.
>
> if(CSS.supports("@keyframes")) { ... }
>
> seems legit but don't work. The function name doesn't express correctly what
> the function does.There's nothing stopping us from later supporting such things. I'm
not willing to lengthen or uglify this name for the sake of avoiding
*uncertain* future pain.
~TJ
On Wed, Aug 8, 2012 at 9:40 AM, Tab Atkins Jr. 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).
>
>I don't like this idea. There's nothing like this in the platform yet, and
the difference between CSS.PixelValue and CSSPixelValue is one letter.
Either way, supports() really needs to be a document level feature anyway
because browsers support different CSS properties in standards vs quirks
mode (IE...), or even in extensions or apps vs web pages (ex -moz-binding).
document.supportsCSS(property, value) is what you want.
- E
On Tue, Aug 14, 2012 at 11:37 PM, Elliott Sprehn wrote:
>
> On Wed, Aug 8, 2012 at 9:40 AM, Tab Atkins Jr. 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).
>>
>>
> I don't like this idea. There's nothing like this in the platform yet, and
> the difference between CSS.PixelValue and CSSPixelValue is one letter.
>
> Either way, supports() really needs to be a document level feature anyway
> because browsers support different CSS properties in standards vs quirks
> mode (IE...), or even in extensions or apps vs web pages (ex -moz-binding).
>
> document.supportsCSS(property, value) is what you want.
>I believe this is intended to be a function of the browser in general,
independent of whether operating in quirks mode or not, which is
effectively under author control. So NO, it should not be defined on
Document. Personally, if it is defined, I would prefer it be defined on
specific sub-interfaces of CSSRule, e.g.,
CSSFontFaceRule.supports(descriptor,value) or
CSSStyleRule.supports(propertyName, value) or
CSSPageRule.supports(pagePropertyName, value), since the first argument is
effectively local (distinct) according to the rule type. Having a single
global CSS.supports(name,value) doesn't sufficiently distinguish if one is
asking for support of a style property, a page property, a font face
descriptor, etc.
Glenn Adams:> I believe this is intended to be a function of the browser in general, > independent of whether operating in quirks mode or not, which is > effectively under author control. So NO, it should not be defined on > Document.Is supportsCSS() even meant to take quirks mode into account? If so, then I'd think that calling window.supportsCSS() would use the quirks mode flag of that window's document. I don't think it's necessary to support quirks mode dependent behaviour of supportsCSS() based on arbitrary documents created with createDocument() or XHR. But anyway, I'm not sure there's much value in having supportsCSS() -- or @supports -- honours quirks mode at all. Gecko does by accident, incidentally: http://people.mozilla.org/~cmccormack/tests/s... http://people.mozilla.org/~cmccormack/tests/s...
On 8/15/12 3:39 AM, Cameron McCormack wrote:
> Glenn Adams:
>> I believe this is intended to be a function of the browser in general,
>> independent of whether operating in quirks mode or not, which is
>> effectively under author control. So NO, it should not be defined on
>> Document.
>
> Is supportsCSS() even meant to take quirks mode into account?Well, @supports certainly should, I think: the whole point of @supports
is to test what's supported in the document being styled.
Whether the DOM API should match that is an interesting question. I
think it should, for consistency.
That doesn't preclude having this hang off a Window or window.CSS; in
either case the current document is easily accessible.
-Boris
On Wed, Aug 15, 2012 at 12:39 AM, Cameron McCormack wrote:
> Glenn Adams:
>
> I believe this is intended to be a function of the browser in general,
>> independent of whether operating in quirks mode or not, which is
>> effectively under author control. So NO, it should not be defined on
>> Document.
>>
>
> Is supportsCSS() even meant to take quirks mode into account?The way this feature has been discussed in the WG thus far, the intent of
the API was to determine if the UA supports the feature independent of any
other settings. But it is certainly worth considering adding some context
as parameters to this API to permit queries to be contextualized.
Especially if the @supports rule should support that logic.
On Wed, Aug 15, 2012 at 12:08 AM, Glenn Adams wrote:
> ...
>>
>> document.supportsCSS(property, value) is what you want.
>>
>
> I believe this is intended to be a function of the browser in general,
> independent of whether operating in quirks mode or not, which is
> effectively under author control. So NO, it should not be defined on
> Document.
>If the function is supposed to return true when the CSS feature is
available then it must be per document, or you write really weird stuff
like iframe.contentWindow.CSS.supports(...), and inside an extension you
must be super careful to access the hostPage.window.CSS.supports because
CSS.supports inside the extension environment is going to return totally
different values.
It's not inconceivable that Chrome OS or Boot2Gecko apps (etc.) will
support fancy "app specific" CSS features that aren't available to regular
web pages (actually these things already exist like -moz-binding or
-apple-dashboard-region).
If you're suggesting it return the exact same values in all environments
then @supports (-moz-binding(...)) is going to be true in Gecko on regular
web pages which is definitely wrong since -moz-binding doesn't work there.
Similarly an embedded <iframe> inside a Dashboard widget with @supports
(-apple-dashboard-region) will evaluate to true..
- E
On Aug 15, 2012, at 9:18 AM, Elliott Sprehn wrote:On Wed, Aug 15, 2012 at 12:08 AM, Glenn Adams wrote:
> ...
>>
>> document.supportsCSS(property, value) is what you want.
>>
>
> I believe this is intended to be a function of the browser in general,
> independent of whether operating in quirks mode or not, which is
> effectively under author control. So NO, it should not be defined on
> Document.
>If the function is supposed to return true when the CSS feature is
available then it must be per document,
Or, optionally, take a context document as an argument.
I don't see how anything you're arguing is a decisive blow against a object
for redirection.
or you write really weird stuff like
iframe.contentWindow.CSS.supports(...), and inside an extension you must be
super careful to access the hostPage.window.CSS.supports because
CSS.supports inside the extension environment is going to return totally
different values.
It's not inconceivable that Chrome OS or Boot2Gecko apps (etc.) will
support fancy "app specific" CSS features that aren't available to regular
web pages (actually these things already exist like -moz-binding or
-apple-dashboard-region).
If you're suggesting it return the exact same values in all environments
then @supports (-moz-binding(...)) is going to be true in Gecko on regular
web pages which is definitely wrong since -moz-binding doesn't work there.
Similarly an embedded <iframe> inside a Dashboard widget with @supports
(-apple-dashboard-region) will evaluate to true..
- E
On 8/15/12 4:15 AM, Elliott Sprehn wrote:
> It's not inconceivable that Chrome OS or Boot2Gecko apps (etc.) will
> support fancy "app specific" CSS features that aren't available to
> regular web pages (actually these things already exist like -moz-binding
> or -apple-dashboard-region).-moz-binding is not going to be available in Boot2Gecko apps.
In fact, I believe the plan is to have the same web platform exposed to
both web pages and Boot2Gecko apps, in terms of CSS.
-Boris
On Tue, Aug 14, 2012 at 11:37 PM, Elliott Sprehn wrote: > On Wed, Aug 8, 2012 at 9:40 AM, Tab Atkins Jr. 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). >> > > I don't like this idea. There's nothing like this in the platform yet, and > the difference between CSS.PixelValue and CSSPixelValue is one letter.That's not what I suggested. With a safe global that can't be author-polluted, we can do *significantly* smaller names without risking collisions. I keep mentioning "CSS.px" as the name we'd probably end up with for these kinds of things, which is significantly better.> Either way, supports() really needs to be a document level feature anyway > because browsers support different CSS properties in standards vs quirks > mode (IE...), or even in extensions or apps vs web pages (ex -moz-binding).Standards vs quirks doesn't change the recognized properties, does it? I wasn't aware of that being a quirks-mode difference. Do extensions get their own script global, separate from the web page? If not, I know they at least get some special objects for their special capabilities. We can give them a special version of this if we want to let them recognize their special properties. > document.supportsCSS(property, value) is what you want. It's really not. :/ ~TJ
On 8/15/12 2:27 PM, Tab Atkins Jr. wrote: > Standards vs quirks doesn't change the recognized properties, does it? > I wasn't aware of that being a quirks-mode difference.It certainly changes the recognized values. In some UAs it may in fact change the recognized properties. For example, according to http://blogs.msdn.com/b/ie/archive/2012/06/04... the 'filter' property is supported in some document modes but not others in IE10 in the Trusted Sites zone. > Do extensions get their own script global, separate from the web page? Typically, yes. -Boris
[Tab Atkins Jr.]> Standards vs quirks doesn't change the recognized properties, does it?
> I wasn't aware of that being a quirks-mode difference.If @supports(display: flexbox) should return true in IE's legacy quirks
(docmode 5) I'm not sure I understand the point of the feature anymore.
At the least it'd be strange for common feature-detection tools like Modernizr
to say one thing and CSS to say another.
On Thu, Aug 16, 2012 at 6:19 PM, Sylvain Galineau
wrote:
> [Tab Atkins Jr.]
>> Standards vs quirks doesn't change the recognized properties, does it?
>> I wasn't aware of that being a quirks-mode difference.
>
> If @supports(display: flexbox) should return true in IE's legacy quirks
> (docmode 5) I'm not sure I understand the point of the feature anymore.
>
> At the least it'd be strange for common feature-detection tools like Modernizr
> to say one thing and CSS to say another.Heh, IE's modes aren't the same things as "quirks mode" - the latter
is a small set of differences that are roughly standardized (and being
tightened up now). IE's modes are much more invasive.
However, I'm not sure what the problem is in the first place. Nested
document have their own "window" object, so they'll have their own
"CSS" object as well. It can return whatever answer is appropriate
for that document's mode.
(I wish I'd said this immediately in response to Elliott, but a brain
fart made me think that <iframe>s shared the top document's window
object.)
The only remaining wrinkle is that document objects that aren't nested
in a browsing context, like what's returned by XHR.responseXML, won't
have their own window object. Are these documents coerced to the
parent document's mode? If so, great. If not, who cares, you can't
run script inside of them anyway until they're given a browsing
context, so the question of what CSS.supports() would return is moot.
~TJ
On Fri, Aug 17, 2012 at 10:27 AM, Tab Atkins Jr. wrote:
>...
> However, I'm not sure what the problem is in the first place. Nested
> document have their own "window" object, so they'll have their own
> "CSS" object as well. It can return whatever answer is appropriate
> for that document's mode.
>This still feels wrong from a software design perspective. I'm not
asking if CSS supports this feature, I'm asking if /this document/
supports this CSS feature.
You also create a cyclical relationship between the CSS object and
document. CSS needs to account for the document state to say what is
supported, and document needs to consult the CSS object to decide
what's allowed while parsing. (Not really, but conceptually this is
what's happening).
This is like adding Events.addDocumentListener instead of
document.addEventListener.
- E
On Fri, Aug 17, 2012 at 12:33 PM, Elliott Sprehn wrote: > On Fri, Aug 17, 2012 at 10:27 AM, Tab Atkins Jr. wrote: >> However, I'm not sure what the problem is in the first place. Nested >> document have their own "window" object, so they'll have their own >> "CSS" object as well. It can return whatever answer is appropriate >> for that document's mode. > > This still feels wrong from a software design perspective. I'm not > asking if CSS supports this feature, I'm asking if /this document/ > supports this CSS feature.While that's a nice argument from theoretical purity, "document.supportsCSS" is way longer than "CSS.supports", while not buying us anything. Worse for authors cancels out marginally better for theoretical purity.> You also create a cyclical relationship between the CSS object and > document. CSS needs to account for the document state to say what is > supported, and document needs to consult the CSS object to decide > what's allowed while parsing. (Not really, but conceptually this is > what's happening).This is a concept wholly invented in your head. It does not reflect reality in any way. The "CSS" object is just a namespacing object to avoid the verbosity that's required when you put things on the global object. ~TJ
It doesn’t have to be on every instance, it could be on the CSSStyleDeclaration object itself (i.e. similar to a static method in traditional OO languages), the same way e.g. Array.isArray() is attached on the Array object itself and not on every instance. I believe that’s what François was suggesting. Lea Verou W3C developer relations http://lea.verou.me ☻ @leaverouOn Aug 4, 2012, at 02:15, Florian Rivoal wrote: > On Fri, 03 Aug 2012 16:03:19 +0200, Daniel Glazman wrote: > >> Le 03/08/12 14:44, François REMY a écrit : >>> I remember I once proposed to use CSSDeclaration instead of the global >>> object. >>> >>> if(CSSDeclaration.isValid("color","red")) { >>> ... >>> } >>> >>> or >>> >>> if(CSSDeclaration.isValid("color: red")) { >>> ... >>> } >> >> That does make a lot of sense, indeed! > > I assume you mean CSSStyleDeclaration rather than CSSDeclaration. > > This makes some sense, but I am only moderately comfortable having it attached to every instance of a CSSStyleDeclaration > in the document, despite the fact that the result does not depend on which one you call it on. > > - Florian >
On Fri, 03 Aug 2012 16:37:11 +0200, Lea Verou wrote: > It doesn’t have to be on every instance, it could be on the > CSSStyleDeclaration object itself (i.e. similar to a static method in > traditional OO languages), the same way e.g. Array.isArray() is attached > on the Array object itself and not on every instance. I believe that’s > what François was suggesting.On Fri, 03 Aug 2012 16:40:38 +0200, François REMY wrote: > It would be a static property. As far as I know, static properties are > not put on the prototype but on the constructor.I see. I think that would work, then. - Floria
On Fri, Aug 3, 2012 at 5:35 AM, Florian Rivoal wrote:
> The global object ('window') of the DOM is already quite crowded. Attaching
> supportsCSS to the 'navigator' object instead makes sense semantically, and
> would avoid adding even more to the global object.Attaching it to navigator or CSSStyleDeclaration means that its
already somewhat-long name becomes much longer.
I don't think adding on to window is a big deal. If we do want to
avoid doing it, though, I suggest defining a new top-level interface
named "CSS" and hanging it off of that. It's short and topical, and
it would be convenient for hanging some of the new css value
constructors we'll want for the cssom values api.
~TJ
| I don't think adding on to window is a big deal. If we do want to
| avoid doing it, though, I suggest defining a new top-level interface
| named "CSS" and hanging it off of that. It's short and topical, and
| it would be convenient for hanging some of the new css value
| constructors we'll want for the cssom values api.I'm afraid WebIDL doesn't support nested interfaces or namespaces right now.
## For every interface that [should be available to JS] a
## corresponding property MUST exist on the ECMAScript
## global object. The name of the property is the identifier of
## the interface, and its value is an object called the interface
## object.
BTW, CSSStyleDeclaration isn't that long to type.
Plus, remember, your IDE supports intellisense ^_^
On Fri, Aug 3, 2012 at 8:19 AM, François REMY wrote:
> | I don't think adding on to window is a big deal. If we do want to
> | avoid doing it, though, I suggest defining a new top-level interface
> | named "CSS" and hanging it off of that. It's short and topical, and
> | it would be convenient for hanging some of the new css value
> | constructors we'll want for the cssom values api.
>
> I'm afraid WebIDL doesn't support nested interfaces or namespaces right now.
>
> ## For every interface that [should be available to JS] a
> ## corresponding property MUST exist on the ECMAScript
> ## global object. The name of the property is the identifier of
> ## the interface, and its value is an object called the interface
> ## object.WebIDL can be improved; that happens constantly, and isn't an issue.
> BTW, CSSStyleDeclaration isn't that long to type.
CSSStyleDeclaration is *enormous*. 19 letters! That's a full quarter
of your 80-char width gone immediately, not even counting the weight
of the rest of the declaration.
CSSStyleDeclaration.supportsCSS("","") is 38 characters of typing.
Considering how much we bitched over document.querySelector(""), which
is a mere 27 characters, 38 is horrible. We *must* take these
ergonomic effects into account when developing APIs.
> Plus, remember, your IDE supports intellisense ^_^
"The tools will save us" isn't an argument. Unneeded verbosity is a
bad thing no matter what. Compare all that to something small like
CSS.supports(""). Now *that's* nice and tidy. One character more
than the current function defined on window, but just as easy to read,
and allows for future expansion quite nicely.
~TJ
The eternal debate between short names and naming conventions =D
I've always been a Windows guy, I can't bear ambigous names for the sake of
brievty (PHP's strstr anyone?). As it's actually a matter of taste, I will
not fuel this debate anymore after this mail: I'll let you do a poll during
your next telcon instead ^^
BTW, I initially had a CSSDeclaration{property as string, value as string}
interface in mind as host for the 'isValid' function (not
CSSStyleDeclaration) but it seems this is a creation of my imagination as it
nowhere to be seen (CSSStyleDeclaration..item returns a DOMString, and
CSSStyleDeclaration..declarations don't exist).
However it's a fact that, even in that case, 'CSSDeclaration.isValid("","")'
is 29 chars long while 'CSS.supports("","")' is only 20.
An additionnal element to factor in is that most feature detection logic
will probably happen in a specific module where you can use a scoped short
name for the function (and should for perf reasons).
-----Message d'origine-----
From: Tab Atkins Jr.
Sent: Friday, August 03, 2012 5:32 PM
To: François REMY
Cc: Florian Rivoal ;
Subject: Re: [css3-conditional] navigator.supportsCSS rather than
window.supportsCSSOn Fri, Aug 3, 2012 at 8:19 AM, François REMY
wrote:
> | I don't think adding on to window is a big deal. If we do want to
> | avoid doing it, though, I suggest defining a new top-level interface
> | named "CSS" and hanging it off of that. It's short and topical, and
> | it would be convenient for hanging some of the new css value
> | constructors we'll want for the cssom values api.
>
> I'm afraid WebIDL doesn't support nested interfaces or namespaces right
> now.
>
> ## For every interface that [should be available to JS] a
> ## corresponding property MUST exist on the ECMAScript
> ## global object. The name of the property is the identifier of
> ## the interface, and its value is an object called the interface
> ## object.WebIDL can be improved; that happens constantly, and isn't an issue.
> BTW, CSSStyleDeclaration isn't that long to type.
CSSStyleDeclaration is *enormous*. 19 letters! That's a full quarter
of your 80-char width gone immediately, not even counting the weight
of the rest of the declaration.
CSSStyleDeclaration.supportsCSS("","") is 38 characters of typing.
Considering how much we bitched over document.querySelector(""), which
is a mere 27 characters, 38 is horrible. We *must* take these
ergonomic effects into account when developing APIs.
> Plus, remember, your IDE supports intellisense ^_^
"The tools will save us" isn't an argument. Unneeded verbosity is a
bad thing no matter what. Compare all that to something small like
CSS.supports(""). Now *that's* nice and tidy. One character more
than the current function defined on window, but just as easy to read,
and allows for future expansion quite nicely.
~TJ
On Fri, Aug 3, 2012 at 9:08 AM, François REMY wrote:
> The eternal debate between short names and naming conventions =D
>
> I've always been a Windows guy, I can't bear ambigous names for the sake of
> brievty (PHP's strstr anyone?). As it's actually a matter of taste, I will
> not fuel this debate anymore after this mail: I'll let you do a poll during
> your next telcon instead ^^There is certainly a point when terseness impairs readability
("strstr" doesn't even *mean* anything). One must always keep in mind
that the goal is user-friendliness, both in writing and reading, and
this requires a balance between being explicit and being terse. I
don't think anything I've suggested crosses the "too terse to read"
boundary. ^_^
~TJ
If verbosity is the issue, it could be attached to CSSStyleSheet or CSSStyleRule instead, which are somewhat shorter. CSSStyleDeclaration is more relevant to what it does though, as it’s not about testing support of *any* CSS feature, but of property-value pairs only.On Aug 4, 2012, at 03:04, Tab Atkins Jr. wrote:
> Attaching it to navigator or CSSStyleDeclaration means that its
> already somewhat-long name becomes much longer.
Ad