Re: Canvas issue with noscript

On Mon, Dec 26, 2011 at 9:15 PM, Charles Pritchard <chuck@jumis.com> wrote:
> You're right: noscript should follow the Canvas specification; it doesn't
> matter what domains are allowed.

I'm unclear what requirement in the canvas specification you think
NoScript developers should be following and are not.

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

NoScript disables and enables script by domain. This is not the same
as having scripting on or off in a browsing context.

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

I'm not convinced vendors not implementing the spec is blocking
NoScript development here. (Looking at the NoScript source, it looks
like it intervenes in the DOM to modify things like plugin objects. I
guess it could do the same for canvases.)

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

OK, those are defects of your particular implementation.

You'd do better to use JS to set a class on the body element and use
the presence of your class to hide all your fallbacks.

In fact this is a common pattern:

https://mikewest.org/2010/03/javascript-detection-pattern

This pattern also avoids the "nasty" flash of unstyled content.

Note more robust progressive enhancement would not replace fallback
with canvas before the script to power the canvas had been executed.
You could avoid flash of unstyled content by having some inline script
at the end of the page that toggles display again if some variable
hasn't been set in the interim. (The significance of inline script is
it isn't subject to network failure.) There is a trade-off between
providing the user something to interact with as fast as possible and
not showing the user an interface until it's fully loaded.

Anyhow there's nothing peculiar to <canvas> about these familiar problems.

> It's not something I would recommend for most developers.

I'd always recommend robust progressive enhancement as a first resort,
and the somewhat less robust class a second resort.

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

I'm not clear we have a clear description of the problem(s) to be solved yet.

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

NoScript selectively disabling scripts by domain is not the same as
scripting being disabled for the canvas element or support for canvas
elements being disabled. Scripts on one domain can affect DOM from
another domain.

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

I don't think we've shown it would help NoScript developers help NoScript users.

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

I don't see how the CSS property would avoid flash of unstyled content
or make progressive enhancement more robust, so I don't at all see how
it helps.

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

Can you elaborate the difficulties with the approach I just suggested?

The leap from you alluding to problems debugging canvas to asserting
vendors should make whether the <canvas> element renders a picture or
its fallback content dependent on CSS "appearance" seems a large one
to me.

--
Benjamin Hawkes-Lewis

Received on Wednesday, 28 December 2011 16:25:31 UTC