W3C home > Mailing lists > Public > public-html@w3.org > April 2007

Re: Feature Strings

From: Maciej Stachowiak <mjs@apple.com>
Date: Thu, 19 Apr 2007 12:13:26 -0700
Message-Id: <85FAC2AD-1434-46B7-8558-A068032B1198@apple.com>
Cc: Brad Fults <bfults@neatbox.com>, public-html@w3.org
To: Jeff Schiller <codedread@gmail.com>


On Apr 19, 2007, at 10:28 AM, Jeff Schiller wrote:

>
> Brad,
>
> Thanks.
>
> I see that Canvas has the ability to provide fallback content [1]  
> like:
>
> <canvas><img src="sorry.png"/></canvas>
>
> I just wanted to verify that existing user agents (IE included) would
> parse the <img/> if they didn't understand what <canvas/> means.
> Someone probably can give me a Yes/No answer there.

Yes, this works. HTML has long had the requirement that unknown  
elements must be treated as inlines, and their contents parsed as  
normal. That's what leads to this working.

>
> I notice <video> says the same thing, though I think there is a
> slightly incorrect statement in [2].  Shouldn't
>
> "Content may be provided inside the video element so that older Web
> browsers, which do not support video, can display text to the user
> informing them of how to access the video contents. User agents should
> not show this fallback content to the user."
>
> be
>
> "Content may be provided inside the video element so that older Web
> browsers, which do not support video, can display text to the user
> informing them of how to access the video contents. User agents that
> support the <video> element should not show this fallback content to
> the user."

I think you are right on this. Also, the document should probably be  
more broad-minded about what kind of fallback content can appear, for  
instance, it might be some alternate way of presenting video or a  
substitute still image rather than text describing how to access the  
video contents.

  - Maciej

>
> I think the fallback content mechanism within WHATWG HTML5 makes
> perfect sense as long as older user agents would automatically display
> the fallback content (which I'm assuming that has already been
> verified given the overall philosphy of the WHATWG HTML5 document).
> Given that, I don't see <switch> as necessary.
>
> Regards,
> Jeff
>
> [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/ 
> section-the-canvas.html#the-canvas
> [2] http://www.whatwg.org/specs/web-apps/current-work/multipage/ 
> section-video.html#video
>
> On 4/19/07, Brad Fults <bfults@neatbox.com> wrote:
>> Section 2.3.3 of the Web Apps 1.0 draft [1] seems to indicate that
>> DOM3 Core's feature strings [2], including getFeature() and
>> isSupported(0, will be relied upon for such things.
>>
>> [1] - http://www.whatwg.org/specs/web-apps/current-work/multipage/ 
>> section-common.html#dom-feature
>> [2] - http://www.w3.org/TR/DOM-Level-3-Core/core.html#DOMFeatures
>>
>>
>> --
>> Brad Fults
>>
>
Received on Thursday, 19 April 2007 19:13:46 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:15:53 GMT