W3C home > Mailing lists > Public > public-canvas-api@w3.org > October to December 2011

Re: Canvas issue with noscript

From: Charles Pritchard <chuck@jumis.com>
Date: Mon, 26 Dec 2011 13:15:46 -0800
Message-ID: <4EF8E402.7050406@jumis.com>
To: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>
CC: software@informaction.com, Canvas <public-canvas-api@w3.org>
On 12/25/2011 5:22 AM, Benjamin Hawkes-Lewis wrote:
> On Sun, Dec 25, 2011 at 1:04 PM, Charles Pritchard<chuck@jumis.com>  wrote:
>>> Given noscript allows selective activation of scripts by domain, and
>>> given that the origin of the script may be different from that of the
>>> DOM containing the canvas, what might the UI for this look like?
>>
>> That's a good point, and I hadn't thought of it. My thinking was that this
>> behavior should be based on the domain serving the page itself .
>>
>> So, whatever the html page is, the primary origin, that's where security
>> should be checked. If that origin is not trusted to run scripts, then the
>> canvas element should not render and the fallback should be used.
> With that UI, if your script is on another domain, you get a broken canvas.
>
> Conversely, if authors only add canvases when they can control them,
> you get no broken canvas.


You're right: noscript should follow the Canvas specification; it 
doesn't matter what domains are allowed.

If scripting is enabled, if the site is interactive, then canvas should 
operate normally. If scripting is disabled for the site, and the site is 
not interactive, then the fallback content should be used.

I suspect that doing this is more difficult for the noscript authors 
than it should be. I understand that if authors program in a very 
specific way, to work-around the defects in browsers, they can get 
better results. I don't think that's where thinkgs should be left. This 
is an implementation detail that simply wasn't followed by vendors.


>>>> Currently, I use some very nasty CSS and JS hacks to get the appropriate
>>>> effect.
>>> What do you currently do?
>>
>> I use a page with full fallback content outside of<canvas>, then I use
>> javascript inline to toggle that fallback content to display: none
>> immediately.
>>
>> <div id="mycontent">
>> My Fallback Content!
>> </div>
>> <script>document.getElementById('mycontent').style.display = 'none';
>> </script>
>>> What stops you create the<canvas>    node from the script that is going
>>> to make it work, rather than putting it into the DOM before you know
>>> that script will execute?
>>
>> It's rather typical in canvas apps that the canvas tag has been
>> authored into the HTML.
> a) "Typical" canvas apps don't provide useful fallback.
> b) Typical is often not best practice.


Point a) The current typical is based on the current standard. I'm 
trying to get Canvas support to a place where providing useful fallback 
is something easy for authors to do. If it's easy, if it works, they'll 
do it. If it's difficult, hacky and vendors don't support it, it's going 
to be a battle to get developers on board. Point b) does nothing for anyone.

>> However, that is something that can be worked around, like the above
>> example.
> I don't see how creating a canvas only if you can control it is hacky,
> or nasty, or a workaround. Your current approach seems reasonable to
> me.

It can cause a flash on the screen, it can lead to unnecessary re-flow, 
it requires inline JS to be laced throughout the static page. It's not 
something I would recommend for most developers. It does belong in the 
list of hacks and tricks at WCAG-TECHS. It's only necessary because 
implementations didn't follow the requirements of the standard. noscript 
is a great example of a third-party package that would really benefit 
from a vendor addressing the use case directly. But, as I said in my 
initial e-mail to them, I've not been able to get the use case accepted 
by vendors.



> It follows a generic principle of progressive enhancement: only
> introduce JS-dependent controls to the DOM if you know you can make
> them work with JS.
>
> Whenever authors deviate from this good practice, Noscript users are
> going to suffer. It doesn't have to involve<canvas>.

"In non-visual media, and in visual media if scripting is disabled for 
the canvas element or if support for canvas elements has been disabled, 
the canvas element represents its fallback content instead."
http://www.w3.org/TR/html5/the-canvas-element.html

Regardless of how close vendors follow that part of the spec, it'd be a 
big help to Canvas developers if a CSS attribute were offered.


>> As for the immediate display: none, it still has some effects during
>> rendering, especially the first time the page is loaded.
> Minor presentational glitches, like flashes of unstyled content, are a
> common disadvantage of robust progressive enhancement.

Robust progressive enhancement is often accomplished with excellent 
techniques and use of CSS.

By introducing a CSS property to handle the situation, we can retire 
this issue.


>> It's nice to have the ability to see the fallback content inline as part of debugging tools. That, and noscript, are two reasons why I'm trying to find a resolution to this.
> I think it might be best not to conflate the problems.
>
> When debugging, maybe you could set a flag in your JS that puts the
> <canvas>  node above its fallback content rather than wrapping the
> fallback content in<canvas>?
>

Benjamin, I've been working at this a long long time. I'm quite aware of 
techniques to debug. I'm telling you they're more difficult than they 
should be.

That said, I don't mean to make this too personal. I've been repeating 
this issue for quite some time, and I've not yet found a 
vendor-developer who has accepted the premise of the use case nor 
accepted the benefits as worthwhile.

-Charles
Received on Monday, 26 December 2011 21:16:06 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 26 December 2011 21:16:07 GMT