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

As the discussion had turned into bunch (good) advice giving, I
decided to repost this if anyone actually has opinion on this matter
and/or could tell me why the spec recommends firing hashchange on the
document instead of a specific element when a user navigates to a URI
with a hash component.

---------- Forwarded message ----------
From: Bjartur Thorlacius <svartman95@gmail.com>
Date: Tue, 3 Nov 2009 18:46:54 +0000
Subject: elemen.onFocus instead of window.onhashcange ?
To: "whatwg at lists.whatwg.org" <whatwg at lists.whatwg.org>

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)).

Received on Tuesday, 17 November 2009 07:50:30 UTC