<legend> implies <fieldset> in parser

RESOLVED FIXED

Status

()

Core
HTML: Parser
P2
normal
RESOLVED FIXED
10 years ago
6 years ago

People

(Reporter: Hixie (not reading bugmail), Assigned: mats)

Tracking

({html5, testcase})

Trunk
html5, testcase
Points:
---
Bug Flags:
wanted1.9.1 +
wanted1.9.0.x -

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [fixed by the HTML5 parser], URL)

Attachments

(5 attachments, 3 obsolete attachments)

(Reporter)

Description

10 years ago
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

10 years ago
Created attachment 317400 [details]
Testcase #2
(Assignee)

Updated

10 years ago
Keywords: testcase
OS: Mac OS X → All
Hardware: PC → All
Version: unspecified → Trunk
Is this a dupe of bug 423721?
(Assignee)

Comment 3

10 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

10 years ago
Created attachment 317407 [details] [diff] [review]
Patch rev. 1

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

10 years ago
Created attachment 317408 [details] [diff] [review]
mochitest.diff

This includes both Hixie's original testcase and Testcase #2.
(Assignee)

Comment 6

10 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)

Updated

10 years ago
Duplicate of this bug: 423721
(Assignee)

Comment 8

10 years ago
Created attachment 317417 [details] [diff] [review]
mochitest.diff, rev. 2

A few more tests...
Attachment #317408 - Attachment is obsolete: true

Comment 9

10 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?

Updated

10 years ago
Keywords: html5

Comment 10

10 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?
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

10 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

9 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

9 years ago
Created attachment 360120 [details]
Test case with multiple figures, images and legends.  Upload did not include images; see http://gemusicboosters.org/about_rss_figure.html

Updated

9 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

9 years ago
Created attachment 360123 [details]
Test case with multiple figures, legends and captions

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

9 years ago
Created attachment 366288 [details]
test case for legend element in various containers

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 18

9 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

9 years ago
Created attachment 366358 [details]
test case for legend element in various containers

The last test case was accidentally the actual _rendered_ source. This is the "source" source.
Attachment #366288 - Attachment is obsolete: true

Comment 20

9 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
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
Last Resolved: 8 years ago
Resolution: --- → FIXED
Whiteboard: [fixed by the HTML5 parser]

Comment 22

6 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.