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:[EMAIL PROTECTED]>
<http://tobyinkster.co.uk>
_______________________________________________
microformats-new mailing list
[email protected]
http://microformats.org/mailman/listinfo/microformats-new
