elements inherit specified positioning property values instead of computed values (computed style)

RESOLVED INVALID

Status

()

Core
Layout: R & A Pos
--
major
RESOLVED INVALID
16 years ago
10 years ago

People

(Reporter: tfriesen, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

16 years ago
According to the CSS2 specs,elements should inherit computed values.
In the test case below,the positioned DIVs seem to inherit the
specified left and top property values from the A.
The A is not positioned,so the it should not have computed values for left and 
top.
So the DIVs should fall back on the initial values which is "auto".

For reference see:
http://www.w3.org/TR/REC-CSS2/cascade.html#value-def-inherit
(Reporter)

Comment 1

16 years ago
Created attachment 63358 [details]
test case
(Reporter)

Comment 2

16 years ago
maybe this is more a styling problem
Component: Layout → Style System

Comment 3

16 years ago
Mozilla's behaviour looks correct to me. The way I read the specification, the 
computed value is merely the specified value converted to absolute units, so 
the same in this case. I don't see that the left and top properties don't apply 
to the non-positioned bloack affects this.

http://www.w3.org/TR/REC-CSS2/cascade.html#computed-value

Inheritance is style system.  Are the divs _really_ inheriting the specified 
value?  The testcase given does not actually test that...

To really test that:

1)  Put the <a> inside an absolutely positioned div with nonzero (preferably
    large) padding.
2)  Make the specified value a percentage value, not a pixel value (otherwise
    there is no difference between computed and specified value)
3)  See whether the offsets of the two divs take the padding into account when
    converting the percentage to pixels.

Not confirming, since I have no Mozilla to test with at the moment....
Assignee: attinasi → dbaron
OS: Windows ME → All
QA Contact: petersen → ian
Hardware: PC → All
The spec doesn't really define what the computed values are for elements to
which the property doesn't apply, I don't think.  Or does it?
(Reporter)

Comment 6

16 years ago
What would be the point of having computed values in this case?
At least in the context of CSS
If CSS is not doing the positioning,what would it use 
for a reference for these values?
It has the values in the style sheet,but those values are a tad misleading.

Summary: elements inherit specified position property values instead of computed values → elements inherit specified positioning property values instead of computed values
(Reporter)

Comment 7

16 years ago
Perhaps my perception of computed values is a bit off.
I would have thought that to get a computed value,all
related properties would need to be taken into account.
So the value of the position property would be considered
when computing values for left and top.
If a computed value is just a converted specified value,then this
bug is probably invalid.
This bug report is not well defined so invaliding may not be
a bad idea in any case. 
Created attachment 64144 [details]
testcase

This testcase tests inheritance of percent offsets from statically positioned
elements (Pixel offsets are just inherited).  It seems that relatively
positioned elements don't inherit anything useful (the computed value is 0)
whereas absolutely positioned elements inherit the offsets of their first
absolutely positioned ancestor (instead of inheriting from the statically
positioned parent).
Attachment #63358 - Attachment is obsolete: true
So the point is that the computed value is not in fact what is inherited, since
the element the value is computed for is not the element inherited from in the
percentage case.  There is no way to make computed style do this right....
Status: UNCONFIRMED → NEW
Ever confirmed: true
->Layout, since almost all of the necessary changes go in Layout (although the
style system might need to use an explicit inherit value in the style struct if
it isn't already).  We might want to discuss this in the CSS WG since this is
hard to implement, though.
Assignee: dbaron → attinasi
Component: Style System → Layout
QA Contact: ian → petersen
Whiteboard: [CSSWG]?
This is definitely something the WG should talk about.  If a clarification of
what computed position values should be for static elements results, that would
be wonderful.

Updated

16 years ago
Target Milestone: --- → mozilla1.2
Setting qa to Ian with the hope of bringing more WG attention to this... ;)
Assignee: attinasi → position
Component: Layout → Layout: R & A Pos
QA Contact: cpetersen0953 → ian
Target Milestone: mozilla1.2alpha → ---
As of recently it was decided that computed values should be layout independent.

Thus, in:

  margin: 59%;

...the computed value of 'margin-top' is '59%', and it is that that is inherited.
Note that this means our hard work for 'text-indent' has to be changed back. :-)

The next CSS2.1 draft should show this in the computed value lines.
How does that affect GetComputedStyle?  If that needs changing, file a bug?
It will need changing too. (I told you we should have a single way of getting
computed style... :-P) I don't want to file any bugs until CSS2.1 is in CR.
Summary: elements inherit specified positioning property values instead of computed values → elements inherit specified positioning property values instead of computed values (computed style)
We render the test case correctly now but the values returned in the DOM are no 
longer the computed values, they are the actual values (I think). Maybe this bug 
should be dependent on a new bug to make getComputedStyle() use the new 
definition of "computed".
Sure thing.  Note that changing the behavior of getComputedStyle for positioning
properties is likely to break many pages, so it's something to be done VERY
carefully, and after consultation with the evang folks.
Depends on: 227280
Whiteboard: [CSSWG]?
Actually, why is this not invalid at this point?  We should be rendering the way
we are rendering and the getComputedStyle issue is covered by bug 227280
fair enough
Status: NEW → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.