[whatwg] <a onlyreplace>

Sat Oct 17 09:57:49 PDT 2009

Tab Atkins Jr. schrieb:
> On Sat, Oct 17, 2009 at 12:22 AM, Jonas Sicking <jonas at sicking.cc> wrote:
>> Also, what should happen if the user presses the 'back' button?
> 
> If the browser can remember what the page state was previously, just
> swap in the old parts.  If not, but it at least remembers what parts
> were replaced, make a fresh request for the previous page and
> substitute in just those bits.  If it can't remember anything, just do
> an ordinary navigation with a full page swap.
> 
> It should act as exactly like current Back behavior as possible.
> We're not really playing with the semantics of navigation, so that
> shouldn't be difficult.

I agree to that. I click a link on a page with an URI, and after 
clicking I get a new page with another URI - so if I hit the back 
button, I expect getting back the page I had seen before clicking the 
link. (Of course with the browser-specific peculiarities - Firefox e.g. 
remembers the scroll position, others may not...) The user experience 
when using the back button should not differ whether a browser supports 
@onlyreplace or not.

> On Sat, Oct 17, 2009 at 3:53 AM, Gregory Maxwell <gmaxwell at gmail.com> wrote:
>> I'm guessing that the rare case where you need to write into a
>> replaced ID you can simply have a JS hook that fires on the load and
>> fixes up the replaced sections as needed.
> 
> The functioning of load events here confuses me a bit, because I've
> never done any hacking in that area and so don't understand the
> mechanics well enough to know what's reasonable.  Should the new page
> still fire a load event once its replaceable content has loaded?  I'm
> guessing that the old page never fires an unload event?  I really
> don't know what should happen in this area.
> 
> (After giving it a little thought, though, I think we shouldn't change
> the semantics of load/unload/etc.  These are still useful, after all,
> for when the page *is* completely unloaded or loaded, such as on first
> visit or when the user hits Refresh.  We'd probably want a new set of
> events that fire at the elements being swapped out, and then at the
> new elements once they've been pushed in.)

I admit I don't fully understand load events either. If I get it 
correctly, this is about functions called on load, that access elements 
in the replaceable parts of the page. A common use case for this is 
setting the focus on the first input element of a form. I don't think 
that this can be solved at the UA side, some authoring will be 
necessary; some possible workarounds are:
- Put page-specific scripts into a separate <script> element with an id, 
and include it in the @onlyreplace list;
- make one script that fits for all pages, by checking if an element 
exists before doing actions on it;
- instead of using <body onLoad="foo()">, put the function call into a 
<script> element at the bottom of the replaceable element.

Anyway such things would be much easier (with or without @onlyreplace) 
if the onLoad event handler would be allowed on every HTML element 
rather than on window and body only:
<input type="text" name="Name" onLoad="this.focus()">

But this looks that trivial to me - element.onLoad must have been 
suggested long ago and been declined for good reasons, I assume?