- From: Robert Burns <rob@robburns.com>
- Date: Sat, 30 Jun 2007 10:28:58 -0500
- To: Anne van Kesteren <annevk@opera.com>
- Cc: "aurelien levy" <levy@tektonika.com>, public-html@w3.org
On Jun 30, 2007, at 9:08 AM, Anne van Kesteren wrote: > On Sat, 30 Jun 2007 15:53:39 +0200, aurelien levy > <levy@tektonika.com> wrote: >> - actually their is no fallback content for embed element > > Why is that needed for plugins? That's when fallback content is needed: for non-text media (that is sometimes serviced through plug-ins). >> - the only fallback content for iframe elements is pure text, i >> think we need to authorize an "a" element to link to the content >> of the iframe > > Doesn't the <iframe> do that already? I'm not sure <iframe> needs > "fallback" content at all. <iframe> in HTML 4.01 has %flow fallback content. In HTML5 it is not supposed to contain anything but another browsing context (another html file I believe though that's probably not explicit or clear enough by simply saying a browser context ). In other words now the draft reads: "An iframe element never has fallback content, as it will always create a nested browsing context, regardless of whether the specified initial contents are successfully used." However, if it said that the type of the iframe @src had to begin with "text/ or "application/xml" then that might be sufficient. Simply saying a browser context could lead authors to think a direct @src link to an image or other non-text media was allowed (even PDF or Flash might require fallback content since those do not have the accessibility capabilities of HTML). Take care, Rob
Received on Saturday, 30 June 2007 15:29:06 UTC