Re: transparent content model and proposed ALT element

Hi Jason,

On Aug 4, 2007, at 1:33 AM, you wrote:
>
> Allowing multiple ALT elements, with @for values that refer to the  
> same media
> element, would achieve the same purpose as your FALLBACK element  
> proposal. It
> would be straightforward to add a boolean attribute serving as a  
> hint to the
> user agent that, if the media element to which @for refers is  
> rendered, the
> content of ALT should be hidden. Debate, I am sure, would then  
> ensue regarding
> the default value of this boolean attribute.
>
> To summarize: I don't think HTML needs a FALLBACK element, but I  
> still favour
> the addition of an ALT element, or a comparable mechanism achieving  
> the same
> purpose.

On Aug 4, 2007, at 1:33 AM, you also wrote:
> I agree with all of Rob's remaining points, including his separate  
> post
> suggesting a flattening of the <object> hierarchy of fallbacks by  
> allowing
> <alt> to be used instead, with appropriate @for references.

The remaining points in that message were:

  • @type is not always MIME type (see INPUT, OL, UL, LI and BUTTON)
  • using  a @longdesc/URL approach instead of a for/IDREF approach  
is preferred
• and I'm in agreement about adding an element (or elements) as an  
equivalent container

As I wrote:
>> 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).

The reason I think going with FALLBACK (which would be the  
transparent kind of element and then contain one or more  ALT   
elements, is to provide greater flexibility in authoring. The various  
ALT elements could be arranged hierarchically or flattened (as Jason  
called it). The content could be visible (e.g., FALLBACK@visible) or  
hidden. And the equivalents could be loaded on the same page or a  
remote page. I think this would be the most backwards compatible and  
the most flexible for authors.

Take care,
Rob