Re: Canvas issue with noscript

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.

>>> 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.

> 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 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>.

> 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.

> 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 Hawkes-Lewis

Received on Sunday, 25 December 2011 13:23:10 UTC