Re: Marking up alternative versions of content

[I see you already pointed to a couple of things I just posted about. Sorry
about that. I normally read an entire thread before posting to it. My mistake
for not doing that this time.]

At 22:06 -0500 UTC, on 2007-08-03, Robert Burns wrote:

[... @type for MIME types, so doesn't allow more generic indication]

> The @type attribute is not always a MIME type. The INPUT and BUTTON
> elements both have types that are not MIME types, but simple
> classifications just like this proposal.

That's true, I didn't think of that. However, I must say that as an author I
find such context-sensitive meanings of attrtibutes confusing. So my initial
take would be to dismiss using @type for non-MIME types here.

Also, I believe there is a need to provide both advisory MIME types *as well
as* advisory information about the 'sort' of equivalent. For example, a
captioned video might in itself be useful to a user, but when it is in a file
type format that his system can't consume, it is useless.

So allowing <alt for=idref title="captioned video"
type="video/ogg"><video></a>, would probably be useful. Both attributes would
provide complimentary advisary information. Authors could then do:

<video id="speech"></video><!-- folowed by any or no content -->
<alt for="speech" title="captioned video" type="video/ogg"><video></video></a>
<alt for="speech" title="captioned video" type="video/mpeg"><video></video></a>
<alt for="speech" title="audio only" type="audio/ogg"><audio></audio></a>
<alt for="speech" title="audio only" type="audio/mpeg"><audio></audio></a>
<alt for="speech" title="transcript" type="text/html">marked up textual
equivalent</a>
<alt for="speech" title="transcript" type="text/plain">plain text
equivalent</a>

Only issue is, what if the UA supports both MPEG and OGG? Answering myself, I
suppose a UA could be configured to favour one over the other, presenting
only the favoured file format. Or a UA could present bth options as
- captioned video [OGG]
- captioned video [MPEG]

and leave the rest of the work up to the user. Might well be good enough
formost users.

[...]

> As for distinguishing between different
> equivalent types, I think a @type attribute would be good (we could
> also have @contenttype to provide two different ways to classify the
> element).

FWIW, I think that would add too much to author confusion of when type takes
what sort of information. I would be OK with using @type for non-MIME types
if for all cases where it takes MIME types we would replace it with
@contenttype. But such a big change would probably generate new problems.
Using @title and @type would appear to be less dramatic.

[...]

> I had earlier suggested a LONGDESC element (ALT, EQUIV, FALLBACK or
> LONGDESC all work for me). At least for a one-to-one relation, to me
> it makes more sense to use the @lkongdesc attribute from the original
> element. To go from primary ---URL---> fallback rather than
> referencing from fallback ---IDREF---> primary.

For a mere "one equivalent only" solution that might indeed work, yes. I
don't understand how it would work for multiple equivalents thogh:

> Multiple equivalents
> could be handled by letting ALT have a content model that includes an
> initial ALT or adding a @longdesc attribute to ALT too.

Sorry, I can't follow. (Perhaps some example mark-up would help me understand
what you mean.)

[...]

> However, I think the for=IDREF approach works better for specifying a
> one-to-many relation between primary and equivalents (without any
> implicit or intended ranking).

Ah, OK:)

> Another advantage for both approaches (specifying an ALT element
> whether Jason's way or the way I'm suggesting) is that either works
> easily in a backwards compatible way with an HTML5 specific style
> sheet (with style declarations like something like "ALT {visibility:
> hidden;}" or "@screen {ALT {display: none}}" With very minimal java
> scripting, we could probably even emulate the role we want UAs to
> play to provide a mechanism for users to switch between equivalents
> in non-HTML5 conforming UAs.

Indeed.


-- 
Sander Tekelenburg
The Web Repair Initiative: <http://webrepair.org/>

Received on Sunday, 5 August 2007 00:30:31 UTC