Closed
Bug 455855
Opened 16 years ago
Closed 16 years ago
visibility:collapse for xul element in xhtml document does not collapse.
Categories
(Core :: XUL, defect)
Core
XUL
Tracking
()
RESOLVED
INVALID
People
(Reporter: arno, Assigned: zwol)
References
Details
(Keywords: regression, testcase)
Attachments
(1 file)
776 bytes,
application/xhtml+xml
|
Details |
Hi, when setting visibility:collapse on a xul element inside xul document, layout renderering is the same as display:none but when setting visibility:collapse on a xul element inside xhtml document, layout renderering is the same as visibility:hidden On gecko 1.8, layout rendering is the same as display:none in both cases. With current behaviour, a <xul:stringbundleset/> inside xhtml document will be displayed; that may not be wanted.
Comment 1•16 years ago
|
||
Confirmed on Windows XP. Works: 2008021400 Fails: 2008021401 Regression windoww is: http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&date=explicit&mindate=2008-02-13+23%3A00&maxdate=2008-02-14+02%3A00 with as the most likely cause Bug 400813.
Flags: blocking1.9.1? → wanted1.9.1+
Assignee | ||
Updated•16 years ago
|
Assignee: roc → zweinberg
Assignee | ||
Comment 3•16 years ago
|
||
The test case doesn't take namespaces into account in the CSS, so the rule doesn't even match. One may change "spacer" to "*|spacer" or add an @namespace rule to the CSS as well and change "spacer" to "xul|spacer". Having done this, there is then a more serious problem. CSS 2.1 section 11.2 ("The 'visibility' property") contains the sentence If used on elements other than [table] rows, row groups, columns, or column groups, 'collapse' has the same meaning as 'hidden'. "spacer" is clearly not such an element, so the browser is actually doing the right thing here per the letter of the spec. However, I see that there is a whole lot of CSS-for-XUL that expects "visibility:collapse" to do for an arbitrary element what it does for table rows (or more precisely, to "hide the content but not destroy the frame" per comments in various files - which is intimate knowledge of the implementation, but that's XUL for you.) So maybe it oughta be fixed regardless.
Assignee | ||
Comment 4•16 years ago
|
||
I was wrong; no namespaces were declared in the CSS, so "spacer" should have matched <xul:spacer>. That would be a separate bug, though.
Comment 5•16 years ago
|
||
Actually what's happening is that the spacer is being treated as a quasi-inline element as if it was a 0x0 image, and a line block is being created to hold it.
Comment 6•16 years ago
|
||
(In reply to comment #0) > With current behaviour, a <xul:stringbundleset/> inside xhtml document will be > displayed; that may not be wanted. The visibility: collapse; is due to XBL originally not working with display: none; elements (although this now works and would save us some frames too).
Assignee | ||
Comment 7•16 years ago
|
||
(In reply to comment #5) > Actually what's happening is that the spacer is being treated as a quasi-inline > element as if it was a 0x0 image, and a line block is being created to hold it. Ah hah. I would have gotten to that conclusion myself (I was already in the middle of a chain of reasoning starting with "wait, this <spacer> is sized 0x0, why is it taking up space when it's visibility:visible?") but I appreciate your short-cutting it. So it's not actually a visibility:collapse bug at all, it's a bug with not knowing which XUL elements ought to be treated as block-level and which as inline-level when stuffed into HTML. Yes/no/mu?
This seems to me like it's not a bug. collapse isn't exactly the same as display:none; it just means that in terms of the flexible box model it disappears. It seems reasonable to still have a line around it.
I agree.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → INVALID
You need to log in
before you can comment on or make changes to this bug.
Description
•