Keep the existing content model of fieldset

Summary

The <fieldset> and <legend> author conformance criteria present in the specification enable authors to use these elements in an interoperable manner and should not be loosened. No use cases have been provided to justify changing the status quo.

This is for ISSUE-200 (legend-placement).

Rationale

The way <fieldset>s get rendered is unusual and impossible to fully describe in CSS. This is required for compatibility with existing Web content and is interoperably implemented in modern browsers.

Change proposal for LEGEND element claims:

Currently, LEGEND element is allowed solely as exact first child of a FIELDSET. This is purely formal limitation that makes styling of LEGEND too complicated, unreliable/non-future-proof, or literally impossible.

This is untrue. The author conformance restriction on <legend> does not cause the styling of <legend> to be error-prone and difficult. The difficulty in styling <legend> is an artifact of <fieldset>'s legacy rendering behavior. In fact, the author conformance restriction on <legend> helps authors to avoid butting heads with <fieldset>'s (unchangeable) weirdness.

LEGEND element should be allowed to be wrapped in elements other than FIELDSET to make it possible to achieve arbitrary styling of LEGEND[…]

As explained earlier, the legacy rendering behavior of <fieldset> and <legend> cannot be fully described in CSS. It can be difficult for Web authors to override this with CSS. This is unfortunate, but unavoidable while maintaining compatibility with Web content. If we were to change this in order to allow other styling of <legend> as suggested, we would likely break sites which depend on the current behavior. This would be favoring theoretical purity over the needs of users, which is an inversion of our Priority of Constituencies. We would be encouraging authors to write content that does not Degrade Gracefully.

Change proposal for LEGEND element suggests we mint a new <ilegend> element, identical in semantics to <legend> but free from <legend>'s compatibility constraints. Having multiple elements with identical semantics balloons the size of HTML's vocabulary and should be avoided unless there are compelling reasons for each element. (Avoid Needless Complexity) For instance, when designing <figure>, we minted <figcaption> (instead of reusing <summary> or <legend> within <figure>) due to the legacy parsing behavior of <summary> and the legacy rendering behavior of <legend>. But this was to enable the various use cases addressed by <figure>. The use cases for <fieldset> are already addressed by it, and it already has an element for naming the set of form controls contained within it.

It might be possible to design a new CSS concept with which we could completely describe the rendering of <fieldset> and <legend>. I encourage those interested to make such a proposal to the CSS Working Group.

Details

No change.

Impact

Positive Effects

• We preserve backward compatible behavior for <fieldset> and <legend>.
• We Avoid Needless Complexity by not minting a new element with identical semantics to <legend>.

Negative Effects

• Authors may need to wrap the contents of <legend> in a <span> to achieve some design goals.

Conformance Classes Changes

None.

Risks

None.

References

Inline.