Re: hit testing and retained graphics

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:50 UTC