Re: [whatwg] a onlyreplace
Nelson Menezes wrote:
2009/10/18 Ian Hickson i...@hixie.ch:
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.
My point (which feeds on Marcus Ernst's point) is that we need some kind
of load event. Maybe something like:
document.addEventListener('replaceonly')
with the event object providing access to the new DOM content and the
old DOM node.
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 nbsp; well in this
context and should be numeric (e.g. #160;)
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.
I like this idea a lot. It seems like a job for the HTTP Content-Range
header (using a different word than 'bytes').
One other thought:
It might be a good idea to allow the server to explicitly demand a full
load. (I.e. a server-side equivalent to window.top=location)
There's still seems like a big danger in addressability. Yes, it's a
problem in ajax, but it's a problem that authors can solve on their own
with hash tags (in ad-hoc ways). When the browser takes over the
location value, the author's ability to do that is undermined. Maybe it
should all *stay* in the hash tags like your implementation has it.
Something like:
http://example.com/#id1=page2;id2=page3;
where the value is the most recent source URL for that @id.
cheers,
sky
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] a onlyreplace
Tab Atkins Jr. wrote:
On Sun, Oct 18, 2009 at 11:20 AM, Schuyler Duveen
wha...@graffitiweb.org wrote:
Nelson Menezes wrote:
My point (which feeds on Marcus Ernst's point) is that we need some kind
of load event. Maybe something like:
document.addEventListener('replaceonly')
with the event object providing access to the new DOM content and the
old DOM node.
I agree, though I think it might be better to follow the current
load/unload model with a replaceUnload/replaceLoad event being fired
at the appropriate elements. (Or, as was suggested by someone else,
just using load/unload on a particular element, since currently it
just fires at window. I don't know if there are inherent problems
with this or what.)
I like the first one. I'd rather it be on the document (or window) so
we don't have to wait for the first instance of an element to show up.
More importantly, then I can write javascript that's more generic rather
having to know about which specific elements will be doing the
loading/unloading in a particular document.
There's still seems like a big danger in addressability. Yes, it's a
problem in ajax, but it's a problem that authors can solve on their own
with hash tags (in ad-hoc ways). When the browser takes over the
location value, the author's ability to do that is undermined. Maybe it
should all *stay* in the hash tags like your implementation has it.
Something like:
http://example.com/#id1=page2;id2=page3;
where the value is the most recent source URL for that @id.
Well, the point is that this should generally act as just an
optimization of normal navigation. Clicking on a href=foo
onlyreplace=bar should give you the same result as clicking on a
href=foo, just without the overall page getting flushed. So the
address should update to http://example.com/foo;, etc.
You can always url-hack on your own, if you need to.
The problem is that people will make links that refresh different parts
of a document, to the point that the current document is no longer
addressable. Use cases for this happen often enough (not necessarily
good design, but people will do this)
In the past, a good way to give (back) addressability to users is with
hash tags. But here, the location changes, and the hash goes away.
Standard anchor tags (with no javascript) have generally been
addressable to users by default. When this hasn't been true, like with
framesets, lots of confusion and frustration ensues.
If this is, in the longterm, going to work non-dynamically, then things
should be addressable by default. It's one of the killer features of
the web :-)
/skjy
~TJ
Re: [whatwg] a onlyreplace
Tab Atkins Jr. wrote: On Sun, Oct 18, 2009 at 11:50 AM, Schuyler Duveen wha...@graffitiweb.org wrote: The problem is that people will make links that refresh different parts of a document, to the point that the current document is no longer addressable. Use cases for this happen often enough (not necessarily good design, but people will do this) In the past, a good way to give (back) addressability to users is with hash tags. But here, the location changes, and the hash goes away. Standard anchor tags (with no javascript) have generally been addressable to users by default. When this hasn't been true, like with framesets, lots of confusion and frustration ensues. If this is, in the longterm, going to work non-dynamically, then things should be addressable by default. It's one of the killer features of the web :-) You're right, and this makes me think more strongly that restricting the ability to specify the replaceable bits to just base is the right way to do this. I'm starting to think the addressability is the main constraint. What if the original @onlyreplace anchor tag: a onlyreplace=id1 id2 href=page2.html / would be equivalent to something like this: a href=#view(page2.html id1 id2) / 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) /sky
Re: [whatwg] a onlyreplace
Tab Atkins Jr. wrote: On Sun, Oct 18, 2009 at 9:42 PM, Schuyler Duveen wha...@graffitiweb.org wrote: Tab Atkins Jr. wrote: On Sun, Oct 18, 2009 at 11:50 AM, Schuyler Duveen wha...@graffitiweb.org wrote: The problem is that people will make links that refresh different parts of a document, to the point that the current document is no longer addressable. Use cases for this happen often enough (not necessarily good design, but people will do this) In the past, a good way to give (back) addressability to users is with hash tags. But here, the location changes, and the hash goes away. Standard anchor tags (with no javascript) have generally been addressable to users by default. When this hasn't been true, like with framesets, lots of confusion and frustration ensues. If this is, in the longterm, going to work non-dynamically, then things should be addressable by default. It's one of the killer features of the web :-) You're right, and this makes me think more strongly that restricting the ability to specify the replaceable bits to just base is the right way to do this. I'm starting to think the addressability is the main constraint. What if the original @onlyreplace anchor tag: a onlyreplace=id1 id2 href=page2.html / would be equivalent to something like this: a href=#view(page2.html id1 id2) / 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) Hmm, that's interesting. So, rather than simply changing the url and hoping that the author is maintaining the correct semantics (so that visiting the url fresh gives you same/similar results), you just explicitly express that the page is a combination of multiple pages. I suppose that if, in your example, you then clicked a a href=page4.html onlyreplace=id3, the url would change to http://example.com/page1.html#view(page2.html id1 id2);view(page4.html id3); that is, it would record the location each segment was drawn from, but not the full history, as that is irrelevant for regenerating the page. Then bookmarking that url and visiting it again would presumably make 3 separate requests, once for page1 for most of the page, and then for page2 and page4 for the particular ids. Right? Exactly. These are the use cases I think we're targeting with such addressability: (when considering some server-side request filter, as well) 1. Avoid flicker and state-reinitialization between similar pages. 2. preserve scroll context across loading similar pages. 3. robots crawling ajax-states reliably (and efficiently) 4. standardize addressability of (most) ajax states 5. Provide AJAX features to static pages that are low-hanging fruit. (considered as those mentioned above) 6. AJAX pages could also use more structure in the hash-tag e.g. to preserve their own state in the hash even while a user visits a specific part of the page 7. simplify very standard behavior in AJAX sites, especially in contexts that affect accessibility (like dynamic form submission) /sky
Re: [whatwg] a onlyreplace
If you'd like to see what this looks like in Javascript, I implemented this technique several years ago. One place you can see it publicly is the swapFromHttp() function at: http://havel.columbia.edu/media_panels/js/MochiPlus.js You can see it in action on some pages like: http://havel.columbia.edu/media_panels/video_window/?material=abrams where it adds in the page on the left from this file http://havel.columbia.edu/media_panels/materials/abrams.html 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. 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 nbsp; well in this context and should be numeric (e.g. #160;) 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/ 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). cheers, sky Date: Sat, 17 Oct 2009 11:34:25 -0700 From: Jonas Sicking jo...@sicking.cc To: Dion Almaer d...@almaer.com Cc: Markus Ernst derer...@gmx.ch, Tab Atkins Jr. jackalm...@gmail.com, Aryeh Gregor simetrical+...@gmail.com, whatwg wha...@whatwg.org Subject: Re: [whatwg] a onlyreplace Message-ID: 63df84f0910171134j193e35exf4d79dcddc5de...@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1 On Sat, Oct 17, 2009 at 11:16 AM, Dion Almaer d...@almaer.com wrote: 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. Yeah, I think this puts the finger on my uneasiness nicely. There's simply a lot of stuff going on with very little control for the author. I'd love to see a JS library developed on top of pushState/XMLHttpRequest that implements this functionality, and then see that JS library deployed on websites, and see what the experiences from that are. If it turns out that this works well then that would be a strong case for adding this to browsers natively. 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. / Jonas -- ___ whatwg mailing list whatwg@lists.whatwg.org http://lists.whatwg.org/listinfo.cgi/whatwg-whatwg.org End of whatwg Digest, Vol 67, Issue 81 **
[whatwg] Experiments in end-tag attributes
The html-parsing section of the spec and the browsers I've tested [1] seem to be doing the right thing, however I'd love if this was noted as a conforming pattern. Probably more testing is prudent. PROBLEM: p id=something-here [ massive bloviation and many inner tags pincluding Not-well indented p-tags /p /p !-- ad hoc solution! comment: id=something-here -- MORE ELEGANT ALTERNATIVE: p id=something-here /p id=something-here If it was noted as specifically conformant, this could possibly help parsers in some cases, including the human variety. cheers, Schuyler Duveen [1] Firefox, Safari, Chromium linux trunk, IE8
Re: [whatwg] Element content models
There is a use case for hierarchical progress elements: e.g. multiple
file uploads (or multiple phases). Consider the following example:
progress id=p max=17 value=5 data-units=MB
progress id=current-file-progress max=21/progress
/progress
could be displayed something like this:
style div {margin:0;padding:0;height:20px;float:left;} /style
div id=p style=width:170px;background-color:red;
div id=p-prog style=width:50px;background-color:green;/div
div id=current-file-progress
style=width:20px;background-color:yellow
div id=f-prog
style=width:10px;background-color:#00FF00/div
/div
/div
Ian Hickson wrote:
On Sun, 26 Nov 2006, Anne van Kesteren wrote:
Some element content model explicitly mention that they can't contain
themself. This probably makes sense for the following elements as well:
* meter
* progress
* time
* t
* m
* abbr?
* cite?
There might be more.
Done for meter, progress, and time. Left the others.
Re: [whatwg] Web Storage: apparent contradiction in spec
I'm one of the lurking web application developers. This discussion has gone mostly how I was hoping, but since 'offline apps' has come up again, I might bootstrap that a bit. Below are some use cases, but I'll summarize my perspective briefly. 1. To run Doom requiring 500M of localStorage sounds like an 'application'--both users and developers currently have the expectation that users have to approve something like that before being installed to their computers to consume possibly valuable resources. A preliminary prompt to the user sounds reasonable and expected here. 2. Once, I've approved of an application to store data locally, that data could very easily be incredibly precious to both user and developer. Neither would want that data to be swept away by a garbage-collecting browser without user/developer action. 3. If the developer is presented with an unprompted option to store data permanently or just have it 'cached'--I'm not sure why the developer (both the nefarious and the good) would ever opt for the only-cached version. 4. We'd like either (OffTopic) a. localStorage to work for file:// AND/OR b. there to be some way for someone with file access to change the manifest file cache in offline applications (while preserving SOME USE CASES -- Where I work (http://ccnmtl.columbia.edu), we have two main use cases for offline applications, which would be great if they were accomodated in the spec and even more importantly, browsers :-) 1. Static deployment as an 'offline app' http://ccnmtl.columbia.edu/portfolio/medicine_and_health/masivukeni.html Requirements/Constraints: * We were most familiar with programming and deploying web applications, so we preferred to use html/js (and python for backend to content development) * The application was to be run on a laptop which could not (and should not) connect to the Internet while being used. * Data (including user accounts) is then maintained using localStorage. * Rare updates (for critical bugs, e.g.) would not require online access again. Experience/Lessons: * We deployed this with Firefox's legacy globalStorage (before ffox3.5 came out) and static html files accessed at file:// * As written, it no longer works in ffox 3.5 or even with updates to ffox 3.0, because whereas file://localhost/ once worked (and thus globalStorage['localhost']), but seems to have been removed. Thankfully, as deployed, it's not connected to the Internet to receive updates :-) * If we implemented it again (which we will!) for HTML5, we would have the laptop download the files as an offline app with a manifest. Then localStorage would (hopefully) still work, and work upon visiting the domain--even offline. However, this might cause problems in updating the cached files without bringing the computer back online. 2. Deprecating experience for unprivileged users. * We have some services which allow annotation of primary sources (video/audio/images). * Some of these sites have public content, but we do not have the resources or interest in storing annotation/analysis from other users. Nonetheless, we've considered offline storage as a way to allow non-privileged users to analyze the content and store their data locally--to be saved for their own benefit and possibly later to be uploaded or shared elsewhere. In concluding, many thanks to all those that are working on HTML5 (esp. the browser vendors). It's an exciting time to be a web developer. cheers, Schuyler Message: 1 Date: Wed, 26 Aug 2009 20:54:12 -0700 From: Drew Wilson atwil...@google.com To: Linus Upson li...@google.com Cc: Brady Eidson beid...@apple.com, WHATWG List wha...@whatwg.org, Jeremy Orlow jor...@chromium.org, Jens Alfke s...@google.com, Aaron Boodman a...@google.com Subject: Re: [whatwg] Web Storage: apparent contradiction in spec Message-ID: f965ae410908262054y7d405cbdq2f7b115c7b694...@mail.gmail.com Content-Type: text/plain; charset=iso-8859-1 This is one of those times when I *really* wish that the application developer community was more active on this list. I absolutely understand Linus' point of view, but I also feel like we are really hamstringing applications when we make choices like this and I wish that those developers were more vocally represented in these types of discussions. Going down this path would basically kill the ability to have offline web applications, because there would be no guarantees that the data would persist until the user comes back online. But since that point's already been made several times, I guess it's not a compelling argument. -atw On Wed, Aug 26, 2009 at 8:23 PM, Linus Upson li...@google.com wrote: I simply want clicking on links to be safe. In a previous thread I wrote safe and stateless but I'm coming to the opinion that stateless is a corollary of safe. Clicking on links shouldn't, either by filling my disk or hitting my global quota, someday lead to a dialog
Re: [whatwg] Web Storage: apparent contradiction in spec
Aryeh Gregor wrote: On Thu, Aug 27, 2009 at 11:14 AM, Schuyler Duveenwha...@graffitiweb.org wrote: 1. To run Doom requiring 500M of localStorage sounds like an 'application'--both users and developers currently have the expectation that users have to approve something like that before being installed to their computers to consume possibly valuable resources. A preliminary prompt to the user sounds reasonable and expected here. I expect 500 MB will require a prompt by anyone's standards, yes, unless maybe the user has a terabyte of free disk space. 3. If the developer is presented with an unprompted option to store data permanently or just have it 'cached'--I'm not sure why the developer (both the nefarious and the good) would ever opt for the only-cached version. For the same reason developers write files in /tmp. If it's user-specific, then why not just use sessionStorage? If it's non-user specific (e.g. defaults) or cachable user-data, why not have it cached with normal HTTP as a file, with an XHR (with allow caching headers)? cheers, Schuyler In concluding, many thanks to all those that are working on HTML5 (esp. the browser vendors). It's an exciting time to be a web developer. Indeed!
Re: [whatwg] Web Storage: apparent contradiction in spec
There should also be a way to ask for more quota (from the user) without losing user data. The API via a form element is a little odd--generally forms are for submitting information to the site. Historically, all of these kinds of things are done via javascript: * cookies * opensearch additions * extension additions This would also have the benefit of allowing a Worker() to request quota without something on the page. cheers, Schuyler Linus Upson wrote: I don't think there is consensus at Google yet. I'm not saying that UAs shouldn't provide file-like lifetime semantics for storage. I'm just saying the user should decide, not the web page. Here's one way such a thing could be achieved: input type=storage src=button.png quota=20GB / When the user clicks the button they see a dialog that mail.google.com http://mail.google.com would like to use 20GB of storage. You have 50GB of free space. [Yes] [No]. Script can't cause the dialog to appear, only a user action. There would also be some affordance in that dialog to allow the user to manage persistent storage from other domains. A small Other sites are using 2GB of storage link perhaps. AppCache, LocalStrorage, and all other persistent bits for that domain would live within this quota. UAs would take this user action as a strong signal that the data is valuable and would act accordingly. If web sites use LocalStorage, AppCache, et. al. without the user clicking on and accepting a storage input button, then the UA would be free to garbage collect as it sees fit. Good UAs would do a good job of not throwing away things that are important to the user, just as they do today with cookies. Linus On Thu, Aug 27, 2009 at 9:42 AM, Brady Eidson beid...@apple.com mailto:beid...@apple.com wrote: On Aug 27, 2009, at 7:47 AM, Maciej Stachowiak wrote: On Aug 26, 2009, at 4:51 PM, Jens Alfke wrote: To repeat what I said up above: *Maybe the local storage API needs a way to distinguish between cached data that can be silently thrown away, and important data that can't.* That makes sense to me. There might even be more than two categories: - Cached for convenience - discarding this will affect performance but not functionality. - Useful for offline use - discarding this will prevent some data from being accessed when offline. - Critical for offline use - discarding this will prevent the app storing this data from working offline at all. - Critical user data - discarding this will lead to permanent user data loss. I agree with Maciej's 4-level distinction on philosophical grounds, and think it's a fine list of use cases. But I think there's been a reasonable amount of agreement on this list that it is unnecessarily fine grained. A developer who is consciously choosing a cache will always choose the most aggressive cache, and a developer who is consciously choose file storage will always choose the most sacred file storage. So we're left with the cache vs file distinction once more. All browser vendors who have implemented LocalStorage are willing to implement the cache, because what they've done either meets or exceeds the cache use-case. The remaining question is the file storage. How do we implement this distinction? I don't like the idea of having different modes on LocalStorage. How would the different mode be triggered? How would it be managed? What happens when two applications from the same security origin try to mix modes? Different modes just makes what is already a dirt simple API more complex, makes implementation more difficult for browser vendors, and confuses web developers. So I resubmit my three-Storage-object solution: SessionStorage, CacheStorage, and FileStorage. From this discussion, it appears that FileStorage is something Google might not be willing to implement. That's fine! They can have the object available to scripts but just give it a zero quota. To be more friendly to developers and not force them into checking abilities by catching exceptions we could add one more property to the storage interface so they can check ahead of time whether their attempt to store data will fail. Web developers would then have the ability to make the conscious decision of Is a cache good enough? and fallback to CacheStorage, or decide No, I really need persistent data and fallback to Flash or some other plug-in. The interfaces are all so similar as to be pretty painless for the developer. Thoughts? ~Brady
