Re: [whatwg]
2009/10/19 Schuyler Duveen : > I'm starting to think the addressability is the main constraint. What > if the original @onlyreplace anchor tag: > > > > would be equivalent to something like this: > > > > which would process onload or onhashchange as we've been describing > @onlyreplace and would appear in the browser's location bar. A more > complicated one (after two jumps) might look something like: > > http://example.com/page1.html#view(page2.html id1 id2);view(page3 id3) Then you are putting specific functionality in the hash. And you would have to, to allow bookmarking. But this breaks the semantics of linking, whereby the hash corresponds to a place within the page (which AJAX applications sometimes use to reconstruct some sort of state). What you are suggesting is putting this AJAX pattern in the browser, in a 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
Re: [whatwg]
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. >>> That way you don't have to wait, nor do you have to know which >>> specific bits are getting replaced. >> >> You would want the event to fire once, though, regardless of how many >> targets are being replaced. Otherwise you won't be able to distinguish >> 3 events generated by one response with content for #div1,#div2, and >> #div3. Event.target should be the original or element, or >> the window object if the request originated via scripting. > > My thoughts were that the event fires at the replaced elements, not > the or that triggered the navigation. So you *would* be > able to distinguish multiple elements, as their event.target would > point to each element as appropriate. > > This isn't a click or whatever event, it's a load/unload event. The > or isn't doing either. Sorry, I had in mind being able to re-apply event listeners to the DOM once the new content was loaded. Of course you can do that in several localised places rather than overall on the whole document (it will be more efficient anyway). Still, it would be nice to be able to identify that "all my bits of content are now loaded" and being able to have an event handler that gets called once, rather than having to account for all the IDs loading independently: I might want to do something that involves several parts of the new content (e.g. highlight it to make the change obvious to the user). Nelson Menezes http://fittopage.org
Re: [whatwg]
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. > That way you don't have to wait, nor do you have to know which > specific bits are getting replaced. You would want the event to fire once, though, regardless of how many targets are being replaced. Otherwise you won't be able to distinguish 3 events generated by one response with content for #div1,#div2, and #div3. Event.target should be the original or element, or the window object if the request originated via scripting. Nelson Menezes http://fittopage.org
Re: [whatwg]
2009/10/18 Tab Atkins Jr. : > On Sun, Oct 18, 2009 at 6:45 AM, tali garsiel wrote: >> It seems the browser will need to make a distinction between a regular >> request and a request invoked by a bookmark. >> In case of a bookmark the server should not strip content so the browser >> must let him know that. > > There's no need to make a distinction. Only requests with onlyreplace > semantics trigger the special behavior. Typing an address into your > browser won't add those semantics, nor will a bookmark; only links > with @onlyreplace (or links on a page with that > don't override their own @onlyreplace with the empty string) carry the > semantics. I guess the @onlyreplace would probably be an important part of making this truly useful. There might be too many maintainability problems stemming from having @onlyreplace all over the place on links (imagine having 5 sections on the page that need updating and dozens of links... and then adding a 6th section). >> In a single page application AJAX updates can be originated in 2 roots: >> 1. The user clicks something in the navigation panel >> 2. The user clicks an action button inside the content panel >> >> An example of use case #2 can be clicking a "save" button. >> In this case the "" tag is usually not used but a button, this means that >> other tags the "" should have the "onlyreplace" attribute. > > I thought it would be interesting to be able to put @onlyreplace on > forms, or perhaps form submission inputs. The two traditional triggers for navigation are anchors and submissions. The @onlyreplace semantics should not be available anywhere else since that would be changing the semantics of non-navigation elements. Any custom UI wizardry should be handled by Javascript, and the semantics of @onlyreplace would be available via something like window.location.assignOnlyReplace(url, [ids]); >> In this example the URL should not be remembered by the history. > > Then you should use ordinary AJAX to do so. �...@onlyreplace is supposed > to be merely an optimization on normal navigation. The url *must* be > remembered by the history. Agreed, as above. I wonder, though, if there might be a problem with this after all... picture 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 to contain the same content as the other two documents. There are a lot of testing paths to guarantee that's the case... does this make the mechanism too fragile? Nelson Menezes http://fittopage.org
Re: [whatwg]
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 refresh so it has the flickering problem, and [2] is custom-built data over AJAX, which is neither bookmarkable nor easy to implement. You could add other variants of [2] that are bookmarkable (e.g. Gmail) but all involve a custom, complex, server-and-client framework. Of course, there's also framesets/iframes, but that also requires server content tailored for this interface -- and it breaks bookmarking. Nelson Menezes http://fittopage.org
Re: [whatwg]
2009/10/18 Ian Hickson : > On Sat, 17 Oct 2009, Schuyler Duveen wrote: >> One of the big issues we found using it on some other sites is that >> javascript listeners (rather than onclick="" attributes), and other DOM >> pointers in the system became stale. Thus, only half the problem was >> solved. Well, you are effectively destroying and regenerating parts of your DOM so whatever JS event handlers you have in place need to be updated on refresh. That is no different from what happens today with AJAX, or indeed multi-frame JS. >> Also, the problem (as I implemented it) is that XMLHttpRequest.xml has >> been very finicky in past (and current) browsers. My comments in the >> code reflect some of the things you need to make sure you're doing to >> make it work across browsers (at least if you want a DOM vs. regex >> implementation): >> >> * IE 6 needed the Content-type: text/xml >> >> * Firefox (?2.x) wants xmlns="http://www.w3.org/1999/xhtml"; in html tag >> >> * IE and Safari don't handle named entities like well in this >> context and should be numeric (e.g. ) I ran into the same problem, but it is possible to invoke in current browsers their HTML parsers by injecting the responseText of XMLHttpRequest (as opposed to responseXml) into a temporary Document (in a temp iframe). I would imagine it would be a requirement for implementing browsers to use the same parsing rules on the "onlyreplace" document as they would for a normal document. Indeed, it should be no harder to build a onlyreplace document than any other, since the same document would be usable interchangeably in both contexts. >> Vendors might better serve us by reducing these hoops to jump through so >> a javascript library could do the job reliably. >> >> This method did make it much easier to leverage server template code. >> But since it largely simplifies server template code, then why not stick >> with server-side solutions like Ian Bicking's: >> http://blog.ianbicking.org/2008/09/08/inverted-partials/ The possibility remains to use partial content responses to optimise resource usage (via the proposed "onlyreplace" HTTP header), but the point of this proposal is that it makes it easy to address the no-UI-refresh requirement without a complex server- and client-side framework, and offers transparent fallback. It is not so much that this can't be done today (it can) but that we would standardise and promote the way to do it right. >> It's still a bit weird that this proposal, instead of allowing every >> element to be a link (like XHTML2), would allow every element to be >> something like an IFRAME (all while a thread remembering how evil >> framesets are continues). But this doesn't make different elements behave like iframes since every link still corresponds to a single document, so it doesn't break navigation or bookmarking. > My recomendation would be to follow the process for adding features: > > > http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F > > In particular the bit about experimental implementations. I think this > idea looks very interesting, but it's hard to evaluate without concrete > experience with a browser implementing this (or, as Jonas suggests, a > library that hacks it in). http://test.fittopage.org/page1.php ? > 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
Re: [whatwg]
The cruft in the hash is needed so that we know what IDs to refresh when navigating back (which could be taken away into a JS URL-to-IDs map), and to detect a change if the same URL is accessed several times (that's probably overkill). Still, the point was to show it can work today; it really 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 be >>> faked using onhashchange and fragment identifier tricks. It's >>> certainly not as elegant as pushState (that is, after all, why >>> pushState was added), but it's something 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: >> >> http://test.fittopage.org/page1.php > > Yay, sweet! But why so much cruft in the hash? Also, going back to the > original page (where there is no hash) doesn't seem to work (at least > in Firefox trunk nightlies). > > / Jonas >
Re: [whatwg]
2009/10/17 Jonas Sicking : > In fact, you don't even need to use pushState. For now this can be > faked using onhashchange and fragment identifier tricks. It's > certainly not as elegant as pushState (that is, after all, why > pushState was added), but it's something 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: http://test.fittopage.org/page1.php Nelson Menezes http://fittopage.org
Re: [whatwg]
2009/10/17 Jonas Sicking :
> On Fri, Oct 16, 2009 at 11:06 AM, Tab Atkins Jr. wrote:
>> Promoting this reply to top-level because I think it's crazy good.
>>
>> On Fri, Oct 16, 2009 at 11:09 AM, Aryeh Gregor
>> wrote:
>>> On Fri, Oct 16, 2009 at 10:16 AM, Tab Atkins Jr.
>>> wrote:
>>>> As well, this still doesn't answer the question of what to do with
>>>> script links between the static content and the original page, like
>>>> event listeners placed on content within the . Do they get
>>>> preserved? How would that work? If they don't, then some of the
>>>> benefit of 'static' content is lost, since it will be inoperable for a
>>>> moment after each pageload while the JS reinitializes.
>>>
>>> Script links should be preserved somehow, ideally. I would like to
>>> see this be along the lines of "AJAX reload of some page content,
>>> without JavaScript and with automatically working URLs".
>> [snip]
>>> I'm drawn back to my original proposal. The idea would be as follows:
>>> instead of loading the new page in place of the new one, just parse
>>> it, extract the bit you want, plug that into the existing DOM, and
>>> throw away the rest. More specifically, suppose we mark the dynamic
>>> content instead of the static.
>>>
>>> Let's say we add a new attribute to , like ,
>>> where "foo" is the id of an element on the page. Or better, a
>>> space-separated list of elements. When the user clicks such a link,
>>> the browser should do something like this: change the URL in the
>>> navigation bar to the indicated URL, and retrieve the indicated
>>> resource and begin to parse it. Every time an element is encountered
>>> that has an id in the onlyreplace list, if there is an element on the
>>> current page with that id, remove the existing element and then add
>>> the element from the new page. I guess this should be done in the
>>> usual fashion, first appending the element itself and then its
>>> children recursively, leaf-first.
>>
>> This. Is. BRILLIANT.
>
> [snip]
>
>> Thoughts?
>
> We actually have a similar technology in XUL called "overlays" [1],
> though we use that for a wholly different purpose.
>
> Anyhow, this is certainly an interesting suggestion. You can actually
> mostly implement it using the primitives in HTML5 already. By using
> pushState and XMLHttpRequest you can download the page and change the
> current page's URI, and then use the DOM to replace the needed parts.
> The only thing that you can't do is "stream" in the new content since
> mutations aren't dispatched during parsing.
>
> For some reason I'm still a bit uneasy about this feature. It feels a
> bit fragile for some reason. One thing I can think of is what happens
> if the load stalls or fails halfway through the load. Then you could
> end up with a page that contains half of the old page and half the
> new. Also, what should happen if the user presses the 'back' button?
> Don't know how big of a problem these issues are, and they are quite
> possibly fixable. I'm definitely curious to hear what developers that
> would actually use this think of the idea.
I have spent most of last night trying to figure out what's wrong with
this proposal. I can't think of anything important except for the back
button behaviour. The suggestions I had have already been mentioned:
the tag extension and the marker HTTP headers. You'd obviously
also need a JS hook to be able to invoke this functionality
programmatically (location.onlyreplace...?)
Another plus point for this idea is that it is implementable on
existing browsers with some JS (I'm trying something simple at the
moment and it works, albeit only for XML documents).
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
Re: [whatwg] framesets
Wow, what a tour de force; 78 messages and no progress. Peter, I believe the only reason the discussion has carried so far is because you are, actually, on to something. You just don't seem very aware that people are actually trying to pin down and solve the "something" and keep banging on about framesets being the cure-all, whilst ignoring other points. Here's (yet another) summary: 1) Framesets have been deprecated for quite a long time. The reasons for the deprecation have been repeated ad nauseam, and very solid. 2) There is a specific use-case (that has nothing to do with databases or bookmarking) that framesets solve better out-of-the box right now in most browsers: that of a panel-based layout that allows resizing and maintains UI state without flickering whilst loading content in different panels (this is, I believe, the "something" you're getting at). 3) There are HTML5-conformant solutions available right now that allow you to replicate the above scenario with a little more work. The iframes solution with a bit of JS [1] [2] for handling the resizing is probably the easiest to implement, although an analogous solution with AJAX is probably the best available (which allows for deep-linking when this is desirable and doesn't automatically break bookmarking). You can also (if you wish) break bookmarking/the back button with these solutions, especially the AJAX one. There is also the CSS position: fixed solution that will be adequate for a large number of scenarios, or can complement the other two. 4) As repeated many times, you don't have to use HTML5. Keep using HTML 4 Frameset [3] if you insist on using the frameset solution and care about validation. The documents within each frame can be HTML5. Or use HTML5 with framesets -- it won't validate but is guaranteed (by the spec) to work. Do expect to run into the usability problems inherent to frames, though. 5) There is a known need for CSS to handle the above panel resizing use-case. That is a first-class CSS problem; don't expect the HTML spec to address that, especially not with a mechanism (framesets) that has many drawbacks and is deprecated for good reasons. For immediate solutions, see 3) and 4) above. 6) For clarity sake, I'll repeat the point made several times:the bookmarking/navigation/security issue is *not* solved by framesets, and the slight hack to make this work (javascript's "replace") as you suggest is neither exclusive to framesets nor (in the case of security) acceptable. As an aside, there is a reason why AJAX has become so popular over the past few years: it solves the specific UI-reset 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/html4/sgml/framesetdtd.html Nelson Menezes http://fittopage.org 2009/10/14 Peter Brawley > > Rimantas, > > >Maybe there are not many sites because nobody wants this type of sites? > > You think nobody wants Javadoc? Javadoc has been shipping with an read-only > version of this use case for years. > > The full use case is treeview database maintenance. Tree logic has been slow > to mature in SQL, is non-trivial in HTML as we see, and is hard to generate > from PHP/Ruby/whatever. > > >I hate this type of documentation sites personally. > > Fine, you've no need for website maintenance of data-driven trees. That's not > a rationale for excluding framesets from HTML5. > > > And to me this use case looks built around the chosen implementation, > > Wrong. Frameset was chosen because it provides the most efficient available > implementaiton. > > > while I prefers solutions built around solving the real need. > > Which this is. > > >So you want HTML5 spec tailored for this particular case of yours? > >Can I have tag, please? > > May I have rational responses please? This is not a request for a new > feature. I want HTML5 to continue support for useful HTML. > > >Nobody forbids you from using previous versions of HTML. > > Correct, but excluding frameset from HTML5 increases the likelihood that > browsers will drop support for the feature. > > PB > > - > > Rimantas Liubertas wrote: > > So it does not answer the question: if framesets are as you claim not needed > for the full spec, there should be lots of non-frameset sites which meet > this spec as efficiently as ours does. > > > Maybe there are not many sites because nobody wants this type of sites? > I hate this type of documentation sites personally. > And to me this use case looks built around the chosen implementation, > wh
