Re: [whatwg] a onlyreplace
On Sat, Oct 17, 2009 at 12:45 PM, Nelson Menezes flying.mushr...@gmail.com wrote: 2009/10/17 Jonas Sicking jo...@sicking.cc: 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] Storage events
On Sat, Oct 17, 2009 at 8:20 PM, Ian Hickson i...@hixie.ch wrote: On Thu, 15 Oct 2009, Darin Fisher wrote: This is interesting since documentURI is a read/write property: http://www.w3.org/TR/DOM-Level-3-Core/core.html#Document3-documentURI I assume that is a mistake. Does anyone support documentURI? It seems completely redundant with document.URL. We implement it in Gecko. We even implement the setter, here: http://mxr.mozilla.org/mozilla-central/source/content/base/src/nsDocument.cpp#5844 :) / Jonas
Re: [whatwg] Storage events
On Sat, Oct 17, 2009 at 8:37 PM, Darin Fisher da...@chromium.org wrote: On Sat, Oct 17, 2009 at 8:20 PM, Ian Hickson i...@hixie.ch wrote: ... On Thu, 15 Oct 2009, Darin Fisher wrote: This is interesting since documentURI is a read/write property: http://www.w3.org/TR/DOM-Level-3-Core/core.html#Document3-documentURI I assume that is a mistake. Does anyone support documentURI? It seems completely redundant with document.URL. Gecko and WebKit appear to both support documentURI. Only WebKit allows it to be modified. Huh? So WebKit effectively have one of the main features of pushState already? Does the URL-bar change? Does the referrer change for subsequent requests such as navigation? I'm guessing it doesn't hook the back-button the way that pushState does though. / Jonas
Re: [whatwg] hgroup functionality absorbed into header?
On Fri, 16 Oct 2009, Kornel Lesi�~Dski wrote: On 9 Oct 2009, at 09:18, Ian Hickson wrote: For example, the W3C copy of HTML5 says: h1HTML5/h1 h2A vocabulary and associated APIs for HTML and XHTML/h2 h2Editor's Draft 9 October 2009/h2 ... h2Abstract/h2 ...which is what it would be interpreted as. This is what is meant: section h1HTML5; A vocabulary and associated APIs for HTML and XHTML; Editor's Draft 9 October 2009/h1 If that's what you mean, why not write it this way? h1HTML5 span class=subtitle A vocabulary and associated APIs for HTML and XHTMLbr Editor's Draft 9 October 2009/span/h1 Because HTML5 A vocabulary and associated APIs for HTML and XHTML Editor's Draft 9 October 2009 is not the title of the document. The title is HTML5, and the rest are distinct subtitles. People already use h2 in this manner, it's a well-established pattern. Your version with split h2 seems to use it only for visual effect. Not just visual, but presentational, yes, pretty much. It also makes it clear how to generate the outline. I still think that subtitle (subheader, tagline) would be just as effective, less confusing and less likely to break outline when used improperly... How is h2 confusing? It's what people do already. I think something like subtitle is just as likely to be misused as hgroup, to be honest. Also, it has a much poorer legacy (backwards compatibility) story. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Workers and addEventListener
On Fri, 16 Oct 2009, Zoltan Herczeg wrote: I would not be opposed to changing the spec to include enabling a port's message queue when addEventListener(message) is invoked. I'm reluctant to make addEventListener() do magic. we have two choices: - extend addEventListener - fix the Shared Worker example on the whatwg site to call start() seems the latter one was preferred by the majority of the people. Ian, could you do this fix? Done! Sorry about that. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] No interface flicker across page loads, without JavaScript
On Fri, 16 Oct 2009, Aryeh Gregor wrote: On Thu, Oct 15, 2009 at 3:49 AM, Nelson Menezes flying.mushr...@gmail.com wrote: 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. I'm trying to think what a solution to this would look like. Maybe something like: static id=fooSome stuff that doesn't change on page load.../static Changeable page content static id=barSome more stuff that doesn't change.../static The semantics would be that when the browser loaded the new page, it would do something like 1) Retrieve the URL. 2) Start parsing the new page. When the time comes to clear the screen so it can be redrawn for the new page, leave any static elements untouched, so they don't flicker or vanish. 3) When parsing the page, if a static element is reached that has the same id as a static element that was on the old page, ignore the contents of the new one. Instead, move the old static element to the position of the new one, copying its DOM. If possible, this shouldn't cause the visible static element to flicker or be redrawn, if it's visible. There should be some reasonable de facto or de jure conditions where no-flicker is guaranteed, e.g., all applicable styles are the same and the element is absolutely positioned relative to the body. As an added optimization, the browser could send an HTTP request header like Static-IDs containing a list of the IDs of all static elements currently on the page, so that the server can just leave those empty. A dynamic id=foo tag might be useful too, to indicate that specific parts of a static element might indeed change -- in this case the static element might have to be redrawn, but only once the new dynamic element was fully parsed, not before. I doubt this is suitable for HTML5, given how far along that is, but it might be interesting to consider anyway. Does the idea sound interesting to anyone else? It sounds rather scary. :-) This is definitely something for which I'd be looking towards experimental implementations as a guide as to the feasibility, rather than speccing it cold. Doing anything with the parsing, especially moving elements from one page to another, is very dodgy, especially when you consider what that means to the original DOM (which other scripts might still have references to, and which might be shown again if the user hits Back). On Fri, 16 Oct 2009, Markus Ernst wrote: [...] it introduces some consistency problems to solve, e.g.: Page1.html contains: static id=fooI eat meat/static and links to page2.html, which contains: static id=fooI am a vegetarian/static So page2.html looks different whether it is called from the link in page1.html, or directly via a bookmark, external link, or manual URI input. This could be solved if static elements have no content on their own, but retrieve it from an external source. The identifyer is then not the id attribute, but the source. This could be done with a src attribute on the static element. But I assume an easier implementation would be adding a static attribute for the iframe element, indicating that the iframe contents should not be reloaded. Sharing documents across multiple browsing contexts is even more scary -- consider what happens to scripts who try to compare the window object. On Fri, 16 Oct 2009, Aryeh Gregor wrote: The obvious use case here would just be to keep navigation elements fixed. For instance, on http://en.wikipedia.org/wiki/, most of div id=column-one could be static. (With a few exceptions, like div id=p-cactions.) Navigation tends not to be very interact-able, so reloading it and throwing out client-side changes would be fine if it changes on the server side. Why can't we just use AJAX, and not reload the page at all, for this? A slightly different use-case would be a dynamic application like Gmail, rewritten without AJAX. The bar on the left contains things like Inbox (2), which are updated by script. In this case, if new contents were loaded from the server, the server or script would promptly fill in the appropriate numbers and so on. So again, this use-case doesn't seem to care much if changes are thrown out. It's not clear to me why GMail would get rid of the AJAXness -- what problem would we be solving? Also, with AJAX you can do things like transitions, which you couldn't do with page loads. Another case to consider is where you have a tree or something that gets uncollapsed depending on what page you're on. This seems like a case where you'd actually want something slightly different: the new version should load, just without flickering. Perhaps a cruder solution would be useful, which doesn't affect display of the new page but only how new elements get loaded -- specifically, allowing a mix of content from
Re: [whatwg] a onlyreplace
On Fri, 16 Oct 2009, Aryeh Gregor wrote: 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 a, like a onlyreplace=foo, 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. On Fri, 16 Oct 2009, Tab Atkins Jr. wrote: Single-page apps are already becoming common for js-heavy sites. The obvious example is something like Gmail, but it's becoming more common everywhere. The main benefit of doing this is that you never dump the script context, so you only have to parse/execute/apply scripting *once* across the page, making really heavy libraries actually usable. In fact, writing a single-page app was explicitly given as a suggestion in the Global Script thread. Even in contexts with lighter scripts, there can still be substantial run-time rewriting of the page which a single-page app can avoid doing multiple times (frex, transforming a nested list into a tree control). The problem, though, is that single-page apps are currently a bit clunky to write. They require javascript to function, and the necessary code is relatively large and clunky, even in libraries like jQuery which make the process much simpler. It requires you to architect your site around the design, either producing a bunch of single-widget files that you query for and slap into place, or some relatively complex client-side logic to parse data structures into HTML. It's also very hard to get accessibility and graceful degradation right, requiring you to basically completely duplicate everything in a static form. Finally, preserving bookmarkability/general deeplinking (such as from a search engine) requires significant effort with history management and url hacking. Aryeh's suggestion, though, solves *all* of these problems with a single trivial attribute. You first design a static multi-page site like normal, with the only change being this attribute on your navigation links specifying the dynamic/replaceable portions of the page. In a legacy client, then, you have a perfectly serviceable multipage site, with the only problems being the reloading of js and such on each pageload. In a supporting client, though, clicking a link causes the browser to perform an ordinary request for the target page (requiring *no* special treatment from the author), parse/treebuild the new page, and then yank out the relevant fragments and replace bits in the current page with them. The url/history automatically updates properly; bookmarking the page and visiting it later will take you to appropriate static page that already exists. Script context is maintained, listeners stay around, overall page state remains stable across 'pageloads'. It's a declarative, accessible, automatic, and EASY way of creating the commonest form of single-page apps. This brings benefits to more than just the traditional js-heavy apps. My company's web site utilizes jQuery for a lot of small upgrades in the page template (like a hover-expand accordion for the main nav), and for certain things on specific pages. I know that loading the library, and applying the template-affecting code, slows down my page loads, but it's not significant enough to be worth the enormous effort to create an accessible, search-engine friendly single-page app. This would solve my problem trivially, though, providing a better overall UI to my visitors (snappier page loads) without any real effort on my part, and without harming accessibility or SEO. This also trivially replaces most/all uses of bad mechanisms like frameset used to address similar problems (such as maintaining state on a complex nav). The only addition I'd make to this is to allow a tag in the head that specifies default replaceability for all same-origin links. Perhaps just an attribute on base? It would accept a space-separated list of ids, just like the @onlyreplace attribute on as. An @onlyreplace attribute on a link would completely override this default (this would allow me to, frex, have the mainnav only replace the subnav,
Re: [whatwg] object behavior
On Fri, 16 Oct 2009, Ben Laurie wrote: On Thu, 6 Aug 2009, Andrew Oakley wrote: - Should the type attribute take precedence over the Content-Type header? No, I believe what the spec says here is the preferred behaviour. Unless this is incompatible with legacy content, we should try to move towards this behaviour. I realise this is only one of dozens of ways that HTML is unfriendly to security, but, well, this seems like a bad idea - if the page thinks it is embedding, say, some flash, it seems like a pretty bad idea to allow the (possibly untrusted) site providing the flash to run whatever it wants in its place. If the site is untrusted, yet you are letting it run flash, then you've lost already. Flash can inject arbitrary JS into your page. If you are worried about security, I recommend using iframe. The new sandbox= feature will help even more, once implemented. On Fri, 16 Oct 2009, Boris Zbarsky wrote: This cuts both ways. If a site allows me to upload images and I upload an HTML file with some script in it and tell it it's a GIF (e.g. via the name) an then put an object type=text/html data=http://this.other.site/my.gif; on my site... then I just injected script into a different domain if we let @type override the server-provided header. This is, imo, a much bigger problem than that of people embedding content from an untrusted site and getting content X instead of content Y, especially because content X can't actually access the page that contains it, right? Indeed. On Fri, 16 Oct 2009, Ben Laurie wrote: The point is that if I think I'm sourcing something safe but it can be overridden by the MIME type, then I have a problem. If you know it's Flash, use embed. If you know it's an image, use img. If you know it's HTML, use iframe. That way you can't get caught like this. On Fri, 16 Oct 2009, Boris Zbarsky wrote: Perhaps we need an attribute on object that says to only render the data if the server provided type and @type match? That way you can address your use case by setting that attribute and we don't enable attacks on random servers by allowing @type to override the server-provided type? Just use one of the more appropriate elements. That way it's safe in older UAs also. On Sat, 17 Oct 2009, Michael A. Puls II wrote: On Fri, 16 Oct 2009 05:28:46 -0400, Ian Hickson i...@hixie.ch wrote: On Sun, 20 Sep 2009, Michael A. Puls II wrote: O.K., so put simply, HTML5 should explicitly mention that the css display property for object, embed (and applet in the handling section) has absolutely no effect on plug-in instantiation and destroying and has absolutely no effect on @src and @data resource fetching. HTML5 could also be extra clear by example that display: none doesn't destroy, or prevent the creation of, the plug-in instance and that changing the display value doesn't destroy the instance. Lastly, HTML5 could briefly mention that what the plug-in does when its window/area is not displayed because of display: none, is plug-in and plug-in API dependent. I've added a note to this effect. I see the note in the object element section, but don't see it in the embed element section and the applet element section. Fixed. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] document.documentURI
On Sat, 17 Oct 2009, Darin Fisher wrote: On Sat, Oct 17, 2009 at 8:20 PM, Ian Hickson i...@hixie.ch wrote: On Thu, 15 Oct 2009, Darin Fisher wrote: This is interesting since documentURI is a read/write property: http://www.w3.org/TR/DOM-Level-3-Core/core.html#Document3-documentURI I assume that is a mistake. Does anyone support documentURI? It seems completely redundant with document.URL. Gecko and WebKit appear to both support documentURI. Only WebKit allows it to be modified. On Sat, 17 Oct 2009, Jonas Sicking wrote: Huh? So WebKit effectively have one of the main features of pushState already? Does the URL-bar change? Does the referrer change for subsequent requests such as navigation? I'm guessing it doesn't hook the back-button the way that pushState does though. I think this is something for Web DOM Core. I've noted it as an issue on the wiki: http://wiki.whatwg.org/wiki/Companion_specifications#Specs_to_edit -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Storage events
On Sat, Oct 17, 2009 at 11:58 PM, Jonas Sicking jo...@sicking.cc wrote: On Sat, Oct 17, 2009 at 8:37 PM, Darin Fisher da...@chromium.org wrote: On Sat, Oct 17, 2009 at 8:20 PM, Ian Hickson i...@hixie.ch wrote: ... On Thu, 15 Oct 2009, Darin Fisher wrote: This is interesting since documentURI is a read/write property: http://www.w3.org/TR/DOM-Level-3-Core/core.html#Document3-documentURI I assume that is a mistake. Does anyone support documentURI? It seems completely redundant with document.URL. Gecko and WebKit appear to both support documentURI. Only WebKit allows it to be modified. Huh? So WebKit effectively have one of the main features of pushState already? Does the URL-bar change? Does the referrer change for subsequent requests such as navigation? I'm guessing it doesn't hook the back-button the way that pushState does though. / Jonas It appears to impact the baseURL for the document. -Darin
Re: [whatwg] a onlyreplace
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 jo...@sicking.cc: On Sat, Oct 17, 2009 at 12:45 PM, Nelson Menezes flying.mushr...@gmail.com wrote: 2009/10/17 Jonas Sicking jo...@sicking.cc: 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] object behavior
On Mon, 14 Sep 2009 02:10:22 -0400, Ian Hickson i...@hixie.ch wrote: On Thu, 3 Sep 2009, Michael A. Puls II wrote: On Wed, 02 Sep 2009 17:39:00 -0400, Ian Hickson i...@hixie.ch wrote: On Thu, 27 Aug 2009, Michael A. Puls II wrote: Here's an example that uses a more modern plug-in that shows what browsers do. window.onload = function() { var obj = document.createElement(object); obj.type = application/x-shockwave-flash; obj.data = http://adobe.com/shockwave/welcome/flash.swf;; obj.width = 320; obj.height = 240; //document.body.appendChild(obj); //obj.style.display = none; setTimeout(function() { alert(obj.SetVariable); }, 1000); }; In other words, for a plug-in to be initialized (and scriptable if it's capable): 1. Its element must be attached to the document. I'm told this is considered a bug. O.K., so once that's fixed in browsers, if I do: var obj = document.createElement(object); obj.type = application/x-shockwave-flash; obj.data = file.swf obj.appendParam(quality, low); , will that load as soon as I set @type (according to HTML5) and result in @data and the param not being honored because the plug-in already initialized? Hm, good point. Fixed. O.K., that requires that the element is in a Document, which is great. However, if I use createDocument() to create an HTMLDocument and then append an HTMLObjectElement to that document, the plug-in shouldn't load as the document is not active/has no browsing context or something. Is the spec clear that nothing should happen in that case? It seems obvious, but want to make sure. -- Michael
Re: [whatwg] a onlyreplace
dd0fbad0910161343s277083c7v4eee5197c15bd...@mail.gmail.com Content-Type: text/plain; charset=windows-1255 Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Some comments: I think an optimization that enables the server to strip unnecessary content is a MUST. 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. 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 a tag is usually not used but a button, this means that other tags the a should have the onlyreplace attribute. In this example the URL should not be remembered by the history. There are other cases of use case #2 where the URL should be remembered - like a next button on a page-able data grid. I think this solution is good for changes of the entire content panel. When a specific widget needs to update a data binding solution may be better. This means the onlyreplace will probably be always the defaults. From: jackalm...@gmail.com Date: Fri, 16 Oct 2009 15:43:25 -0500 To: simetrical+...@gmail.com CC: derer...@gmx.ch; wha...@whatwg.org Subject: Re: [whatwg] A few public responses to issues/questions brought up in IRC: (thanks, Aryeh and Philip!) How is this better than and lt;a targetgt;?lt;br /gt;gt; =lt;br /gt;gt; It's significantly better in multiple ways, actually.lt;br /gt;gt;lt;br /gt;gt; 1. lt;iframegt;s, like frames before them, break bookmarking. If a userlt;br /gt;gt; bookmarks the page and returns to it later, or gets deeplinked via alt;br /gt;gt; search engine or a link from a friend, the lt;iframegt; won't show thelt;br /gt;gt; correct content. The only way around this is some fairly non-triviallt;br /gt;gt; url-hacking with javascript, altering the displayed url as the userlt;br /gt;gt; navigates the iframe, and parsing a deeplink url into an appropriatelt;br /gt;gt; url for the iframe on initial pageload. @onlyreplace, on the otherlt;br /gt;gt; hand, automatically works perfectly with bookmarking. The UA stilllt;br /gt;gt; changes urls and inserts history appropriately as you navigate, and onlt;br /gt ;gt; a fresh pageload it just requests the ordinary static page showing thelt;br /gt;gt; appropriate content.lt;br /gt;gt;lt;br /gt;gt; 2. lt;a targetgt; can only navigate one iframe at a time. Many/mostlt;br /gt;gt; sites, though, have multiple dynamic sections scattered throughout thelt;br /gt;gt; page. The main site for my company, frex, has 3 (content,lt;br /gt;gt; breadcrumbs, and section nav) which *cannot* be combined to display aslt;br /gt;gt; a single lt;iframegt;, at least not without including a whole bunch oflt;br /gt;gt; static content as well. You'd have use javascript to hook the linkslt;br /gt;gt; and manually navigate the additional iframes. @onlyreplace, on thelt;br /gt;gt; other hand, handles this seamlessly - just include multiple ids in thelt;br /gt;gt; attribute value.lt;br /gt;gt;lt;br /gt;gt; 3. lt;iframegt;s require you to architect your site around them. Ratherlt;br /gt;gt; than a series of independen t pages, you must create a single masterlt;br /gt;gt; page and then a number of content-chunk mini-pages. This breakslt;br /gt;gt; normal authoring practices (though in some ways it's easier), andlt;br /gt;gt; requires you to work hard to maintain accessibility and such in thelt;br /gt;gt; face of these atrophied mini-pages. @onlyreplace works on full,lt;br /gt;gt; ordinary pages. It's *possible* to link to a content-chunk mini-pagelt;br /gt;gt; instead, but this will spectacularly break if you ever deeplinklt;br /gt;gt; straight to one of the pages, so it should become automatic forlt;br /gt;gt; authors to do this correctly.lt;br /gt;gt;lt;br /gt;gt; 4. lt;iframegt;s have dubious accessibility and search effects. I don'tlt;br /gt;gt; know if bots can navigate lt;a targetgt; links appropriately. I alsolt;br /gt;gt; believe that this causes problems with screen-readers. While eitherlt;br /gt;gt; of these sets of UAs can be rewritten to handle lt;iframegt;s better (andlt;br /gt;gt; handle @onlyreplace replacement as well), with @onlyreplace theylt;br /gt;gt; *also* have the option of just completely ignoring the attribute andlt;br /gt;gt; navigating the site as an ordinary multi-page app. Legacy UAs willlt;br /gt;gt; automatically do so, providing perfect backwards compatibility.lt;br /gt;gt;lt;br /gt;gt;lt;br /gt;gt; Isn't if inefficient to request the whole page and then throw most oflt;br /gt;gt; it out? With proper AJAX you can just request the bits you
Re: [whatwg] object behavior
On Sun, Oct 18, 2009 at 5:37 AM, Ian Hickson i...@hixie.ch wrote: On Fri, 16 Oct 2009, Ben Laurie wrote: On Thu, 6 Aug 2009, Andrew Oakley wrote: - Should the type attribute take precedence over the Content-Type header? No, I believe what the spec says here is the preferred behaviour. Unless this is incompatible with legacy content, we should try to move towards this behaviour. I realise this is only one of dozens of ways that HTML is unfriendly to security, but, well, this seems like a bad idea - if the page thinks it is embedding, say, some flash, it seems like a pretty bad idea to allow the (possibly untrusted) site providing the flash to run whatever it wants in its place. If the site is untrusted, yet you are letting it run flash, then you've lost already. Flash can inject arbitrary JS into your page. Perhaps I am failing to understand, but if I embed anything from an untrusted site, then it can choose what type it is - so how would I prevent it running Flash? If you are worried about security, I recommend using iframe. The new sandbox= feature will help even more, once implemented. I am worried about security, and I recommend using Caja - but Caja still has to output valid HTML/CSS/JS... On Fri, 16 Oct 2009, Boris Zbarsky wrote: This cuts both ways. If a site allows me to upload images and I upload an HTML file with some script in it and tell it it's a GIF (e.g. via the name) an then put an object type=text/html data=http://this.other.site/my.gif; on my site... then I just injected script into a different domain if we let @type override the server-provided header. This is, imo, a much bigger problem than that of people embedding content from an untrusted site and getting content X instead of content Y, especially because content X can't actually access the page that contains it, right? Indeed. You just said it could, above. On Fri, 16 Oct 2009, Ben Laurie wrote: The point is that if I think I'm sourcing something safe but it can be overridden by the MIME type, then I have a problem. If you know it's Flash, use embed. If you know it's an image, use img. If you know it's HTML, use iframe. That way you can't get caught like this. On Fri, 16 Oct 2009, Boris Zbarsky wrote: Perhaps we need an attribute on object that says to only render the data if the server provided type and @type match? That way you can address your use case by setting that attribute and we don't enable attacks on random servers by allowing @type to override the server-provided type? Just use one of the more appropriate elements. That way it's safe in older UAs also. On Sat, 17 Oct 2009, Michael A. Puls II wrote: On Fri, 16 Oct 2009 05:28:46 -0400, Ian Hickson i...@hixie.ch wrote: On Sun, 20 Sep 2009, Michael A. Puls II wrote: O.K., so put simply, HTML5 should explicitly mention that the css display property for object, embed (and applet in the handling section) has absolutely no effect on plug-in instantiation and destroying and has absolutely no effect on @src and @data resource fetching. HTML5 could also be extra clear by example that display: none doesn't destroy, or prevent the creation of, the plug-in instance and that changing the display value doesn't destroy the instance. Lastly, HTML5 could briefly mention that what the plug-in does when its window/area is not displayed because of display: none, is plug-in and plug-in API dependent. I've added a note to this effect. I see the note in the object element section, but don't see it in the embed element section and the applet element section. Fixed. -- Ian Hickson U+1047E )\._.,--,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] object behavior
On Sun, 18 Oct 2009 14:21:56 +0200, Ben Laurie b...@google.com wrote: On Sun, Oct 18, 2009 at 5:37 AM, Ian Hickson i...@hixie.ch wrote: On Fri, 16 Oct 2009, Ben Laurie wrote: On Thu, 6 Aug 2009, Andrew Oakley wrote: - Should the type attribute take precedence over the Content-Type header? No, I believe what the spec says here is the preferred behaviour. Unless this is incompatible with legacy content, we should try to move towards this behaviour. I realise this is only one of dozens of ways that HTML is unfriendly to security, but, well, this seems like a bad idea - if the page thinks it is embedding, say, some flash, it seems like a pretty bad idea to allow the (possibly untrusted) site providing the flash to run whatever it wants in its place. If the site is untrusted, yet you are letting it run flash, then you've lost already. Flash can inject arbitrary JS into your page. Perhaps I am failing to understand, but if I embed anything from an untrusted site, then it can choose what type it is - so how would I prevent it running Flash? Running Flash and allowing the same Flash to script your page are two different things. Flash needs allowscriptaccess=always to script if it is loaded from a different domain. This may not be true for all plug-ins though. -- Ola P. Kleiven, Core Compatibility, Opera Software
Re: [whatwg] hgroup functionality absorbed into header?
On Sun, 18 Oct 2009 08:54:59 +0100, Ian Hickson i...@hixie.ch wrote: Your version with split h2 seems to use it only for visual effect. Not just visual, but presentational, yes, pretty much. It also makes it clear how to generate the outline. I don't understand how presentational h2s make outline clear. I thought they're an exception that didn't work simple outline algorithm: http://validator.w3.org/check?uri=http%3A%2F%2Fwww.w3.org%2FTR%2Fhtml5%2Foutline=1#outlineresult and hgroup exists to resolve ambiguity caused by presentational use of headers. I still think that subtitle (subheader, tagline) would be just as effective, less confusing and less likely to break outline when used improperly... How is h2 confusing? h2 alone isn't. hgroup is the source of confusion. * Difference between hgroup and header is not obvious. It wasn't to me when I first saw them, and this isn't first thread about them. * Makes meaning of hx overloaded (sometimes it's a header that affects outline and level or other headers, sometimes it's a subheader that doesn't do anything that header would). Have you seen this post? http://www.onderhond.com/blog/work/the-hgroup-tag I think it sums up problems quite well. I think something like subtitle is just as likely to be misused as hgroup, to be honest. Sure, but it's much more fail-safe. If you use header instead of hgroup or fail to use hgroup, you may significantly change structure of the document. You can't make much damage with subheader. Sections will remain correct and at worst you'll add wrong subtitles to headers. My proposal for processing of subheader: * look for first hx preceeding subheader in tree order (depth-first starting with last child) [makes any subheader after hx work] * abort and ignore subheader when search crosses section boundaries [prevents misplaced subheader from being associated with wrong section]. Optionally: * if hx is an ancestor of subheader, associate subheader with that header The last rule allows: h1subheaderThe magnificent/subheader HTML 5 specification/h1 which addresses one of use cases you've mentioned a while ago when hgroup was discussed. Also, it has a much poorer legacy (backwards compatibility) story. Both solutions have problems. I don't think ones are much worse than the others. hgroup breaks the outline, subheader is ignored. Without CSS h2s will be too large and have too big margins. subheader will not get special rendering, but at least will look like block element (hx and p typically surrounding it will cause this). One might use psubheaderb if non-CSS display is a concern. With CSS subheader will work fine and doesn't limit styling possibilities. hgroup's content model doesn't allow any non-header elements, so one can't add any extra hooks for styling: hgroup h1/ div!-- add fancy border around subheaders? -- h2/ h2/ /div /hgroup Another thing - can you write XPath query that extracts all headers from the document? Without hgroup it's simple. With hgroup I'm not sure if I could manage to write correct query. -- regards, Kornel Lesinski
Re: [whatwg] a onlyreplace
On Sun, Oct 18, 2009 at 4:30 AM, Ian Hickson i...@hixie.ch wrote: 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). 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. Yup, was planning on this. Just wanted to hack it out on the list first before jumping down any rabbit holes. If nobody beats me to it, this should be relatively easy to hack in (and may already be hacked in in some form, via mooTools?). ~TJ
Re: [whatwg] a onlyreplace
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. 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. 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
On Sat, Oct 17, 2009 at 2:45 PM, Nelson Menezes flying.mushr...@gmail.com wrote: 2009/10/17 Jonas Sicking jo...@sicking.cc: 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 Awesome, Nelson! Seems to work pretty cool! I'll hack on it a bit today, see if I can make it a bit more featureful. ~TJ
Re: [whatwg] a onlyreplace
2009/10/18 Nelson Menezes flying.mushr...@gmail.com: [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] a onlyreplace
On Sun, Oct 18, 2009 at 6:45 AM, tali garsiel t_gars...@hotmail.com wrote: Some comments: I think an optimization that enables the server to strip unnecessary content is a MUST. Well, as I explained, it's not really a MUST. Doing an ordinary navigation requests an entire page, and without optimizations this does the exact same thing. You're not burning *more* bandwidth than normal; you're just slightly changing the effect of it. That said, such optimizations would be really useful, I agree. It could significantly cut down bandwidth use (on my company's site, the average request would drop from about 20k to about 1.5k). This could *really* improve site performance, and even perhaps be good for the overall net. 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 base onlyreplace that don't override their own @onlyreplace with the empty string) carry the semantics. If you're talking about this in terms of optimizations, then the onlyreplace information would be carried by a request header. When the browser doesn't send this header, the server wouldn't strip anything down. 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 a tag is usually not used but a button, this means that other tags the a should have the onlyreplace attribute. I thought it would be interesting to be able to put @onlyreplace on forms, or perhaps form submission inputs. 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. There are other cases of use case #2 where the URL should be remembered - like a next button on a page-able data grid. Yup, exactly. A paged control is a great use-case! It's extremely simple to set up (just pass paging info in query params), and bookmarking works beautifully! I think this solution is good for changes of the entire content panel. When a specific widget needs to update a data binding solution may be better. Yeah, this is not meant to be a general replacement for AJAX. It just makes a particular set of common cases extremely easy. In many circumstances being explicit with javascript is still the better solution. This means the onlyreplace will probably be always the defaults. I'm not sure what you mean here. ~TJ
Re: [whatwg] a onlyreplace
2009/10/18 Tab Atkins Jr. jackalm...@gmail.com: On Sun, Oct 18, 2009 at 6:45 AM, tali garsiel t_gars...@hotmail.com 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 base onlyreplace that don't override their own @onlyreplace with the empty string) carry the semantics. I guess the base @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 a tag is usually not used but a button, this means that other tags the a 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 a and form 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: ... a onlyreplace=div1 div2 href=ingredients.htmlIngredients/a a onlyreplace=div2 href=nutrition.htmlNutrition/a a onlyreplace=div3 href=preparation.htmlPreparation/a ... div id=div1/div div id=div2/div div id=div3/div ... 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] Storage events
On Sun, Oct 18, 2009 at 2:53 AM, Darin Fisher da...@chromium.org wrote: On Sat, Oct 17, 2009 at 11:58 PM, Jonas Sicking jo...@sicking.cc wrote: On Sat, Oct 17, 2009 at 8:37 PM, Darin Fisher da...@chromium.org wrote: Gecko and WebKit appear to both support documentURI. Only WebKit allows it to be modified. Huh? So WebKit effectively have one of the main features of pushState already? Does the URL-bar change? Does the referrer change for subsequent requests such as navigation? I'm guessing it doesn't hook the back-button the way that pushState does though. / Jonas It appears to impact the baseURL for the document. WebKit's behavior of documentURI was my attempt to reconcile the DOM spec with security and reality. Previously, WebKit actually let you assign the internal representation of the documentURI, which was obviously disaster from a security point of view. Adam
Re: [whatwg] a onlyreplace
On Sun, Oct 18, 2009 at 10:07 AM, Nelson Menezes flying.mushr...@gmail.com wrote: I guess the base @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). Yup, my thought exactly. I wonder, though, if there might be a problem with this after all... picture this: ... a onlyreplace=div1 div2 href=ingredients.htmlIngredients/a a onlyreplace=div2 href=nutrition.htmlNutrition/a a onlyreplace=div3 href=preparation.htmlPreparation/a ... div id=div1/div div id=div2/div div id=div3/div ... 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? Ooh, that... is a problem. I mean, if this is used properly it shouldn't ever happen, obviously, as every page should be a valid page. But the example you described above seems very possible, with authors thinking that it's okay to create 4 nearly identical pages, with the sub-pages containing only particular bits filled in (not just content chunks, but still incomplete). This degrades badly (just following each link gives you only partial recipes). I'd like bookmarking to return you to something as similar as what you were looking at before as possible. The better would be to have only two pages, foo-empty.html and foo-complete.html, with the links grabbing particular bits from foo-complete. Then bookmarking would take you to foo-complete, which isn't horrible. Ideally, though, we should never have this situation at all. Using @onlyreplace for information hiding is stupid; that's what details was made for, and it does it *way* better (instantaneous replacement, no bandwidth waste, bookmarking is fine). So, hmm. Is this enough of a problem that we have to address it? If it is, probably the best thing to do would be to remove the id list from a and only leave it on base, with some attribute on links to indicate whether they should trigger an onlyreplace or a normal navigation. That way all links carrying the onlyreplace semantic will replace the same bits, making the above scenario impossible. This eliminates many useful cases for onlyreplace, though. Frex, say you have a documentation site, with a main-nav up top, a fancy treeview section-nav on the left, and documentation pages on the right. Clicking one of the mainnav links should replace both the section-nav and the doc page, but clicking on a section-nav link should only replace the content. I suppose this is still possible by just making the main-nav links trigger a normal navigation, the section-nav links trigger an onlyreplace navigation, and having base onlyreplace=content. I feel this may still render onlyreplace unusable for more complex single-page apps, though. I dunno, this may be ok - perhaps those apps are complex enough that we can't meet their needs with a mechanism this simple anyway. This limitation wouldn't really hurt the simpler use-cases that I envisioned (ordinary pages which want to enhance their static area with heavy js, but don't want the cost of reloading libraries on every navigation and having things move around as they get manipulated every time). Okay, so possible revision: base onlyreplace=foo carries a list of ids to replace. This automatically makes all links and forms on the page carry the onlyreplace semantics. You can turn this off for specific links by setting @noreplace (a binary attribute) on the link or form; activating/submitting them will trigger a normal navigation. Can anyone think of any concrete cases that were addressed well by the older suggestion, but are now impossible with this newer revision? I'm sure there are some, I just want to assess how valuable they may be before I decide to cut them off. ~TJ
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
bay117-w90f5b859cd291ac4e373b83...@phx.gbl dd0fbad0910180717q60e0c0f5l12e81a337af57...@mail.gmail.com Content-Type: text/plain; charset=windows-1255 Content-Transfer-Encoding: 8bit MIME-Version: 1.0 When I said an optimization is a must I didn't just mean bandwidth. Imagine this use case: You have a page with a chart and a table showing data calculated from complex statistical analysis on your huge database. Both the chart and the table have refresh buttons implemented with a onlyreplace Recalculating the chart when you refresh the table or vice verse will not be acceptable by your project manager :) The server will need to know what is currently requested. The solution is not necessarily to strip the content, but the server must get information of the updated parts and choose what to calculate. From: jackalm...@gmail.com Date: Sun, 18 Oct 2009 09:17:19 -0500 Subject: Re: [whatwg] To: t_gars...@hotmail.com CC: simetrical+...@gmail.com; derer...@gmx.ch; wha...@whatwg.org On Sun, Oct 18, 2009 at 6:45 AM, tali garsiel wrote: Some comments: I think an optimization that enables the server to strip unnecessary content is a MUST. Well, as I explained, it's not really a MUST. Doing an ordinary navigation requests an entire page, and without optimizations this does the exact same thing. You're not burning *more* bandwidth than normal; you're just slightly changing the effect of it. That said, such optimizations would be really useful, I agree. It could significantly cut down bandwidth use (on my company's site, the average request would drop from about 20k to about 1.5k). This could *really* improve site performance, and even perhaps be good for the overall net. 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. If you're talking about this in terms of optimizations, then the onlyreplace information would be carried by a request header. When the browser doesn't send this header, the server wouldn't strip anything down. 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. 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. There are other cases of use case #2 where the URL should be remembered - like a next button on a page-able data grid. Yup, exactly. A paged control is a great use-case! It's extremely simple to set up (just pass paging info in query params), and bookmarking works beautifully! I think this solution is good for changes of the entire content panel. When a specific widget needs to update a data binding solution may be better. Yeah, this is not meant to be a general replacement for AJAX. It just makes a particular set of common cases extremely easy. In many circumstances being explicit with javascript is still the better solution. This means the onlyreplace will probably be always the defaults. I'm not sure what you mean here. ~TJ _ Keep your friends updatedeven when youre not signed in. http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_5:092010
Re: [whatwg] a onlyreplace
On Sun, Oct 18, 2009 at 11:20 AM, Schuyler Duveen wha...@graffitiweb.org wrote: 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. 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.) 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'). Yup, something like this should emerge at some point. 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) Ah, interesting, a response header that says I know you only asked me for certain parts of the response, but here's the whole thing instead, and please load it all. 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. ~TJ
Re: [whatwg] a onlyreplace
On Sun, Oct 18, 2009 at 11:22 AM, tali garsiel t_gars...@hotmail.com wrote: When I said an optimization is a must I didn't just mean bandwidth. Imagine this use case: You have a page with a chart and a table showing data calculated from complex statistical analysis on your huge database. Both the chart and the table have refresh buttons implemented with a onlyreplace Recalculating the chart when you refresh the table or vice verse will not be acceptable by your project manager :) The server will need to know what is currently requested. The solution is not necessarily to strip the content, but the server must get information of the updated parts and choose what to calculate. That's not really an appropriate use of @onlyreplace. Just put the chart and table in iframes with @name and use a target to refresh them. That also automatically optimizes bandwidth, since the subpages that the chart and frame will live on contain *only* them. (Preventing this sort of abuse might be a good reason to do the only base can carry an id list revision.) ~TJ
Re: [whatwg] a onlyreplace
On Sun, Oct 18, 2009 at 12:28 PM, Tab Atkins Jr. jackalm...@gmail.comwrote: 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. I've only been partially following this thread, so this may have been answered previously. Is this an accurate summary of what you're thinking of? Clicking a href=foo and a href=foo onlyreplace=bar would send the exact same headers to the server with the exception of a single extra header for the @onlyreplace version? In the case of @onlyreplace, would the #bar element end up being replaced, or just its content? Would the server be expected to reply with div id=bar.../dv or just what would would become bar.innerHTML?
Re: [whatwg] a onlyreplace
2009/10/18 Scott González scott.gonza...@gmail.com: On Sun, Oct 18, 2009 at 12:28 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: 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. I've only been partially following this thread, so this may have been answered previously. Is this an accurate summary of what you're thinking of? Clicking a href=foo and a href=foo onlyreplace=bar would send the exact same headers to the server with the exception of a single extra header for the @onlyreplace version? Yes. In the case of @onlyreplace, would the #bar element end up being replaced, or just its content? The full element. Would the server be expected to reply with div id=bar.../dv or just what would would become bar.innerHTML? The former. As well, the server *can* return the whole document, but is only required to send the requested elements. ~TJ
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
On Sun, Oct 18, 2009 at 11:50 AM, Schuyler Duveen wha...@graffitiweb.org wrote: 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. 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. 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 :-) 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. ~TJ
Re: [whatwg] a onlyreplace
dd0fbad0910180717q60e0c0f5l12e81a337af57...@mail.gmail.com bay117-w9daba5e3a74376fb4bbfc83...@phx.gbl dd0fbad0910180935i6b07e025t14f4cc5aaacb3...@mail.gmail.com Content-Type: text/plain; charset=windows-1255 Content-Transfer-Encoding: 8bit MIME-Version: 1.0 I'll try to fix my example. The table button is not refresh but a next button that keeps track of the table navigation. That is a valid use case , isn't it? (at least by your first suggestion). You still wouldn't want the server to do any heavy calculation except for the data that needs to be displayed. I tried to find an extreme use case but even showing the navigation panels often evolves lots of server work. Examples can be license and permission checks for an entire tree and parsing xml files containing tab contents. Some of this work can be avoided by using session caching but some is not, mainly security checks. From: jackalm...@gmail.com Date: Sun, 18 Oct 2009 11:35:11 -0500 Subject: Re: [whatwg] To: t_gars...@hotmail.com CC: derer...@gmx.ch; simetrical+...@gmail.com; wha...@whatwg.org On Sun, Oct 18, 2009 at 11:22 AM, tali garsiel wrote: When I said an optimization is a must I didn't just mean bandwidth. Imagine this use case: You have a page with a chart and a table showing data calculated from complex statistical analysis on your huge database. Both the chart and the table have refresh buttons implemented with . Recalculating the chart when you refresh the table or vice verse will not be acceptable by your project manager :) The server will need to know what is currently requested. The solution is not necessarily to strip the content, but the server must get information of the updated parts and choose what to calculate. That's not really an appropriate use of @onlyreplace. Just put the chart and table in s with @name and use lt;a targetgt; to refreshlt;br /gt;gt; them. That also automatically optimizes bandwidth, since the subpageslt;br /gt;gt; that the chart and frame will live on contain *only* them.lt;br /gt;gt;lt;br /gt;gt; (Preventing this sort of abuse might be a good reason to do the onlylt;br /gt;gt; lt;basegt; can carry an id list revision.)lt;br /gt;gt;lt;br /gt;gt; ~TJlt;br /gt; _ Keep your friends updatedeven when youre not signed in. http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_5:092010
Re: [whatwg] a onlyreplace
2009/10/18 Tab Atkins Jr. jackalm...@gmail.com: 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 a or form element, or the window object if the request originated via scripting. Nelson Menezes http://fittopage.org
Re: [whatwg] a onlyreplace
On Sun, Oct 18, 2009 at 12:20 PM, Nelson Menezes flying.mushr...@gmail.com wrote: 2009/10/18 Tab Atkins Jr. jackalm...@gmail.com: 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 a or form element, or the window object if the request originated via scripting. My thoughts were that the event fires at the replaced elements, not the a or form 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 a or form isn't doing either. ~TJ
Re: [whatwg] a onlyreplace
On Sat, Oct 17, 2009 at 1:22 AM, Jonas Sicking jo...@sicking.cc wrote: Also, what should happen if the user presses the 'back' button? It should be the same as for regular navigation. If the UA usually stores some page state in a cache when the user navigates, it should store the same state. If it doesn't have the previous contents cache, it should reload, assuming that's what it normally does. On Sun, Oct 18, 2009 at 11:51 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: Okay, so possible revision: base onlyreplace=foo carries a list of ids to replace. This automatically makes all links and forms on the page carry the onlyreplace semantics. You can turn this off for specific links by setting @noreplace (a binary attribute) on the link or form; activating/submitting them will trigger a normal navigation. By all links and forms do you really mean all same-domain links and forms? Even that's too many. Consider a typical site with a forum at /forum and a wiki at /wiki. You don't want links from one to the other to try onlyreplacing. Even within an app it can be complicated. MediaWiki is often installed in both /w (actual files) and /wiki (fake rewrite path), and you'd probably want links to everything in /wiki but only some things in /w to be affected. Perhaps a onlyreplace should be a boolean attribute. Opting links into onlyreplace seems safer than opting them out. In many cases you might be injecting some raw HTML into the page, like using a template system or JavaScript, such that adding noreplace to all links you're unsure about would be tricky or impossible. Opt-in is much easier to verify. In any event, this variant is fairly disastrous for copy-pasting. What you thought meant load only foo and bar from the target might suddenly mean load only baz and quuz from the target, and the result will probably be that the link completely fails. I think sticking only to per-a attributes is a safer idea, one way or another. Also, I anticipate that on many pages that would like to use this feature, only some unpredictable minority of links would actually need it. I don't think there will be any way to identify which ones without some kind of case-by-case human intervention, so I don't think base would be terribly useful. Some attention needs to be given to error handling. What happens if one or more of the requested id's aren't found? Do they silently fail? If so, this could result in the link doing absolutely nothing in hard-to-control situations -- like an error page that occurs sporadically, say a 500. Do they trigger a normal page load? If so, they have to wait until the entire page has loaded, which would be bad user experience but hard to track down -- a long, inexplicable delay followed by everything working normally. This could be mitigated by having an HTTP header to say that id doesn't exist, load the whole page instead, but it would fail in the default case (standard HTTP server unaware of new feature). Also, what happens if some of the given id's are present, but not others? One final observation is that this method isn't ideal for fixing flickering, because often you'll want to change everything at once -- you just don't want it to flicker. For instance, consider a case where you have a navigation pane and a content pane. Changing pages will change the content pane, but also sometimes cause a different item to be highlighted in the navigation pane, or cause some contextual items to disappear and reappear, etc. However, a solution to that has all the advantages of the onlyreplace proposal, that's simple to describe using existing functionality, and works well with URLs, but doesn't kill all script handlers and such, seems hard. On Sun, Oct 18, 2009 at 12:22 PM, tali garsiel t_gars...@hotmail.com wrote: Imagine this use case: You have a page with a chart and a table showing data calculated from complex statistical analysis on your huge database. Both the chart and the table have refresh buttons implemented with a onlyreplace Recalculating the chart when you refresh the table or vice verse will not be acceptable by your project manager :) I don't think the scenario is realistic. You can't usually get away with calculating anything very expensive on page load, because then page load would take unacceptably long. Calculations like this that you want to run as infrequently as possible are normally cached on the server side, in my experience. If they weren't you'd re-run the calculations every time the user navigates away and then back, or reloads the page. I don't see why that would be acceptable if the behavior you describe isn't.
Re: [whatwg] a onlyreplace
On Sun, Oct 18, 2009 at 12:25 PM, Aryeh Gregor simetrical+...@gmail.com wrote: On Sun, Oct 18, 2009 at 11:51 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: Okay, so possible revision: base onlyreplace=foo carries a list of ids to replace. This automatically makes all links and forms on the page carry the onlyreplace semantics. You can turn this off for specific links by setting @noreplace (a binary attribute) on the link or form; activating/submitting them will trigger a normal navigation. By all links and forms do you really mean all same-domain links and forms? Yes. Even that's too many. Consider a typical site with a forum at /forum and a wiki at /wiki. You don't want links from one to the other to try onlyreplacing. Even within an app it can be complicated. MediaWiki is often installed in both /w (actual files) and /wiki (fake rewrite path), and you'd probably want links to everything in /wiki but only some things in /w to be affected. Perhaps a onlyreplace should be a boolean attribute. Opting links into onlyreplace seems safer than opting them out. In many cases you might be injecting some raw HTML into the page, like using a template system or JavaScript, such that adding noreplace to all links you're unsure about would be tricky or impossible. Opt-in is much easier to verify. I think the opposite. If I upgraded my site to this, I'd want nearly all the links to onlyreplace. There's only a handful of same-origin links that I'd instead want to trigger a full load. In any event, this variant is fairly disastrous for copy-pasting. What you thought meant load only foo and bar from the target might suddenly mean load only baz and quuz from the target, and the result will probably be that the link completely fails. I think sticking only to per-a attributes is a safer idea, one way or another. It's true that this could be bad on copypasta, but is your failure scenario going to be common? Are people going to often use different bases on different pages in the same origin? I think more usually a single origin will have the same base onlyreplace everywhere, or else not have base onlyreplace at all. In the latter case, you'd presumably want all links to trigger full navigation, since that's what you're indicating with the lack. (Also, the same problem you note happens similarly with per-a onlyreplace - what if you copy a link from one page to another, and the new page has *different* elements with the same #ids as elements in the old page? Then you'd be replacing random bits of the page. Is this situation more/less likely than the one you brought up?) Also, I anticipate that on many pages that would like to use this feature, only some unpredictable minority of links would actually need it. I don't think there will be any way to identify which ones without some kind of case-by-case human intervention, so I don't think base would be terribly useful. I disagree, and think that most links would use it on a typical page. Some attention needs to be given to error handling. What happens if one or more of the requested id's aren't found? Do they silently fail? If so, this could result in the link doing absolutely nothing in hard-to-control situations -- like an error page that occurs sporadically, say a 500. Do they trigger a normal page load? If so, they have to wait until the entire page has loaded, which would be bad user experience but hard to track down -- a long, inexplicable delay followed by everything working normally. This could be mitigated by having an HTTP header to say that id doesn't exist, load the whole page instead, but it would fail in the default case (standard HTTP server unaware of new feature). Also, what happens if some of the given id's are present, but not others? I'll think a bit about these issues today. I'm not sure, off the top of my head, what the best response is. One final observation is that this method isn't ideal for fixing flickering, because often you'll want to change everything at once -- you just don't want it to flicker. For instance, consider a case where you have a navigation pane and a content pane. Changing pages will change the content pane, but also sometimes cause a different item to be highlighted in the navigation pane, or cause some contextual items to disappear and reappear, etc. However, a solution to that has all the advantages of the onlyreplace proposal, that's simple to describe using existing functionality, and works well with URLs, but doesn't kill all script handlers and such, seems hard. You'd just hook the links with javascript and use that to change the navigation-pane highlight. (Or, in some cases, harness CSS, such as by using the proposed pseudoclass that matches links to the current document.) ~TJ
Re: [whatwg] No interface flicker across page loads, without JavaScript
On Sun, Oct 18, 2009 at 5:19 AM, Ian Hickson i...@hixie.ch wrote: Why can't we just use AJAX, and not reload the page at all, for this? 1) AJAX is more difficult to set up, as far as I understand it. I can't say for sure, since I haven't ever tried to set up AJAX from scratch. 2) Getting bookmarkable/sharable URLs right requires extra effort with AJAX. Without HTML5 scripted history traversal (pushState, etc., IIRC -- I haven't looked at that yet, you know what I mean), it's not even possible to do it in a way that interoperates with non-JS UAs, like search engines following links that users have posted to forums. You have to store state in hashes, and reconstruct it using JS. 3) Getting fallback to non-JS UAs right requires you to write everything twice, pretty much. Or create a complicated framework that will automatically generate everything twice. In particular, search engines don't work well with AJAX at all. All I can say is that in practice, I've never even bothered looking at AJAX for page-reload situations (as opposed to performing actions within the current page) because it seems too complicated to do right. A simple method that would automatically fall back to full page retrieval would be much more attractive to me. It's not clear to me why GMail would get rid of the AJAXness -- what problem would we be solving? Also, with AJAX you can do things like transitions, which you couldn't do with page loads. I don't think Gmail specifically would get rid of AJAX. The feature described here is only useful for simple cases. It's not clear to me at this point whether it's a good enough tradeoff between simplicity and power to get significant uptake at all, let alone in sites with much more complicated needs. On Fri, 16 Oct 2009, Aryeh Gregor wrote: So, here's a preliminary description of a use-case. I'm not sure it's sane yet. Use Case: A page should be able to instruct that when a user follows a link, only part of the page is reloaded, while the rest stays fixed. That's not a use case, it's a feature description. The use case is the _why_ -- what is the problem being solved? I'm not *entirely* sure, since I've never seen the need to use anything like this myself. The desired features seem to include: a) Avoiding flickering and jumping on page load. b) Saving bandwidth. c) Being able to preserve state of some parts of the page (e.g., navigation collapse state) when others change (e.g., new content loaded). Is the desirability of those three things clear enough for them to qualify as use cases? I don't know if the list is exhaustive. (a) seems to have some people (at least Tab) interested in the feature proposal for its sake alone. It's possible that (a) could best be solved by general adjustments to how browsers lay out pages, perhaps opt-in, but that's way beyond my field of expertise. The basic problem seems to be that on the one hand, browsers need to do progressive rendering so that the page is usable as quickly as possible; but on the other hand, this means they need to clear away the whole page, including parts that won't actually change. Some way of hinting that certain parts shouldn't be cleared away, or should be cleared away in a different manner, but *without* changing what will show up when the page is finally loaded, might be a better solution here. It might affect only presentation and be invisible even to scripts. (b) is probably the least important of the three features, and can be addressed by other means that might be more useful overall (like SDCH). Some of the proposals have incidentally included some features in this direction because they seemed simple to tack on. (c) looks like the part that really needs to be solved by something along the lines of the given proposals, if AJAX and frames (and saving state in cookies and recreating it on page load, etc.) are unacceptable for whatever reason. Frames have problems that are very well recognized. AJAX has at least the problems mentioned above. Saving and recreating state on page load is a pain, I guess, and it would be nicer if it were automatic. I'm not the best person to ask here, though. All I can say personally is that if a good, robust mechanism were developed along the lines I and others have described, that doesn't create the potential for scary random errors of various stripes, then I *might* use it. I wrote my proposal based on the discussion about frames -- use AJAX didn't seem acceptable to a lot of people in the discussion, for whatever reason. I'm not personally all that interested in this feature.
Re: [whatwg] a onlyreplace
On Sun, Oct 18, 2009 at 1:37 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: I think the opposite. If I upgraded my site to this, I'd want nearly all the links to onlyreplace. There's only a handful of same-origin links that I'd instead want to trigger a full load. It's very common for several web apps to be installed under a single domain, with links from one to the others: the wiki, forum, and CMS all linking to each other, say. These links are often added to templates by admins as static HTML that the app doesn't even look at. Having them break horribly when the next version of the software uses onlyreplace isn't helpful. Basically, if you're outputting *any* HTML without parsing and sanitizing it, opt-out isn't acceptable, since you *can't* opt out of links in that HTML. And every web app I'm familiar with (admittedly that's about two) does output some HTML without parsing and sanitizing it. Keep in mind that if you can't opt out when you need to, the link will fail. If you can't opt in when you need to, the link will work, just trigger a full reload. Opt-in is a much better idea for that reason alone, given that many apps won't be able to sanitize some of the links they output. It's true that this could be bad on copypasta, but is your failure scenario going to be common? Are people going to often use different bases on different pages in the same origin? I think more usually a single origin will have the same base onlyreplace everywhere, or else not have base onlyreplace at all. In the latter case, you'd presumably want all links to trigger full navigation, since that's what you're indicating with the lack. I didn't remember that it would only be same-domain. You're right that that's a mitigation. But yes, I'd very much expect the same domain to often use different onlyreplace. Different web apps will have different onlyreplaces, and different web apps are often on the same domain. (Also, the same problem you note happens similarly with per-a onlyreplace - what if you copy a link from one page to another, and the new page has *different* elements with the same #ids as elements in the old page? Then you'd be replacing random bits of the page. Is this situation more/less likely than the one you brought up?) I'd hope id collision would be rare enough that this isn't a huge issue. MediaWiki tries to prefix all new classes and id's with mw- for this sort of reason. id's like content are likely to show up pretty often, though, you're right. (And in fact MediaWiki does have an id=content in the default skin.) I disagree, and think that most links would use it on a typical page. I'm not sure anymore. It depends how it's used. You'd just hook the links with javascript and use that to change the navigation-pane highlight. (Or, in some cases, harness CSS, such as by using the proposed pseudoclass that matches links to the current document.) Well, okay. That completely defeats the ease of use of this proposal, though.
Re: [whatwg] a onlyreplace
2009/10/18 Tab Atkins Jr. jackalm...@gmail.com: On Sun, Oct 18, 2009 at 12:20 PM, Nelson Menezes flying.mushr...@gmail.com wrote: 2009/10/18 Tab Atkins Jr. jackalm...@gmail.com: 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 a or form element, or the window object if the request originated via scripting. My thoughts were that the event fires at the replaced elements, not the a or form 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 a or form 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] object behavior
On Sun, 18 Oct 2009, Ben Laurie wrote: On Sun, Oct 18, 2009 at 5:37 AM, Ian Hickson i...@hixie.ch wrote: On Fri, 16 Oct 2009, Ben Laurie wrote: On Thu, 6 Aug 2009, Andrew Oakley wrote: - Should the type attribute take precedence over the Content-Type header? No, I believe what the spec says here is the preferred behaviour. Unless this is incompatible with legacy content, we should try to move towards this behaviour. I realise this is only one of dozens of ways that HTML is unfriendly to security, but, well, this seems like a bad idea - if the page thinks it is embedding, say, some flash, it seems like a pretty bad idea to allow the (possibly untrusted) site providing the flash to run whatever it wants in its place. If the site is untrusted, yet you are letting it run flash, then you've lost already. Flash can inject arbitrary JS into your page. Perhaps I am failing to understand, but if I embed anything from an untrusted site, then it can choose what type it is - so how would I prevent it running Flash? You can't exclude one type and allow others, but if you want a very specific type used for a plugin, you can use embed. If you just want to allow the untrusted site to do anything, but in their own security context so it can't harm your site, use iframe. If you are worried about security, I recommend using iframe. The new sandbox= feature will help even more, once implemented. I am worried about security, and I recommend using Caja - but Caja still has to output valid HTML/CSS/JS... I don't understand the problem. On Fri, 16 Oct 2009, Boris Zbarsky wrote: This cuts both ways. If a site allows me to upload images and I upload an HTML file with some script in it and tell it it's a GIF (e.g. via the name) an then put an object type=text/html data=http://this.other.site/my.gif; on my site... then I just injected script into a different domain if we let @type override the server-provided header. This is, imo, a much bigger problem than that of people embedding content from an untrusted site and getting content X instead of content Y, especially because content X can't actually access the page that contains it, right? Indeed. You just said it could, above. The example Boris mentioned was HTML. Embedded HTML is always origin-blocked. The example I mentioned earlier was Flash. Flash runs in the context of the embedder page. HTH, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] object behavior
On Sun, 18 Oct 2009, Ola P. Kleiven wrote: On Sun, 18 Oct 2009 14:21:56 +0200, Ben Laurie b...@google.com wrote: On Sun, Oct 18, 2009 at 5:37 AM, Ian Hickson i...@hixie.ch wrote: On Fri, 16 Oct 2009, Ben Laurie wrote: On Thu, 6 Aug 2009, Andrew Oakley wrote: - Should the type attribute take precedence over the Content-Type header? No, I believe what the spec says here is the preferred behaviour. Unless this is incompatible with legacy content, we should try to move towards this behaviour. I realise this is only one of dozens of ways that HTML is unfriendly to security, but, well, this seems like a bad idea - if the page thinks it is embedding, say, some flash, it seems like a pretty bad idea to allow the (possibly untrusted) site providing the flash to run whatever it wants in its place. If the site is untrusted, yet you are letting it run flash, then you've lost already. Flash can inject arbitrary JS into your page. Perhaps I am failing to understand, but if I embed anything from an untrusted site, then it can choose what type it is - so how would I prevent it running Flash? Running Flash and allowing the same Flash to script your page are two different things. Flash needs allowscriptaccess=always to script if it is loaded from a different domain. This may not be true for all plug-ins though. Ah, good to know. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] No interface flicker across page loads, without JavaScript
On Sun, Oct 18, 2009 at 1:00 PM, Aryeh Gregor simetrical+...@gmail.com wrote: a) Avoiding flickering and jumping on page load. b) Saving bandwidth. c) Being able to preserve state of some parts of the page (e.g., navigation collapse state) when others change (e.g., new content loaded). I intend to solve a combination of (a) and (c) (b might be an ancillary benefit, however). Basically, there are two classes of websites who I think will benefit from this. 1. Fairly ordinary sites which have heavy widgetry in their skeleton. These might be js-based (good semantic scripting often involves sending something over the wire that's simple and accessible, then substantially transforming it with js on the client to something more useful/dynamic), flash-based, or something else entirely. The idea is that there are things which are expensive to initialize (in cpu, time, whatever) that are present on every page. 2. Relatively simple single-page apps. Something on the scale of gmail probably won't be able to use this, and that's fine; they're already making a significant js investment and can afford a bit more to handle their single-pageness themselves, plus html5 will add several features to make this easier. However, a simpler mail client may benefit significantly from this, as it eliminates a big chunk of necessary js. Other apps that have complex scripts that should maintain their state may benefit too. The idea here is similar in that there may be a significant blob of js state that is expensive to initialize or reload. Really simple sites with static sections that are *actually* static won't really see much benefit (the decrease in flickering may be useful, but it's such a minor benefit that it's not worth engineering towards). As well, very complex js-driven applications will have more complex requirements than can be met by this mechanism, and so won't benefit from it. But the middle ground I outlined above has significant ability to grow, and I think is currently being held back by the architecture of the web (where every page is a completely independent resource) and the difficulty/expense of routing around it with js. ~TJ
Re: [whatwg] a onlyreplace
On Sun, Oct 18, 2009 at 2:31 PM, Nelson Menezes flying.mushr...@gmail.com wrote: 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). Well, the best way to do this is probably to use event delegation in the first place, so you don't have to reinitialize listeners every time. jQuery makes this extremely easy with the $(target).live(event, callback) functionality, but it's pretty simple to do by hand as well. 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). Worst case, you just have a listener on body which notes the id of the target as each swapIn event bubbles up to it, and calls some function when it's received all of them. This would be really easy to automate. ~TJ
Re: [whatwg] a onlyreplace
On Sun, Oct 18, 2009 at 1:15 PM, Aryeh Gregor simetrical+...@gmail.com wrote: On Sun, Oct 18, 2009 at 1:37 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: I think the opposite. If I upgraded my site to this, I'd want nearly all the links to onlyreplace. There's only a handful of same-origin links that I'd instead want to trigger a full load. It's very common for several web apps to be installed under a single domain, with links from one to the others: the wiki, forum, and CMS all linking to each other, say. These links are often added to templates by admins as static HTML that the app doesn't even look at. Having them break horribly when the next version of the software uses onlyreplace isn't helpful. Basically, if you're outputting *any* HTML without parsing and sanitizing it, opt-out isn't acceptable, since you *can't* opt out of links in that HTML. And every web app I'm familiar with (admittedly that's about two) does output some HTML without parsing and sanitizing it. Keep in mind that if you can't opt out when you need to, the link will fail. If you can't opt in when you need to, the link will work, just trigger a full reload. Opt-in is a much better idea for that reason alone, given that many apps won't be able to sanitize some of the links they output. This seems compelling. I agree, then. @onlyreplace on base defines the id-list, and then @onlyreplace on links/forms says I should carry the onlyreplace semantics. In the former case it's a space-separated list of IDREFs, in the latter it's a binary attribute. You'd just hook the links with javascript and use that to change the navigation-pane highlight. (Or, in some cases, harness CSS, such as by using the proposed pseudoclass that matches links to the current document.) Well, okay. That completely defeats the ease of use of this proposal, though. Hmm? No it doesn't. The @onlyreplace still makes the page *way* easier to handle. Needing a little bit more js to hook extra behavior around doesn't seem unreasonable. (It's better than refreshing the navlist just to highlight a new section.) ~TJ
Re: [whatwg] hgroup functionality absorbed into header?
On Sun, 18 Oct 2009, Kornel Lesinski wrote: On Sun, 18 Oct 2009 08:54:59 +0100, Ian Hickson i...@hixie.ch wrote: Your version with split h2 seems to use it only for visual effect. Not just visual, but presentational, yes, pretty much. It also makes it clear how to generate the outline. I don't understand how presentational h2s make outline clear. I thought they're an exception that didn't work simple outline algorithm: http://validator.w3.org/check?uri=http%3A%2F%2Fwww.w3.org%2FTR%2Fhtml5%2Foutline=1#outlineresult and hgroup exists to resolve ambiguity caused by presentational use of headers. I mean that it defines exactly what value to use in the outline. This: h1The Reality Dysfunction; Space is not the only void/h1 ...would result in an outline that had the following title: The Reality Dysfunction; Space is not the only void However, this: hgroup h1The Reality Dysfunction/h1 h2Space is not the only void/h2 /hgroup ...results in an outline with just: The Reality Dysfunction ...as desired. (A user agent could also include the subtitle, but it isn't required.) I still think that subtitle (subheader, tagline) would be just as effective, less confusing and less likely to break outline when used improperly... How is h2 confusing? h2 alone isn't. hgroup is the source of confusion. * Difference between hgroup and header is not obvious. It wasn't to me when I first saw them, and this isn't first thread about them. Sure, but people get it pretty quickly. Most of the threads are along the lines of I don't like it, not It does X where X is wrong. * Makes meaning of hx overloaded (sometimes it's a header that affects outline and level or other headers, sometimes it's a subheader that doesn't do anything that header would). Have you seen this post? http://www.onderhond.com/blog/work/the-hgroup-tag I think it sums up problems quite well. If those are the problems, then I think we're doing pretty well. There were a couple of misunderstandings quickly addressed by the comments. As far as I can tell, the other concerns were all theoretical, such as not approving of the element taking its meaning from its parents. However, this is a pattern used all over HTML5, and I don't see why it's a problem. I think something like subtitle is just as likely to be misused as hgroup, to be honest. Sure, but it's much more fail-safe. If you use header instead of hgroup or fail to use hgroup, you may significantly change structure of the document. That's clearly not the end of the world, since people are doing it all the time today! You can't make much damage with subheader. Sections will remain correct and at worst you'll add wrong subtitles to headers. There's plenty of damage you could make. What if someone decides that header should be subheader because it's in a section, and they end up putting entire sections in there, for instance? Authors have an unlimited capacity for misusing HTML. Also, it has a much poorer legacy (backwards compatibility) story. Both solutions have problems. I don't think ones are much worse than the others. I think subheader has far bigger problems than hgroup (primarily its lack of default styles in legacy UAs). hgroup breaks the outline I still think this is incorrect. It fixes the outline in new UAs, and has no effect on legacy UAs. subheader is ignored. Without CSS h2s will be too large and have too big margins. The CSS is already there, though, since people are already using h2 for this. With CSS subheader will work fine and doesn't limit styling possibilities. hgroup's content model doesn't allow any non-header elements, so one can't add any extra hooks for styling: hgroup h1/ div!-- add fancy border around subheaders? -- h2/ h2/ /div /hgroup That's a good point. However, in general, I would encourage people to not insert HTML divs purely for styling; instead, in the future, XBL and CSS will hopefully provide the tools to address this. (We can always allow div later if this becomes a real problem.) Another thing - can you write XPath query that extracts all headers from the document? Without hgroup it's simple. With hgroup I'm not sure if I could manage to write correct query. This problem exists in general in HTML -- can you write an XPath that selects the elements on a per-section basis, say? Or that selects all the third-level headers, including the right h1s in sections? For that kind of thing we'll need pesudo-elements (in Selectors) or custom functions (in XPath). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] object behavior
On Sun, Oct 18, 2009 at 3:47 PM, Ian Hickson i...@hixie.ch wrote: On Sun, 18 Oct 2009, Ben Laurie wrote: On Sun, Oct 18, 2009 at 5:37 AM, Ian Hickson i...@hixie.ch wrote: On Fri, 16 Oct 2009, Ben Laurie wrote: On Thu, 6 Aug 2009, Andrew Oakley wrote: - Should the type attribute take precedence over the Content-Type header? No, I believe what the spec says here is the preferred behaviour. Unless this is incompatible with legacy content, we should try to move towards this behaviour. I realise this is only one of dozens of ways that HTML is unfriendly to security, but, well, this seems like a bad idea - if the page thinks it is embedding, say, some flash, it seems like a pretty bad idea to allow the (possibly untrusted) site providing the flash to run whatever it wants in its place. If the site is untrusted, yet you are letting it run flash, then you've lost already. Flash can inject arbitrary JS into your page. Perhaps I am failing to understand, but if I embed anything from an untrusted site, then it can choose what type it is - so how would I prevent it running Flash? You can't exclude one type and allow others, Sure, and that's fine. but if you want a very specific type used for a plugin, you can use embed. So what's the difference between embed and object? If you just want to allow the untrusted site to do anything, but in their own security context so it can't harm your site, use iframe. iframe is insufficient to prevent untrusted content from doing harm. It also makes it painful to communicate with the untrusted content. If you are worried about security, I recommend using iframe. The new sandbox= feature will help even more, once implemented. I am worried about security, and I recommend using Caja - but Caja still has to output valid HTML/CSS/JS... I don't understand the problem. On Fri, 16 Oct 2009, Boris Zbarsky wrote: This cuts both ways. If a site allows me to upload images and I upload an HTML file with some script in it and tell it it's a GIF (e.g. via the name) an then put an object type=text/html data=http://this.other.site/my.gif; on my site... then I just injected script into a different domain if we let @type override the server-provided header. This is, imo, a much bigger problem than that of people embedding content from an untrusted site and getting content X instead of content Y, especially because content X can't actually access the page that contains it, right? Indeed. You just said it could, above. The example Boris mentioned was HTML. Embedded HTML is always origin-blocked. The example I mentioned earlier was Flash. Flash runs in the context of the embedder page. HTH, -- Ian Hickson U+1047E )\._.,--,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
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
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? ~TJ
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] object behavior
On Sun, 18 Oct 2009 23:48:51 +0200, Ian Hickson i...@hixie.ch wrote: On Sun, 18 Oct 2009, Ben Laurie wrote: but if you want a very specific type used for a plugin, you can use embed. So what's the difference between embed and object? embed only allows plugins; object also allows other things, like HTML and images. embed also allows images (including SVG with scripts), at least in browsers. -- Simon Pieters Opera Software
Re: [whatwg] Superset encodings [Re: ISO-8859-* and the C1 control range]
On Sat, 18 Jul 2009, Øistein E. Andersen wrote: On 7 Jul 2009, at 09:25, Ian Hickson wrote: On Tue, 9 Jun 2009, Anne van Kesteren wrote: [S]hould HTML5 mention that Windows-932 maps to Windows-31J? (It does not appear in the IANA registry.) I've added this mapping too, just in case. Added x-sjis. What are the other mappings that would be good? Potentially quite a few... The following do not appear in the IANA registry and seem to be supported in IE as well as in at least two of the three browsers Safari, Firefox and Opera. [...] I've noted your e-mail here: http://wiki.whatwg.org/wiki/Web_Encodings#E-mails ...and moved the whole thing out of the spec. I think the conclusion is that we should just do this using IANA aliases. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'