Re: Marking up links to alternative versions of content

On Thu, Aug 02, 2007 at 06:30:28PM +0200, Sander Tekelenburg wrote:
 >
> > It could instead be defined as an alternative to the parent element.
> 
> "Defined in the spec to have that meaning in that situation" is what you
> mean, right?

Correct.
> 
 
> Agreed. That's what led me to suggest a boolean "equiv" attribute, to be
> combined with @for pointing to an id (and I'm not claiming there are no
> downsides to that ;)). See
> <http://www.w3.org/mid/p06240643c2d6870fc339@%5B192.168.0.101%5D>
> 
> > This is why I would prefer the introduction of a new element, <alt> to carry
> > alternative content, assuming that <audio> <video> and <embed> are going to
> > remain in the spec.
> 
> How would <alt> indicate what it is an alternative for?

It would use @for=idref, as in your proposal.

Before reading your proposal, I also considered adding a single attribute,
@altfor=idref which would combine the functions of your boolean attribute and
@for into one.

It seemed to me, and this is open to dispute, that <alt> would be a more
conservative change to the language as it wouldn't require the addition of an
attribute to a variety of elements. This is why I opted to mention it instead
of the @altfor idea.

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. All of the above proposals are
compatible with a policy of allowing only one alternative to be associated
with any given media element (the first alternative, in document tree order,
would be treated as a fallback, with the remainder of such alternatives being
ignored, i.e., as though @irrelevant were in effect).

Although my preference is to allow multiple alternatives, for reasons that you
mention in another thread, the "one alternative per media element" restriction
might be reasonable if backed by strong considerations regarding the need to
simplify UA implementations of the feature.

All proposals degrade gracefully in legacy UAs that fail to recognize the
new element or attributes, as the case may be.

There may also be use cases for allowing multiple idrefs to be listed in @for
(or @altfor under the third proposal), but this would require further
analysis.

Received on Friday, 3 August 2007 01:10:37 UTC