specific format.
I'm not keen on solving this problem by changing the way linking
works; that was the beauty of the original proposal (other problems
notwithstanding). This seems like a fancy way to bookmark frames...
Nelson Menezes
http://fittopage.org
2009/10/18 Tab Atkins Jr. :
> On Sun, Oct 18, 2009 at 12:20 PM, Nelson Menezes
> wrote:
>> 2009/10/18 Tab Atkins Jr. :
>>> As long as the event bubbles, you can always just listen at the
>>> document root and then check event.target to see who got updated.
>>&g
iginated via scripting.
Nelson Menezes
http://fittopage.org
ure this:
...
Ingredients
Nutrition
Preparation
...
...
Let's say I click the links in order (Ingredients, Nutrition,
Preparation), and now bookmark the page (it's now preparation.html).
When I return to it, #div1 and #div2 will only be populated if
preparation.html is guaranteed t
2009/10/18 Nelson Menezes :
> [1] http://msdn.microsoft.com/en-us/library/aa155133.aspx
> [2] http://developer.yahoo.com/yui/examples/treeview/dynamic_tree.html
Oops, sorry, I meant to give a couple of examples (above) of existing
approaches to maintain user UI state. [1] involves page refr
?
> It seems like the kind of thing that we could adopt early on in the next
> feature cycle, if it turns out to be a good solid model.
Is there a mailing list for HTML 6? :-)
[1] http://msdn.microsoft.com/en-us/library/aa155133.aspx
[2] http://developer.yahoo.com/yui/examples/treeview/dynamic_tree.html
Nelson Menezes
http://fittopage.org
eally isn't an elegant solution as-is :)
Nelson Menezes
http://fittopage.org
2009/10/18 Jonas Sicking :
> On Sat, Oct 17, 2009 at 12:45 PM, Nelson Menezes
> wrote:
>> 2009/10/17 Jonas Sicking :
>>> In fact, you don't even need to use pushState. For now this can
ing that can be tried today.
Well, here's a badly-hacked-together solution that emulates this behaviour...
I think it'll be helpful even if it only gets used in a JS library as
you mention (change the attribute to a classname then). Still, it can
be made to work with today's browsers:
ht
As for the back button, there are a few possibilities:
- Reload the full page
- Load & process the document using the same "onlyreplace" behaviour
as explained in the original email
- Allow a response header that specifies which of the above the
browser should do on clicking the back button
("backwards-navigation-safe: True"?)
- The browser remembers the state of the document as it was prior to
each history point and resets it to that state before applying the
point in history we are jumping to (yikes!)
Any concerns about caching that aren't covered by the above?
Nelson Menezes
http://fittopage.org
et issue that is inherent
in full-page refreshes. Maybe there is room for a better,
standard-based approach to solving this issue, but framesets ain't it.
[1] http://methvin.com/splitter/4psplitter.html
[2] http://developer.yahoo.com/yui/examples/layout/page_layout.html
[3] http://www.w3.org/TR/htm
10 matches
Mail list logo
