Re: DOMActivate vs. Click

Doug Schepers wrote:
> I suppose this will save some small amount of code size and complexity, 
> but not enough to break even a small amount of content.  I'd be curious 
> exactly how much code size this would actually save.

The code size is less important to me than the complexity (and spec 
size, which are more or less the same thing).  The focus processing 
model is pretty complex even if all you have are onfocus and onblur, if 
you allow focus changes within those event handlers.  It gets more 
complicated the more handlers there are; you have to specify the result 
of all possible actions in all possible handlers, in all possible 
combinations.

For DOMActivate, it complicates the processing model for activations a 
good bit, especially since it can be canceled (as can click, of course; 
things get particularly fun when one is canceled an the other is not).

Removing complexity where possible is a very high priority, since it 
leads to code that is more understandable, easier to write without 
creating security holes, more maintainable, easier to reason about when 
changing other code around it, and probably faster.

We (Gecko) are definitely willing to break small (if they really are 
small) amounts of content by removing features that are over-complicated 
by design.  We've certainly done so in the past...  I think the comments 
Jonas and I made here are motivated by our perception of this particular 
feature being complicated no matter how you go about it and very rarely 
used in practice on the web.

> (For those who 
> have already implemented it, it would actually be more work to take it 
> out, so I don't think this saves effort.)

Short-run, sure.  Medium to long run, it certainly saves effort to not 
have to deal with code like this:

http://mxr.mozilla.org/mozilla-central/source/content/html/content/src/nsHTMLInputElement.cpp#1690 


> This strikes me as just the opposite of what the WebApps WG has as one 
> of its core missions: specifying what already exists to interoperably 
> support a wider array of existing content.

I'm not sure we really want to specify the union of things that are in 
use on the web and things that are in use in various walled gardens.  IF 
that is indeed the WG's core mission, that's a little unfortunate.  Not 
to mention being a tall order, I suspect.

I can see pulling in things that are not in use on the web on a case by 
case basis if there's good reason to do it and if it doesn't complicate 
the web platform too much (for both authors and implementors).  I'm not 
sure where the tradeoff on that lies for DOMActivate.  I'm very sure it 
does not lie with adding more focus events.

> If there is some significant amount of content (e.g. SVGT1.2 content) 
> that uses it, even if that content is currently in a walled garden (as 
> much mobile content seems to be even today), this would prevent that 
> content from working on the wider Web even if it would otherwise.  As 
> these walled gardens break down the walls, which is happening today, 
> wouldn't it be better to be able to support that content?

That depends on the other costs involved, right.  From what I recall of 
SVGT1.2, this is not exactly the most glaring issue involved in moving 
that content over to things that are generally supported by web UAs... 
Or have things changed significantly?

-Boris

Received on Monday, 27 July 2009 00:00:08 UTC