Re: Proposal for <canvas src> to allow images with structured fallback by Tab Atkins Jr.

Tab Atkins Jr., Tue, 8 Mar 2011 11:13:53 -0800:
> On Tue, Mar 8, 2011 at 1:43 AM, Laura Carlson
> Laura Carlson wrote:

> [...] <canvas src> is resistant to copypaste errors.  

The one and only issue here seems to be that the URL of @longdesc could 
be a relative URL. If the @src is a relative URL and gets out of sync, 
then the error immediately is experienced by a sighted author (provided 
he/she tests it in a graphical browser). Whereas for links, including 
@longdesc, they have to be tested by the author to see that they work.

But even normal 'blue' link have to be tested to see that they work.  
The real issue, thus, is not copypaste errors but the fact that it is a 
bit difficult to test longdesc URLs, manually. It requires specific 
user agents. Or special set up. 

As I tested the <canvas src> idea (by using a <object data=image> as 
"test bed"), it becmae clear that it is also very demanding to test a 
link that appears inside the fallback of <canvas src>. It requires 
special set-up, and it doesn't work in all an any user agent:

If you disable images in Webkit, then nothing happens in the object 
element, whereas for the <img element one can, via CSS, display the 
values of the attributes inside the image canvas. In Firefox and IE one 
can disable image loading in the preferences - then one can test it. (I 
have not tested if this makes displays the @alt or children of <object 
as fallback.) Opera is the only browser were it is really simple to 
test what happens with images disabled.

May be it is more straight forward to explain how to test that a link 
inside <object@data=image works compared to testing @longdesc. But not 
very much. 

Regarding Laura's pont about 'fallback' versus 'altnernative content': 
it precisely because it is fallback, that it demands so much from the 
user to display and test it ...

> [...] Focusing entirely on "we need a 100% feature replacement 
> for @longdesc" is not a useful direction, [...]

An axiom that @longdesc should be removed is also unhelpful.

> * "<canvas src> would be limited to text in the same document" - I
> don't understand what this is supposed to mean.

If you recommend doing something like this:

    <canvas src=image > Lorem ipsum. <a href=link >Long 
desc</a></canvas>

then, since that link is realtive, what about the resistance towards 
copypaste errors: ? (See above.) And what about links around the 
<canvas element? (THat, I admit, is mostly a conformance question - 
because it works, in browsers.)

> [...] Is it a restatement of the following point that a single
> @longdesc document can be linked to from multiple images?

One can of course place a link inside the fallback of <canvas@src. 
Would authors do that? When would it work? That is: When can we expect 
UAs to support <canvas@src ? For a long period, designers would find it 
difficult to rely on. It would also be demanding to get them to change 
habit. 

> * "<canvas src> would not permit pointing to external sources... such
> as MathML or SVG" - This doesn't make any sense.  <canvas> takes any
> valid HTML as descendants, including MathML and SVG.

You are right about this. But see above.

> * "To display an image, an author would have to create a canvas
> context. This would make it more prone to authoring error." - This
> doesn't make any sense.  Maybe the writer didn't understand the role
> that @src would play, and assumed that you'd have to use JS and use
> drawImage on a Canvas 2d Context to get the image to display?

It *is* true until that time when UAs support <canvas@src. Would take a 
long time before designers could trust <canvas@src to work. See above.

> * "People don't copy and paste the img elements." - This doesn't make
> sense (note - this isn't in full context - the full context is this
> line, combined with the paraphrased next point).  The "copypaste
> safety" argument that I made was about authors copypasting code.  I
> assume that the writer of this point didn't understand what I was
> trying to say, and assumed I was making some point about copypasting
> the image itself.

Authors copypaste code, right. But the problem here is being able to 
*experience* that the URL is wrong. See above. Even if the fallback is 
markup - without any link at all, it is not straight forward to get the 
fallback - instead of the image - to display in a browser. At least not 
for ordinary users/authors.

> * (paraphrased) "[Using canvas breaks right-click 'Save Image'.]" -
> This doesn't make sense.  Firefox, for example, certainly exposes
> "Save Image" on <canvas> elements.  Chrome doesn't, but this is a UA
> issue, and should be fixed in due time.

There are many user agents to support, including legacy ones. I don't 
think authors will pick <canvas@src for ordinary images, for a long 
time yet. As for Webkit, then Safari have similar problems with 
<object@data=image. Not to speak <object@data=iamge in legacy IE ...  
Often legacy compatibility is extremely important to HTMLwg members ... 
Not in this case?

Note that neither I or Laura are "against" <canvas@src.  So is it so 
that <canvas@src wouldn't be any useful if it doesn't replace 
@longdesc? 

Personally I think that it could very well be taken into use in cases 
were one otherwise could have used <img@longdesc. If the one or the 
other feature will end up working very much better in real life, then 
that feature might "win", despite that they are different and even if 
they are not ideal. But why force anyone to do this or that?

> * "The long description would be forced upon the screen reader user."
> - This is incorrect, and I explicitly addressed this in my proposal.

You said about that issue, FIRSTLY: 
	]] there is nothing requiring a screen-reader to automatically 
       present the alternative content to the user[[
However, for <img@alt=content, the @alt=content is immediately 
presented to the user. Why and how would you special case <canvas with 
regard to when the alternative content is presented? A UAs must present 
*something* - what? Just say "image"? That's not how <img> is presented.

SECONDLY:
  ]] UAs must already have ways to delay
showing in-band information until requested, so as to correctly
represent the <details> element, for example.  The same mechanism can
be used for <canvas>; while I'm not in any place to recommend UI for
screen-readers, it may even make sense to present <canvas> and
<details> in a unified fashion [[
But, gain were is the short "head" of <canvas, that could be presented 
to the user before the "body" is presented? <canvas does not have such 
a head.

Your addressing of the problem does not meet my bar for being 
"explicitly addressed".

> This is an AT issue; ATs can easily decide to expose the <canvas>
> descendants only when the user requests it.

Again, this is very different from how the <img@alt=content is 
presented to the user. 
 
> * "<canvas src>... does not have an existing base..." - I can't parse
> this sentence.  I have a glimmer of what the author was intending to
> write, but I'd prefer not to have to imagine the argument when I could
> instead just request it be clarified to make sense.

This is the full text:

]] * details is not recognized by existing authoring tools, user 
agents, assistive technologies, educational material, etc. It does not 
have an existing base that if taken away would slow down quite 
considerably getting back to the important gains longdesc has given. [[

Which leaves me wonder what you couldn't parse.

> * "Not all images that require a long description will be in <canvas>"
> - This doesn't make sense.  Perhaps the writer didn't read my
> proposal?  The point of <canvas src> is that it should be able to
> function as a drop-in replacement for <img src>.

So would you say that all the @alt text writing rules applies to 
<canvas@src ? Of course not. Would you tout <canvas@src as the solution 
_only_ when the image needs a long description? Will you make <img 
illegal or deprecate it? There would be a long transition period before 
authors would even trust it - see point that you couldn't parse, above.
 
> * "Accessible does not equate to fallback." - This doesn't make sense.
>  <canvas>'s fallback is defined to be accessibility fallback.

I think that the fallback can be authored so that it can serve as 
alternative content ... 

> Once you remove all the nonsensical or incorrect points in the
> section,

Assuming that there is no sense, is nonsensical.

> the points left are that (1) <canvas src> isn't a 100%
> drop-in replacement for @longdesc, 

Very little in the debated section parse into something like that. [1]

> and (2) <canvas src> isn't yet
> implemented, so it will take time before its a usable solution.
> 
> The second point can be mitigated with a simple polyfill that grabs
> the @src off the <canvas>, creates an <img> with the same @src, and
> then draws the <img> into the <canvas>.

One would probably solve it like that - at least out on the Web. But in 
other contexts, such as e-mail, and when the fallback isn't very 
complicated, then one would simply place an <img inside the fallback. 
This <img could also have a @longdesc ... I get a deja vu about how 
<object@data=image works in legacy IE ... 

So the simple solution would be to just use <img - in the fallback or 
instead of <canvas. Thus, in practice, it is likely that one only use 
<canvas@src whenever a long description would be needed. Which, in 
practise, means that one would not use this method very much at all, 
I'm afraid.

I imagine that <canvas@src could be useful, but if you consider that it 
its usability w.r.t. @longdesc that makes it live and dies, then I 
think it will die, in the cradle.

[1] 
http://www.w3.org/html/wg/wiki/ChangeProposals/InstateLongdesc#.3Ccanvas_src.3E
-- 
leif halvard silli

Received on Tuesday, 8 March 2011 23:07:00 UTC