Closed
Bug 480532
Opened 16 years ago
Closed 16 years ago
Computed style does not give absolute values when element has binding attached
Categories
(Core :: DOM: CSS Object Model, defect)
Tracking
()
RESOLVED
DUPLICATE
of bug 276116
People
(Reporter: martijn.martijn, Unassigned)
Details
(Keywords: testcase)
Attachments
(2 files)
See testcase, when an element has a binding attached, then it doesn't return absolute values for the various computed styles that should return absolute values, like width and so.
This is sometimes a problem with the marquee code, which uses width: -moz-available and a binding. Then the computed style width is used to add a margin somewhere else, which then can result in a css parsing error.
More specifically, I see it happen with the testcase from bug 235564, https://bugzilla.mozilla.org/attachment.cgi?id=142239 which gives a CSS parsing error in the error console. It seems to only happpen for display: none marquees, it seems.
Reporter | ||
Comment 1•16 years ago
|
||
Ok, apparently with display: none the computed style is always relative, so I guess this is the problem I have with the "This is sometimes a problem with the marquee code".
Opera seems to be doing it correct (giving absolute values), Webkit seems to give relative values also in this case.
![]() |
||
Comment 2•16 years ago
|
||
We hand out "absolute" values only when there is a frame. No frame means we can't get actual layout information, of course: the layout hasn't been done.
In this case, the binding is still loading when your script runs, so there is no frame. In the display:none case there is just no frame.
The display:none case is a duplicate, I'm pretty sure.
Whiteboard: DUPEME
Reporter | ||
Comment 3•16 years ago
|
||
Ok, thanks for the info.
I guess the display: none case is basically bug 276116, so I should take care of that in the marquee binding (although I found out it only gives a warning in the error console).
And I guess this bug about the binding affecting the computed value is also invalid. According to CSS2.1: "Computing a value never requires the user agent to render the document".
http://www.w3.org/TR/CSS21/cascade.html#computed-value
Although, I have to say, I don't really see anymore why bug 276116 is invalid.
It might not make sense from a Gecko point of view, but the spec doesn't specifically say that specified values should be used when the elements hasn't been rendered.
![]() |
||
Comment 4•16 years ago
|
||
We can mark bug 276116 wontfix if that would help....
And we're not returning specified values. We're returning CSS2.1 computed values (as opposed to used values, which is what you seem to want out of this).
Reporter | ||
Comment 5•16 years ago
|
||
(In reply to comment #4)
> We can mark bug 276116 wontfix if that would help....
Yes, that would make it probably make more clear.
Indeed, the used value, is what I want (which is in general someone would want when using the computed style).
Is this bug also a wontfix?
![]() |
||
Comment 6•16 years ago
|
||
Yeah, it's the same issue...
Reporter | ||
Updated•16 years ago
|
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•