W3C home > Mailing lists > Public > public-canvas-api@w3.org > April to June 2010

Re: Clarification on non-interactive, static, visual media

From: Simon Pieters <simonp@opera.com>
Date: Wed, 12 May 2010 13:53:46 +0200
To: "Chris Lilley" <chris@w3.org>
Cc: "public-canvas-api@w3.org" <public-canvas-api@w3.org>, "Jatinder Mann" <jmann@microsoft.com>
Message-ID: <op.vclcnwtkidj3kv@simon-pieterss-macbook.local>
On Wed, 12 May 2010 13:33:52 +0200, Chris Lilley <chris@w3.org> wrote:

> On Wednesday, April 28, 2010, 7:45:55 AM, Simon wrote:
>
> SP> On Tue, 27 Apr 2010 22:16:27 +0200, Jatinder Mann  
> <jmann@microsoft.com>
> SP> wrote:
>
>>> I would like to get clarification on the following passage [1]:
>
>>> "In non-interactive, static, visual media, if the canvas element has
>>> been previously painted on (e.g. if the page was viewed in an
>>> interactive visual medium and is now being printed, or if some script
>>> that ran during the page layout process painted on the element), then
>>> the canvas element represents embedded content with the current image
>>> and size. Otherwise, the element represents its fallback content
>>> instead."
>
> SP> This seems like a stupid requirement. Why would we want to print the
> SP> fallback? In many cases the fallback will be "your browser does not
> SP> support canvas".
>
> In which case it isn't fallback, its an excuse for not having provided  
> any fallback.
>
> *Actual* fallback would be a static snapshot of the graphic, or a text  
> description of what the graphic shows.

If nothing has been painted on the canvas (which is the case under  
discussion), then the canvas is blank, so the correct "actual" fallback  
presumably is the empty string? Still, it seems like a stupid requirement.  
Why would we want to print the fallback instead of the canvas?

-- 
Simon Pieters
Opera Software
Received on Wednesday, 12 May 2010 11:54:24 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:31:50 UTC