This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Specification: http://www.whatwg.org/specs/web-apps/current-work/multipage/rendering.html Multipage: http://www.whatwg.org/C#tables Complete: http://www.whatwg.org/c#tables Comment: "When a Document is in quirks mode, vertical margins on HTML elements at the top or bottom of td or th elements are expected to be collapsed to zero." is wrong. The top margin is correct, but the *bottom* margin should only be collapsed for p elements. http://mxr.mozilla.org/mozilla-central/source/layout/style/quirk.css#135 Posted from: 85.227.157.105 by simonp@opera.com User agent: Opera/9.80 (Macintosh; Intel Mac OS X 10.7.2; U; en) Presto/2.10.229 Version/11.61
Seems like body shouldn't collapse bottom margin, and we can have a limited set of elements that collapse the top margin for body, td and th. Empty elements (same set) at the start of body, td and th should get collapsed bottom margin. Empty elements (same set) at the end of td and th should get collapsed top margin.
Also, not collapse, but set to 0.
This bug was cloned to create bug 18054 as part of operation convergence.
I don't understand what it is you want me to write here. (In reply to comment #2) > Also, not collapse, but set to 0. No, collapse, because the whole point is that all the elements at the top of the document have their margins go to zero. As in the <h1>'s top margin here: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1771 But I agree that the statement in the spec isn't accurate enough. For example, the <body>'s top margin itself doesn't eat the others, it's just that the whole stack at the top goes to the body's 8px. Not really sure what the right solution is here. Anyone want to have a crack at defining this quirk? (With tests, ideally.)
(In reply to comment #4) > I don't understand what it is you want me to write here. I want you to basically copy Gecko (but don't include multicol). > (In reply to comment #2) > > Also, not collapse, but set to 0. > > No, collapse, because the whole point is that all the elements at the top of > the document have their margins go to zero. No, the point is to be compatible with the Web. It's hard to know what has the best Web compat properties, I guess. Opera has bugs reported in this area where I have concluded that Gecko's behavior would be better. > As in the <h1>'s top margin here: > > http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1771 This doesn't collapse in Firefox.
http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=1771 renders the same in Opera, WebKit, and IE. Why would we want to follow Gecko here, which is the lone one not collapsing the margin?
zcorpan: ping
Because: I'd like to minimize the amount of quirks we have to the set that is *needed* for Web compat, and not let quirks leak to new features (e.g. <section>). Firefox has a fixed list of elements that have 0 margin, and this appears to be Web compatible enough that Gecko haven't felt any need to change it. (We've similarly limited the two CSS parsing quirks to a fixed set of properties even though no browser had that (Gecko had a blacklist rather than a whitelist but has now implemented the whitelist).) I don't really understand what other browsers do to be able to accurately describe it in a spec. Opera's behavior breaks some sites that would be fixed if we implemented Gecko's behavior. (Comment 0 describes such an instance.)
So what exactly does Gecko do? I really don't understand what you want the spec to say (I can't just "copy Gecko" since Gecko is written in C++ and the spec is written in English prose). Do other browser vendors have an opinion on this? For example, are there know Gecko compatibility issues here? Are other browsers (WebKit, Microsoft) willing to change to match Gecko?
The Gecko behavior is actually written in CSS, not C++; see the link to quirk.css in comment 0. That said, I'm not particularly happy with that behavior, though I'm not sure if I'm any happier with the various alternatives proposed in https://bugzilla.mozilla.org/show_bug.cgi?id=33784 or elsewhere. (I thought I had a better one in there, but I don't see it.)
dbaron: What does :-moz-only-whitespace:-moz-last-node do?
:-moz-only-whitespace matches a node all of whose children are either (a) comments, (b) processing instructions, or (c) text nodes that do not contain a character other than space, tab, LF, CR, or form feed. (It's a superset of :empty, which considers only (a), (b), and text nodes with zero-length data.) :-moz-last-node matches an element that does not have any later sibling other than (a), (b), or (c) as above.
(Note that I don't think Gecko CDATA section nodes anymore. If it did, I think the above definitions might need adjusting for them (probably by treating them just like text nodes).)
Simon, can you share an example of a site broken in Opera that you believe would be fixed by this change?
The site that led me to report this bug was probably this one: http://boards.4chan.org/n/ At the time (about a year ago), it was in quirks mode and expected the bottom margin of <blockquote> in <td> to *not* be collapsed, which is what happens in WebKit/Gecko but not Opera. (Apparently IE9 collapses, but the site wasn't broken in IE. Maybe they had a CSS hack for IE?) We sitepatched it, and now it appears this page isn't in quirks mode anymore. I would be OK with going with IE or WebKit instead of Gecko, except that I don't know what they're doing. They do not match the spec. Here are two examples (which I found in our bug database with a brief search): This one is broken in Opera/the spec, and don't collapse in IE9/Gecko/WebKit: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2174 This one collapses in Opera/IE9/the spec, and don't collapse in Gecko/WebKit: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2175
Here are more examples that illustrate that Gecko/WebKit/Opera differ from the spec. (IE's log is empty which suggests it's close to what the spec does, however <hr> doesn't collapse, which probably means IE doesn't respect specified margins on <hr>.) http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2176 Note that this only tests <td>, not <body>. IIRC, the handling of bottom margin differ between the two.
Moreover, the spec says to collapse the margin even if a margin was specified in author CSS, which does not match any of IE9/Opera/WebKit/Gecko: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2177
As far as I can tell, IE9's behaviour is simple: Any UA-set margin that collapses with, or is: - the margin adjacent to the top of a Document, <td>, or <th> - the last margin in a Document, <td>, or <th>, even if that margin is not adjacent to the bottom of the Document, <td>, or <th> in question, ...gets set to zero. I couldn't reproduce the <hr> thing. This, however, is apparently not Web-compatible (per comment 15)? Gecko's behaviour is noticeably different than IE9/Safari/Chrome, so I'm reluctant to adopt it, but it does have the advantage of being quite narrow. As far as I can tell, here's what that behaviour is: A node is purple if it is a text node that is not inter-element whitespace, or if it is an element node. A node is blank if it is an element that contains no purple nodes. Set S consists of the following elements: p, dl, multicol, blockquote, h1–h6, listing, plaintext, xmp, pre, ul, menu, dir, ol. Any element from the set S that is the child of a <body>, <td>, or <th> element and has no purple previous siblings has its top margin set to zero. Any element from the set S that is the child of a <body>, <td>, or <th> element, has no purple previous siblings, and is blank, has its bottom margin set to zero also. Any element from the set S that is the child of a <td> or <th> element, has no purple following siblings, and is blank, has its top margin set to zero. Any <p> element that is the child of a <td> or <th> element and has no purple following siblings has its bottom margin set to zero, even if it is not blank. We'd drop 'multicol' if we used this definition since the spec doesn't give it margins anyway. Is this Web-compatible even though it doesn't match IE or Safari/Chrome? (Let me know if I got the descriptions above wrong. In the absence of disagreement, I'll spec Gecko's behaviour using the text above more or less verbatim, as Simon originally requested over a year ago. If anyone has a better term than "purple", let me know. The term "blank" is from Selectors. The name of set "S" will be more verbose.)
astearns suggests "substantial" instead of "purple", which seems reasonable.
I believe your description is correct as long as "has its * margin set to zero" just means there is a UA sheet rule to that effect (so that pages can still change the styling however they want).
Fwiw, Gecko calls the "purple" nodes "significant children". Though significance is parametrized on some booleans ("text is significant" and "whitespace is significant").
Yeah, this would be setting the margins in the UA sheet only. Actually, Tab brings up an interesting point in IRC, which is that Gecko is affected by 'white-space:pre': http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2231 So I guess the definition (using 'significant' instead of 'purple') has to be: A node is significant if it is an element or if it generates a box that is not an inline box containing only collapsible whitespace. ...or some such?
Make that: A node is significant if it is an element or if it generates a box that is not an anonymous inline box containing only collapsible whitespace.
(Note to self: when fixing this, search for "collapsed to zero".)
Nevermind, I'm dumb. Ignore comments 22 and 23. My test was misleading. http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2234
(And for the record, Re comment 22: the comments Tab made on IRC were correct, it was my mistake in extrapolating from them that led to the error above. :-) )
I was about to say! This stuff can't depend on the value of white-space, since it affects selector-matching in Gecko. ;)
Checked in as WHATWG revision r7924. Check-in comment: Define margin collapsing quirk in more detail. http://html5.org/tools/web-apps-tracker?from=7923&to=7924