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

Hi Tab,

Thank you for your comments. I am sorry that you don't understand the
change proposal, Tab. I'll work on trying to improve its clarity. But
in the mean time a few comments.

The point is that none of the "suggestions" presented to date are
functional replacements for longdesc. None of them solve the all of
the use cases.

Even if the canvas contortion could be an alternative to longdesc in a
few situations why add such needless complexity in an attempt to
reinvent the wheel?

Related solutions do not negate the need for longdesc.
http://www.w3.org/html/wg/wiki/ChangeProposals/InstateLongdesc#Related_Solutions_Do_Not_Negate_the_Need_for_longdesc

longdesc should be included in HTML5
http://www.w3.org/html/wg/wiki/ChangeProposals/InstateLongdesc#Conclusion:_longdesc_Should_be_Included_in_HTML5

> * The point of <canvas src> is that it should be able to function as a drop-in
> replacement for <img src>.

I don't consider img broken. But if you consider img broken, it may
more productive to concentrate on fixing img rather than contorting
canvas.

Best Regards,
Laura

On 3/8/11, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> On Tue, Mar 8, 2011 at 1:43 AM, Laura Carlson
> <laura.lee.carlson@gmail.com> wrote:
>> Hi Steve,
>>
>> Thank you for bringing Tab's proposal [1] to our attention [2]. I'm
>> please that longdesc is being thought about again.
>>
>> However <canvas src> is not a viable solution. I added <canvas src>
>> [3] to the "Suggested Alternatives Are Not Viable Solutions" section
>> [4] of the change proposal to reinstate longdesc in HTML5 [5].
>
> While I'm disappointed that you don't think it's a viable solution, I
> understand the reasoning - it attempts to sidestep the "reinstate
> @longdesc" issue by defining a better solution for the future.
>
> Unfortunately, most of the points in the section of your Change
> Proposal
> <http://www.w3.org/html/wg/wiki/ChangeProposals/InstateLongdesc#.3Ccanvas_src.3E>
> are incorrect, misleading, or seemingly nonsensical.
>
> * "<canvas src> is not a functional replacement" - It doesn't have
> 100% of @longdesc's functionality, but it has benefits beyond
> @longdesc as well, which I pointed out.  For example, while a document
> pointed to by @longdesc can be shared by multiple images (how common
> is this?), <canvas src> is resistant to copypaste errors.  Focusing
> entirely on "we need a 100% feature replacement for @longdesc" is not
> a useful direction, unless you really believe that every feature of
> @longdesc is absolutely vital.
>
> * "<canvas src> would be limited to text in the same document" - I
> don't understand what this is supposed to mean.  Is it a restatement
> of the following point that a single @longdesc document can be linked
> to from multiple images?
>
> * "<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.
>
> * "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?
>
> * "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.
>
> * (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.
>
> * "The long description would be forced upon the screen reader user."
> - This is incorrect, and I explicitly addressed this in my proposal.
> This is an AT issue; ATs can easily decide to expose the <canvas>
> descendants only when the user requests it.
>
> * "<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.
>
> * "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>.
>
> * "Accessible does not equate to fallback." - This doesn't make sense.
>  <canvas>'s fallback is defined to be accessibility fallback.
>
>
> Once you remove all the nonsensical or incorrect points in the
> section, the points left are that (1) <canvas src> isn't a 100%
> drop-in replacement for @longdesc, 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>.
>
> ~TJ
 [1] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-March/030766.html
[2] http://lists.w3.org/Archives/Public/public-html/2011Mar/0156.html
[3] http://www.w3.org/html/wg/wiki/ChangeProposals/InstateLongdesc#.3Ccanvas_src.3E
[4] http://www.w3.org/html/wg/wiki/ChangeProposals/InstateLongdesc#Suggested_Alternatives_Are_Not_Viable_Solutions
[5] http://www.w3.org/html/wg/wiki/ChangeProposals/InstateLongdesc

-- 
Laura L. Carlson

Received on Tuesday, 8 March 2011 21:34:03 UTC