7978 2009-10-20 11:58:38 +0000 Form foster parenting introduces extra space to layout 2010-10-04 13:57:03 +0000 1 1 1 Unclassified HTML WG pre-LC1 HTML5 spec (editor: Ian Hickson) unspecified PC All CLOSED FIXED https://bugzilla.mozilla.org/show_bug.cgi?id=510063 NE P2 normal --- 1 hsivonen ian annevk bzbarsky ian mike public-html-admin public-html-wg-issue-tracking zcorpan public-html-bugzilla oldest_to_newest 28580 0 hsivonen 2009-10-20 11:58:38 +0000 See https://bugzilla.mozilla.org/show_bug.cgi?id=510063 The issue needs a spec-level solution. 28681 1 zcorpan 2009-10-21 08:00:25 +0000 "Inserting a form on a page would often break the pixel-perfect design by pushing things around. That was caused by the forms margins, but I didnt know that. So to prevent this I used to insert the forms start and end tags between table rows." - http://www.456bereastreet.com/archive/200511/reveal_your_old_school_web_development_hacks/ I think we should just change the parser to not foster parent forms, to match old Gecko and WebKit (and not break oldschool pixel-perfect designs with 1em gaps whitespace here and there). 28755 2 ian 2009-10-21 11:39:03 +0000 What exactly would this consist of? Does it affect the foster parenting that goes on in the AAA also? How do we deal with kids, like "<table><form>x"? What about "<table><form><input type=hidden>"? Why would these forms inside tables not affecting the rendering even more than forms outside tables? 28762 3 hsivonen 2009-10-21 12:03:11 +0000 (In reply to comment #2) > Why would these forms inside tables not affecting the rendering even more than > forms outside tables? They need to be made display: none; in the rendering section. http://mxr.mozilla.org/mozilla-central/source/layout/style/html.css#273 28772 4 hsivonen 2009-10-21 12:16:58 +0000 (In reply to comment #3) > They need to be made display: none; in the rendering section. > http://mxr.mozilla.org/mozilla-central/source/layout/style/html.css#273 :-moz-is-html means "the HTMLness bit of the owner document of this node is true". 28833 5 ian 2009-10-23 05:11:50 +0000 Why check for the HTML bit? Seems like the same could be applied in XHTML. EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Accepted Change Description: see diff given below Rationale: Concurred with reporter's comments. 28834 6 contributor 2009-10-23 05:12:46 +0000 Checked in as WHATWG revision r4288. Check-in comment: Change for <form> is parsed in <table>. http://html5.org/tools/web-apps-tracker?from=4287&to=4288 29018 7 hsivonen 2009-10-26 12:27:58 +0000 (In reply to comment #5) > Why check for the HTML bit? Seems like the same could be applied in XHTML. CCing Boris, because I recall discussing this with him but I forgot what the reason for applying the style in HTML documents only was. 29020 8 bzbarsky 2009-10-26 13:16:10 +0000 Because if you apply that in XHTML, then the following perfectly reasonable (from a parsing point of view; it's clearly invalid) XHTML document won't work right: <body> <table> <form> <tr><td>Some text</td></tr> </form> </table> </body> This is a common pattern in HTML authoring, in fact; the display:none is OK in HTML because in this case the <form> ends up empty when parsed as HTML. 29025 9 bzbarsky 2009-10-26 14:13:27 +0000 So I'm trying to understand the change linked to in comment 6. What behavior does it give for the following document: <body> <table> <form><tr><td><input name="one"></td></tr></form> <form><tr><td><input name="two"></td></tr></form> </table> <input name="three"> <form><input name="four"></form> <input name="five"> </body> ? What does the DOM look like? Which input is associated with which form? How does that compare to what UAs do currently? 29030 10 zcorpan 2009-10-26 14:40:40 +0000 (In reply to comment #8) > Because if you apply that in XHTML, then the following perfectly reasonable > (from a parsing point of view; it's clearly invalid) XHTML document won't work > right: > > <body> > <table> > <form> > <tr><td>Some text</td></tr> > </form> > </table> > </body> You could end up with this tree in HTML too with scripting. Does it matter? Could we use :empty instead of :htmlness if it matters, or is that more expensive? > This is a common pattern in HTML authoring, in fact; the display:none is OK in > HTML because in this case the <form> ends up empty when parsed as HTML. 29031 11 zcorpan 2009-10-26 14:52:29 +0000 (In reply to comment #9) > So I'm trying to understand the change linked to in comment 6. What behavior > does it give for the following document: > > <body> > <table> > <form><tr><td><input name="one"></td></tr></form> > <form><tr><td><input name="two"></td></tr></form> > </table> > <input name="three"> > <form><input name="four"></form> > <input name="five"> > </body> > > ? What does the DOM look like? Like this XML: <body> <table> <form/><tbody><tr><td><input name="one"/></td></tr> <form/><tr><td><input name="two"/></td></tr> </tbody></table> <input name="three"/> <form><input name="four"/></form> <input name="five"/> </body> > Which input is associated with which form? Same as before. "three" and "five" aren't associated with any form; "one", "two" and "four" are associated with the form you'd expect. > How does that compare to what UAs do currently? http://software.hixie.ch/utilities/js/live-dom-viewer/saved/292 In this case it seems to match old Gecko, WebKit and Opera (even though Opera has a different strategy for dealing with forms in tables currently). The association should match IE, too. 29032 12 bzbarsky 2009-10-26 15:11:33 +0000 > You could end up with this tree in HTML too with scripting. Does it matter? Apparently not, since Mozilla has gotten no bug reports on it, unlike the other approaches we've tried here. > Could we use :empty instead of :htmlness if it matters, or is that more > expensive? :empty is certainly more expensive; I can't say how much more offhand. In some cases it's probably not noticeable at all. On the other hand, I can certainly construct pathological testcases which cause :empty to trigger O(N) behavior on append in Gecko. I can't speak to other engines. Comment 11 sounds good. 29033 13 bzbarsky 2009-10-26 15:13:32 +0000 I should note that the fact that :empty could trigger said O(N) behavior in cases when the form is not in fact a child of a table/tr is considered a bug: https://bugzilla.mozilla.org/show_bug.cgi?id=501848 29034 14 zcorpan 2009-10-26 15:24:56 +0000 (In reply to comment #12) > > You could end up with this tree in HTML too with scripting. Does it matter? > > Apparently not, since Mozilla has gotten no bug reports on it, unlike the other > approaches we've tried here. Ok. But does the invalid XHTML case matter? 29036 15 bzbarsky 2009-10-26 15:36:34 +0000 It seems like the behavior for that case is well-specified by the XML (for the parsing) and CSS (for the layout) specifications. If the HTML specification requires a UA stylesheet that modifies that behavior, then we could probably get away with making that form display:none; absent that, doing so would be a bug, pure and simple. Are we ok with documents either showing the form elements or not depending on whether they're served as HTML or XHTML? I realize there will be other layout differences between the two in this case, but this is a slightly different order of breakage. 29037 16 annevk 2009-10-26 15:53:28 +0000 FWIW, it makes more sense to me if HTML and XHTML have the same style sheet applied to them. I doubt we'd break existing invalid XHTML by doing this, but I guess we'll notice when someone ships with this. 29038 17 bzbarsky 2009-10-26 15:57:45 +0000 What's the context for the stylesheet change in that diff? Is that a required stylesheet (MUST), or a recommended one (SHOULD)? Note that I'm somewhat averse to in-the-wild experimentation on this topic (aka the "ship and see what breaks and what bad press you get" approach), since it seems that there are solutions not requiring that. In general, that feels like it ought to be a last resort unless there is hard data that there should be minimal compat issues (e.g. at least one major UA already ships the behavior). 29042 18 zcorpan 2009-10-26 19:05:05 +0000 (In reply to comment #17) > What's the context for the stylesheet change in that diff? Is that a required > stylesheet (MUST), or a recommended one (SHOULD)? The rendering section is non-normative, so neither. However, I think the goal is for visual interactive desktop browsers to follow it exactly... http://www.whatwg.org/specs/web-apps/current-work/multipage/rendering.html#rendering 29043 19 bzbarsky 2009-10-26 19:25:37 +0000 The point is, if someone shows up and says "this breaks my site", then we need to either point to the part of the HTML spec that requires us to have this bizarre behavior in XHTML or admit that the breakage is a browser bug, no? 29044 20 zcorpan 2009-10-26 19:36:54 +0000 You could point out that they're using invalid XHTML, and that HTML5's rendering section says to do this, and that doing this is a slight performance win (or maybe it isn't?). I could say that Opera would be ready to do this, but we'd need to switch to the HTML5 way or parsing and so first so it'd be some time yet until we could actually usefully do it. I wouldn't object to making HTML5 say to have different behavior for HTML and XHTML in this case for now and revisit this when Opera is ready to do the experiment. 29048 21 ian 2009-10-27 00:44:38 +0000 (In reply to comment #8) > Because if you apply that in XHTML, then the following perfectly reasonable > (from a parsing point of view; it's clearly invalid) XHTML document won't work > right: > > <body> > <table> > <form> > <tr><td>Some text</td></tr> > </form> > </table> > </body> This wouldn't work right anyway. You'd end up with two nested CSS tables. So I don't really see that it matters if we make this display:none or display:block. The spec change doesn't require the 'display:none' on table>form to be !important, unlike the Gecko implementation. Is that a problem? I don't mind changing any of this, but I'd really like to avoid quirks or XHTML mode differences if at all possible. Please reopen the bug if there's something to change. 29049 22 ian 2009-10-27 00:46:15 +0000 Based on https://bugzilla.mozilla.org/show_bug.cgi?id=349695 I assume that this needs to be hard-coded for HTML (without the ability for author-CSS to override); if this is the case, it probably makes sense to make it HTML only. If anyone concurs that this should indeed change, please reopen the bug. 29050 23 bzbarsky 2009-10-27 01:38:11 +0000 > You'd end up with two nested CSS tables. Sure. Note that sites do that a good bit by setting "display: block" on their table rows right now, by the way. > So I don't really see that it matters if we make this display:none or > display:block. You don't think it matters whether the user can see the inputs? > Is that a problem? As you note in comment 22, yes. > if this is the case, it probably makes sense to make it HTML only. Right. > If anyone concurs that this should indeed change, please reopen the bug. I would love to do that, but do not have editbugs bits in this bugzilla, and therefore cannot do so. 29051 24 ian 2009-10-27 02:00:57 +0000 zcorpan/mike, can you hook bz up with perms? 29053 25 ian 2009-10-27 10:01:43 +0000 EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Accepted Change Description: see diff given below Rationale: Concurred with reporters' comments. 29054 26 contributor 2009-10-27 10:02:35 +0000 Checked in as WHATWG revision r4347. Check-in comment: Rephrase how <form> in <table> is to be hidden for compatibility. http://html5.org/tools/web-apps-tracker?from=4346&to=4347 29162 27 hsivonen 2009-10-28 07:44:00 +0000 Thanks.