W3C home > Mailing lists > Public > www-dom@w3.org > January to March 2010

Re: New DOM event types

From: Charles Pritchard <chuck@jumis.com>
Date: Tue, 23 Mar 2010 21:38:27 -0700
Message-ID: <4BA99743.7030006@jumis.com>
To: Joe D Williams <joedwil@earthlink.net>
CC: João Eiras <joaoe@opera.com>, Jacob Rossi <rossi@gatech.edu>, www-dom@w3.org
The existence of old browsers is not something to be ignored.

Yes new code should run in new browsers;
and yes, new browsers should be able to work with old code.

It would be a disservice to that "rarely encountered" percentage of
users, to dismiss them. Even one percent is a tremendous amount of users.

No, DOM scripting should not "cater" to these users. But it should allow
individual developers to cater to them, and it should allow, the best it 
can, for
backward compatibility.

....

I'm very much talking about the "mouse" event. Because just about 
anything else
can be controlled through the "old" DOM interfaces.

Even that darned mouse-wheel can be fudged with, but they are clunky hacks.

There isn't a thing we can do about the standard "mousemove" event, however.
We can stop it from bubbling; we can't stop it from happening.

Your 4-row table suggests that "new code" which would literally control 
the mouse
pointer, would be acceptable.

I'd love it if we could; and we could certain spec out the necessary 
security restrictions.

But this can't be supported, period, in an older browser.

Any suggestion for a new, cancelable, event, must keep existing 
implementations in mind,
or risk alienating the disabled, the impoverished, the non-technical, 
and other very human,
very vulnerable people who use the Internet.

...

Back to the actual start of the thread: beforescroll.

I'd suggest taking a look at the mousewheel event.

Hack'ish as it may be, mousewheel has been, for some time, a general
pointer event. A mouse wheel could be a keyboard short cut, a touch screen,
a pen, a mouse gesture, or, as it was originally, a mouse wheel.

Tapping into the mousewheel event allows you to stop scrolling, 
provided, of course,
that the user does not decide to use the scroll bar.

I'd agree with Jacob that it's dangerous to "prevent a high level UI 
task such as scrolling [the overflow/scroll bar]"
from happening. That kind of host environment manipulation seems outside 
of the scope of DOM.

Meanwhile, DOM does provide for detecting scroll events, and reacting 
accordingly.

Remember, we are in a single threaded event loop.


-Charles




Joe D Williams wrote:
> Charles > But -- there are good reasons to continue supporting them, 
> and appreciate their existence.
>
> I was thinking there is no reason to support older obsolete and rarely 
> encountered browsers, but there are great reasons to attempt to 
> support the old html user code that the old browsers used to run.
>
> old code, old browser = OK
> old code, new browser = OK as much as possible
> new code, old browser = probably not.
> new code, new browser = html5 spec
>
> Especially for DOM scripting, interactivitity, any worthwhile new 
> features, accessibility, and general usabiilty in today's WWW, not 
> worth it to cater to old browsers but maybe worth it to cater to old 
> html code.
> Thanks and Best Regards,
> Joe
>
>
>
Received on Wednesday, 24 March 2010 04:39:43 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 22 June 2012 06:14:04 GMT