- From: Robert Burns <rob@robburns.com>
- Date: Sat, 7 Jul 2007 22:31:32 -0500
- To: Ben Boyle <benjamins.boyle@gmail.com>
- Cc: "Sander Tekelenburg" <st@isoc.nl>, public-html@w3.org
In reply to, Robert Burns <rob@robburns.com> who wrote on 7/7/07 [with corrected longdesc value]: > <figure> > <video src="media/gw.ogg"> > <img longdesc='#gw' src="media/gw.jpg" alt=""> > <longdesc id='gw'>Because of his role as the Commander in Chief of > American forces > in the Revolutionary War, and, later, the first President of the > United States, George Washington is often called the "Father of > his Country".</longdesc> > </video> > <legend>George Washington</legend> > </figure> On Jul 7, 2007, at 9:10 PM, Ben Boyle wrote: > Yes, that is similar. > > One issue I see is that the longdesc is associated with the img > element, but not the video element. Well it is associated with <video> in the sense that it is hierarchically two fallbacks away from <video. That is the UA, by default, displays the embedded content of the video referenced by the <video> element. If it cannot, then the UA displays the embedded content image referenced by the <img> element. If it cannot do that, then the UA displays the content of the <longdesc> element. Whichever alternate the UA displays, it does so within the bounds of the <figure> element along along with the caption in the <legend> element. Also, the other advantage of a new <longdesc> element is that it would work within a <figure> OR among inline-level content that's not inside a <figure> element. > Perhaps @longdesc belongs on > <figure> but then I think the contents of the figure would suffice and > the id/idref could be redundant. No, I don't think that @longdesc goes with <figure>. The idea is to provide a standard container for the document fragment that the @longdesc attribute points to. Ideally, this wouldn't be necessary if we could just place that document fragment within the <img> element itself. However, it seems the next best thing to simply recommend authors place a next sibling <longdesc> element, immediately after any <img> or <embed> element to contain the alternate fallback for those two elements. We also recommend UAs only display the contents of <longdesc> element as fallback if the <img> or <embed> cannot be displayed. > "figure" can already contain: > 1. embedded content element (which can fallback) Except for two embedded content elements: <img> and <embed> The <figure> element can deal with fallback until the author needs to use on of those two elements that don't readily support fallback. > 2. caption using <legend> The legend element would work alongside the primary or fallback content regardless of how that's handled. > I'd like to extend this to say it can include other elements (block > level probably?) which get treated as "contextual information related > to the figure". That's explicit enough for me, and pretty easy to > author (and probably what is meant, if an author chucks extra stuff > within <figure>) I'm not clear about what you mean here. Are you saying that the non- embedded contents of a <figure> should be treated as fallback for the primary embedded content within the <figure>. > We could add in @longdesc and a new element like <longdesc> but I > don't see that it adds much and being more proscriptive is probably an > unnecessary challenge for authors. I''m not sure what you mean by "being more proscriptive". The <longdesc> element simply adds to what an author can do. I'm not suggesting that authors not be allowed to use the <img longdesc=""> in ways their already accustomed to. Take care, Rob
Received on Sunday, 8 July 2007 03:31:42 UTC