3.56 KB, application/x-gzip
3.53 KB, application/octet-stream
4.53 KB, text/html
Until 0.9.6, getComputedStyle() would compute correctly the absolute value of the "left" and "right" properties, that is, it would have given the absolute position of the inspected element even if the position had not been set explicitly. Now for such elements "auto" is returned instead. Note that for things like dynamically generated popup menu based on visibility properties this is absolutely necessary. It is my understanding that a discussion is ongoing about whether getComputedStyle() should compute the result of the cascading or the result of the actual layout. However, I could not find a note about this in the release notes, so I'm filing a bug report.
Are the elements in question positioned? Testcase? Also, are you testing 0.9.6 or 0.9.7?
Assignee: jst → bzbarsky
Attachment #63151 - Attachment mime type: application/octet-stream → application/x-gzip
OK. Looking at the code, the element with id "leftlinks" is not positioned. As such, it has no computed value of left, since setting "left" on it will not change where it's located. This change was put in place because our old behavior was a fairly clear violation of the DOM2 CSS spec. See bug 109523 for some details, as well as bug 84599, comment #30. The short story is that DOM2 CSS does not allow one to do what you want to do (that is, to find the absolute offset of a statically positioned element). You probably want to use offsetLeft to get the left edge and "offsetTop + offsetHeight" to get the bottom edge.... Marking invalid. The code is correct as designed and as the spec says. 0.9.6 had pretty bogus behavior for positioning properties in computed style (bug 94855 and bug 84599) and the fix changed the static-position behavior to be per-spec as well... > It is my understanding that a discussion is ongoing about whether > getComputedStyle() should compute the result of the cascading or the result of > the actual layout. I don't know of such a discussion (if there is one, I would be highly interested in it)... The actual layout doesn't have much to do with computed style.... It's all about what would be inherited by children of the element whose style you are computing. Marking invalid because the code is functioning as designed. If I've missed something important in the js/css/html, please reopen....
Status: UNCONFIRMED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → INVALID
But why is "auto" returned when dealing with static pos. elements? If the properties do not apply to the element,should'nt getPropertyValue() be returning an empty string? Likewise,should'nt getPropertyCSSValue() return null?
Well... because even if the property does not apply to this element, it _does_ have a value and this value _is_ inherited by its children. Rerturning the empty string fails the "if you set the inline style value to the computed value nothing in the page layout should change" test.
Boris,Iam sure you know what you are talking about but to me that does not make a lick of sense :) How/Why are these positioning properties inherited? And why would setting the inline style for these properties change anything if they are not applied? As far as Iam concerned,"auto" is a value and if you are going to return a value you might as well return the right one.
<a style="left: 20%"> <div id="one" style="position: absolute; left: inherit; top: 20px" /> <div id="two" style="position: relative; left: inherit; top: 20px" /> </a> While the 20% does not affect the position of that <a> and is not computed for the <a>, it _is_ inherited by the divs. So the <div>s inherit "left: 20%" and then compute what value that actually corresponds to in pixels. Now the two types of positioning are different and so the 20% is taken of two different lengths for the two divs. Now, what values can computed left for the <a> return? The criterion is that setting "left" for the <a> to the computed value should not change the layout of the page.
Created attachment 63293 [details] Second HTML/CSS/JS test files From the discussion, at least I got the pleasing impression that I'm not the one confused by these issues 8^). OK: I moved everything into offsetLeft/offsetRight etc. I even split the JS code because MS Explorer wouldn't give the right values on elements whose containing block was not closed. Now, however, there is another problem: the style.left property works great and as expected, but style.top offsets the elements from the *root block* instead of the *contaning block*. As a result, the elements are vertically misplaced. On the contrary, the left property positions the elements with respect to their containing block (you cannot see that from the example, because the containing block has left offset 0, but I have other examples in which style.left does work). So I am completely missing the point, or Mozilla is offsetting vertically in a different manner than then one in the CSS2 specs? I'm dubious because testing the same code on MSIE gave the same result (i.e., offset w.r.t the root block). So I don't know whether it is a known quirk for backward compatibility, a feature, or a bug. I would like some advice before filing the n-th wrong bug report...
style.top and style.left both position with respect to the containing block. The containing block for a positioned element is not the first block-level ancestor but the first _positioned_ ancestor. Try setting "position:relative; top:0; left:0" on the element you think should be the "containing block" in this case.
Created attachment 63306 [details] Modified HTML test case that uses relative positioning to create a positioned containing box I tried that. My menu headings are in a TD element containing a DIV element. Setting relative positioning on the TD element has no effect. Setting it on the DIV element (as in the modified test file included) gives correct positioning of the menus, but now a large empty space filled with background colour appears underthe headings, as if the DIV elements giving the menus were made invisible, but not actually taken out from the flow. Note that I'm just trying to make some dynamic menus "in the right way". I am trying to use exclusively standard interfaces, and use Mozilla as a reference browser, so please bear with me.
reply to comment #7 Are you sure those divs are suppose to be inheriting the specified value? CSS2 specs seem to be saying they should be inheriting the computed value. Then they would inherit "left:auto;" (at least that is what mozilla now returns) . take a look at CSS2 section 6.2.1
I filed a Layout bug concerning this. Lets see what happens with that. bug #117887
The testcase in bug 117887 has pixel values set for top and left on the <a>. Are you saying computed style returns "auto" in that case?
No,Iam not saying that. You get values in pixels in that case. I just was testing the example you gave and modified it for the testcase for that bug report I guess I was just too lazy to make my own :-) But would you consider those return values to be computed values?
I'm not sure what that question means... You're asking for a computed value in a situation in which it does not really make sense. I suppose we could throw an exception (tried that; breaks lots of sites because exceptions halt code execution and sites tend to not catch exceptions from DOM calls). We could return the empty string and null for getPropertyCSSValue(). We could do what we do now. The choice between the latter two should depend on how inheritance works in the style system. I'll write a decent testcase for bug 117887 once I get back from vacation; then we'll know for sure.
You need to log in before you can comment on or make changes to this bug.