- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Wed, 01 Feb 2012 15:15:01 -0500
- To: www-style@w3.org
On 2/1/12 3:06 PM, Glenn Adams wrote: > While (a) and possibly (c) appear to be the case for current > implementations, I'm not sure if this is intended or sanctioned by > existing spec text, either in DOM2 Style or current CSSOM ED. The DOM2 Style text is basically nuts. I wouldn't worry too much about it. We should make the CSSOM ED say whatever the right behavior is. First we need to decide on that behavior. > * the existing specs are ambiguous; > * this has resulted in significant differences in implementations, and > possibly differences from the intentions of the published spec text; Yes. Note that the "intentions" of the DOM2 Style authors may simply not be achievable, because it was written by people who didn't understand CSS very well as far as I can tell. It makes some clear normative requirements that are impossible to satisfy for a CSS OM. > 1. On query operations (e.g., getting cssText, length, invoking item, > getPropertyValue, etc.), does ElementCSSInlineStyle.style represent > *only* the declarative content of @style? *OR* > 2. On query operations, does ElementCSSInlineStyle.style represent the > UA's so-called "specified values" [1] state of all properties that > do or could apply to the element? i.e., the results of applying the > cascading and inheritance steps of the property resolution process? Depending on what you mean by "declarative content", the aswer is either #1 or "neither". > 3. On mutation operations (e.g., setting cssText, invoking setProperty, > etc), does ElementCSSInlineStyle.style represent *only* the > declarative content of @style? *OR* > 4. *On mutation operations, does ElementCSSInlineStyle.style represent > the *the UA's "specified values" [1] state of all properties that do > or could apply to the element? Again, no idea what #3 means. #4 makes no sense for mutations. > 5. Does mutation implicitly trigger reapplication of the entire > property resolution process *and* reformatting? Yes. The conceptual model has generally been that any mutation throw away all computed data (style and layout) and recomputes everything. Modulo the transition-starting mess, that's still the conceptual model; everything else is optimizations. > [Is there an implied > delay before acting on this trigger, e.g., in order to coalesce > multiple mutations? Or does each mutation require serialized and > distinct re-resolution and reformatting?] Is this observable? > 6. Do the length and item() members of the CSSStyleDeclaration instance > referenced by *ElementCSSInlineStyle.style represent only* the > declarations present in cssText or not? If not, then what exactly do > they represent? Longhand equivalents only? Longhand equivalents plus > shorthand? This is what we need to decide, yes. -Boris
Received on Wednesday, 1 February 2012 20:15:29 UTC