- From: Jason White <jason@jasonjgw.net>
- Date: Fri, 3 Aug 2007 11:10:20 +1000
- To: public-html@w3.org
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