- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Wed, 6 Jul 2011 14:25:02 -0700
- To: Charles Pritchard <chuck@jumis.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 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. > > This is very you/your-industry centric. > > There are several implementations for HTML rendering for output to PDF > and other document formats. Companies have built products based on it. > > You seem to misunderstand the diversity of a free market. > > Consider that a company might start-up, with the intention of creating > another HTML to PDF rendering utility; or a rendering utility for some other > format. > > By implementing in ECMAScript, they may indeed have a head-start against > other companies implementing in C++; though ecmascripten and NaCl > are great projects, I'd see greater success sticking to ECMAScript and > Canvas > to implement with. 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 in the browser that reimplement the browser. If you want to use PDF in an analogy, it's like designing a webpage by first writing HTML, then converting to PDF, then hosting those on your site. >> (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. > > If you have something to back that stance up, share it here. I'm not for > DRM, I'm not for obfuscation, > nor am I for over-specification. But -- if you want to put those forward as > an argument, I will keep > an open mind, as I do understand there are a business needs for each. I... I don't know how you achieved such a confusion over my goals or my proposed solutions. There are right ways and wrong ways to do things. Ideally, the right way is easy, and the wrong way is painful. That way, natural incentives will encourage people to do things the right way. We don't need to force *everyone* to do things the right way - it may very well be the case that, on occasion, the "wrong" way is actually right for an individual situation - but as long as most people do things right, we're okay. 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. We can choose to patch the latter into the former. It has a good chance of turning out badly, because the basic assumptions underlying the two approaches are somewhat incompatible. Or, we can promote existing examples of the former (like SVG), find out what problems 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. 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. ~TJ
Received on Wednesday, 6 July 2011 21:25:51 UTC