- From: Charles Pritchard <chuck@jumis.com>
- Date: Wed, 06 Jul 2011 15:11:24 -0700
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- CC: Charles McCathieNevile <chaals@opera.com>, Henri Sivonen <hsivonen@iki.fi>, "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>
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