Re: hit testing and retained graphics

On 7/6/2011 2:25 PM, Tab Atkins Jr. wrote:
> On Sat, Jul 2, 2011 at 9:01 AM, Charles Pritchard<chuck@jumis.com>  wrote:
>> On 7/1/2011 12:15 PM, Tab Atkins Jr. wrote:
>>> Honestly, attempting to reimplement HTML in<canvas>    sounds like a
>>> great way to give your competitors a free head-start against you.
>> There are several implementations for HTML rendering for output to PDF
>> and other document formats. Companies have built products based on it.
> I'm not sure how writing an HTML-to-PDF converter is relevant here.
> PDFs are useful outside the web.  We're talking about writing webapps
PDF rendering and generation are useful inside the web as well.
PDF rendering is included in some browsers, and otherwise made
available via plugin for others.

I brought up pdf.js as another example of Canvas being used
for rich application purposes.

Web Apps -- or "Applications" may work with a wide variety of formats;
PDF is a good example of a rich format.

>>> (Imo, we should continue to make it difficult to do full-featured text
>>> and UI in canvas, so that it stays painful.  Then we can make it less
>>> painful to do things the right way, and natural incentives will help
>>> people make the right choice.)
>> Why would you say that out loud Tab? The world is hard enough as it is.
>> It pains me to see this kind of thinking applied to such important
>> decisions.
>>
>> I should not have to defend free enterprise to developers on a web
>> standards mailing list.
> [continued in the following reply]
>> IMO, if your strategy includes actively or passively creating or maintaining
>> "painful" situations for developers, you are doing it wrong.
> I... I don't know how you achieved such a confusion over my goals or
> my proposed solutions.

You've proposed to 1) create a new retained mode API or 2) use SVG, 
abandon Canvas.

I did put forward use cases as you've requested.
> In this specific topic, the right way to get bounds information for
> objects, associate drawn images with captions, keep text around so it
> can be read later by a machine, etc. is to use a retained-mode API.
> The wrong way is to use an immediate-mode one.
The Canvas shadow DOM is a retained mode API -- the DOM is retained-mode.

In what ways are .setAttribute or .appendChild
fundamentally different than  .setElementPath?

They all work on DOM elements.

3) Canvas 2d is an immediate mode API; WebGL is mixed; both
rely on DOM Core as a pre-requisite.

We need to allow authors to update the shadow DOM with the current path
from Canvas. We'd like to allow authors to pull a string representing
the current path, as a DOMString based on SVG paths. We'd also like
to have a Path object, which would make management of multiple
paths a little more efficient in the UA / rendering engine
and little easier on developers.

First and foremost, we have that current issue. The shadow DOM needs 
path data
and bounding boxes.

> the two approaches are somewhat incompatible.  Or, we can promote
> existing examples of the former (like SVG), find out what problems
Canvas requires a subset of DOM and CSS, it does not need SVG,
and requiring it would be big burden on implementers. It's overkill.

it could borrow from existing examples of SVG path strings,
as has been pointed that out for years.
> they have that make them difficult to use, and fix them.  Or, we can
> come up with new retained-mode solutions that are designed up-front to
> solve the problems we know of and be easy to use.
This is what we've done, by specifying the Canvas shadow DOM and learning
that Canvas developers would like pointer events to bubbling from the 
shadow DOM.

> I'm on the side of one of the latter solutions, but only because I
> think it has a better chance of solving accessibility problems
> "automatically".  I am *strongly opposed* to any solution that is
> completely optional, as that will leave the large majority of
> applications using the relevant technology less accessible.

Canvas accessibility will always be completely optional: authors can at
their choosing decide not to use the DOM, and treat the canvas as a
semantically opaque image.

Accessibility is still "optional" on the web; and it's not "automatic",
it just happens that, with authoring tools or good practices, developers
realize that there are opportunities expose semantic data.

Companies and developers can set their own policies as to what
they feel is -optional- and what is not -- Authoring Tools have
a strong obligation to include accessibility in the work-flow.

Received on Wednesday, 6 July 2011 22:11:56 UTC