Closed
Bug 430416
Opened 16 years ago
Closed 14 years ago
<legend> implies <fieldset> in parser
Categories
(Core :: DOM: HTML Parser, defect, P2)
Core
DOM: HTML Parser
Tracking
()
RESOLVED
FIXED
People
(Reporter: ian, Assigned: MatsPalmgren_bugz)
References
()
Details
(Keywords: html5, testcase, Whiteboard: [fixed by the HTML5 parser])
Attachments
(5 files, 3 obsolete files)
1.22 KB,
text/html
|
Details | |
4.39 KB,
patch
|
Details | Diff | Splinter Review | |
7.10 KB,
patch
|
Details | Diff | Splinter Review | |
7.55 KB,
text/html
|
Details | |
1.62 KB,
text/html
|
Details |
STEPS TO REPRODUCE: 1. parse data:text/html,<legend>test</legend> 2. examine the DOM EXPECTED RESULTS <html><head></head><body><legend>test</legend></body></html> ACTUAL RESULTS There's a <fieldset> in there! See also: http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E...%3Clegend%3E...%3C%2Flegend%3E If we can resolved this relatively soon (like a FF3 point release) that would be cool. If we can't get browsers to fix this, then we're going to have to introduce a new element for <figure>'s caption, which would be a pain. As far as I know, other browsers don't have this behaviour with <legend>.
Assignee | ||
Comment 1•16 years ago
|
||
Assignee | ||
Updated•16 years ago
|
Comment 2•16 years ago
|
||
Is this a dupe of bug 423721?
Assignee | ||
Comment 3•16 years ago
|
||
Testcase #2 results in summary, IE/Safari/Opera accepts block level children IE/Opera creates empty legend node when outside fieldset Safari does not create a DOM node at all if not direct child of fieldset IE/Opera accepts legend as direct child of legend [inside a fieldset]
Assignee | ||
Comment 4•16 years ago
|
||
It looks fairly straight forward to fix... I looked through the frame constructor briefly, we have some special code to arrange legend frames inside a fieldset frame but that shouldn't be affected by this change. We also have a hack in nsHTMLLegendElement for accesskey handling, it won't cause problems but we probably want to look at that code again at some to decide what is really correct for stray legends.
Assignee | ||
Comment 5•16 years ago
|
||
This includes both Hixie's original testcase and Testcase #2.
Assignee | ||
Comment 6•16 years ago
|
||
In summary, the patch creates legend DOM nodes also when outside a fieldset; does not auto-create a fieldset; auto-close legend when bumping into a block-level tag, or a legend tag. The attached mochitest.diff includes the input and resulting DOM tree.
Assignee | ||
Comment 8•16 years ago
|
||
A few more tests...
Attachment #317408 -
Attachment is obsolete: true
Comment 9•16 years ago
|
||
(In reply to comment #2) > Is this a dupe of bug 423721? > Yep, it is/was. Without this, the HTML5 constructs[1]: <figure><img/><legend>caption for the image</legend></figure> and <figure><legend>caption for the image</legend><img/></figure> are a royal pain to use. Since early bug triage has begun, requesting wanted1.9.1 to get it on radar early in cycle. 1: http://www.whatwg.org/specs/web-apps/current-work/#the-figure
Flags: wanted1.9.1?
Comment 10•16 years ago
|
||
Adding wanted1.9.0.x? in case someone thinks this and another legend-related bug (bug 433700) should perhaps both go in (same?) point release.
Flags: wanted1.9.0.x?
Comment 11•16 years ago
|
||
Mats, I assume you double-checked that nsLegendFrame doesn't do anything during layout that depends on it being in the fieldset?
Assignee: nobody → mats.palmgren
Flags: wanted1.9.1?
Flags: wanted1.9.1+
Flags: wanted1.9.0.x?
Flags: wanted1.9.0.x-
Priority: -- → P2
Comment 12•16 years ago
|
||
Mats, since this is wanted for 1.9.1 and the beta1 freeze is rapidly approaching...any status update? Sorry for the bugspam
Depends on: 476063
Comment 13•15 years ago
|
||
I looked at your test cases, and they show DOM illustrations. I am uploading an example test page that has multiple <figure> tags, each with a <legend> and <img>. It looks like the first legend turns on an outline box starting above my image (expected), but doesn't turn it off until the end of the document. Additionally, the width is the entire screen, not just the width of the image. I am using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b2) Gecko/20081201 Firefox/3.1b2 (.NET CLR 3.5.30729)
Comment 14•15 years ago
|
||
Updated•15 years ago
|
Attachment #360120 -
Attachment description: Test case with multiple figures, images and legends. → Test case with multiple figures, images and legends. Upload did not include images; see http://gemusicboosters.org/about_rss_figure.html
Comment 15•15 years ago
|
||
Hopefully this attempt will include all of the images. The original document is at http://gemusicboosters.org/about_rss_figure.html
Attachment #360120 -
Attachment is obsolete: true
Comment 16•15 years ago
|
||
In my test, the legend is simply REMOVED if included in a figure _and_ a div, or any inline element (the latter being invalid HTML5 anyway though). So in those cases, a fieldset is not inserted. Should I create another bug for that behaviour? Original test at http://jacobrask.net/lab/debug/legend.html
Comment 17•15 years ago
|
||
That testcase doesn't have a <legend> in the "legend wrapped in figure and div" section.
Comment 18•15 years ago
|
||
Comment on attachment 366288 [details] test case for legend element in various containers <!DOCTYPE html> <html lang="en"> <head> <meta charset="utf-8"> <title>legend / figure test in HTML5</title> </head> <body> <h1>testing <code>legend</code> behaviour in <abbr>HTML5</abbr></h1> <p>The <code>legend</code> element is <em>removed</em> in Firefox if contained within a <code>figure</code> <em>and</em> a <code>div</code> element. This also applies when wrapped with any inline elements, but that is invalid <abbr>HTML5</abbr> anyway.</p> <p>Also, as described in <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=430416">this bug report</a> including the <code>legend</code> element without a <code>fieldset</code> element as a parent automatically inserts a <code>fieldset</code> containing the remainder of the <code>body</code>.</p> <p><code>style="color:red;font-weight:bold;"</code> is applied to all <code>legend</code>s.</p> <!-- example 1 --> <fieldset> <legend style="color:red;font-weight:bold;">Example legend text</legend> <p><code>legend</code> wrapped in a <code>fieldset</code>.</p> </fieldset> <!-- example 2 --> <div> <figure> <legend style="color:red;">Example legend text</legend> <p><code>legend</code> wrapped in <code>figure</code> and <code>div</code>.</p> </figure> </div> <!-- example 3 --> <figure> <legend style="color:red;">Example legend text</legend> <p><code>legend</code> wrapped only in <code>figure</code>.</p> </figure> <p>Some random text outside the last <code>figure</code> element.</p> <p>Some random text outside the last <code>figure</code> element.</p> <!-- example 4 --> <legend style="color:red;">Example legend text</legend> <p><code>legend</code> on it's own.</p> </body> </html>
Comment 19•15 years ago
|
||
The last test case was accidentally the actual _rendered_ source. This is the "source" source.
Attachment #366288 -
Attachment is obsolete: true
Comment 20•15 years ago
|
||
Bump. This bug goes away if serving as application/xhtml+xml. This is holding back HTML5 support. I'm serving as xhtml on my website because of this bug. Please fix so I can drop the x. http://camendesign.com
Comment 21•15 years ago
|
||
Not to dispute importance (although as a matter of principle I think it would be much better if HTML5 introduced a <description> element for this use rather than reusing one that's heavily overloaded with form baggage), but there's a workaround pointed out by Hixie: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-February/014038.html <style type="text/css"> figure legend, figure .legend { display: block; /* legend has this in HTML5, must replicate for the span */ } </style> <figure> <img src="lolcat.jpg" alt="A cat whose body fully occupies a small wastebasket" /> <legend><span class="legend">Trashcat is not amused</span></legend> </figure> There's some complication regarding how the legend element may be used -- it must be the direct child of the figure, and it can't contain block-level elements (so <div><legend/></div> and <legend><p/></legend> aren't acceptable) -- but this hackaround does work reliably, and I currently use it on my own site.
Updated•14 years ago
|
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Whiteboard: [fixed by the HTML5 parser]
Comment 22•12 years ago
|
||
It looks like <figcaption> is the preferred tag to use, and it can be styled in CSS without affecting <legend> tags anywhere else.
You need to log in
before you can comment on or make changes to this bug.
Description
•