Re: Marking up alternative versions of content

On Aug 3, 2007, at 8:23 PM, Jason White wrote:

>
> On Fri, Aug 03, 2007 at 07:07:12PM +0200, Sander Tekelenburg wrote:
>> Ah, right. I get it. <alt for=idref>equivalent</alt> would then  
>> remove the
>> need for the equiv attribute that I suggested. It would also not  
>> need @rel,
>> and thus remove the need to refine the definition of @rel. (Or am I
>> overlooking something?)
>
> No, I don't think you're overlooking anything; @rel is not needed  
> in this
> proposal.
>>
>> Yeah, that would seem to be easier to author and easier to implement.
>>
>> A potential issue: thinking about the different types of  
>> situations in which
>> publishing of equivalents would need to be possibe, it would seem  
>> to be
>> necessary to allow <alt> as both block and inline. (Or not? I  
>> don't really
>> 'see' that yet.)
>
> For flexibility, it would be best to allow it in both block-level  
> and inline
> contexts, with a transparent content model, I think.

Does this mean your proposal specifies a content model of "block- 
level or inline, but not both" (I'm still trying to understand what  
transparent means so perhaps that's the exact same thing).

>> [...]
>>
>>> With all three proposals, there arises a need to specify how a  
>>> user agent
>>> should treat multiple idrefs referring to the same element. As  
>>> you suggested
>>> elsewhere, a type attribute could be introduced to distinguish  
>>> different
>>> alternatives to the same media element.
>>
>> Right. But unless I'm mistaken, type is currently only for MIME  
>> types. It
>> might not be wise to start allowing other sorts of values. Or would
>> "application/video+caption" and such be appropriate? I don't know  
>> enough
>> about MIME types to judge that.
>
> I agree that MIMe types may be insufficiently expressive for this  
> purpose.
> Furthermore, if one media element is used as an alternative to  
> another, the
> task of deciding whether the alternative can be retrieved and  
> rendered is the
> same as for the original, so I don't think additional resource type
> information needs to be disclosed in the proposed <alt> element.

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. Though deprecated, LI, OL  
and UL all had @type attributes unrelated to MIME type, but rather  
classification types. Despite being deprecated fo some of these, the  
point  is there is plenty of historical precedent in HTML for non- 
MIME type @type attributes. 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). Also we have the @title attribute available on the ALT  
element to provide human-readable information about the differences.

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. 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. Advantages of  
this approach include:

  • @longdesc is already supported (backwards compatible)
  • @longdesc as a URL instead of an IDREF permits greater author  
flexibility (to optimize bandwidth usage and the like) by pointing  
@longdesc to either a local '#idref' URL or a remote document URL
  • authors can (I guess have to in some sense) express a ranked  
preference for equivalents that users and UAs can take into  
consideration.

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).

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.

I'm in total agreement about the problem. As I understand it, we want  
to provide a way for authors to explicitly markup equivalents (even  
from IMG) and expose those equivalents to users in a consistent way  
(like in the chrome as Sander says). I think it could work in a  
manner similar to switching among alternate style sheets in current  
browsers (like Firefox). For example, the frame dedicated to the  
original primary equivalent could be the same frame used to display  
the alternate equivalents. Authors could specify through CSS how  
alternates would get displayed in that frame (i.e., changing the  
frames metrics and reflowing the document or maintaining the frame  
metrics and providing a scrolling mechanism or other content overflow/ 
clip handling).

Take care,
Rob

Received on Saturday, 4 August 2007 03:06:36 UTC