Re: unifying alternate content across embedded content element types

On 7/14/07, Sander Tekelenburg <st@isoc.nl> wrote:
>
> But context !=
> alternates/equivalents/fallback. Context is context, and is exactly the
> same/exactly as useful for whichever equivalent the user happens to
> access.


I hope I'm not beating a dead horse here...

context is often equal to fallback. There are cases where the context and
the fallback would be exactly the same, and then the fallback would be
unnecessary and redundant.  But, equivalent != alternate

In other words, "fallback" is sometimes equivalent of content:
- "PDF" instead of a PDF logo
- equivalent media, but a different format when the preferred format is
unsupported
- the textual transcript of a video
- any other case where completely replacing the media object with the
fallback does not change the meaning of the document

and sometimes "fallback" is a description of a content:
- a description of a photo of the Grand Canyon
- a description of a video
- any other case where the "fallback" seems out of place without a note that
certain media are missing

I think better defining the markup for a semantic "equivalent" vs. a
semantic "alternate" is more useful than defining markup for "long" vs.
"short".  If those semantics are clearly defined, authors will have a better
chance at making more accessible content, and UAs will have a better chance
at presenting it appropriately.  I think this is more useful than creating
more ambiguously defined markup that authors and UAs will treat incorrectly.

Are the contents of <object> an equivalent or a description?  Both, in
certain cases?

Does <object> need a <caption> descendant that serves as descriptive
fallback instead of equivalent fallback?  If it had one, UAs could treat it
differently from equivalent fallback by noting that media is missing
possibly noting why (e.g. "Failed to load example.mpg", "Link to example.mpg
")


-- 
Jon Barnett