[whatwg] elemen.onFocus instead of window.onhashcange ?

Wouldn't it make more sense to fire a focus event on a element whose
id is that of the new hash instead of firing hashchange on the whole
window? In most cases script authors will check the hash against a few
options and then act upon with actions such as loading a new body (or
div).

It would make sense to have the new elements in the HTML but hidden
(or out of view, but scrollable to -- though that's hard to implement)
and when the focus is thrown on the element it's scrollIntoView()d.
Maybe click or some new 'scrolledTo' event might be used instead of
focus, I don't know, but my point is the event should fire on the
element not window and it would be best to do so using an already
supported event.

Importantly this would encourage authors to use real HTML elements as
targets for their #references so UAs which don't support HTML 5
scripting interfaces and/or CSS will render all the content (though
likely some of it'll be out of the screen or not-yet rendered) but
when a user follows a link to it it'll simply scrollIntoView(). This
won't always be exactly what supposed but often close enough.

But then the scrollIntoView function definition should make clear that
non-visual UAs should also support the top argument, by only rendering
the referenced element when applicable (scrollIntoView(false)).

BTW: What happens when scrollIntoView is callod on hidden element? Or
when it's invisible because of styling?

PS: Please ease on the JavaScripting on the WHATWG version of the
spec. I've got a quite old computer and Firefox freezes on me when I
visit that page too often. Is all of that needed? Or don't old UAs
matter to such an backwards compatible spec?

------------------------------------------------------- Switch over to
Linux today --------------------------------------------------
http://www.linux.org

Received on Tuesday, 3 November 2009 10:46:54 UTC