Closed Bug 430416 Opened 16 years ago Closed 14 years ago

<legend> implies <fieldset> in parser

Categories

(Core :: DOM: HTML Parser, defect, P2)

defect

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)

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>.
Attached file Testcase #2
Keywords: testcase
OS: Mac OS X → All
Hardware: PC → All
Version: unspecified → Trunk
Is this a dupe of bug 423721?
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]
Attached patch Patch rev. 1Splinter Review
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.
Attached patch mochitest.diff (obsolete) — Splinter Review
This includes both Hixie's original testcase and Testcase #2.
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.
A few more tests...
Attachment #317408 - Attachment is obsolete: true
(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?
Keywords: html5
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?
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
Mats, since this is wanted for 1.9.1 and the beta1 freeze is rapidly approaching...any status update?

Sorry for the bugspam
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)
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
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
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
That testcase doesn't have a <legend> in the "legend wrapped in figure and div" section.
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>
The last test case was accidentally the actual _rendered_ source. This is the "source" source.
Attachment #366288 - Attachment is obsolete: true
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
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.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Whiteboard: [fixed by the HTML5 parser]
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.

Attachment

General

Created:
Updated:
Size: