[whatwg] <a onlyreplace>

This feels like really nice sugar, but maybe the first step should be to get
the shim out that gets it working using JS now.... and then see how it works
in practice. I totally understand why this looks exciting, but I have the
same uneasiness as Jonas.  It feels like a LOT of magic to go grab a page
and grab out the id and ..... and I am sure there are edges. Cool idea for
sure! It also feels like this should work nicely with the history/state work
that already exists.

On Sat, Oct 17, 2009 at 9:57 AM, Markus Ernst <derernst at gmx.ch> wrote:

> 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?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091017/2ccd98ae/attachment.htm>

Received on Saturday, 17 October 2009 11:16:14 UTC