On Feb 25, 2008, at 2:42 PM, Ian Hickson wrote:
<label>
This would preclude any sane way of putting form controls in
legends, which would be bad.
This can't be fixed in the spec.
Is the ability to put form controls in figure captions (let alone more
than one form control) really more important than ability to style
them sanely? Putting a form control in a figure caption seems unlikely
to me. Even more so for <details>, where form controls inside the
label would be confusingly inside another interactive element. Indeed,
<details> is arguably a kind of form control.
<legend>
Parsing issues in Firefox and IE:
http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%3Cscript%3Edocument.createElement(%27figure%27)%3C%2Fscript%3E%3Ctitle%3ETitle%3C%2Ftitle%3E%3Cp%3E...%3C%2Fp%3E%0A%3Cfieldset%3E%0A%20...%0A%20%3Cfigure%3E%0A%20%20%3Clegend%3Efigure%3C%2Flegend%3E%0A%20%20content%0A%20%3C%2Ffigure%3E%0A%20...%0A%3C%2Ffieldset%3E
...and the element doesn't appear in the DOM when there's no
<fieldset> in at least Safari and Firefox.
This is quite the messy situation.
I think we should discount <dt>, <h1>-<h6>, <header>, <div>, and <p>
right
off the bat, since they would confuse matters greatly. We should
similarly
discount <title>, <caption>, <th>, <dt>, and <label>, because the
problems
with those can't be fixed.
That leaves <legend>, or inventing a new element. Both options are
unappealing.
One of the advanages with <legend> is that while the parse issues
today
are messy, we can fix those (indeed the spec now has them fixed
already,
though we might want to consider making <legend> close <p> tags).
A new element would be a neat solution, but frankly I'm out of words
to
use, and if we keep adding new ways to mark up titles and captions and
legends and labels, authors aren't going to be able to work out when
they
should use each element. Various people suggested various element
names in
the e-mails below, but from the names proposed it should be clear
that we
are scarping the bottom of the barrel. I'd rather have a cleaner
solution
for something that could be with us for years to come.
It seems to me that the problems with adding a new element are purely
aesthetic, while the problems with reusing 'legend' are practical and
harm deployment of the new element.
I think our only option is to use <legend>, and, while in the
migration
period, have people use markup like:
<figure>
<legend><span class="legend"> ... </span></legend>
...
</figure>
...with styles like:
figure > legend, figure > .legend { ... }
Yuck. Surely writing <legend><span class="legend"> ... </span></
legend> is uglier than writing something like <figcaption> ... </
figcaption>. And the migration period could take more than a decade.
Given the lengths that HTML5 goes to so that it can degrade
gracefully, this sounds like a high price to pay to avoid adding an
element.
4) Another alternative would be using a new unknown element. Whipping
out my thesaurus, I see <rubric>, <inscription>. Another
possibility is
something like <figcaption> (to avoid the problems <caption> would
cause
for figures inside tables), but that wouldn't be a good fit for
<details>.
<figcaption> and <detailscaption> and so on just seems like it would
make
the language really complicated.
But <rubric> is pretty reusable and about as semantically correct as
<legend> for general use as a caption:
http://dictionary.reference.com/browse/rubric
http://dictionary.reference.com/browse/legend
I agree that the multiplicity of single-purpose elements for seemingly
similar purposes is confusing. But HTML is already well down this
road. I think introducing a new element that's intended to be reusable
for similar contexts would be cleaner than trying to force reuse of
what was meant to be a special-purpose element.
We've waited years for <figure>, can't we wait a few more while
browsers
get their act together in their parsers?
<figure> could be used right now with CSS styling as backup and
without polluting up the markup if it didn't rely on an aspect of the
HTML5 parsing algorithm that no browser implements yet. Otherwise we
will indeed have to wait years, needlessly.
Regards,
Maciej
