In article <[EMAIL PROTECTED]>, Magnus W wrote: > Chris Hoess <[EMAIL PROTECTED]> wrote in > [EMAIL PROTECTED]:">news:[EMAIL PROTECTED]: > >> In article <[EMAIL PROTECTED]>, Magnus W >> wrote: >>> >>> This is not crap. This will make it possible to use the wheel to >>> scroll in DHTML scrollers, which is a quite useful feature... >> >> ...for building even more ridiculously specific web pages. "This page >> best viewed in IE 6--with a wheelmouse!" > > You don't seem to understand the issue, or rather, are blinded by your > anti-MS feelings. I say; this is a useful feature. I can provide examples > of why it is a useful feature.
Sure, it's a "useful feature". So was <font> at one point, and SHORTTAG and OMITTAG, and so on, and so forth...but in the long run, all of them ultimately hinder the development of the Web. > Features are not evil. Exposing hardware events is not evil. Implementation > may be bad, and maybe some more thought should have gone into that event > model, but the fact that a web designer can capture all kinds of mouse > events makes it easier to build advanced web applications. In fairness, most of the blame should go to the W3C here, in dropping in a slapdash, mouse-centric model for event handlers. Onmousewheel is simply a logical extension of the current ad hoc way of doing things; unfortunately, the current way is wrong. It would be nice if MS said "Waitasec, this whole way of doing things is broken; why don't we look at developing a better framework," but also unrealistic; it provides (as you rightly pointed out) an immediate, cheap payoff to DHTML authors, and the consequences when the installed base of DHTML on the web slams head-on into device independence issues is not their problem. So take this more as a lament that the W3C has screwed up again, and vendors have begun more-or-less innocently following, than a polemic against MS in particular. (I have a box of those at home, anyhow. :-) > More object-oriented event handling WOULD be nice, though. Amen. Rather than the current "hard-coded" event handlers, there should perhaps be a mechanism to create generic event handlers and bind them to specific events in a flexible way (so that an event handler might be bound to a mouseover for mouse-equipped devices and, say, "onread" for a speech-based device). Unfortunately, most of the W3C's work on device independence has gone into CC/PP, which has always struck me as an unrealistic and unimpressive standard. On a somewhat more upbeat note, while I was poking around looking for an official list of event handlers, I found <URL:http://lists.w3.org/Archives/Public/w3c-wai-gl/2002JanMar/0036.html>, which suggests that someone's looking into the situation; maybe event handlers will wind up being divided into generic and device-specific categories, much like logical and presentational elements/attributes in HTML. -- Chris Hoess
