117501 - getComputedStyle() return "auto" on unset left/right properties

Status: RESOLVED INVALID

(Core :: DOM: CSS Object Model, defect)

Description

[Sebastiano Vigna]

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.

Comment 1

[Boris Zbarsky [:bzbarsky]]

Are the elements in question positioned?  Testcase?

Also, are you testing 0.9.6 or 0.9.7?

Comment 2

[Sebastiano Vigna]

Attachment: An HTML, JavaScript and CSS file to test the problem reported

I am testing 0.9.7 (0.9.6 worked fine).

I am including a test case from our website. There is a number of menus
dynamically generated by JS, which must be aligned some A elements. However,
the "left" property of the computed style of those element is "auto" (it's
unset in their STYLE attribute). Just load "test.html" and move over the links
on the top left part--the menus are not correctly aligned (there are in 0.9.6).
The JS code has a comment at the point where getComputedStyle() returns "auto".

Comment 3

[Boris Zbarsky [:bzbarsky]]

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....

Comment 4

[tfriesen]

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?

Comment 5

[Boris Zbarsky [:bzbarsky]]

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.

Comment 6

[tfriesen]

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.

Comment 7

[Boris Zbarsky [:bzbarsky]]

<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.

Comment 8

[Sebastiano Vigna]

Attachment: 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...

Comment 9

[Boris Zbarsky [:bzbarsky]]

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.

Comment 10

[Sebastiano Vigna]

Attachment: 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.

Comment 11

[tfriesen]

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

Comment 12

[tfriesen]

I filed a Layout bug concerning this.
Lets see what happens with that.
bug #117887

Comment 13

[Boris Zbarsky [:bzbarsky]]

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?

Comment 14

[tfriesen]

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? 

Comment 15

[Boris Zbarsky [:bzbarsky]]

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.