Re: [whatwg] should we add beforeload/afterload events to the web platform?
On Sat, 4 Feb 2012, Boris Zbarsky wrote: On 2/3/12 11:15 PM, Ian Hickson wrote: I agree with you that if the author is using HTTP styles on their HTTPS page that an attacker could screw with the page. But my point is that fixing that is easy: just move the styles to HTTPS. In the case of scripts it's not that easy because the scripts might be on third-party servers Styles are also commonly found on third-party servers... in complicated setups Likewise. Styles are not as generic as scripts. Styles are almost always very specific to the site, so you have control over them. Scripts on the other hand could be things like analytics, or be related to social widgets, or who knows what else. (I'll grant that maybe some of those embed style sheets which you might then want to enable, but I'd imagine most of them would do that inside iframes, not directly in your page.) The point being that while I could see wanting to control things per-script (and I believe this is now specced out), I don't really see a compellingly similar story for styles or for making this completely generic. Having said that, of course, if browser vendors implement it, I'll spec it... (There were other e-mails on this thread but they did not seem to have any actionable feedback on the spec so I have not included them here.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] should we add beforeload/afterload events to the web platform?
On Tue, Jan 17, 2012 at 6:29 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 1/17/12 7:49 AM, Henri Sivonen wrote: On Sun, Jan 15, 2012 at 11:23 PM, Boris Zbarskybzbar...@mit.edu wrote: Preventing _all_ loads for a document based on some declarative thing near the start of the document, on the other hand, should not be too bad. A page-wide disable optimizations flag could easily be cargo-culted into something harmful. Consider if the narrative becomes that setting such a flag is good for mobile or something. Who said anything about disable optimizations? I suggested a flag to prevent all subresource loads, not just speculative preloads. Basically a treat this as a data document flag. Oh I see. Sorry. If that plus a beforeprocess event addresses the majority of the web-facing use cases, we should consider adding that. So what are the Web-facing use cases? As in: What are people trying to accomplish with client-side transformations? Well, what mobify is apparently trying to accomplish is take an existing (not-mobile-optimized, or in other words typically ad-and-float-and-table-laden) page and modify it to look reasonable on a small screen. That includes not loading some of the stylesheets and various changes to the DOM, as far as I can tell. FWIW, I'm completely unsympathetic to this use case and I think we shouldn't put engineering effort into supporting this scenario. As far as the user is concerned, it would be much better for the site to get its act together on the server side and not send an ad-laden table page to anyone. It sucks to burn resources on the client side to fix things up using scripts provided by the same server that sends the broken stuff in the first place. -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [whatwg] should we add beforeload/afterload events to the web platform?
On 2/6/12 5:37 AM, Henri Sivonen wrote: FWIW, I'm completely unsympathetic to this use case and I think we shouldn't put engineering effort into supporting this scenario. That depends on timeframes. As far as the user is concerned, it would be much better for the site to get its act together on the server side and not send an ad-laden table page to anyone. It sucks to burn resources on the client side to fix things up using scripts provided by the same server that sends the broken stuff in the first place. Well, yes. But doing that might take months to years depending on the size of the site, while deploying something like mobify is more on the order of weeks... I agree that long-term the mobify use case is not something the web will really need; it's needed while people transition to the realization that their current websites suck and need changing. ;) -Boris
Re: [whatwg] should we add beforeload/afterload events to the web platform?
On Fri, Feb 3, 2012 at 10:47 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 2/3/12 11:15 PM, Ian Hickson wrote: No, I agree with you that if the author is using HTTP styles on their HTTPS page that an attacker could screw with the page. But my point is that fixing that is easy: just move the styles to HTTPS. In the case of scripts it's not that easy because the scripts might be on third-party servers Styles are also commonly found on third-party servers... in complicated setups Likewise. But yeah, I'd love to hear from Adam here. I've somewhat lost track of this thread. If you're asking about how dangerous it is to include HTTP styles in an HTTPS page, it's less dangerous than script but more dangerous than images. Chrome classifies styles as active mixed content, which has a number of effects, including triggering scarier UI. One way to think about insecure styles is to imagine they let the attacker completely control the appearance of the page (this is actually not that far from the truth). There are many pages where controlling their appearance is almost as good as injecting script into them. For example, you can convince the user to type their password into a text field that is actually a direct message to the attacker, etc. Adam
Re: [whatwg] should we add beforeload/afterload events to the web platform?
On Mon, 9 Jan 2012, Tantek �~Gelik wrote: WebKit supports a 'beforeload' event [1] which is supported in shipping Safari and Chrome[2] and apparently has (enabled) the real-world use-cases of: 1. Performance. Reducing bandwidth use / HTTP requests, e.g. AdBlock extension Extensions are out of scope, since they don't have to use standard Web features. 2. Clientside transformations, e.g. Mobify I couldn't work out the use case here. Can you elaborate? If it's just make a Web site work for multiple media including handheld and desktop, then it seems like building a multimedia site from the ground up using media queries, CSS, and media-aware JS is a far better solution than taking a Desktop site and pushing extra JS into it to hack the page to work on a mobile device. As might be expected, there is at least one use-case for a complementary 'afterload' event: Downloadable fonts - people who want to use custom fonts for drawing in the canvas element need to know when a font has loaded. 'afterload' seems like a good way to know that, since it happens as a side effect of actually using it and fonts don't have an explicit load API like images do. Seems like the right way to support that is to provide a font loading API, not a global loading notification API that you can use to look for font URLs. Safari and Chrome have already shipped 'beforeload' [...]. On Tue, 10 Jan 2012, Boris Zbarsky wrote: The goal of the client-side transformation case is effectively do something like what one can do with XSLT in XML. Specifically: 1) Don't actually render the HTML coming down the pipe. This includes not doing any loads from it, but also includes not actually doing layout, not running scripts in the page, etc. 2) Bind some sort of transformation to it (in this case a script that runs on the DOM or on the original source, depending). 3) Render the result of that transformation. Having the mobile device do this sounds like a terrible idea. Surely it would be orders of magnitude more effective to have the server do this kind of transformation. I agree that this is a good use case to solve, but beforeload doesn't really solve it. We should provide a better solution. I'm not sure I agree it's a good use case to solve, but I definitely agree that even if it was, beforeload wouldn't cut it. For the rest, I just checked and WebKit does set the event target to the node triggering the load, at least for script nodes. I can nearly guarantee that we would NOT be willing to do that in Gecko even if we were convinced that the 'beforeload' event is a good idea in the first place. Indeed. In fact, at that point I don't really understand the difference between beforeload and the progress-events-suggested loadstart, which some objects and elements use. On Wed, 11 Jan 2012, Simon Pieters wrote: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1297 Might not be cross-browser yet (e.g. Opera seems to run the image's onload handler), but should work per spec I think. Well, the load can't be prevented if it's speculatively loaded it before the script has executed, but maybe that's fine for the use case. Yeah that's pretty much sufficient for the transformation case... On Sun, 15 Jan 2012, Boris Zbarsky wrote: Again, preventing preloads on a per-load basis is a hard problem if you want to have sane parallelism. Preventing _all_ loads for a document based on some declarative thing near the start of the document, on the other hand, should not be too bad. If that plus a beforeprocess event addresses the majority of the web-facing use cases, we should consider adding that. Preventing all loads in a document seems trivial. Don't declare any loads! I really don't understand why you would include script and img elements, etc, if you're not going to want them to be processed. (The only exception I can think of is for defining templates or shadow trees for segments or components that are going to be stamped out later. The Web Components work on templates will likely end up providing a declarative way to neuter parts of a document for that purpose, though.) On Tue, 17 Jan 2012, James Robinson wrote: It seems like there are two [features being requested]: 1.) Monitoring/modifying/preventing network activity for a given resource load 2.) Monitoring/modifying/preventing DOM modifications that occur as the result of a resource load For (1) I can't think of any web-facing [use cases]. For extensions, I believe this is better addressed by APIs that target the network layer more directly - for example proxy auto config scripts, or things like http://code.google.com/chrome/extensions/trunk/webRequest.html. For (2) I think this would be better addressed by using next-generation mutation events to observe (and potentially react) to the changes that occur when an img is loaded, for example. I
Re: [whatwg] should we add beforeload/afterload events to the web platform?
On 2/3/12 3:07 PM, Ian Hickson wrote: OK. I have no serious problem with a beforeprocess event that fires before processing the response, esp. if processing is defined in a page-visible way (so e.g. you could still compile a script in the background before firing beforeprocess; you just couldn't run it). I don't have an objection to adding a cancelable bubbling event that fires synchronously as part of the execute a script block algorithm, between the current steps 1 and 2 of if the load was successful, which gets the URL of the script, targetted at the script, which if canceled cancels the execution of the script. Does any browser have an event like that already? If not, any opinions on an event name?script onbeforerun=? Gecko has a beforescriptexecute event. It's a simple event targeted at the element; there's no reason to include the URI, since that can be gotten off the element. I believe calling preventDefault() on it will prevent the script from executing. I also believe that we have proposed this for standardization in the past, though it seems to have fallen through the cracks a bit... But note that this is script-specific; I believe that content-blocker use cases would want this for images, stylesheets, etc. -Boris
Re: [whatwg] should we add beforeload/afterload events to the web platform?
On Fri, 3 Feb 2012, Boris Zbarsky wrote: On 2/3/12 3:07 PM, Ian Hickson wrote: OK. I have no serious problem with a beforeprocess event that fires before processing the response, esp. if processing is defined in a page-visible way (so e.g. you could still compile a script in the background before firing beforeprocess; you just couldn't run it). I don't have an objection to adding a cancelable bubbling event that fires synchronously as part of the execute a script block algorithm, between the current steps 1 and 2 of if the load was successful, which gets the URL of the script, targetted at the script, which if canceled cancels the execution of the script. Does any browser have an event like that already? If not, any opinions on an event name?script onbeforerun=? Gecko has a beforescriptexecute event. It's a simple event targeted at the element; there's no reason to include the URI, since that can be gotten off the element. I believe calling preventDefault() on it will prevent the script from executing. Ok, I've added that to the spec. I also believe that we have proposed this for standardization in the past, though it seems to have fallen through the cracks a bit... I couldn't find any mention of it in the WHATWG archives or Bugzilla, though I did find an e-mail from sicking saying he'd proposed it to the WHATWG list. :-( But note that this is script-specific; I believe that content-blocker use cases would want this for images, stylesheets, etc. As noted in the previous e-mail, it's not clear that the content-blocker use cases are valid. The use case that is compelling for beforescriptexecute is regarding sites who are trying to address mixed content vulnerabilities progressively and need to closer control over external script execution. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] should we add beforeload/afterload events to the web platform?
On 2/3/12 3:38 PM, Ian Hickson wrote: I also believe that we have proposed this for standardization in the past, though it seems to have fallen through the cracks a bit... I couldn't find any mention of it in the WHATWG archives or Bugzilla, though I did find an e-mail from sicking saying he'd proposed it to the WHATWG list. :-( http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-August/027975.html and then there were some followup mails with broken threading bikeshedding the names looks like. As noted in the previous e-mail, it's not clear that the content-blocker use cases are valid. The use case that is compelling for beforescriptexecute is regarding sites who are trying to address mixed content vulnerabilities progressively and need to closer control over external script execution. That's the use case I was talking about, but they'd want at least control over stylesheets too, I'd think. -Boris
Re: [whatwg] should we add beforeload/afterload events to the web platform?
On 2/3/12 11:15 PM, Ian Hickson wrote: No, I agree with you that if the author is using HTTP styles on their HTTPS page that an attacker could screw with the page. But my point is that fixing that is easy: just move the styles to HTTPS. In the case of scripts it's not that easy because the scripts might be on third-party servers Styles are also commonly found on third-party servers... in complicated setups Likewise. But yeah, I'd love to hear from Adam here. -Boris
Re: [whatwg] should we add beforeload/afterload events to the web platform?
Le 17 janv. 2012 à 19:37, Tab Atkins Jr. a écrit : SPDY push allows the server to send down additional resources along with the main resource, before the client actually requests them. When you say additional resources. Is that from the same domain? -- Karl Dubost - http://dev.opera.com/ Developer Relations, Opera Software
Re: [whatwg] should we add beforeload/afterload events to the web platform?
Le 17 janv. 2012 à 19:51, Boris Zbarsky a écrit : On 1/17/12 7:37 PM, Tab Atkins Jr. wrote: SPDY push allows the server to send down additional resources along with the main resource […] Ah, ok. Yeah, there's obviously no way the client can prevent that, nor should it try. no way the client can prevent that It might seem unfortunate. should it try maybe. It seems to me that somehow it is partially breaking something along privacy/security, etc. but I may be missing something. -- Karl Dubost - http://dev.opera.com/ Developer Relations, Opera Software
Re: [whatwg] should we add beforeload/afterload events to the web platform?
On Sun, Jan 15, 2012 at 11:23 PM, Boris Zbarsky bzbar...@mit.edu wrote: Preventing _all_ loads for a document based on some declarative thing near the start of the document, on the other hand, should not be too bad. A page-wide disable optimizations flag could easily be cargo-culted into something harmful. Consider if the narrative becomes that setting such a flag is good for mobile or something. A per-element disable optimizations attribute would be slightly less dangerous, since authors couldn't just set it once and forget it. If that plus a beforeprocess event addresses the majority of the web-facing use cases, we should consider adding that. So what are the Web-facing use cases? As in: What are people trying to accomplish with client-side transformations? -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [whatwg] should we add beforeload/afterload events to the web platform?
On 1/17/12 7:49 AM, Henri Sivonen wrote: On Sun, Jan 15, 2012 at 11:23 PM, Boris Zbarskybzbar...@mit.edu wrote: Preventing _all_ loads for a document based on some declarative thing near the start of the document, on the other hand, should not be too bad. A page-wide disable optimizations flag could easily be cargo-culted into something harmful. Consider if the narrative becomes that setting such a flag is good for mobile or something. Who said anything about disable optimizations? I suggested a flag to prevent all subresource loads, not just speculative preloads. Basically a treat this as a data document flag. If that plus a beforeprocess event addresses the majority of the web-facing use cases, we should consider adding that. So what are the Web-facing use cases? As in: What are people trying to accomplish with client-side transformations? Well, what mobify is apparently trying to accomplish is take an existing (not-mobile-optimized, or in other words typically ad-and-float-and-table-laden) page and modify it to look reasonable on a small screen. That includes not loading some of the stylesheets and various changes to the DOM, as far as I can tell. -Boris
Re: [whatwg] should we add beforeload/afterload events to the web platform?
On Sun, Jan 15, 2012 at 1:23 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 1/12/12 9:22 AM, Boris Zbarsky wrote: On 1/12/12 5:16 AM, Simon Pieters wrote: Note that it removes the root element when the script element is executed, not at DOMContentLoaded. Ah, I missed that. I guess the HTML5 parsing algorithm means that now the elements are parsed into the other document, eh? That's actually pretty cute. I wonder whether we can get the mobify folks to switch to this Thinking back on this, this still has the issue of not preventing preloads. Again, preventing preloads on a per-load basis is a hard problem if you want to have sane parallelism. Preventing _all_ loads for a document based on some declarative thing near the start of the document, on the other hand, should not be too bad. Even this scheme doesn't work with a model like SPDY push or other bundling techniques or with more aggressive preloading that initiates loads before the main resource is loaded. It seems like there are two use cases: 1.) Monitoring/modifying/preventing network activity for a given resource load 2.) Monitoring/modifying/preventing DOM modifications that occur as the result of a resource load For (1) I can't think of any web-facing needs. For extensions, I believe this is better addressed by APIs that target the network layer more directly - for example proxy auto config scripts, or things like http://code.google.com/chrome/extensions/trunk/webRequest.html. For (2) I think this would be better addressed by using next-generation mutation events to observe (and potentially react) to the changes that occur when an img is loaded, for example. I struggle to think of good web-facing use cases for this, though. In any event I think that beforeload as it exists today is a bad API for the web and hope that we can stop exposing it to the web in WebKit (although I suspect it'll stick around for extension contexts, which is more acceptable in my view). - James If that plus a beforeprocess event addresses the majority of the web-facing use cases, we should consider adding that. -Boris
Re: [whatwg] should we add beforeload/afterload events to the web platform?
On 1/17/12 7:24 PM, James Robinson wrote: Even this scheme doesn't work with a model like SPDY push or other bundling techniques or with more aggressive preloading that initiates loads before the main resource is loaded. Er... you mean it initiates loads before it has any idea whether the main resource might have changed such that it no longer links to the objects in question? I agree that such aggressive preloading is impossible to control from the source document; an interesting question is whether it's desirable. I know that in the past when Gecko preloaded too aggressively we got huge complaints from various ad providers about bogus impressions 1.) Monitoring/modifying/preventing network activity for a given resource load 2.) Monitoring/modifying/preventing DOM modifications that occur as the result of a resource load For (1) I can't think of any web-facing needs. I believe mobify does in fact want (1) as much as it can to conserve bandwidth... In any event I think that beforeload as it exists today is a bad API for the web Good, we agree on that. ;) (although I suspect it'll stick around for extension contexts, which is more acceptable in my view). It's obviously just fine from my pov at that point. ;) -Boris
Re: [whatwg] should we add beforeload/afterload events to the web platform?
On Tue, Jan 17, 2012 at 4:29 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 1/17/12 7:24 PM, James Robinson wrote: Even this scheme doesn't work with a model like SPDY push or other bundling techniques or with more aggressive preloading that initiates loads before the main resource is loaded. Er... you mean it initiates loads before it has any idea whether the main resource might have changed such that it no longer links to the objects in question? SPDY push allows the server to send down additional resources along with the main resource, before the client actually requests them. (The server, ideally, should know what resources the main resource links to.) ~TJ
Re: [whatwg] should we add beforeload/afterload events to the web platform?
On Tue, Jan 17, 2012 at 4:29 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 1/17/12 7:24 PM, James Robinson wrote: Even this scheme doesn't work with a model like SPDY push or other bundling techniques or with more aggressive preloading that initiates loads before the main resource is loaded. Er... you mean it initiates loads before it has any idea whether the main resource might have changed such that it no longer links to the objects in question? The way that these sorts of schemes work is that the server knows that a set of resources are needed in addition to the main resource and it starts sending them down before the client has received/parsed the main resource. The server serving foo.html can have a pretty good idea about whether foo.html contains the string script src=foo.js so there isn't any real reason for it to not serve foo.js at the same time assuming that the underlying protocol can handle such a thing. In situations with high RTTs and reasonable bandwidth (like common mobile networks) this can be a big win. I bring this up to make sure that we aren't making promises about resource loads that we can't keep. - James I agree that such aggressive preloading is impossible to control from the source document; an interesting question is whether it's desirable. I know that in the past when Gecko preloaded too aggressively we got huge complaints from various ad providers about bogus impressions 1.) Monitoring/modifying/**preventing network activity for a given resource load 2.) Monitoring/modifying/**preventing DOM modifications that occur as the result of a resource load For (1) I can't think of any web-facing needs. I believe mobify does in fact want (1) as much as it can to conserve bandwidth... In any event I think that beforeload as it exists today is a bad API for the web Good, we agree on that. ;) (although I suspect it'll stick around for extension contexts, which is more acceptable in my view). It's obviously just fine from my pov at that point. ;) -Boris
Re: [whatwg] should we add beforeload/afterload events to the web platform?
On 1/17/12 7:37 PM, Tab Atkins Jr. wrote: SPDY push allows the server to send down additional resources along with the main resource, before the client actually requests them. (The server, ideally, should know what resources the main resource links to.) Ah, ok. Yeah, there's obviously no way the client can prevent that, nor should it try. -Boris
Re: [whatwg] should we add beforeload/afterload events to the web platform?
On 1/17/12 7:37 PM, James Robinson wrote: The way that these sorts of schemes work is that the server knows that a set of resources are needed in addition to the main resource and it starts sending them down before the client has received/parsed the main resource. The server serving foo.html can have a pretty good idea about whether foo.html contains the string script src=foo.js so there isn't any real reason for it to not serve foo.js at the same time assuming that the underlying protocol can handle such a thing. In situations with high RTTs and reasonable bandwidth (like common mobile networks) this can be a big win. I bring this up to make sure that we aren't making promises about resource loads that we can't keep. Yeah, makes sense. Such promises are precisely what I'd like to avoid, yes. -Boris
Re: [whatwg] should we add beforeload/afterload events to the web platform?
On 1/12/12 9:22 AM, Boris Zbarsky wrote: On 1/12/12 5:16 AM, Simon Pieters wrote: Note that it removes the root element when the script element is executed, not at DOMContentLoaded. Ah, I missed that. I guess the HTML5 parsing algorithm means that now the elements are parsed into the other document, eh? That's actually pretty cute. I wonder whether we can get the mobify folks to switch to this Thinking back on this, this still has the issue of not preventing preloads. Again, preventing preloads on a per-load basis is a hard problem if you want to have sane parallelism. Preventing _all_ loads for a document based on some declarative thing near the start of the document, on the other hand, should not be too bad. If that plus a beforeprocess event addresses the majority of the web-facing use cases, we should consider adding that. -Boris
Re: [whatwg] should we add beforeload/afterload events to the web platform?
On 1/13/12 2:50 AM, Roman Rudenko wrote: True. In its current form, beforeload is not very useful for partial processing. What if we had 'beforedownload' event specifically for resource fetching, and constructed stub elements to feed it as event.target when load is readahead-induced? That still has the fundamental problem of serializing subresource processing on the main JS thread that page JS is running on. I believe that as hardware becomes more parallel and browsers strive to make use of that parallelism having such a requirement in a specification will be actively harmful. Maybe the benefits outweigh the harm, but they'd have to be some pretty serious real benefits, not just hypothetical ones, if they're going to constrain the web platform in a major way like that. Hence me trying to understand the actual use cases here. So, do we expect to need to block loads from _part_ of a document, in the long term? -Boris
Re: [whatwg] should we add beforeload/afterload events to the web platform?
On Wed, 11 Jan 2012 15:51:47 +0100, Boris Zbarsky bzbar...@mit.edu wrote: On 1/11/12 6:59 AM, Simon Pieters wrote: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1297 Might not be cross-browser yet (e.g. Opera seems to run the image's onload handler), but should work per spec I think. Well, the load can't be prevented if it's speculatively loaded it before the script has executed, but maybe that's fine for the use case. This also doesn't prevent rendering (which can easily start before DOMContentLoaded), doesn't prevent execution of script in the document that's being loaded, etc. Sure it does (or at least should, and does in Firefox). Note that it removes the root element when the script element is executed, not at DOMContentLoaded. It does the transformation and puts the root element *back* at DOMContentLoaded. Scripts don't run when parsed into the other document since it is a different document than the one the HTML parser runs on. They don't run when the root element is put back, either, since they are marked as already-executed, I think. The only way something could be rendered with the above script before it runs is in Opera with DSE enabled. Again, the hard part of doing a transformation on HTML is not doing the transformation; it's preventing the transformation source document from being treated as usual. -- Simon Pieters Opera Software
Re: [whatwg] should we add beforeload/afterload events to the web platform?
On 1/12/12 5:16 AM, Simon Pieters wrote: Note that it removes the root element when the script element is executed, not at DOMContentLoaded. Ah, I missed that. I guess the HTML5 parsing algorithm means that now the elements are parsed into the other document, eh? That's actually pretty cute. I wonder whether we can get the mobify folks to switch to this -Boris
Re: [whatwg] should we add beforeload/afterload events to the web platform?
On Thu, Jan 12, 2012 at 6:22 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 1/12/12 5:16 AM, Simon Pieters wrote: Note that it removes the root element when the script element is executed, not at DOMContentLoaded. Ah, I missed that. I guess the HTML5 parsing algorithm means that now the elements are parsed into the other document, eh? That's actually pretty cute. I wonder whether we can get the mobify folks to switch to this This only works for the initial page load, no?
Re: [whatwg] should we add beforeload/afterload events to the web platform?
On 1/12/12 1:27 PM, Ojan Vafai wrote: This only works for the initial page load, no? Yes, but does mobify use the beforeload handler after the initial page load? They're generating new content and document.writing it back into the document, and that new content needs to perform loads, so I would think they aren't so much. -Boris
[whatwg] should we add beforeload/afterload events to the web platform?
On Jan 12 10:32, Boris Zbarsky wrote: Yes, but does mobify use the beforeload handler after the initial page load? They're generating new content and document.writing it back into the document, and that new content needs to perform loads, so I would think they aren't so much. At the moment, we are capturing raw page HTML by containing it within style with nonstandard type or textarea elements. If we know that a page is well-behaved and has no textareas in head or styles in body, we can document.write an opening textarea to capture what's in head, and capture page body with a similarly written style. Once we capture raw HTML text, we rename resource-loading attributes (src, href), allowing us to build and process DOM representation without any external requests firing. Beforeload comes in when our assumptions are violated. If the page has a style.../style within body and we don't take preventive measures, our capturing method will allow everything after /style to leak into DOM. So, we use beforeload (along with some other tricks) to block resources that elude capture. We don't need beforeload after that, as we control all HTML we return into the page. Now that Henri Sivonen showed us that plaintext can be used for capturing, we could get away with not using beforeload at all. However, it may be useful for folks who use smaller, more controlled transformations. For example, @media-controlled mobile view of a page originally designed for desktop will typically include all desktop assets. beforeload can fix that, as desktop resource loads could be cancelled or even replaced with mobile-specific ones without complete HTML reconstruction. -- Roman Rudenko
Re: [whatwg] should we add beforeload/afterload events to the web platform?
On 1/12/12 2:19 PM, Roman Rudenko wrote: For example, @media-controlled mobile view of a page originally designed for desktop will typically include all desktop assets. beforeload can fix that, as desktop resource loads could be cancelled or even replaced with mobile-specific ones without complete HTML reconstruction. Except they can't, because beforeload fires after the load has started in many cases, right? -Boris
Re: [whatwg] should we add beforeload/afterload events to the web platform?
On Thu, Jan 12, 2012 at 11:32 AM, Boris Zbarsky bzbar...@mit.edu wrote: For example, @media-controlled mobile view of a page originally designed for desktop will typically include all desktop assets. beforeload can fix that, as desktop resource loads could be cancelled or even replaced with mobile-specific ones without complete HTML reconstruction. Except they can't, because beforeload fires after the load has started in many cases, right? Blocking is possible under some circumstances. Webkit differentiates between normal parser and speculative parser. Speculative parser is launched only if normal parser is blocked on execution of a script. So, one could use beforeload to block resources in Webkit, for as long as no synchronous scripts are allowed to slip through. Unfortunately, one runaway script blocks the parser and spoils blocking for anything after itself. This might not work as nicely in Firefox, which, according to Boris, does not maintain separation between main and speculative parser. Even if that does not work, beforeload can prevent processing of needlessly fetched resource (which makes it behave more like 'beforeprocess', suggested by Boris). -- Roman Rudenko
Re: [whatwg] should we add beforeload/afterload events to the web platform?
On 1/12/12 9:23 PM, Roman Rudenko wrote: Blocking is possible under some circumstances. Webkit differentiates between normal parser and speculative parser. Speculative parser is launched only if normal parser is blocked on execution of a script. So, one could use beforeload to block resources in Webkit, for as long as no synchronous scripts are allowed to slip through. Unfortunately, one runaway script blocks the parser and spoils blocking for anything after itself. I just thought about this some more... This caveat makes beforeload not very helpful for blocking or redirecting loads from only part of a document, and for blocking loads from the whole document there are the better solutions mentioned earlier in this thread. -Boris
Re: [whatwg] should we add beforeload/afterload events to the web platform?
On Tue, 10 Jan 2012 07:34:19 +0100, Boris Zbarsky bzbar...@mit.edu wrote: On 1/10/12 1:02 AM, Boris Zbarsky wrote: I'd like to understand the client-side transformation use-case better, in particular. What is it really trying to do? OK, I got more context on this. The goal of the client-side transformation case is effectively do something like what one can do with XSLT in XML. Specifically: 1) Don't actually render the HTML coming down the pipe. This includes not doing any loads from it, but also includes not actually doing layout, not running scripts in the page, etc. 2) Bind some sort of transformation to it (in this case a script that runs on the DOM or on the original source, depending). 3) Render the result of that transformation. mobify uses beforeload for a poor-man's approximation to #1: it can block loads, but not prevent execution of inline scripts or prevent layout (short of adding display:none styles to the page itself). Then it does various other hackery to do #2 and #3. I agree that this is a good use case to solve, but beforeload doesn't really solve it. We should provide a better solution. For the rest, I just checked and WebKit does set the event target to the node triggering the load, at least for script nodes. I can nearly guarantee that we would NOT be willing to do that in Gecko even if we were convinced that the 'beforeload' event is a good idea in the first place. The 'afterload' event doesn't have the same sort of problems, of course; it's no different from existing 'load' events in cases when it's fired on an element. Whether it provides a good solution for other cases, I haven't had a chance to think through yet. -Boris http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1297 Might not be cross-browser yet (e.g. Opera seems to run the image's onload handler), but should work per spec I think. Well, the load can't be prevented if it's speculatively loaded it before the script has executed, but maybe that's fine for the use case. -- Simon Pieters Opera Software
Re: [whatwg] should we add beforeload/afterload events to the web platform?
On 1/11/12 6:59 AM, Simon Pieters wrote: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1297 Might not be cross-browser yet (e.g. Opera seems to run the image's onload handler), but should work per spec I think. Well, the load can't be prevented if it's speculatively loaded it before the script has executed, but maybe that's fine for the use case. This also doesn't prevent rendering (which can easily start before DOMContentLoaded), doesn't prevent execution of script in the document that's being loaded, etc. Again, the hard part of doing a transformation on HTML is not doing the transformation; it's preventing the transformation source document from being treated as usual. -Boris
Re: [whatwg] should we add beforeload/afterload events to the web platform?
On Jan 10, 2012, at 8:43 AM, Boris Zbarsky wrote: So in WebKit this event is only good for preventing _processing_ of the data in the page (e.g. preventing the script from executing when the target is a script) but not much use for preventing loads, even if some people seem to think that it is. That’s a bug in the current implementation that we are working on fixing. -- Darin
Re: [whatwg] should we add beforeload/afterload events to the web platform?
On 1/10/12 1:54 PM, Darin Adler wrote: On Jan 10, 2012, at 8:43 AM, Boris Zbarsky wrote: So in WebKit this event is only good for preventing _processing_ of the data in the page (e.g. preventing the script from executing when the target is ascript) but not much use for preventing loads, even if some people seem to think that it is. That’s a bug in the current implementation that we are working on fixing. If I might ask, how do you plan to fix it without at least breaking speculative loads in the presence of beforeload handlers? I just don't see how WebKit's current event setup can be used without doing that, because it requires the relevant DOM node to exist. -Boris
Re: [whatwg] should we add beforeload/afterload events to the web platform?
On Jan 10, 2012, at 10:59 AM, Boris Zbarsky wrote: On 1/10/12 1:54 PM, Darin Adler wrote: On Jan 10, 2012, at 8:43 AM, Boris Zbarsky wrote: So in WebKit this event is only good for preventing _processing_ of the data in the page (e.g. preventing the script from executing when the target is ascript) but not much use for preventing loads, even if some people seem to think that it is. That’s a bug in the current implementation that we are working on fixing. If I might ask, how do you plan to fix it without at least breaking speculative loads in the presence of beforeload handlers? I just don't see how WebKit's current event setup can be used without doing that, because it requires the relevant DOM node to exist. Good question, and I don’t know. I’ll try to find someone who does know. -- Darin
Re: [whatwg] should we add beforeload/afterload events to the web platform?
On Mon, Jan 9, 2012 at 10:02 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 1/10/12 12:48 AM, Tantek Çelik wrote: Should 'beforeload'/'afterload' be explicitly specified and added to the web platform? Outside of extensions, what are the use cases? Can they usefully labor under restrictions like knowing the URI to be loaded but not the context it's being loaded in? AdBlock apparently can in at least some cases, yes? Some web sites use beforeload to monitor for mixed content vulnerabilities. In some cases, they block the load, and in other cases they allow it (e.g., because they're working to clean up their mixed content bugs). Adam
[whatwg] should we add beforeload/afterload events to the web platform?
WebKit supports a 'beforeload' event [1] which is supported in shipping Safari and Chrome[2] and apparently has (enabled) the real-world use-cases of: 1. Performance. Reducing bandwidth use / HTTP requests, e.g. AdBlock extension[2] 2. Clientside transformations, e.g. Mobify[3] As might be expected, there is at least one use-case for a complementary 'afterload' event: 1. Downloadable fonts - people who want to use custom fonts for drawing in the canvas element need to know when a font has loaded. 'afterload' seems like a good way to know that, since it happens as a side effect of actually using it and fonts don't have an explicit load API like images do.[4] Safari and Chrome have already shipped 'beforeload', and Mozilla is strongly considering implementing 'beforeload' and 'afterload'.[4] Should 'beforeload'/'afterload' be explicitly specified and added to the web platform? Rather than attempt to provide a specific detailed design at this point, I'd prefer to ask for the list's consideration/discussion, and leave detailed specification of the two events to the editor. Thanks, Tantek [1] http://developer.apple.com/library/safari/documentation/Tools/Conceptual/SafariExtensionGuide/MessagesandProxies/MessagesandProxies.html [2] http://google-chrome-browser.com/tags/beforeload [3] http://mobify.com/static/talks/client-side-transformations.html#27 [4] https://bugzilla.mozilla.org/show_bug.cgi?id=715695#c9 -- http://tantek.com/ - I made an HTML5 tutorial! http://tantek.com/html5
Re: [whatwg] should we add beforeload/afterload events to the web platform?
On 1/10/12 12:48 AM, Tantek Çelik wrote: Mozilla is strongly considering implementing 'beforeload' and 'afterload'.[4] It's more like one person in a Mozilla bug has suggested that it be implemented, while others, myself included, are a bit skeptical. The devil, of course, is in the details; if this event is specified very carefully it might simply slow down pageload a bit, more so as browsers introduce more parallelism because background threads or processes that might be able to perform the load will have to block on the main page JS thread to handle the event first. If done carelessly (e.g. the event target is the node the load is associated with), it'll be a pretty large slowdown. For example, that approach precludes the sort of speculative parsers UAs use nowadays to deal with having to block parsing on script tags. Should 'beforeload'/'afterload' be explicitly specified and added to the web platform? Outside of extensions, what are the use cases? Can they usefully labor under restrictions like knowing the URI to be loaded but not the context it's being loaded in? AdBlock apparently can in at least some cases, yes? I'd like to understand the client-side transformation use-case better, in particular. What is it really trying to do? -Boris
Re: [whatwg] should we add beforeload/afterload events to the web platform?
On 1/10/12 1:02 AM, Boris Zbarsky wrote: I'd like to understand the client-side transformation use-case better, in particular. What is it really trying to do? OK, I got more context on this. The goal of the client-side transformation case is effectively do something like what one can do with XSLT in XML. Specifically: 1) Don't actually render the HTML coming down the pipe. This includes not doing any loads from it, but also includes not actually doing layout, not running scripts in the page, etc. 2) Bind some sort of transformation to it (in this case a script that runs on the DOM or on the original source, depending). 3) Render the result of that transformation. mobify uses beforeload for a poor-man's approximation to #1: it can block loads, but not prevent execution of inline scripts or prevent layout (short of adding display:none styles to the page itself). Then it does various other hackery to do #2 and #3. I agree that this is a good use case to solve, but beforeload doesn't really solve it. We should provide a better solution. For the rest, I just checked and WebKit does set the event target to the node triggering the load, at least for script nodes. I can nearly guarantee that we would NOT be willing to do that in Gecko even if we were convinced that the 'beforeload' event is a good idea in the first place. The 'afterload' event doesn't have the same sort of problems, of course; it's no different from existing 'load' events in cases when it's fired on an element. Whether it provides a good solution for other cases, I haven't had a chance to think through yet. -Boris
Re: [whatwg] should we add beforeload/afterload events to the web platform?
On Tue, Jan 10, 2012 at 7:48 AM, Tantek Çelik tan...@cs.stanford.edu wrote: 1. Performance. Reducing bandwidth use / HTTP requests, e.g. AdBlock extension[2] Extension use cases don't require an API exposed to Web content, though. Furthermore, IE9 has a built content blocking rule engine and Firefox has a de facto dominant rule engine for year even though it has been shipped separately (AdBlock Plus). Maybe instead of exposing arbitrary programmability for content blocking, other browsers should follow IE9 and offer a built-in rule engine for content blocking instead of letting extensions run arbitrary JS to inspect every load. 2. Clientside transformations, e.g. Mobify[3] There's already an easier cross-browser way to deactivate an HTML page and use its source as input to a program: document.write(plaintext style='display:none;'); (This gives you source to work with instead of a DOM, but you can explicitly parse the source to a DOM.) Anyway, I'd rather see mobile adaptations be based on CSS instead of everyone shipping a bunch of JS to the client munge the page in ways that foil all optimizations that browsers do for regular page loads. As might be expected, there is at least one use-case for a complementary 'afterload' event: 1. Downloadable fonts - people who want to use custom fonts for drawing in the canvas element need to know when a font has loaded. 'afterload' seems like a good way to know that, since it happens as a side effect of actually using it and fonts don't have an explicit load API like images do.[4] It seems like fonts should have an API for listening when they become available, yes. Should 'beforeload'/'afterload' be explicitly specified and added to the web platform? I'm worried about the interaction with speculative loading. Right now, Gecko is more aggressive than WebKit about speculative loading. I don't want to make Gecko less aggressive about speculative loading in order to fire beforeload exactly at the points where WebKit fires them. I'm even worried about exposing resource load decisions to the main thread at all. Right now in Gecko, the HTML parser sees the data on a non-main thread. Networking runs on another non-main thread. Even though right now speculative loads travel from the parser thread to networking library via the main thread, it would be unfortunate to constrain the design so that future versions of Gecko couldn't communicate speculative loads directly from the parser thread to the networking thread without waiting on the main-thread event loop in between. (In this kind of design, a built-in content blocking rule engine would be nicer than letting extensions be involved in non-main threads.) -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
