Re: New DOM event types

Top-posting:

High Level UI tasks should be singled out for support of legacy systems:
we must recognize that a significant number of clients access the web under
a variety of circumstances: accessibility must be a priority for forward 
looking
technologies.

We can't prevent high level UI events from happening on the client side.

There simply aren't available APIs to handle it, in older software. And 
while many
like to think of software as replaceable: software support has often 
given way to
hardware support -- OS X 10.4 is 'obsolete', Windows 98, ME are 'obsolete',
and the browsers they run are 'unsupported'. Obviously, there are good 
reasons for this.

But -- there are good reasons to continue supporting them, and 
appreciate their existence.
I don't feel comfortable excluding legacy browsers from simple, 
functional web applications.

One consequence of this, is that we must recognize that 'high level UI' 
tasks can not be canceled;
though there are some options for mousewheel.

I've spent some time working with alternative pointing devices, and I'd 
like to find a solution which
works in older browsers (degrades gracefully) and works brilliantly in 
newer browsers.

Let's find a way.

-Charles


João Eiras wrote:
> On Tue, 23 Mar 2010 04:51:26 +0100, Jacob Rossi <rossi@gatech.edu> wrote:
>
>>> The specification already specifies the 'scroll' event, which is not
>>> synchronized with the scrolling action, and not cancelable, being
>>> therefore only useful as a notification.
>>
>> What situation would cause a scroll event to not be synchronized with 
>> the
>> scrolling action?  I agree that it only serves as a notification. But 
>> do we
>> really want web pages to be able to prevent a high level UI task such as
>> scrolling or zooming?  If I go to scroll the web page and the page 
>> cancels
>> the beforescroll, how will this not be perceived as unresponsive 
>> browser UI?
>> Similarly, why would I want to prevent users from zooming the page? 
>> I'm not
>> sure that's helpful for accessibility either.
>>
>> Maybe I'm being ignorant of possible use cases for these events to be
>> cancelable. But otherwise, I'm not sure I grasp the point of these 
>> events.
>> Can you provide some example use cases?
>>
>
> All that info and responses to your concerns were provided in the 
> first e-mail.
>
>

Received on Tuesday, 23 March 2010 05:28:01 UTC