[html4all] Figure ideas (was: Article by Catherine: Feedback on accessibility concerns in HTML5)

[Leif Halvard Silli]

On 2007-09-22 05:18:10 +0200 Robert Burns <rob at robburns.com> wrote:
> On Sep 21, 2007, at 7:26 PM, Leif Halvard Silli wrote:
>> On 2007-09-22 01:39:21 +0200 rob at robburns.com wrote:
>>>> On 2007-09-21 05:06:25 +0200 Robert Burns <rob at robburns.com>:
>>>>> On Sep 20, 2007, at 9:49 PM, zara wrote:

For some reason, I did only find your reply just now ...

>>> I'm not sure what automatic cross-reference system [...]
>> <http://www.w3.org/html/wg/html5/#the-dfn>
>> (3rd time I refer to the source in this thread.)
>[...] all you have to say it that you're referring to the
> proposed DFN element referencing). 

A good tip. (Though I had some refs to DFN.)

> [...] There is another proposal on the wiki for a
> cross reference system and is actually called a cross reference.

This one I guess: <http://esw.w3.org/topic/HTML/AttrtibuCitaQuotationReferencing>.

(The wording in the draft is «automatic cross-references».)

[ ... longdesc's nature ...]
>>> longdesc is closer to an embedding than it is to a link.
>>
>> The automatic cross-reference feature is, as much as I understand
>> it, a special kind of linking - just as longdesc is another kind of
>> special linking.
>
> No, it's not linking.  As I said before, longdesc is actually closer
> to embedding than it is to linking. [...]

In iCab, one access the longdesc URL via the same submenu as where one access the URL of an embedded image - I guess that supports your assertation.

>> Are there any viewpoints on my proposal to either use SPAN (and/or
>> other phrase elements) - or perhaps even DIV, instead of LABEL and
>> LEGEND in FIGURE?
>
> I assume you want to do that to provide better backwards
> compatibility. I'm sympathetic to that. 

Just so that it is clear: My motivation was not only compatibility, but also about semantics. A table caption is a special kind of text. It is close to a title of the table. But I don't think that the text inside a FIGURE needs to be a caption in that pure sense. 

> However for the XML serialization that's not necessary and it is also
> not necessary for HTML5 UAs. I think, just like with XHTML2, we will
> see forward- looking authors using span and div elements to implement
> HTML5 semantics, I'm not sure if we should make that a part of the
> language. Part of my motivation in the graceful degradation thought
> experiment page was to see if there are semantics that make sense
> to introduce with attributes and existing elements rather than new
> elements.
 
I had believed that you would see my idea here as in line with that thought experiment?

Btw, the most obvious thing then, could be to simply drop the FIGURE element, and instead use a P element with a special attribute ... 

> The legend/caption element does not fit that criteria in
> my view. I also feel that caption (both for tables and for figures)
> should allow block content. So I'd rather see us introduce a
> blockcaption or bcpation or cptn element that supports block content
> for both tables and for figures.

The caption element for FIGURE - which is currently named <LEGEND> in the HTML 5 draft - does allow «block content» since it allows «inline-level content», which is a term that includes «Structured inline-level elements» - which is a term that includes the typical block elements. For some reason, the CAPTION element has a different model - where block content is excluded. Perhaps because one could think that it would be strange if e.g. a CAPTION contained a TABLE.

At any rate, there is nothing which prevents SPAN from taking block content.
-- 
leif halvard silli