This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
See https://bugzilla.mozilla.org/show_bug.cgi?id=510063 The issue needs a spec-level solution.
"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).
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?
(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
(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".
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.
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
(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.
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.
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?
(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.
(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.
> 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.
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
(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?
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.
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.
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).
(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
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?
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.
(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.
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.
> 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.
zcorpan/mike, can you hook bz up with perms?
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.
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
Thanks.