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)

x86
Windows XP
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 276116

People

(Reporter: martijn.martijn, Unassigned)

Details

(Keywords: testcase)

Attachments

(2 files)

Attached file testcase
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.
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.
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
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.
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).
(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?
Yeah, it's the same issue...
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → DUPLICATE
Whiteboard: DUPEME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: