w3c/wbs-design or
by mail to sysreq.
W3C
Site Navigation
Nearby
Results of Questionnaire ISSUE-200: Should LEGEND be allowed to be wrapped in non-FIELDSET elements - Straw Poll for Objections
The results of this questionnaire are available to anybody. In addition, answers are sent to the following email addresses: pcotton@microsoft.com, rubys@intertwingly.net, mjs@apple.com, mike@w3.org
This questionnaire was open from 2012-07-03 to 2012-07-19.
4 answers have been received.
Jump to results for question:
- Objections to the Change Proposal to permit LEGEND to be wrapped in non-FIELDSET elements.
- Objections to the Change Proposal to keep the existing content model of FIELDSET elements
1. Objections to the Change Proposal to permit LEGEND to be wrapped in non-FIELDSET elements.
We have a Change Proposal that proposes to permit the LEGEND element to be wrapped in non-FIELDSET elements. If you have strong objections to adopting this Change Proposal, please state your objections below.
Keep in mind, you must actually state an objection, not merely cite someone else. If you feel that your objection has already been adequately addressed by someone else, then it is not necessary to repeat it.
Details
| Responder | Objections to the Change Proposal to permit LEGEND to be wrapped in non-FIELDSET elements. |
|---|---|
| Tab Atkins Jr. | I object to this change proposal. The first example in the change proposal was discussed in the mailing list. There, it was demonstrated that it is very easy to change the markup to achieve the same styling effects while obeying the current <legend> placement rules. The second example doesn't seem to solve a real problem. Legends are usually very short, and so the minor duplication that might appear between a legend and a longer explanation is not something that's sufficiently worth killing to justify adding a new element or changing the parsing of existing elements. Further, the example as written is very likely not what's desired - the <ilegend> wraps a word in the middle of the sentence, which is lowercase, but legends are usually presented with initial caps. Similarly, the wording of a legend (acting as a section header) is often slightly different than a similar phrase in a longer description. It seems unlikely that this use-case will usually be possible without employing extra CSS and/or awkward phrasing. The "Negative Effects" section is drastically incomplete. The most pressing omitted entry is the extra work of adjusting the parsing and display of existing <legend> elements, and adding a new <ilegend> element. Omitting this cost can make a lot of trivial changes seem worthwhile. Another omitted entry is the possibility that existing content is (incorrectly) using <legend> in invalid locations, and the suggested change would alter the presentation of that element. In some cases this may be a minor visual change, while in others it may be a significant rearranging (if the <legend> was in the middle of other content where its placement was important). Overall, the Change Proposal attempts to solve problems that are either insignificant or non-existent, and omits consideration of the costs involved, both in terms of implementor time and possible backwards-compat issues. |
| Boris Zbarsky | The part of this proposal that introduces an "ilegend" element seems completely unnecessary. As far as I can tell, it would just be an alias for "legend" and needlessly increase complexity. There seems to be no good reason for introducing the new tag, and I object to that part. Apart from that, this change proposal seems to mostly talk about changing the set of conforming documents; those changes seem reasonable to me. Note that the spec already has the rendering requirements for a "legend" whose parent is not a "fieldset" that this change proposal is asking for, though it doesn't spell them out explicitly. Perhaps it should. |
| Henri Sivonen | I strongly object to the part of this change proposal that adds an ilegend element. The usefulness of this alias would be too limited: the sole piece of usefulness would be working around undesirable parser behaviors in Firefox 3.6 and earlier, since the other oddities of fieldset/legend that occur when legend is a non-first child (but is a child) of fieldset could be worked around by adding a wrapper element (and some padding-zeroing CSS). I think we should not introduce new elements solely because of their fallback characteristics in Firefox 3.6 or earlier. Firefox 3.6 usage share will probably not be an issue a year from now, but an ilegend element would be with us forever. As a validator developer, I do not object to loosening the authoring conformance requirements for the placement of legend as long as: 1) each legend has a fieldset ancestor, 2) each fieldset has at most one legend descendant that doesn't have another nearer fieldset ancestor, 3) a legend whose parent is a fieldset is the first child of the fieldset (to avoid legacy oddities) and 4) the definition of finding the legend for the fieldset is changed such that the first descendant legend that doesn't have another nearer fieldset ancestor is the legend of the fieldset. On the other hand, I neither particularly support such loosening as I understand #4 might complicate accessibility implementation or break compatibility with existing accessibility implementations in ways that I'm not well positioned to assess before the deadline of this poll (so I might even object if I knew about such breakage for a fact; I encourage the Chairs to investigate the possibility of such breakage). I also acknowledge that the provisions on my non-objection as a validator developer are complex enough that it wouldn't be unreasonable to reject a change that'd involve such complexity. |
| David Bolter | There may be some performance cost to associating a field-set element with a legend that could be anywhere in the subtree, which we would need to do in our accessibility engine (in gecko). The cost (and impact on usability) is currently unknown and I don't know how big field-set subtrees might get in the wild. I can't say this is a strong objection at this time. |
2. Objections to the Change Proposal to keep the existing content model of FIELDSET elements
We have a Change Proposal that proposes to keep the existing content model of FIELDSET elements and thus NOT permit the LEGEND element to be wrapped in non-FIELDSET elements. If you have strong objections to adopting this Change Proposal, please state your objections below.
Keep in mind, you must actually state an objection, not merely cite someone else. If you feel that your objection has already been adequately addressed by someone else, then it is not necessary to repeat it.
Details
| Responder | Objections to the Change Proposal to keep the existing content model of FIELDSET elements |
|---|---|
| Tab Atkins Jr. | |
| Boris Zbarsky | The HTML5 parser already allows "legend" in an arbitrary place in the DOM, in the sense that if you put it there it will get parsed as if it were any other tag. The change proposal does not propose changing that. The change proposal also does not propose changing section 14.3.12, which is pretty straightforward: the "rendered legend" of a fieldset gets some special behavior, but any other legend is just a block like any other block (because the spec says nothing to the contrary; it _does_ define that legends are display:block by default in section 14.3.3). The various comments in the change proposal about the legacy rendering restrictions on legend and fieldset only apply to the rendered legend of the fieldset, of course, and hence have no bearing on legends that are not a child of the fieldset at all. While in the past UAs have had various rendering restrictions on such legends, they have been moving away from that for years (e.g. see https://bugzilla.mozilla.org/show_bug.cgi?id=476063 ) and there is actually fairly good interoperability on the rendering behavior of legends whose parent is not a fieldset, with very few bugs remaining. Given that the rendering for both legends which are a child of a fieldset but not the first child and legends that are not a child of a fieldset at all is already well-defined in a sane way and that UAs are already converging on that rendering, I see no benefit to keeping the completely arbitrary restriction that legend must only appear as the first child of the fieldset. While sticking with that rule does ensure that content will render in a reasonable way on certain old UAs, and that is probably worth calling out in the spec, I don't think that necessitates an authoring conformance requirement. Furthermore, I don't think that loosening this restriction increases implementation complexity: a UA has to have code to do the "just a block" thing no matter what, since legends can in fact appear as children of non-fieldsets and a fieldset can have multiple child "legend" elements, all but one of which have to be treated as blocks. Therefore I object to this change proposal: it's unnecessarily restricting authors, while changing nothing for implementors in practice. |
| Henri Sivonen | Cursory testing suggests that both Firefox and IE are quite okay with legend as a non-child descendent of a fieldset from the CSS perspective. It also appears that Opera merely special-cases the meaning of display: inline; in that case and non-inline display values (including inline-block) behave normally. It appears that WebKit special cases display for legend so that it's permanently stuck, which seems like a weakness in WebKit in the light of what the other engines do and the weakness isn't even fatal when considering plausible use cases that want a block-ish appearance for legend. Thus, the CSS-oriented rationale of this change proposal seems weak to the extent it applies to legend as a non-child descendant of fieldset. (Layout-oriented rationale for not allowing legend as a non-first child of fieldset seems reasonable in the light of the legacy, though.) |
| David Bolter |
More details on responses
- Tab Atkins Jr.: last responded on 17, July 2012 at 22:32 (UTC)
- Boris Zbarsky: last responded on 18, July 2012 at 08:04 (UTC)
- Henri Sivonen: last responded on 18, July 2012 at 09:22 (UTC)
- David Bolter: last responded on 18, July 2012 at 15:39 (UTC)
Everybody has responded to this questionnaire.
Compact view of the results / list of email addresses of the responders
WBS home / Questionnaires / WG questionnaires / Answer this questionnaire
Report issues
on GitHub project