15993 2012-02-15 12:22:43 +0000 The margin collapsing quirks is not described properly 2013-06-06 20:33:37 +0000 1 1 1 Unclassified WHATWG HTML unspecified Other other RESOLVED FIXED http://www.whatwg.org/specs/web-apps/current-work/#tables P3 normal Unsorted 1 contributor ian adrianba bzbarsky dbaron eoconnor ian jackalmage mike mjs sylvaing tross zcorpan contributor oldest_to_newest 64138 0 contributor 2012-02-15 12:22:43 +0000 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 64140 1 zcorpan 2012-02-15 12:51:05 +0000 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. 64141 2 zcorpan 2012-02-15 12:52:08 +0000 Also, not collapse, but set to 0. 70577 3 contributor 2012-07-18 16:17:37 +0000 This bug was cloned to create bug 18054 as part of operation convergence. 73961 4 ian 2012-09-15 17:59:59 +0000 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.) 73990 5 zcorpan 2012-09-17 07:43:38 +0000 (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. 74092 6 ian 2012-09-19 22:22:36 +0000 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? 76345 7 ian 2012-10-15 23:18:44 +0000 zcorpan: ping 76359 8 zcorpan 2012-10-16 08:31:33 +0000 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.) 82174 9 ian 2013-01-26 00:00:30 +0000 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? 82176 10 dbaron 2013-01-26 00:10:58 +0000 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.) 82177 11 ian 2013-01-26 00:48:17 +0000 dbaron: What does :-moz-only-whitespace:-moz-last-node do? 82182 12 dbaron 2013-01-26 01:06:10 +0000 :-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. 82183 13 dbaron 2013-01-26 01:08:29 +0000 (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).) 82212 14 sylvaing 2013-01-27 00:32:23 +0000 Simon, can you share an example of a site broken in Opera that you believe would be fixed by this change? 84789 15 zcorpan 2013-03-21 19:50:24 +0000 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 84790 16 zcorpan 2013-03-21 20:16:25 +0000 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. 84791 17 zcorpan 2013-03-21 20:22:47 +0000 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 86957 18 ian 2013-04-29 22:31:02 +0000 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.) 86960 19 ian 2013-04-29 22:37:01 +0000 astearns suggests "substantial" instead of "purple", which seems reasonable. 86963 20 bzbarsky 2013-04-29 22:46:22 +0000 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). 86964 21 bzbarsky 2013-04-29 22:49:06 +0000 Fwiw, Gecko calls the "purple" nodes "significant children". Though significance is parametrized on some booleans ("text is significant" and "whitespace is significant"). 86966 22 ian 2013-04-29 23:00:17 +0000 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? 86967 23 ian 2013-04-29 23:07:15 +0000 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. 86968 24 ian 2013-04-29 23:08:16 +0000 (Note to self: when fixing this, search for "collapsed to zero".) 86970 25 ian 2013-04-29 23:20:47 +0000 Nevermind, I'm dumb. Ignore comments 22 and 23. My test was misleading. http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2234 86972 26 ian 2013-04-29 23:23:43 +0000 (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. :-) ) 86979 27 bzbarsky 2013-04-30 01:18:39 +0000 I was about to say! This stuff can't depend on the value of white-space, since it affects selector-matching in Gecko. ;) 88855 28 contributor 2013-06-06 20:33:37 +0000 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