- From: Garrett Smith <dhtmlkitchen@gmail.com>
- Date: Tue, 22 Sep 2009 13:54:46 -0700
- To: Travis Leithead <travil@microsoft.com>
- Cc: www-style CSS <www-style@w3.org>, Sylvain Galineau <sylvaing@microsoft.com>, Sharon Cohen <sharco@microsoft.com>
On Tue, Sep 22, 2009 at 12:21 PM, Travis Leithead <travil@microsoft.com> wrote: >> -----Original Message----- >> From: Garrett Smith [mailto:dhtmlkitchen@gmail.com] >> On Tue, Sep 22, 2009 at 7:07 AM, Travis Leithead <travil@microsoft.com> >> wrote: >> > We (the IE team) are _considering_ dropping support for currentStyle >> > and runtimeStyle in our next most "standards compliant" mode. However, >> > because there is interest in this space (via the CSSOM spec [1], we >> > wanted to get a feel for whether other browsers are considering >> > implementing these APIs or not. (We see that Opera has an >> > implementation.) >> > >> [...] >> > >> > Given existing API design precedent, it seems logical to create a >> > "getCascadedStyle" API that would replace "currentStyle" in the >> > future--it can handle pseudo-elements and would be similar to related >> > style APIs of which web developers are already familiar. >> > >> >> document.defaultView.getCascadedStyle? >> As in: >> http://lists.w3.org/Archives/Public/www-dom/2000AprJun/0112.html >> >> ? > > Exactly that. > >> >> > >> > >> > Any strong opinions on this matter? >> > >> >> A strong opinion can be formed by making observations. Using google code >> search to find existing code can reveal usage patterns. When analyzing >> existing code, one can formally or informally write a program with the new >> feature. Often it is obvious just from looking at the code. >> >> Dropping support for currentStyle and runtimeStyle would break Microsoft- >> only sites and applications. > > True, but IE handles legacy compatibility by versioning. > OK, so we could have an "IE8" mode, then? I'm not sure I like that idea, because this has the type of problem where, say, a program might want to get a feature or bugfix that was in IE9 but can't get that because it is in IE8 mode. >> Gecko, Webkit, Opera, IE all have no implementation of >> document.defaultView.getCascadedStyle. It would just make more work for >> all involved. Those involved included: Microsoft, for working to implement >> getCascadedStyle, Microsoft's business customers, for having to update their >> code, the w3c (who would presumably write up a spec), and the rest of the >> web, . >> >> Consider how existing code that uses currentStyle (only) would have to >> change to still try to function:- >> [snip example] > > This makes it seem like developers just want "some" value for a style, but aren't looking specifically for a computed/cascaded value. That's actually what I want to discover--is this true? Are there specific needs to get both the computed value and the cascaded style? Or do developer care? > There are needs to get a computed value. The value should be consistent (unit, or otherwise). A cascaded value could be useful the value is "auto" or "inherit", but in that case, it would still want to be an absolute value that is "consistent". The type of situations I've found useful for reading styles:- * animation to a certain value, starting from the current value, (opacity, color, width, etc) * drag and drop: to know the z-index or position values (this allows the API to be flexible enough to allow for relative or absolute positioning) * toggle a style value (is the object visible?) * read a border width to determine element dimensions (clientTop and clientLeft are recent additions in some browsers, do not exist in other browsers, and are only half the picture (no clientBottom or clientRight)). To perform the above tasks, a program needs to read value that has a clearly defined unit or value measurement (for things like font-weight, z-index, border-width). A value "inherit" or "auto" is bad because it requires the program perform traversal up the parent chain. To do this, programs can rely on using only px, and this includes in CSS. The problems with solutions that use currentStyle and getComputedStyle, as L pointed out, is that reading consistent values requires using px only in the CSS. Things like borderWidth, which may result in "medium" in IE. The problem with that is that the "medium" border width might be a 0 width border where the borderStyle is none: alert(document.body.appendChild(document.createElement("div")).currentStyle.borderWidth); IE: "medium" Opera "3" For "length" or the unspecified "positive length" (border, padding), px can mostly work. Garrett
Received on Tuesday, 22 September 2009 20:55:31 UTC