This is my bug report sent via "Feedback Comments" form in "Status of This document" section of the HTML5 spec (http://www.w3.org/TR/html5/).

Same response as your <figcaption> bug.  Any case where you want to wrap <legend> in <div>s, you can instead just wrap the <legend>'s contents.

(In reply to comment #2)
Completely wrong. Things that are not legend at all should not be inserted into legend element. It would be semantically nonsensical and harmful.

(In reply to comment #2)
> Same response as your <figcaption> bug.  Any case where you want to wrap
> <legend> in <div>s, you can instead just wrap the <legend>'s contents.

<legend> can only contain phrasing content.

Can you give an example of what you mean? I'm not sure I follow the problem here. Do you have an example of a real page that has this issue?

(In reply to comment #5)
> Can you give an example of what you mean? I'm not sure I follow the problem
> here. Do you have an example of a real page that has this issue?

The bug is an isolated situation. Please see more common bug report (bug 13062)
that I have created.

Thanks.

mass-move component to LC1

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: Did Not Understand Request
Change Description: no spec change
Rationale: Please give specific examples for this specific case if you wish it to be considered. As it stands, I do not understand what specific problem with <legend> exists here or how it affects real sites.

(In reply to comment #8)
> Please give specific examples for this specific case if you wish it
> to be considered.

Example is provided in description of bug 13062:

    <fielset>
        <div>
            <ul>
                <li><a href="#">Minimize</a></li>
                <li><a href="#">Close</a></li>
            </ul>
            <legend>Example</legend>
        </div>
    </fieldset>

You need to reopen the bug if you want the editor to consider further comments.  He doesn't see resolved bugs -- his script filters them out.

> Example is provided in description of bug 13062:
> 
>     <fielset>
>         <div>
>             <ul>
>                 <li><a href="#">Minimize</a></li>
>                 <li><a href="#">Close</a></li>
>             </ul>
>             <legend>Example</legend>
>         </div>
>     </fieldset>

I don't understand why this isn't sufficient:

    <fieldset>
      <legend>Example</legend>
      <ul>
        <li><a href="#">Minimize</a></li>
        <li><a href="#">Close</a></li>
      </il>
    </fieldset>

(In reply to comment #11)

The code is brief example of what should be valid.

In real world, DIV, of course, is followed by actual form fields themselves:

    <fielset>
        <div>
            <ul>
                <li><a href="#">Minimize</a></li>
                <li><a href="#">Close</a></li>
            </ul>
            <legend>Example</legend>
        </div>
        <input type="text" name="something" />
        <input type="text" name="another-field" />
        ...
    </fieldset>

Here, DIV wrapper is needed only for legend and functional-links list (to style them together), not for all contents of the fieldset.

(In reply to comment #12)
> 
>     <fielset>
>         <div>
>             <ul>
>                 <li><a href="#">Minimize</a></li>
>                 <li><a href="#">Close</a></li>
>             </ul>
>             <legend>Example</legend>
>         </div>
>         <input type="text" name="something" />
>         <input type="text" name="another-field" />
>         ...
>     </fieldset>

Why can't you do:

     <fielset>
         <legend>Example</legend>
         <div>
             <ul>
                 <li><a href="#">Minimize</a></li>
                 <li><a href="#">Close</a></li>
             </ul>
         </div>
         <input type="text" name="something" />
         <input type="text" name="another-field" />
         ...
     </fieldset>

...?

(In reply to comment #13)

Because, in real-world web-development, specific visual decoration is often unachievable without a wrapper. It's axiom.

That's why requirement for displayable specific  element to be direct child of another displayable specific element is purely theoretic and detached from reality.

In my example, legend is needed to be _inside_ wrapper and cannot be outside it. These are completely different situations.

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: Did Not Understand Request
Change Description: no spec change
Rationale: Then you still haven't provided a complete example.

Please provide a complete example showing what result you want, and how you cannot achieve it currently without doing what you propose. This means you need to include all the CSS, scripts, markup, images, whatever, that are necessary to demonstrate the problem.

(In reply to comment #15)

Consequences of inability to add an extra-wrapper for layout purposes are obvious for any practicing client-side web-developer.

Though, if it's needed, here is a bunch of testcases:
http://tanalin.com/_experimentz/bugs/w3/html/wrap-legend/

Thanks.

(In reply to comment #16)
> (In reply to comment #15) 
> Though, if it's needed, here is a bunch of testcases:
> http://tanalin.com/_experimentz/bugs/w3/html/wrap-legend/

What are you hoping user agents for blind and high magnification users will do with these bits of extra text? What are their semantics? It's traditionally been a bad idea to place text in forms that is not associated to a field/control using a defined relationship (e.g. <label>, <legend>, @title, @aria-labelledby, @aria-describedby, etc.), since otherwise the user might miss the text when tabbing through the fields/controls of the form.

(In reply to comment #17)

The testcases just bulletproofly illustrate how _layout_ possibilities can be heavily limited by purely theoretical spec-requirement contradicting to actual browser support.

If some effect is needed for layout, then it will be achieved _anyway_. And if it cannot be achieved using semantic LEGEND element just because 'spec says this is invalid', then just an other element will be used instead of LEGEND. Needless to say that LEGEND missing at all would be semantically (and thus for accessibility) much worse than just wrapping LEGEND in DIV. (By the way, this rationale is quite clearly described in description (comment 0) of the bug.)

(In reply to comment #18)
> (In reply to comment #17)
> 
> The testcases just bulletproofly illustrate how _layout_ possibilities can be
> heavily limited by purely theoretical spec-requirement contradicting to actual
> browser support.

Indeed, and as such they do not answer my question.

It's not obvious to me that the only way to achieve the layout effects you mention is to put the extra text inside fieldset, but more generally if you cannot determine the semantics you need to express, then you cannot determine the actual DOM that needs styling, so you cannot begin to assess whether CSS does or does not include the features required to achieve the layouts you want.

> If some effect is needed for layout, then it will be achieved _anyway_. And if
> it cannot be achieved using semantic LEGEND element just because 'spec says
> this is invalid', then just an other element will be used instead of LEGEND.

Perhaps. But this might imply a deficiency to be fixed in CSS not HTML. 

> By the way, this rationale is quite clearly described in description (comment 0) of the bug.

I read Comment 0, but it doesn't describe the semantic relationships in play.

Perhaps pointing to some real-world designs would help clarify what semantics these odd layouts are attempting to visually express?

(In reply to comment #19)

> It's not obvious to me that the only way to achieve the layout effects you
> mention is to put the extra text inside fieldset

Hm, text is not a _solution_ to something here. Texts in the testcases are means to illustrate spec shortcoming as for LEGEND. So this your phrase is probably result of some multiple typos or just misunderstanding of the testcases or of intention of them.

> > If some effect is needed for layout, then it will be achieved _anyway_. And if
> > it cannot be achieved using semantic LEGEND element just because 'spec says
> > this is invalid', then just an other element will be used instead of LEGEND.
> 
> Perhaps. But this might imply a deficiency to be fixed in CSS not HTML. 

CSS currently cannot generate wrappers. On the contrary, we can easily add wrappers in HTML _right now_. So some potential fixing of CSS in some potential future is not an equivalent option. Fixing HTML here does not need to implement _anything_ new in browsers -- it _already_ works and should be just documented to make pages formally valid.

> > By the way, this rationale is quite clearly described in description (comment 0) of the bug.
> 
> I read Comment 0, but it doesn't describe the semantic relationships in play.
> 
> Perhaps pointing to some real-world designs would help clarify what semantics
> these odd layouts are attempting to visually express?

Initially I've encountered need for arbitrary styling of LEGEND. (I believe that LEGEND is most appropriate semantic element for use as fieldset header -- for accessibility in particular.) Then, I've discovered that possibilities of legend styling are considerably differ between browsers. Then I've tried to wrap legend in DIV to style the wrapper instead of legend itself while still having LEGEND element for semantics purposes. Then I've discovered that this is formally invalid though actually perfectly works in real browsers.

The bug itself is about fundamental theoretical issue: instead of requiring an element to be literally first direct child, it would be much smarter and practical to define it as "first descendant element [of specific type] in document tree order". For additional clarification: in terms of JavaScript, instead of:

fieldset.firstElementChild

we should use:
fieldset.getElementsByTagName('legend').item(0).

We have reasons why the current requirement is bad while not having any serious reasons why wrapping legend in DIV is bad. It's enough to accept the bug, in my opinion.

(In reply to comment #20)
> (In reply to comment #19)
> 
> > It's not obvious to me that the only way to achieve the layout effects you
> > mention is to put the extra text inside fieldset
> 
> Hm, text is not a _solution_ to something here. Texts in the testcases are
> means to illustrate spec shortcoming as for LEGEND. 

Since we don't particularly want to allow extraneous text before <legend>, I fail to see how.

> CSS currently cannot generate wrappers. On the contrary, we can easily add
> wrappers in HTML _right now_. So some potential fixing of CSS in some potential
> future is not an equivalent option. Fixing HTML here does not need to implement
> _anything_ new in browsers -- it _already_ works and should be just documented
> to make pages formally valid.

The claim that it "_already_ works" seems plausible but would need to be verified by demonstrating that <legend> elements wrapped in or preceded by other elements are still correctly associated with their ancestor <fieldset> elements when HTML documents are represented to the accessibility APIs used by assistive technology and by current AT using those APIs or the DOM.

In the past, there have often been bugs in the plumbing that makes accessibility work, even for markup that follows the standard. For example:

http://green-beast.com/blog/?p=254

Also, just because something already works now does not mean it's the best design long term.

> The bug itself is about fundamental theoretical issue: instead of requiring an
> element to be literally first direct child, it would be much smarter and
> practical to define it as "first descendant element [of specific type] in
> document tree order". 

With respect to simply _wrapping_ legend for the purpose of styling it, can you please point to a design that you think cannot be implemented in HTML5 and CSS3 as currently proposed, rather than test cases that include extraneous text like the ones you linked to?

You haven't given any rationale at all for allowing elements to precede rather than enclose <legend>. If you're *not* proposing to place elements with text before <legend> what do you want these preceding elements for? Why could you not wrap the whole <fieldset> in a <div> and place those preliminary elements outside the <fieldset>?

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: Rejected
Change Description: no spec change
Rationale:

> Consequences of inability to add an extra-wrapper for layout purposes are
> obvious for any practicing client-side web-developer.

If they're so obvious, it should be easy for you to provide the information. Since you refuse to do so, I'm rejecting this bug. If you still think something should be done, then I encourage you to either escalate the bug and try to convince the chairs, or actually provide the information I asked for and reopen this bug.

Please do not reopen this bug if you're not going to actually provide the use case with examples showing why a change is needed to make the use cases work. Without the requested information, I will keep drawing the same conclusions from your statements.

(In reply to comment #22)

Why do you say that I haven't provide the information (testcases that you've requested in comment 15) while I've actually done this (see comment 16)?

For even more clarity, I've added more testcases.

Demo for styling issues of LEGEND as direct child of fieldset as opposed to consistent crossbrowser styling of wrapper:

http://tanalin.com/_experimentz/bugs/w3/html/wrap-legend/#t-5.1
http://tanalin.com/_experimentz/bugs/w3/html/wrap-legend/#t-5.2

Testcase 3 is splitted to two subtestcases (in 3.2, text is after legend instead of before it as in 3.1):

http://tanalin.com/_experimentz/bugs/w3/html/wrap-legend/#t-3.1
http://tanalin.com/_experimentz/bugs/w3/html/wrap-legend/#t-3.2

Thanks.

Here's what I need to be able to evaluate the proposal in this bug:

> Please provide a complete example showing what result you want, and how you
> cannot achieve it currently without doing what you propose. This means you need
> to include all the CSS, scripts, markup, images, whatever, that are necessary
> to demonstrate the problem.

These test cases are not it. They do not show the rendering you would like, they just do things that are currently invalid and claim that the result is more interoperable than some hypothetical other rendering without explaining what the rendering should be, what the browsers do now, etc.

Note that if your use case is "I want more styling control over <legend>", then the right place to ask for that is the CSS working group. (And it's being worked on already.)

(In reply to comment #25)
> Here's what I need to be able to evaluate the proposal in this bug:
> 
> > Please provide a complete example showing what result you want, and how you
> > cannot achieve it currently without doing what you propose. This means you need
> > to include all the CSS, scripts, markup, images, whatever, that are necessary
> > to demonstrate the problem.
> 
> These test cases are not it. They do not show the rendering you would like,
> they just do things that are currently invalid and claim that the result is
> more interoperable than some hypothetical other rendering without explaining
> what the rendering should be, what the browsers do now, etc.

How can I show desired result using something that don't allow to achieve this desired result? 

The testcases shows exactly "the rendering I would like". If they currently are formally invalid, this does not make rendering wrong or unclear. What exactly don't you understand in the testcases (if any)?

> Note that if your use case is "I want more styling control over <legend>", then
> the right place to ask for that is the CSS working group. (And it's being
> worked on already.)

Quoting myself from comment 20:

CSS currently cannot generate wrappers. On the contrary, we can easily add
wrappers in HTML _right now_. So some potential fixing of CSS in some potential
future is not an equivalent option.

Ian, I've added "Issue" block to each of testcases. "Issue" block describes exact issue with current spec as for concrete testcase. Maybe this will help.

> How can I show desired result using something that don't allow to achieve this
> desired result? 

Any number of ways, e.g. an image, or prose description.


> The testcases shows exactly "the rendering I would like".

In what browser, what version, on what platform?


> What exactly don't you understand in the testcases (if any)?

When I suggest that rendering problems should be fixed by fixing CSS, you mention wrappers. Yet I see no wrappers in the rendering on my browser.


From looking at your updated test case, as far as I can see, your use case is:

"I would like to have a fieldset with a border, and I would like the legend of that fieldset to be entirely within the border of the fieldset, not straddling the fieldset border". Is that correct?

(In reply to comment #28)
> > How can I show desired result using something that don't allow to achieve this
> > desired result? 
> 
> Any number of ways, e.g. an image, or prose description.

Do I understand correctly that current updated testcase page satisfies you in this regard?

> > The testcases shows exactly "the rendering I would like".
> 
> In what browser, what version, on what platform?

The testcases shows exactly "the rendering I would like" at least in current (latest stable) versions of ALL browsers (this is usually implied by default if nothing else is mentioned) and IE7+ (abstracting from IE6-nonsupported CSS-selectors, wrapping LEGEND in DIV likely results in same rendering even in IE6, but I'm just not developing for IE6 for a year already). Just in case, current versions of browsers are Firefox 8, Chrome 15, Opera 11.5, Safari 5.1.1, IE9 (tested on Windows platform).

> > What exactly don't you understand in the testcases (if any)?
> 
> When I suggest that rendering problems should be fixed by fixing CSS, you
> mention wrappers. Yet I see no wrappers in the rendering on my browser.

How exactly would you want to "see" wrappers (if this is still applicable to the updated testcase page)? (I, of course, assume by default that the HTML-spec editor should clearly understand difference between markup and its rendering result.)

> From looking at your updated test case, as far as I can see, your use case is:
> 
> "I would like to have a fieldset with a border, and I would like the legend of
> that fieldset to be entirely within the border of the fieldset, not straddling
> the fieldset border". Is that correct?

I would like to remove purely theoretical spec-limitation contradicting to real browser (all current browsers) behavior.

In particular (but NOT limited to), as for _exactly_ the testcase 5 (that probably is what you are talking about), I want to style LEGEND as if it was regular block like DIV -- without fantom nonresettable margins, with regular width, etc. typical for regular block like DIV. Wrapping legend in DIV allows to achieve this _right now_ in all current browsers while is not bad at all (more generally, _any_ styleable element should be allowed to be wrapped in DIV -- that's one of key difference between styleable element and attribute).

To help visually distinguish between legend and its wrapper, I've added dark-gray background to LEGEND elements in my testcases.

Please distinguish between the solution you would like, and the use case. "I would like HTML to work like this" is not a use case. It's a solution. If what I wrote at the end of comment 28 is not your use case, then I still do not understand what it is.

(In reply to comment #31)

As I've said in the end of comment 29, one of (one of) usecases is desired ability to style LEGEND as if it was regular element like DIV. What exactly is unclear for you here?

That's not a use case. Users don't go to Web sites and think "oh my, this site is awesome, it has <legend>s styled just like <div>s!". They go to Web sites and think "This looks pretty [because it has the title box wrapped in another box which contains the content]". A use case gives the effect you are trying to achieve, not the mechanism by which you are trying to achieve it.

(In reply to comment #33)

Maybe this is what you are calling usecase: legend in my forms is usually heading/title of the entire form. For example, poll form:

<form action="#" method="post"><fieldset>
	<legend>Some question</legend>
	<ul>
		<li><label><input type="radio" ...> Answer 1</label></li>
		<li><label><input type="radio" ...> Answer 2</label></li>
		<li><label><input type="radio" ...> Answer 3</label></li>
	</ul>
	<div><input type="submit" value="Vote" /></div>
</fieldset></form>

I want to style legend _consistently_ across browsers _without_ workarounds and tricks. Styling legend itself is inconsistent across browsers while styling wrapper is consistent.

(In reply to comment #33)

By the way, we are discussing technical things here. We are developing markup-language spec. We are developers, not users.

When someone want to achieve some particular effect during solving specific task, he would just apply solutions that work or ask a question in a forum.

Here, in W3 bug-tracker, we're trying to make HTML as a whole better by resolving _fundamental_ problems instead of solving narrow specific tasks. All tasks are different, while we are developing instruments to solve wide range of tasks. And doing this (hopefully) according to common sense.

(In reply to comment #31)

> If what I wrote at the end of comment 28 is not your use case

What you've wrote at the end of comment 28 is one of possible usecases.

Ian, you are substituting notions by substituting a fundamental issue to specific usecase. I've intentionally noted _multiple times_ that straddling (fantom nonresettable margins, etc.) is just _one of_ possible usecases.

The real bug-point is need for having exactly _same_ possibilities/flexibility when styling legend as we have when styling any other regular element.

If you have other use cases, please list them. I would be happy to consider them also.

(In reply to comment #38)

See the testcases and their descriptions available at the bug URL.

Actually we currently have just two options:

1. accept the proposal (allow LEGEND element to be wrapped in DIV);

2. if the editor think the proposal would result in negative impact, the he should directly describe _what exactly_ such negative impact is.

Thanks.

The negative impact:

 * It makes determining what the legend of a <fieldset> is harder, because you have to go poking around in the DOM to find the legend.

 * It increases the complexity of maintaining pages that use <fieldset>, because you can't be guaranteed that the <legend> will always be in the right place.

 * It makes it more likely that authors will make mistakes with <fieldset>, because now you have to look all over the place to make sure you haven't already given a legend.

 * It makes writing editors and conformance checkers more complicated.

(In reply to comment #41)

All the listed factors are inessential.

> The negative impact:
> 
>  * It makes determining what the legend of a <fieldset> is harder, because you
> have to go poking around in the DOM to find the legend.

No, it's trivial both for browsers and authors. From browser's perspective, implementing fieldset.legend should not be harder than existing form.elements, element.form, etc.

From author's perspective, it's trivial too. I've have created reference implementations for getLegend(fieldset) and getFieldset(legend) in JavaScript, so, from now on, developers can just use these implemented function until similar functionality is implemented natively in browsers.

For my mentioned implementations, see demo page:
http://tanalin.com/_experimentz/bugs/w3/html/wrap-legend/js/

>  * It increases the complexity of maintaining pages that use <fieldset>,
> because you can't be guaranteed that the <legend> will always be in the right
> place.

No, the essence of the my proposal is that legend should be allowed to be in any place inside of a fieldset (for exception of inside of a nested fieldset in which case this nested fieldset becomes legend's owner). Besides, complexity for implementors is less essential than usability for author (see last paragraph in my current comment below).

>  * It makes it more likely that authors will make mistakes with <fieldset>,
> because now you have to look all over the place to make sure you haven't
> already given a legend.

One of the most ridiculous arguments. Sounds like "We cannot use nested DIVs since otherwise you have to look all over the place to make sure you have no already an open <div> tag".

If fieldset would have more than one legend, validator will point this out as an validation error. If author don't use validator, the he could have multiple legends (and in any places) _right now_ regardless of whether it is allowed by the spec or not.

>  * It makes writing editors and conformance checkers more complicated.

You've probably forgot one of fundamental HTML design principles:

	"consider users over authors over implementors over specifiers over theoretical purity"
	http://www.w3.org/TR/html-design-principles/#priority-of-constituencies

So complication of implementation cannot be a reason to abandon a change that would give authors more flexibility/possibilities.

Another option is to introduce new iLEGEND (named from "inline legend") element (wrappable too as it was originally proposed for LEGEND).

	<fieldset>
		<p>Please provide your <ilegend>credentials</ilegend></p>
	
		<input type="text" name="username" />
		<input type="password" name="password" />
	</fieldset>

Compared with LEGEND, potential benefit is that new element has no "special rendering rules" legacy at all and therefore is fully and predictably styleable by nature. In turn, using this inside wrapper allows markup to be in more accordance with DRY principle.

I've reflected this in testcase 6 (the testcase itself is not subject to discuss and is provided just for additional demonstrativeness):

http://tanalin.com/_experimentz/bugs/w3/html/wrap-legend/#t-6

(In reply to comment #43)
> Another option is to introduce new iLEGEND (named from "inline legend") element
> (wrappable too as it was originally proposed for LEGEND).
> 
>     <fieldset>
>         <p>Please provide your <ilegend>credentials</ilegend></p>
> 
>         <input type="text" name="username" />
>         <input type="password" name="password" />
>     </fieldset>
> 
> Compared with LEGEND, potential benefit is that new element has no "special
> rendering rules" legacy at all and therefore is fully and predictably styleable
> by nature.

We already have features for indicating <legend>-like semantics without popular user agents applying default styles in the form of ARIA:

    <fieldset aria-labelledby="credentials-legend">
        <p>Please provide your <span id="credentials-legend">credentials</p>
       <input type="text" name="username" />
       <input type="password" name="password" />
    </div>

Unlike "ilegend" this already has some support in current software.

(In reply to comment #44)

Thanks. However using such preusosemantics is dirty and verbose like microformats. So I personally as well as likely most of web-developers will just avoid using these attributes at all.

I'm talking about core HTML semantics here, not about some pseudo-semantics layer, be it microformats or ARIA attributes.

(In reply to comment #45)
> (In reply to comment #44)
> 
> However using such preusosemantics

[A typo: preusosemantics => pseudosemantics]

(In reply to comment #45)
> Thanks. However using such preusosemantics is dirty and verbose like
> microformats.

How is "aria-labelledby" "pseudosemantic" in a way that <ilegend> is not?

What does "dirty" mean in objective, technical terms?

I totally agree it's a bit more verbose, but that's probably not good reason to add complexity to the core vocabulary.

> So I personally as well as likely most of web-developers will
> just avoid using these attributes at all.

Alleged personal taste has no technical relevance. HTML is a host language for ARIA; these attributes are part of HTML, and they appear to do precisely what you are asking for.

(In reply to comment #47)

The bug is solely about styling LEGEND element. iLEGEND is just an option that would be probably easier for the spec editor to accept than changing existing LEGEND element behavior. ARIA/microdata or anything else are outside of the bug scope.

If it would be enough for me to use _some common_ label-like markup, then I would just use DT inside DL (currently web-developers are _forced_ to do this). On the contrary, the bug is about form/fieldset LEGEND exactly.

(In reply to comment #47)
> 
> I totally agree it's a bit more verbose, but that's probably not good reason to
> add complexity to the core vocabulary.

Such guesswork is theoretical purity by the way. Authors' interests should be considered over theory according to HTML design principles (http://www.w3.org/TR/html-design-principles/#priority-of-constituencies).

From the original resolution: if you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug (done), and suggest title and text for the tracker issue (still needed).

(In reply to comment #50)

It's not quite obvious how exactly do I suggest title and text for the tracker issue. If comment is sifficient for that, then here it is:

title/text of the tracker issue can be same as summary/description of the bug.

Thanks.

https://www.w3.org/html/wg/tracker/issues/200

Changed status per: http://lists.w3.org/Archives/Public/public-html/2012Jan/0087.html

Corresponding change proposal:
http://www.w3.org/wiki/User:Mtanalin/legend-placement