Closed Bug 32169 Opened 25 years ago Closed 25 years ago

getComputedStyle (DOM Level 2) not implemented

Categories

(Core :: DOM: CSS Object Model, enhancement, P3)

Product:
Core
Component:
DOM: CSS Object Model
Type:
enhancement

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: joe, Assigned: jst)

References

Details

(Whiteboard: [nsbeta2+][6/01])

This is not a bug, it is a feature request. I am posting it to remind everyone that this is one of the most important parts of DOM Level 2 that has not yet been implemented. Without this feature, many DHTML applications are going to have problems. DOM Level 2 specifies the method ViewCSS::getComputedStyle for determining what CSS styles are applying to an element. Currently in Mozilla, this style info can be determined via el.style, but only if the styles were set inline (e.g. <div style="...">) or via Javascript (e.g. el.style.blah = "blah"). IE5 implements this functionality using the non-standard el.runtimeStyle... not a standard, but at least we can use it. Without this, developers are encouraged to use the <div style=".."> syntax for all CSS, rather than taking advantage of the "cascading" part of CSS. As an example, this means that DHTML app developers will be unable to write an XUL- like widget with Javascript by reading in style values from a big CSS file, then laying out a component according to it's computed box model. You've seen the benefits of this in XUL, so imagine how this would benefit developers who want to do the same with HTML/Javascript. I realize everyone is swamped with stuff to do, I just wanted to remind you of this feature so you can prioritize it when deciding what things you can and cannot finish in time for feature freeze. IMHO, this one is important. Read about getComputedStyle in the latest DOM WD: http://www.w3.org/TR/1999/CR-DOM-Level-2-19991210/css.html#CSS-ViewCSS
While I recognize the importance of eventual DOM2 support, I think that even minor CSS1/DOM1 issues should get priority over any CSS2/DOM2 ones. Once we have 100% level 1 support, then move on to level 2. DOM2 is particularly tricky, because it hasn't been finalized by the W3C, so whatever we might implement runs the risk of having the standard change underneath us. Then we'd get saddled with the issue of backward-compatibility with an old implementation that doesn't match the final standard. I'll wait until DOM2 has been finalized before voting for this feature.
While I agree with you that DOM1/CSS1 issues should get priority, the simple fact is that DOM2 provides many tools that are absolutely ESSENTIAL to DHTML, and are far more important than minor CSS1 issues. CSS1/DOM1 are nice, but alone they are useless. DOM1 doesn't even provide a facility for working with styles! Mozilla realized this and implemented the .style attribute, but it should also be noted that .style is not enough, we need getComputedStyle to be able to truly interact with CSS via the DOM. Anyway, I do agree that CSS1/DOM1 issues should be resolved first. Still, this issue is just as essential.
*** This bug has been confirmed by popular vote. ***
Status: UNCONFIRMED → NEW
Ever confirmed: true
*** Bug 34500 has been marked as a duplicate of this bug. ***
Status: NEW → ASSIGNED
Target Milestone: --- → M16
I must postulate that it it is incorrect to mark bug #34500 as a duplicate of this bug. #34500 states that there needs to be a way to get the x/y/width/height of an element. However, getComputedStyle() does not guarantee to return the absolute pixel value for size and position. If, for instance, an CSS had : "width: auto". getComputedStyle() would then return "auto" for the width property, which is not is not what the reporter of bug #34500 is looking for. Instead, let me suggest that #34500 be marked as a duplicate of bugs #9844 and #34938. These bugs refer to the properties offsetLeft, offsetTop, offsetWidth, and offsetHeight, which are there to report the exact pixel values of an element's position and size. getComputedStyle() is meant only to evaluate the cascade of CSS rule-sets for a given element, merge them together according to specificity, and return one new rule-set with all of the CSS values that are actually applied to the element. getComputedStyle() should not actually compute special values for left, top, width, and height, it should only determine the value of these properties that has cascaded.
Joe, you're right, it's nice to know that at least someone is paying attention to what I'm doing, since I'm obviously not ;). Thank you. (I assume that you're reffering to bug #34398 and not bug #34938)
I just ran into a big reason why this feature is important. When using margins, borders, and padding, it becomes impossible to calculate the exact coordinates and size of an element. Because the .offsetLeft (etc..) properties only reflect offset from the margin, you can't determine total offset unless you can calculate the margin of the offset parent as well. A real example of this is when trying to calculate the "clientLeft" or "clientTop" or an element (their offset from the top/left corner of the browser). Often times, a mouse event will be received and you'll need to take the value you get from e.clientX or e.clientY, and determine the distance of that point from an element on the page. Without getComputedStyle(), such a calculation is impossible. If you don't believe me, I'd bet the XPToolkit team will run into this problem sooner or later.
Joe, don't worry, I do believe you :), I do see the problems here and I personally believe that getComputedStyle() will offer a *lot* to developers of dynamic web content. There are problems with the way getComputedStyle() is defined tho, the latest DOM Level 2 CSS candidate recommendation states that the return value from getComputedStyle is: CSSStyleDeclaration The computed style. The CSSStyleDeclaration is read-only and contains only absolute values. ^^^^^^^^^^^^^^^^^^^^ Now, imagine you have the following document (basically the problem you're talking about in your comment above): <html> <head> <style> body { margin: 10%; padding: 10%; border: 2em solid red; } </style> </head> <body> <p>Hello World!</p> </body> </html> If we follow the spec and ask for the computed margin for the body element, what do we get? "10%", no, that's not an absolute value, from reading the definition of getPropertyValue() it should return an empty string if the property has not been set, well since we're only dealing with absolute values here no useable value has been set, so we should return an empty string? Not very useful. What the developer (script writer) usually wants in a browser is the absolute value for the margin, usually in pixels, in this case, if the width of the window is 800 pixels the returned margin should be 80 pixels. Conclusion: For getComputedStyle() to be useful to content developers in as many situations as possible I'd like to (and probably soon will) make getComputedStyle() really return the computed style, not just what's immediately specified in the stylesheets since that's rarely enough, but the actual computed style as it is displayed on the screen (or whatever media, actually). The implementation will support CSSPrimitiveValue so the values will be accessible in a number of units (px, mm, cm, in, pt, ...) depending on the property. (Besides, I *really* *don't* want to add the offset{Width,Height,...} properties to all our elements, they simply will not work, they don't make sense in XML, for instance, what's the offsetParent in a XUL button, what's the offsetLeft for the button, offset from what? And, they won't work when DOM3 introduces displaying a document in multiple views. IMO they don't belong in a *document* object model at all, So, we really need a replacement for them and IMO getComputedStyle() is it, I hope people will agree with me, if not, I don't really see the importance of getComputedStyle) (I once again think that bug 34500 is a dup of this but I'll wait untill this is implemented before I mark it as a dump)
I agree with you, except that I think that it is still extremely valuable to be able to obtain the literal CSS value that has been assigned to a property, whether it is an absolute (pixel) value or not. I think that the getPropertyValue method should always return the literal value that has cascaded, regardless of it's unit. If the developer wants to get access to the pixel value of a property, they can use getPropertyCSSValue ("margin").getFloatValue(CSS_PX) command. I don't think it's safe to assume that for numeric css properties the developer will always want the pixel value, and nothing else. The developer should be able to access the actual value that cascades, and use the flexible CSSPrimitiveValue methods to interpret this value as they see fit. Indeed, the DOM spec does unfortunately specify that these values should be "absolute". I think that this is wrong; getComputedStyle() should NOT rob the developer of the ability to determine the literal value that has cascaded. Vidur, any comments?
Just thought I'd also note that IE5's proprietary .currentStyle property does behave the way I'd like it to: for each property it reports the literal value that cascades, and doesn't attempt to compute an absolute value. If you want absolute values, you have the offset* properties. Yes, I see the evil in the offset properties, and agree it's better not to use them, but I think the solution I outlined above (using getPrimitiveValue and a unit type) is the best solution.
Joe, and others - Would the proposal http://www.people.fas.harvard.edu/~dbaron/tmp/getCascadedStyle be useful to you? I would like to send this to www-dom, but I wanted to know if this would be helpful to you, and if you have any comments on it first. jst - Have you investigated how hard it would be to fully implement getComputedStyle()? I would imagine it would be quite hard, since a lot of the needed information is all over layout, but I could be wrong.
David, that's an excellent proposal IMHO. It's clear that getComputedStyle is not enough in itself. However, what I would prefer is that getComputedStyle simply be renamed to getCascadedStyle, and the CSSPrimitiveValue interface could be used to find the "computed" value. After all, what is the point of the CSSPrimitiveValue::getFloatValue method anyway? I would think it would be to transform values like "50%", "3em", or "auto" into any other unit (like pixels), thus "computing" the style. If this method will in fact be able to make these computations, then getComputedStyle is completely unnecessary. The DOM2 draft is completely vague about how getFloatValue will work. Vidur, your name is on the draft, can you elaborate?
A few more thoughts. How does getComputedStyle know how to compute an "absolute" value for various unit types? How does it define what units are "relative"? It really SHOULDN'T know. The developer should be able to make this decision. Sure, maybe "px" is absolute if you're talking about a monitor, but what if you're talking about a printed copy? Then maybe you want "pt". getComputedStyle has no way to know what you want. "font-size" is a good example. If I want the computed value of "font-size: medium", do I want it in "em", "px", "pt", or what? getComputedStyle doesn't know. What if I want the computed value of "color: red". Do I wanted it to be "red" or "#ff0000". Again, we should use CSSPrimitiveValue to make this decision for ourselves. So, my proposal to the DOM working group is as follows: 1). rename getComputedStyle to getCascadedStyle 2). The values in the returned CSSStyleDeclaration should not be absolute values, they should be whatever value has cascaded. In the case of computed inherited values, the unit of the cascaded value will be the unit that the user agent has done the computation in. 3). CSSStyleDeclaration::getPropertyValue would return the string value that cascaded. 4). CSSStyleDeclaration::getPropertyCSSValue would get a CSSPrimitiveValue interface which could then be used to convert this string into whatever "absolute" unit the developer may be seeking.
In response to the comment at 13:46: I think CSSPrimitiveValue is an inappropriate place for finding computed values since it can occur in style rules that match multiple elements. The conversions done by getFloatValue are explained better in the interface definition for CSSPrimitiveValue than in the definition of the method. In response to the comment at 14:09: Your proposal in (2) for dealing with inherited values has all the implementation difficulties of dealing with computed values, since inheritance works on computed values (not cascaded values). Technically, absolute values are in, pt, pc, mm, cm (or, for angles, any angle units). See http://www.w3.org/TR/REC-CSS2/syndata.html#length-units . So, IMO, converting everything to absolute values is really a bad idea. Perhaps the getComputedStyle should just return a CSSStyleDeclaration where all conversions are allowed in CSSPrimitiveValue::getFloatValue? (This would leave the string values for inherited things implementation-dependent.)
Ok, I see now that, as it is currently defined, CSSPrimitiveValue can't do conversions based on the dimensions of any specific element in the document. However, having such an ability would be amazingly useful. Perhaps, as David suggested, getComputedStyle (or getCascadedStyle) should return a CSSPrimitiveValue which is bound to a specific element, and can therefore make relative-to-absolute, relative-to-relative, or absolute-to-relative conversions based on information about this element.
Simple getComputedStyle should be in beta2, what this means is that only a few properties will be implemented. David, I like your proposal, I agree that the computed style and the cascaded style should be different methods. I haven't had time to think about all the details involved here and I probably won't untill I land the initial support for this. A full implementation of getComputedStyle() is a lot of work, there's something like 120 different properties in CSS2 but I don't think that implementing any one property is really difficult but doing them all is a lot of work.
Keywords: nsbeta2
I mentioned the discussion on this bug in the W3C www-dom mailing list and got this response from Phillipe Le Hegaret: http://lists.w3.org/Archives/Public/www-dom/2000AprJun/0111.html
Putting on [nsbeta2+][6/01] radar. This work must be done by 06/01 or we may pull this for PR2.
Whiteboard: [nsbeta2+][6/01]
This work was actually done, and it was checked in on 5/16. The current support is very limited and I've opened bug 39892 for tracking support for more properties. Marking FIXED.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Marking Verified per jst comments.
Status: RESOLVED → VERIFIED
Component: DOM Level 2 → DOM Style
You need to log in before you can comment on or make changes to this bug.