W3C home > Mailing lists > Public > whatwg@whatwg.org > October 2013

Re: [whatwg] Canvas implementors

From: Michael Norton <norto@me.com>
Date: Tue, 08 Oct 2013 13:34:49 -0400
Message-id: <D2D94AD5-EFED-4BA1-8928-06E691D637A2@me.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: "whatwg@lists.whatwg.org" <whatwg@lists.whatwg.org>
Thank you TJ, i think your last statement is more to the point:

> That said, using <canvas> to easily create cross-platform
> visualizations of data is a very worthwhile and appropriate thing to
> do.

My mention of text's "glyphiness" within canvass is a mere bonus IMO as the more valuable characteristic is this element's apparent ability to scale and repeat visual effects while incorporating text from data sources, and grow and collapse upon targeted cursor events for accessibility sake without any mess upon related texts.  

Cheers to <canvass> creators! I really haven't been this excited about HTML since the <a> element but it's fair to say that <canvass> at least in the 2d context is a cohesion of several processing languages, scripts, and protocols.

Anyone in the New England area up for a meetup to mesh <canvass> with a digital spectrometer browser extension?

Sent by the hope boat.

On Oct 8, 2013, at 12:24 PM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote:

> On Tue, Oct 8, 2013 at 5:53 AM, Michael Norton <norto@me.com> wrote:
>> It seems that the canvas element could really help make this a reality.  The Editor's Draft I reviewed on the w3c site  this week seems to suggest that text and glyphs generated with accessibility-scale functions would not be able to be easily edited (text) nor cut-and-pasted.  Am I understanding this correctly?  If so, that's a plus for me as the data which would be utilized to populate the digital spectrometer on the front end would be pulled from other sources where editing functionality is authorized.
> 
> The last sentence seems unrelated to the rest of the paragraph.
> Editing a data source is a very different thing from editing a local
> copy of text on a webpage.  There is no reason to worry about the
> latter when it's the former that needs authorization.  Using <canvas>
> just to make less-accessible text is inappropriate.
> 
> Similarly, lack of copy/paste functionality is disconnected from
> anything you might need authorization for at the data source level. If
> you can copy/paste, you can just type it out yourself, so you aren't
> preventing anything.  Efforts to restrict or disallow copy/paste on
> websites in the past (stretching back to the early days of JavaScript)
> have always been that terrible combination of utterly worthless and
> completely user-hostile.  Using <canvas> to try and restrict
> copy/paste is a fool's errand, and inappropriate as well.
> 
> That said, using <canvas> to easily create cross-platform
> visualizations of data is a very worthwhile and appropriate thing to
> do.
> 
> ~TJ
Received on Tuesday, 8 October 2013 17:35:17 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:11 UTC