This bug covers deciding on and implementing getComputedStyle() for values taht are not computed. Examples: width/height for inline elements (currently NS_ERROR_NOT_IMPLEMENTED) left/top/right/bottom for statically positioned elements (NOT_IMPLEMENTED) All of these and z-index for elements which have display:none (hence no frames and thus no computed size/position/z-index properties). (currently returns 0) Ian? David? Any of these that you _do_ agree on? :) If so, I'll start working on those...
*** Bug 111133 has been marked as a duplicate of this bug. ***
Well, since Bug #111133 got duped do this one :-) What I would like to do is create a menubar, with a series of submenus. There's an example of this at http://www.brainjar.com/dhtml/menubar/demo.html , but it uses the non-standard offsetLeft and offsetParent-properties. I would like to do the same, but without using anything not in the DOM 1/2 or CSS 1/2-specification. The size of each menuitem will depend on a variety of influences, some not under the control of the page-author (user stylesheets, installed fonts, screen resolution), so I either the position or size of each item have to be determined at runtime.
glazou, could you review?
I applied to patch provided by Boris to my tree. Now using getPropertyValue doesn't cause an exception anymore. However, getPropertyValue("left") always returns 0px, no matter where the element actually resides on the page. This makes it essentially useless for statically positioned elements, and is no better than the previous situation. I've updated my test page to demonstrate this effect. It is available at: http://www.felliweb.de/tests/getPropertyValue.html
That's the correct behavior. getComputedStyle isn't much more useful than getCascadedStyle. If you want to know where something is on the page, you need another API.
Well, I've seen the offsetXXX-attributes used to get this information. But these are not in the specification. Is there no they, a JS programm can get information about the actual layout of the page without using proprietary APIs?
That's correct. Unless an element is absolutely (or arguably fixed) positioned, the W3C DOM api does not provide a way to find where it's located on the page.
...and even then, you have to do a bit of calculation to get the right position for absolutely positioned elements that are the descendants of other absolutely positioned elements.
Can one query statically positioned elements for where width/height?
*** Bug 112093 has been marked as a duplicate of this bug. ***
For some, yes. You can query block or inline-block or table-cell elements for width/height. You can also query replaced inline elements (eg images). For non-replaced statically positioned inline elements, width/height once again make no sense. What is the "width" of the span in the following case: <span>some text<br> a</span> if the first line is indented, so the shape of the span is: ************ ** For these elements my patch just returns the specified value of width/height
Comment on attachment 59001 [details] [diff] [review] Proposed fix >Index: content/html/style/src/nsComputedDOMStyle.cpp > ... >+ case eStyleUnit_Auto: >+ val->SetString(NS_LITERAL_STRING("auto")); >+ case eStyleUnit_Inherit: >+ val->SetString(NS_LITERAL_STRING("inherit")); >+ default: Don't you want to break after the string assignments ? >+ case eStyleUnit_Auto: >+ val->SetString(NS_LITERAL_STRING("auto")); >+ case eStyleUnit_Inherit: >+ val->SetString(NS_LITERAL_STRING("inherit")); >+ default: Same thing here. Patch looks fine otherwise. r=glazman providing the fact the changes above are made.
Oy. Yes, I do want to break. :) Fixed that in my tree.
Comment on attachment 59001 [details] [diff] [review] Proposed fix sr=attinasi