- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Tue, 11 Oct 2011 17:47:38 -0700
- 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 UTC