Closed Bug 200089 Opened 17 years ago Closed 9 years ago

bad computed style width for table centered with 'margin: auto'

Categories

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

defect
Not set
major

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: glazou, Unassigned)

References

Details

(Keywords: topembed+, Whiteboard: edt_b3)

1. launch mozilla
2. open http://daniel.glazman.free.fr/tmp/table_computed_width_problem.html

Expected result: the computed width of each table should be 300px
Actual result: the computed width of the centered table is not 300px

I selected "Style System" for the Component but it could also be "Layout"
or "Layout Tables"
This bug is a MAJOR bug from an embedding point of view since it breaks table
resizing when the table is centered. AFAIC, this bug should be nsbeta1+ and
topembed+. It should also be EDITORBASE+.
Sorry for spam, bad component.
Assignee: varga → dbaron
Component: SQL: Native Database Support → Style System
QA Contact: malachi → ian
Component: Style System → SQL: Native Database Support
uhh... sorry for spam. i'm not sure why it accepted that collision.
Component: SQL: Native Database Support → Style System
Obviously the returned size is the size of the outer table frame. While what you
would like to get is the inner table frame size.
table_outer_width= margin_left + inner_table + margin_right

I thought Boris did fix it along with bug 98159.
See bug 98159 comment 5.  I explicitly did not switch to using the inner table
frame because I was under the impression that the computed dimensions of the
outer frame were the ones we wanted.... Apparently that is not the case.

Problem is, we do still want the computed offsets of the outer frame, eg...  So
we can't just switch to computing style on the inner frame.  <sigh>.

Over to DOM style; there is no style system bug here, and no layout bug... The
"correct" fix would be to evaluate every single CSS property, decide whether the
inner or outer frame should be used to compute it, and write something similar
to attachment 64047 [details] [diff] [review], I guess...
Component: Style System → DOM Style
Summary: bad computed width for table centered with 'margin: auto' → bad computed style width for table centered with 'margin: auto'
.
Assignee: dbaron → dom_bugs
Keywords: topembedtopembed+
Whiteboard: edt_b3
adt: nsbeta1-
Keywords: nsbeta1nsbeta1-
This bug would be fixed by making computed style mean computed style too.
Ian, please file a bug on computed style to that effect and add dependencies?
Depends on: 227280
This major bug is now more than a year old. It's a blocker for Nvu
since Nvu relies on JS side on computed styles for a lot of operations.
In particular, it messes up table manipulation with the mouse and "layer"
positioning.

Proposing a blocker flag for this bug.
Flags: blocking1.8a2?
I doubt that fixing this bug would help what you are doing, given that the 
correct answer for the computed value of 'margin-left' on an element with 
'margin-left:auto' is in fact 'auto' per CSS2.1.
Flags: blocking1.8a2? → blocking1.8a2-
See comment 4.  The solution is described there.  It'll probably double the size
of our computed style code, though.
Er, scratch that.  Ian is right -- per the CSS2.1 definition of "computed", you
can't get useful info out of this API anymore, really.
Assignee: general → nobody
QA Contact: ian → general
QA Contact: general → style-system
This worksforme.  We must have switched to the inner table at some point....
Status: NEW → RESOLVED
Closed: 9 years ago
Flags: in-testsuite?
Resolution: --- → WORKSFORME
Pushed a test: http://hg.mozilla.org/projects/cedar/rev/a7546cc8c2ee
Flags: in-testsuite? → in-testsuite+
You need to log in before you can comment on or make changes to this bug.