Re: [whatwg] several messages about figure and related subjects
On Mon, 25 Feb 2008, Maciej Stachowiak wrote:
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.
It's easy to imagine UIs, e.g. of templates, that have text boxes in
captions and are waiting for user input there. The default open file
dialog on Mac OS X has a kind of details-like UI with a control in the
caption, too. And finally, label already has so many semantics and
special rules and so forth that reusing it here just seems like a
particularly bad idea.
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.
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 don't think we should discount the problems with introducing a new
element quite that quickly.
I think our only option is to use legend, and, while in the
migration period, have people use markup like:
figure
legendspan class=legend ... /span/legend
...
/figure
...with styles like:
figure legend, figure .legend { ... }
Yuck. Surely writing legendspan class=legend ... /span/legend
is uglier than writing something like figcaption ... /figcaption.
Yes, but the former would only last a decade or two, while the latter
would last for the lifetime of HTML.
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
Except people don't know what a rubric is. They know what a legend is.
Legend is what people call this (or caption, but the parsing issues
there are even more intractable).
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.
I think the cost of a few years here is worth it. It's not like this is
input type=date where introducing this feature today is ten years too
late; the figure element is helpful, and worth adding, but not a
panacea. Thus I don't see the problems as a big deal.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] several messages about figure and related subjects
Dnia 27-02-2008, Śr o godzinie 08:06 -0500, Michel Fortin pisze: Now, suppose you have this: pA header looks like this in your browser:/p h1Some text!/h1 ... unfortunately, the h1 here isn't a real header in the document: it's an illustration of a header (ah-ha: figure!) which can't be removed from te flow of the document (oops, can't use figure). There's no rational way to markup this with the current wording of the spec; abusing figure is the most reasonable option I can find: pA header looks like this in your browser:/p figureh1Some text!/h1/figure The problem being that figure needs the ability to be moved around without changing the meaning of the document, so the markup above would be non-conforming because the sentence just makes no sense if you put the figure elsewhere. Perhaps figure could have an optional anchored attribute to indicate it belongs to a specific point in the document. If the page has a header, you can refer the reader to its ordinary header instead. The purpose of headers is to make looking around the page easier; your sample header would be a distraction if it is styled like a normal header and would not make a good demonstration if it is not. Chris
Re: [whatwg] several messages about figure and related subjects
Le 2008-02-25 à 17:42, Ian Hickson a écrit : On Mon, 16 Jul 2007, Michel Fortin wrote: Since I'm not convinced that the current content model for figure is adequate [1], I decided to dig more examples where figures in HTML pages would be hard to fit with the current model. Here are the results. Thank you hugely for this research! This is very useful. I have updated the spec to handle these cases, and given examples of some of the key ones. Let me know if you think anything else deserves an example. I'm glad it was helpful. I quite like the new definition for figure and I think it covers the vast majority of illustration use cases I could come with. I don't think it needs more examples either. I'm wondering however about the definition leaving something out. It says: The figure element represents some prose content, optionally with a caption, which can be moved away from the main flow of the document without affecting the document's meaning. Now, suppose you have this: pA header looks like this in your browser:/p h1Some text!/h1 ... unfortunately, the h1 here isn't a real header in the document: it's an illustration of a header (ah-ha: figure!) which can't be removed from te flow of the document (oops, can't use figure). There's no rational way to markup this with the current wording of the spec; abusing figure is the most reasonable option I can find: pA header looks like this in your browser:/p figureh1Some text!/h1/figure The problem being that figure needs the ability to be moved around without changing the meaning of the document, so the markup above would be non-conforming because the sentence just makes no sense if you put the figure elsewhere. Perhaps figure could have an optional anchored attribute to indicate it belongs to a specific point in the document. Note that there was a couple of such markup rendering examples like these at the end of the email you're referring to. Now, perhaps that case isn't important or frequent enough to justify adding it to the spec -- I won't be the juge of that -- but I have myself such a page on my website for which I'd like to use better markup than div class=html at each example (page included in the list in the old email) and I still don't see what I should use (was hoping for figure). It could also be useful to allow labeling of subfigures, perhaps like this: figure figurelegend(a)/legend img .../figure figurelegend(b)/legend img .../figure legendMy house seen (a) from the front; (b) from the back/ legend /figure This is allowed, but I haven't included an example. I don't think it's necessary. Michel Fortin [EMAIL PROTECTED] http://michelf.com/
Re: [whatwg] several messages about figure and related subjects
On Wed, 27 Feb 2008, Michel Fortin wrote: I'm wondering however about the definition leaving something out. It says: The figure element represents some prose content, optionally with a caption, which can be moved away from the main flow of the document without affecting the document's meaning. Now, suppose you have this: pA header looks like this in your browser:/p h1Some text!/h1 ... unfortunately, the h1 here isn't a real header in the document: it's an illustration of a header (ah-ha: figure!) which can't be removed from te flow of the document (oops, can't use figure). There's no rational way to markup this with the current wording of the spec; abusing figure is the most reasonable option I can find: pA header looks like this in your browser:/p figureh1Some text!/h1/figure The problem being that figure needs the ability to be moved around without changing the meaning of the document, so the markup above would be non-conforming because the sentence just makes no sense if you put the figure elsewhere. Perhaps figure could have an optional anchored attribute to indicate it belongs to a specific point in the document. Using figure here doesn't help. What you are illustrating in this case isn't what a header looks like, it's a section that happens to have a header. In fact the only difference between this case and the first example above is that the first example above breaks the outline, but you could work around that by doing this: pA header looks like this in your browser:/p sectionh1Some text!/h1/section ...and it would have roughly the same meaning as in the figure case. The problem is that there's no way to mark up content as being metacontent, that is, there's no way to mark up an element as having no semantics but its default presentation. This is a rare edge case which basically only affects tutorials and test cases. We could come up with a feature to annotate markup as being literal or meta rather than working as defined, but I don't see the point. Test cases aren't going to use it because they are trying to fake out the browser into thinking that some particular convoluted case is occuring, and frankly tutorials are better off not using it because otherwise people would copy and paste that without realising it is specific to tutorials. I recommend simply not worrying about it. In cases where you're self-referrentially discussing markup, the document's semantics don't really make sense. But that's ok, I don't think anyone but semantic nerds like us are going to really notice or care. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] several messages about figure and related subjects
On Tue, 26 Feb 2008 06:16:15 +0100, Maciej Stachowiak [EMAIL PROTECTED]
wrote:
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.
What would you recommend for the am I hot or not and the like? At first
glance, that seems like a reasonable use case to me.
...
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...
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.
Agreed.
I think our only option is to use legend, and, while in the migration
period, have people use markup like:
figure
legendspan class=legend ... /span/legend
...
/figure
...with styles like:
figure legend, figure .legend { ... }
Yuck. Surely writing legendspan 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.
cheers
chaals
--
Charles McCathieNevile Opera Software, Standards Group
je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com
Re: [whatwg] several messages about figure and related subjects
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
legendspan class=legend ... /span/legend
...
/figure
...with styles like:
figure legend, figure .legend { ... }
Yuck. Surely writing legendspan 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
