W3C home > Mailing lists > Public > public-canvas-api@w3.org > July to September 2011

Re: hit testing and retained graphics

From: Maciej Stachowiak <mjs@apple.com>
Date: Tue, 12 Jul 2011 01:14:16 -0700
Cc: Richard Schwerdtfeger <schwer@us.ibm.com>, James Robinson <jamesr@google.com>, Charles McCathieNevile <chaals@opera.com>, Charles Pritchard <chuck@jumis.com>, Henri Sivonen <hsivonen@iki.fi>, "Tab Atkins Jr." <jackalmage@gmail.com>, Karl Dubost <karld@opera.com>, "public-canvas-api@w3.org" <public-canvas-api@w3.org>, "public-html@w3.org" <public-html@w3.org>, "public-html-a11y@w3.org" <public-html-a11y@w3.org>, public-html-request@w3.org, Doug Schepers <schepers@w3.org>
Message-id: <F8211246-2741-408A-986D-C26407EC1E97@apple.com>
To: robert@ocallahan.org

On Jul 11, 2011, at 8:52 PM, Robert O'Callahan wrote:

> Doug seems to be proposing a few different things:
> 1) a canvas-like object that reimplements the canvas 2D context API to output an SVG DOM subtree instead
> 2) attaching canvas buffers to SVG elements so you can draw into them as if they're canvases
> 3) some way to get SVG elements into the canvas shadow tree and have them be rendered as well
> I don't understand #3 very well, partly because it's not specified how those elements would participate in rendering. Why not just put the SVG elements over or under the canvas? They'll be rendered and accessible.
> #2 could be addressed by extending SVG stroke and fill values to include arbitrary CSS image values, and using the element() image value to refer to a canvas. I think that feature would be useful in many ways, and I'd be interested in supporting it.
> I think #1 can be quite easily implemented as a JS library. I'm not convinced it would be necessary to provide direct browser support.

Historical note: I believe Dean Jackson actually did #1 within a few weeks of the first Safari release to include Canvas.

Received on Tuesday, 12 July 2011 08:14:56 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:10:32 UTC