[uf-new] Re: figure microformat

[Toby A Inkster]

In answer to a few messages...

Sarven Capadisli wrote:
> If FIGURE contains IMAGE and LEGEND is not present, then parsers
> should use the ALT attribute value for legend.

Benjamin Hawkes-Lewis wrote:
> I suspect ALT="", as featured in your Einstein example, is suboptimal
> for content images that people might want to find, bookmark, save, or
> otherwise manipulate.

There's two main reasons I decided against using alt as a legend in  
the draft. Firstly, the simplest reason, this counts as invisible  
data -- except in Internet Explorer which displays alt attributes as  
a roll-over tooltip.

Secondly, and more importantly, accessibility issues with the ABBR  
pattern have shown that we shouldn't hijack accessibility-related  
elements and attributes without a lot of thought. Otherwise we may  
end up with results like:

	<div class="figure">
		<img src="foo" alt="Picture of a crazy foo">
		<span class="legend">Picture of a crazy foo</span>
	</div>

Where the result in a screen reader or text browser is actually far  
worse than leaving blank alt text:

	<div class="figure">
		<img src="foo" alt="">
		<span class="legend">Picture of a crazy foo</span>
	</div>

I did actually intend to include an example with non-empty alt text,  
and will edit the draft now to correct this oversight.

> Whatever you think of the necessity of alternative text for content
> images, such supplementary uses of ALT and LONGDESC need (it seems to
> me) to have some sort of place in the proposed draft.

I think these attributes are very important, and that's why we should  
avoid overloading them, and allow authors to use them for the very  
important purpose for which they were designed.

Sarven Capadisli wrote:
> This suggests that the CAPTION that was mentioned in
> http://microformats.org/wiki/figure-examples is no longer needed.

The "caption" and "legend" classes appeared to be semantically  
identical. Can anyone think of a reason for both to be included? Out  
of the two, I chose the name "legend" rather than "caption", as  
"legend" is the name used in the HTML5 draft.

Sarven Capadisli wrote:
> I think in this case it would be appropriate to suggest that subject,
> credit, tags, license *should* be a child of LEGEND. Hence:


Perhaps *should*, but certainly not *must* as that would prevent  
convenient uses like:

	<p class="figure">
		<img src="foo" class="legend" title="Picture of a crazy foo">
		<a class="include" href="#photocredits">(credits)</a>
	</p>
	<!-- etc -->
	<p class="smallprint">
		All photography by <span id="photocredits" class="credit">Toby  
Inkster</span>.
	</p>

Andy Mabbett wrote:
> Turning to specifics, I think the dismissal of the "include  
> pattern" is
> unfortunate and needs to be reversed


The draft has always explicitly said that the include pattern *may*  
be used.

It suggests that the ABBR pattern *should not* be used, because  
frankly I can't see any reason why it *should* be used. The ABBR  
pattern is useful when you want parsers to have a long string  
available, one that would be too long to be appropriate to show to  
human readers. For legends, credits and subjects, there's no need to  
do that -- it is always appropriate to show humans the full string.

Besides which, it's a *should not* and not a *must not*.

Hopefully that answers all the questions that have been brought up.

-- 
Toby A Inkster
<mailto:mail at tobyinkster.co.uk>
<http://tobyinkster.co.uk>