- From: Jason White <jasonw@ariel.its.unimelb.edu.au>
- Date: Sun, 29 Jul 2007 13:15:02 +1000
- To: "Patrick H. Lauke" <redux@splintered.co.uk>
- Cc: Lachlan Hunt <lachlan.hunt@lachy.id.au>, Sander Tekelenburg <st@isoc.nl>, public-html@w3.org, wai-xtech@w3.org
On Sun, Jul 29, 2007 at 03:22:22AM +0100, Patrick H. Lauke wrote: > But, unless I'm mistaken, no current UA even renders HTML5's <audio> and > <video>, so comparing how they currently handle HTML4's <object> may not be > all that relevant. And if the spec stated that UAs need to handle fallback > content a certain way (possibly making reference to UAAG 1.0 in passing as > well) that gives users control, would that be a likely step in the right > direction? Yes, that's moving in exactly the right direction. > Or is the historically flaky implementation of <object> going to > kill this idea off right from the get-go? It shouldn't kill the idea off at all. If there are concrete problems with OBJECT that can be avoided in the design of the new elements, while still exposing the desired semantics, then those considerations should be taken into account so as to facilitate implementation of <audio> and <video>. As mentioned earlier in this thread, a uniform means of referring to alternative content is desirable for consistency reasons. Implementors of HTML 4 are faced with ALT, LONGDESC and OBJECT, each having its own semantics. Regrettably, ALT is likely to remain for some time to come, due primarily to the inadequate content model of IMG. So, if ALT is left in place, I would suggest simplifying the design by choosing a single mechanism for (1) linking to alternative content, and (2) allowing block-level alternative content to appear in a document. In both cases, the relationship between the alternative content, and the primary content, would be explicit in the markup. The second requirement - block-level alternatives in the document itself, could be dispensed with, as long as the UA is allowed to traverse the link to the alternative content without user intervention, and to insert it into the document. If the link is at the inline level, though, having block-level content inserted into the document tree could pose significant problems, and so far as I know, there are no existing conventions for dealing with document fragments. Thus the best solution would appear to be a block-level element: <alt for="IDREF"> [alternative content belongs here - either a link or a full alternative] </alt> Open questions are: 1. Whether to allow multiple alternatives to refer to the same element, and if so the semantics of the selection mechanism. 2. Whether to allow nested alternatives, as in OBJECT, which would achieve the same result. In comparing these and other options, including alternative proposals for solving the same problem, the experience of implementors with OBJECT becomes relevant and useful. For example, a "one alternative per resource" rule could simplify implementation at the expense of flexibility, but on balance it might be worth the trade-off - that's a matter which would need to be discussed. If a general alternative content mechanism is introduced, I, for one, would be comfortable to see LONGDESC relegated to history.
Received on Sunday, 29 July 2007 03:15:17 UTC