W3C home > Mailing lists > Public > www-style@w3.org > October 2011

Re: [css-device-adapt][cssom] Missing VIEWPORT_RULE definition

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Tue, 11 Oct 2011 17:47:38 -0700
Message-ID: <CAAWBYDAXWUUZATdg_bV_RuzighU_4upXp8XbF5PncWU=MUgG5A@mail.gmail.com>
To: John Daggett <jdaggett@mozilla.com>
Cc: Sylvain Galineau <sylvaing@microsoft.com>, www-style@w3.org
On Tue, Oct 11, 2011 at 5:37 PM, John Daggett <jdaggett@mozilla.com> wrote:
> Defining new constants across specs that need to be consistent with
> the ones defined in the OM spec  (e.g. the keyframe rule constants in
> CSS3 Animations [1]) is a recipe for screwups.
>
> Seems like it would be *much* nicer to have an CSSRule interface that
> allowed the precise value to be queried rather than relying on a
> brittle universal definition, especially taking into account prefixed
> implementations of new @-rules.

Agreed.  WebappsWG ran into similar "distributed number minting" with
error types, and just gave up on numeric codes in favor of names.  Old
types still return the values they were previously defined with, but
new errors just have a code of 0 and communicate their type solely
through their name.

We could easily do the same thing, I think.  Strings don't need any
more coordination than the feature's name itself does.


> Also, new @-rules need to have some form of DOM interface definition
> and in general should probably follow the behavior of other OM API's.
> For example, the cssText field of CSSRule raises a DOMException on a
> syntax error but the wording in CSS3 Animations says nothing about
> similar exception when setting fields of keyframe rules.  The @-rules
> in GCPM lack any DOM intereface information.

Yes, definitely.

~TJ
Received on Wednesday, 12 October 2011 00:48:26 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:45 GMT