[whatwg] [URL] Resolving against the base of the current page
http://url.spec.whatwg.org/
How would I create a URL relative to the page, but taking into account
base (and anything else that may affect relative urls on the page)?
It feels like the 2nd constructor parameter should default to the page's
base url, and you could pass window.location.href in if you wanted to
override base.
So:
img src=cat.gif
new URL('cat.gif').href == document.querySelector('img').src;
And:
if (new URL('cat.gif').href !== new URL('cat.gif', location.href).href) {
// something is modifying the base url
}
Jake.
Re: [whatwg] Script preloading
On Wednesday, 10 July 2013, Kyle Simpson wrote:
You know, I keep relying on the fact that the body of work on this topic for
almost 3 years … I've spent more time over the last 4+ years obsessing on
script loading than any other developer … I am saying the same things I've
been saying for 3 years.
This is the open web, length of service does not excuse anyone from
reasoning and evidence.
But sure, I'll say them, AGAIN, because now someone wants to hear them again.
If you feel you're repeating content from elsewhere, you could have
linked to it (hurrah for the web)! If you hadn't compiled your
use-cases requirements in one place before, then excellent, you have
now. You can link to this in future.
I doubt anyone is going to read this crazy long message and actually read all
these, but I'll put them here nonetheless.
I am reading this, and I will show how Hixie's #1 solution (plus the
minor additions I suggested) meet your use-cases. For others reading
I'll also detail the use-case in a complete but succinct way.
1. Premise: I'm the author of a popular and wide-spread used script loader.
It's a general utility that's used in tens of thousands of different sites,
under a myriad of conditions and in different ways, and in a huge swath of
different browsers and devices. I need the ability inside this general
utility to do consistent, 100% reliable, predictable script loading for
sites, without making ANY assumptions about the site/markup/environment
itself. I need to be as unintrusive as possible. It needs to be totally
agnostic to where it's used.
Use-case: Script loaders such as LabJS should continue to work at
least as well as they do now.
As you've stated previously, LabJS is complete in that it continues to
work without much development effort. LabJS could either improve by
using the new feature, or not, and continue as is.
2. Premise: I need a solution for script (pre)loading that works not JUST in
markup at page-load time, but in on-demand scenarios long after page-load,
where markup is irrelevant. Markup-only solutions that ignore on-demand
loading are insufficient, because I have cases where I load stuff on-demand.
Lots of cases. Bookmarklets, third-party widgets, on-demand loading of heavy
resources that I only want to pay the download penalty for if the user
actually goes to a part of the page that needs it (like a tab set, for
instance). In fact, most of the code I write ends up in the on-demand world.
That's why I care so much about it.
Use-case: I want to preload scripts that execute straight away, such
as social media scripts, and defer their execution. The need for the
script may be determined by script (eg feature detection), so you need
to be able to trigger preload via script. Executing the script should
be optional (user may not interact with the button).
(this is actually many of the use-cases in this email rolled into one,
to save on reading and repetition)
Anyway, here's how you'd preload two scripts and have them execute in
order some time later (but not be held up by other scripts like
async=false). If the script have more flexibility in terms of
execution order, you can specify that and get better performance.
link rel=subresource href=path/to/script.js class=preload
link rel=subresource href=path/to/another-script.js class=preload
script
// scripts are preloading at this point
function loadScripts(done) {
var toLoad = document.querySelectorAll('.preload');
var script;
for (var i = 0, len = toLoad.length; i len; i++) {
script = document.createElement('script');
// depend on the previous script
if (i) script.dependencies = 'script[src=' + toLoad[i-1].href + ']';
script.src = toLoad[i].href;
document.head.appendChild(script);
}
script.onload = done;
}
loadScripts(function() {
// scripts are ready!
});
/script
The without-markup solution is the same as above, but the
link[rel=subresource] elements are created conditionally with JS.
link[rel=subresource] is the right solution for preloading, it's what
it's for and it works on more than just script. If there are issues
with this cache headers, there shouldn't be, let's fix that.
3. Premise: this is NOT just about deferring parsing. Some people have argued
that parsing is the expensive part. Maybe it is (on mobile), maybe not.
Frankly, I don't care. What I care about is deferring EXECUTION, not parsing
(parsing can happen after-preload or before-execution, or anywhere in
between, matters not to me). Why? Because there's still lots of legacy
content on the web that has side-effects when it runs. I need a way to
prevent those side effects through my script loading, NOT just hoping someday
they rewrite their code so that it has no side effects upon execution.
Use-case: this is just the previous use-case with more words.
See above. Although most libraries etc defer major execution to
function calls
Re: [whatwg] Script preloading
On 10 July 2013 17:37, Jake Archibald jaffathec...@gmail.com wrote: On 10 July 2013 16:39, Kyle Simpson get...@gmail.com wrote: I personally don't care about scripts being discoverable by pre-parsers. I have done testing and am not convinced that something appearing earlier (in markup) leads to better performance than allowing my script loading logic to load things when I want, and just relying on the browser to do that as quickly as possible. Pre-parsers can kick in before a page is actually opened, but script cannot be executed. Let me dig up some numbers on the benefits of this report back. Here it is: https://plus.sandbox.google.com/+IlyaGrigorik/posts/8AwRUE7wqAE ~20% improvement.
Re: [whatwg] [URL] Resolving against the base of the current page
On Thu, Jul 11, 2013 at 7:56 AM, Jake Archibald jaffathec...@gmail.com wrote:
http://url.spec.whatwg.org/
How would I create a URL relative to the page, but taking into account
base (and anything else that may affect relative urls on the page)?
document.baseURI?
It feels like the 2nd constructor parameter should default to the page's
base url, and you could pass window.location.href in if you wanted to
override base.
So:
img src=cat.gif
new URL('cat.gif').href == document.querySelector('img').src;
And:
if (new URL('cat.gif').href !== new URL('cat.gif', location.href).href) {
// something is modifying the base url
}
I think I'd prefer consistent results for the constructor across
scripts if you omit a base URL.
--
http://annevankesteren.nl/
Re: [whatwg] [URL] Resolving against the base of the current page
On 11 July 2013 15:59, Anne van Kesteren ann...@annevk.nl wrote: On Thu, Jul 11, 2013 at 7:56 AM, Jake Archibald jaffathec...@gmail.com wrote: http://url.spec.whatwg.org/ How would I create a URL relative to the page, but taking into account base (and anything else that may affect relative urls on the page)? document.baseURI? I am an idiot please delete me from the internet. Case closed.
Re: [whatwg] Script preloading
Here's the Plus URL without the googler cruft: https://plus.google.com/u/1/+IlyaGrigorik/posts/8AwRUE7wqAE On Thu, Jul 11, 2013 at 3:47 PM, Jake Archibald jaffathec...@gmail.comwrote: On 10 July 2013 17:37, Jake Archibald jaffathec...@gmail.com wrote: On 10 July 2013 16:39, Kyle Simpson get...@gmail.com wrote: I personally don't care about scripts being discoverable by pre-parsers. I have done testing and am not convinced that something appearing earlier (in markup) leads to better performance than allowing my script loading logic to load things when I want, and just relying on the browser to do that as quickly as possible. Pre-parsers can kick in before a page is actually opened, but script cannot be executed. Let me dig up some numbers on the benefits of this report back. Here it is: https://plus.sandbox.google.com/+IlyaGrigorik/posts/8AwRUE7wqAE ~20% improvement.
Re: [whatwg] Adding features needed for WebGL to ImageBitmap
On Wed, Jul 10, 2013 at 9:37 PM, Rik Cabanier caban...@gmail.com wrote: On Wed, Jul 10, 2013 at 5:07 PM, Ian Hickson i...@hixie.ch wrote: On Wed, 10 Jul 2013, Kenneth Russell wrote: ImageBitmap can cleanly address all of the desired use cases simply by adding an optional dictionary of options. I don't think that's true. The options only make sense for WebGL -- flipping which pixel is the first pixel, for example, doesn't do anything to 2D canvas, which works at a higher level. (The other two options don't make much sense to me even for GL. If you don't want a color space, don't set one. If you don't want an alpha channel, don't set one. You control the image, after all.) I suspect that in the future some options will be desired even for the 2D canvas use case, and having the dictionary already specified will make that easier. There is no need to invent a new primitive and means of loading it. If options make sense for 2D canvas, then having ImageBitmap options would make sense, sure. yeah, these options seem a bit puzzling. From the spec: An ImageBitmap object represents a bitmap image that can be painted to a canvas without undue latency. note: The exact judgement of what is undue latency of this is left up to the implementer, but in general if making use of the bitmap requires network I/O, or even local disk I/O, then the latency is probably undue; whereas if it only requires a blocking read from a GPU or system RAM, the latency is probably acceptable. It seems that people see the imageBitmap as something that doesn't just represent in-memory pixels but that those pixels are also preprocessed so they can be drawn quickly. The latter is not in the spec. I think authors will be very confused by these options. What would it mean to pass a non-premultiplied ImageBitmap to a canvas object? Would the browser have to add code to support it or is it illegal? Maybe it's easier to add an optional parameter to createImageBitmap to signal if the ImageBitmap is for WebGL or for Canvas and disallow a Canvas ImageBitmap in WebGL and vice versa. You are implying a pretty heavy imposition as to what constitutes undue latency. I think the spec should stay away from forcing implementations to pin decoded image buffers in RAM (or on the GPU), so that the browser may have some latitude in preventing out of memory exceptions. In its current form, the spec implies that it would be acceptable for an implementation to discard the decoded buffer and only retain the resource in encoded form in RAM. Do we really need to make further optimizations explicit? For example, an implementation could prepare the image data for use with WebGL the first time it is drawn to WebGL, and keep it cached in that state. If the same ImageBitmap is subsequently drawn to a 2D canvas, then it would use the non-WebGLified copy, which may be cached, or may require re-decoding the image. No big deal. Fundamental question: Do we really need the caller to be able to specify what treatments need to be applied to prepare an image for WebGL, or is it always possible to figure that out automatically? As long as there is a way to do it automatically, shouldn't we avoid adding complexity to the API?
Re: [whatwg] Adding features needed for WebGL to ImageBitmap
On Thu, Jul 11, 2013 at 8:29 AM, Justin Novosad ju...@google.com wrote: On Wed, Jul 10, 2013 at 9:37 PM, Rik Cabanier caban...@gmail.com wrote: On Wed, Jul 10, 2013 at 5:07 PM, Ian Hickson i...@hixie.ch wrote: On Wed, 10 Jul 2013, Kenneth Russell wrote: ImageBitmap can cleanly address all of the desired use cases simply by adding an optional dictionary of options. I don't think that's true. The options only make sense for WebGL -- flipping which pixel is the first pixel, for example, doesn't do anything to 2D canvas, which works at a higher level. (The other two options don't make much sense to me even for GL. If you don't want a color space, don't set one. If you don't want an alpha channel, don't set one. You control the image, after all.) I suspect that in the future some options will be desired even for the 2D canvas use case, and having the dictionary already specified will make that easier. There is no need to invent a new primitive and means of loading it. If options make sense for 2D canvas, then having ImageBitmap options would make sense, sure. yeah, these options seem a bit puzzling. From the spec: An ImageBitmap object represents a bitmap image that can be painted to a canvas without undue latency. note: The exact judgement of what is undue latency of this is left up to the implementer, but in general if making use of the bitmap requires network I/O, or even local disk I/O, then the latency is probably undue; whereas if it only requires a blocking read from a GPU or system RAM, the latency is probably acceptable. It seems that people see the imageBitmap as something that doesn't just represent in-memory pixels but that those pixels are also preprocessed so they can be drawn quickly. The latter is not in the spec. I think authors will be very confused by these options. What would it mean to pass a non-premultiplied ImageBitmap to a canvas object? Would the browser have to add code to support it or is it illegal? Maybe it's easier to add an optional parameter to createImageBitmap to signal if the ImageBitmap is for WebGL or for Canvas and disallow a Canvas ImageBitmap in WebGL and vice versa. You are implying a pretty heavy imposition as to what constitutes undue latency. I think the spec should stay away from forcing implementations to pin decoded image buffers in RAM (or on the GPU), so that the browser may have some latitude in preventing out of memory exceptions. In its current form, the spec implies that it would be acceptable for an implementation to discard the decoded buffer and only retain the resource in encoded form in RAM. Do we really need to make further optimizations explicit? For example, an implementation could prepare the image data for use with WebGL the first time it is drawn to WebGL, and keep it cached in that state. If the same ImageBitmap is subsequently drawn to a 2D canvas, then it would use the non-WebGLified copy, which may be cached, or may require re-decoding the image. No big deal. Doesn't that double the memory requirement? Also, since bitmaps will need to be prepared for either WebGL or Canvas 2d, won't that introduce undue latency? Fundamental question: Do we really need the caller to be able to specify what treatments need to be applied to prepare an image for WebGL, or is it always possible to figure that out automatically? As long as there is a way to do it automatically, shouldn't we avoid adding complexity to the API? I agree. However, since Gregg was asking for this features, he must believe there's a need for this feature.
Re: [whatwg] Script preloading
On Thu, Jul 11, 2013 at 9:41 PM, Kyle Simpson get...@gmail.com wrote: I'm still going to respond, in detail, with code comparisons, to Jake's suggestions that the other proposals besides mine handle all my stated use-cases. However, before I do that, just to document for posterity, I just recalled another use-case which is a feature very frequently requested of LABjs, but is impossible with the current web platform. It's so common, I'm not sure why I forgot it in the other list, except perhaps sheer exhaustion. 12: Use-case: you have a string of scripts (A.js, B.js, and C.js) loading which constitute a dependency chain. A must run before B, which must run before C. However, if you detect an error in loading, you stop the rest of the executions (and preferably loading too!), since clearly dependencies will fail for further scripts, and the errors will just unnecessarily clutter the developer console log making it harder to debug. How is this any different from the case today when script elements are fetched and run in the situation where one 404's? And why is the fix not a stop on first script error devtools option rather than a change to the intrinsics for loading? This is the usual recourse for most debuggers. Or are you saying we should be able to detect (via HTTP status code? some other mechanism?) that a script load as failed before we even attempt to run the code which might depend on it? I'm unsure how any of this is apropos to the debate at hand. Changes to this proposal seem entirely the wrong place to be dealing with this sort of failure/recovery issue. One reason developers want this ability to pause/abort part of a chain of dependencies is the idea of graceful recovery, where they could re-try the failed download again a few times, or perhaps try fallback URLs for a script, etc. In any case, the desire is to stop C from running if B fails to load, for whatever reason. In fact, some developers have even requested to be able to stop the chain and prevent further executions if the script loads, but there's some compile-time syntax error or run-time error that happens during the execution. For them, it's not enough for B to simply finish loading successfully, but that it must fully execute without error. Generally speaking, separate JS files are treated as separate programs and are NOT prevented from executing if there's an error running a previous file. These developer requests are that they'd like script loaders to be able to give them that stop the presses! sort of error handling which they currently do not have. From my observation of Jake's proposed code, the former part of this use-case seems possible, assuming `dependencies` would fail to match on a script which resulted in a load error (4xx, 5xx). There would be the extra complication that the script loader might switch to an alternate fallback URL for a script, in which case it'd have to go find any script elements waiting on the previous (failed) URL and update their `dependencies` list to the new URL. However, it's less clear to me if `dependencies` would fail a match on a script that loaded successfully and started trying to run, but had some uncaught error happen during compile or execute? If so, fine. Would that also mean that if the script loader were to retry (either with same or alternate URL) B, and that were to succeed finally, then C would then recognize that eventual success (in spite of previous failures) and run as expected? If so, fine. If however `dependencies` can't be made sensitive to unerrored-execution, and there's no other event that a script loader can intercept **between** B and C and have a chance to stop C from running (yet), then I think this would be a use-case not fully served by what I've seen so far. Also, there's the question of what it would mean/tak to stop C from running (yet). Perhaps the suggestion is to remove C's script element from the DOM for the time being? Would that actually be sufficient to prevent it from executing (even if it had already finished loading and was just paused waiting)? Or perhaps the suggestion would be to temporarily change C's `dependencies` list to have some selector in it that's made up and not possibly fulfilled, like a made up/impossible script URL, so that C remains paused, until a later time when the script loader can come back and set the dependencies list back to something sane so that C can resume? --Kyle
Re: [whatwg] Script preloading
How is this any different from the case today when script elements are fetched and run in the situation where one 404's? Right now, without any script loader, AFAICT, if A loads fine, B 404's or 500's, and C loads fine, both A and C will run, and usually C will have lots of cascading errors because it assumes B ran when it clearly didn't. What I'm saying is that quite a few developers have repeatedly asked for LABjs to provide some relief to that, because they would like to be able to have code-driven logic that tries to gracefully handle such an error. As I said, some developers have expressed the desire to have a script loader be able to re-try a failed script load a few times. Others have expressed the desire to have alternate fallback URL(s) if a script fails to load at its primary location. The point is, normal script tags don't let devs do that AT ALL, and when they want to do such things, they hope that a script loader could give them that capability. Since LABjs currently relies on script elements in pretty much all cases, LABjs can't give them what they want. As far as I'm concerned, this is absolutely a *candidate* for a perfect silver-bullet next-generation script loading mechanism that handles all the complex use-cases under discussion thus far under discussion. And why is the fix not a stop on first script error devtools option rather than a change to the intrinsics for loading? This is the usual recourse for most debuggers. As stated, this isn't as much about developers doing things in dev-mode, it's about them wanting to have more robust loading logic in their production installations that is capable of doing things like script-load-retries or script-load-fallback-URLs. Certainly developers asking LABjs for this don't care nearly as much whether other developers can effectively deal with the issue using their devtoosl as they care that their production website in front of end-users has the ability to respond more robustly, if they care that much in the first place. Or are you saying we should be able to detect (via HTTP status code? some other mechanism?) that a script load as failed before we even attempt to run the code which might depend on it? I was suggesting if we're inventing a new mechanism called `depends` as Jake has suggested, it would be nice if that new mechanism was made sensitive to things like did the script load successfully (non 4xx/5xx), and even better if it could also be sensitive to things like the script load successfully, but was there an uncaught error thrown during its main execution? The more sensitive the mechanism is, the more capable it would be to handling the use-cases these developers care about. I'm unsure how any of this is apropos to the debate at hand. Changes to this proposal seem entirely the wrong place to be dealing with this sort of failure/recovery issue. Why so hostile? Isn't it quite apropos/germane to discuss HERE what real-world developers want to do (and cannot do currently!) in their code as it relates to script loading? I exhaustively listed out 11 other use-cases of things I care about, as a script loader author/maintainer. Are none of those use-cases apropos? Then I noted an additional 12th use-case here that I may not personally care as much about, but dozens of times developers have filed issues against LABjs begging/insisting for. It appears that some people care enough about production loading robustness that they go to extraordinary efforts in their code to detect and respond to such conditions. I felt like those many requests to LABjs (and I'm sure other script loaders get similar requests) was evidence enough that there's a valid use-case to consider and I was just bringing it up for such consideration. --Kyle
Re: [whatwg] Script preloading
I am interested to see how the above use-cases would be met in your counter proposal(s) to see if it would be simpler/faster. If LabJS is a requirement, it must be factored in as a unit of complexity and load-step. Please do this rather than declare anything to be insufficient without reasoning. It's gonna take a lot of time to write proof-of-concept code for all the different nuances and use-cases I've brought up. I'm presenting 2 here. There's more to come. Unfortunately, Jake made a number of simplifying assumptions, or simply missed various nuances, in his attempt to combine/reduce/restate my use-case list. I'm not ascribing any ill-will to that, but just pointing out that it's not nearly as easy as his list might suggest. I've spent some time trying to put together a first set of code comparisons between the `script preload` proposal I've put forth and the `link rel=subresource` + `script dependencies=..` proposal Jake is advocating. This is by no means an exhaustive comparison or even nearly stating the many issues I forsee, but it starts the discussion with actual code instead of theoretical concepts. https://gist.github.com/getify/5976429 There's lots of code comments in there to explain intended semantics, outstanding questions/issues, etc. Some observations/clarifications: * ex1-getify.js is my attempt at creating a simple `loadScripts()` script loader that loads scripts in parallel, but executes them strictly in request order, serially. -- ONE KEY NOTE: my implementation accomplishes my use case #11 quite easily, in that it doesn't start executing any of the scripts in a group until ALL the scripts are finished preloading, thus minimizing any gaps/delays between them running. I'm able to do this easily because every script fires a preload event, so it's trivial to know when all such events have fired as my clue on when to start execution. * ex1-jaffathecake.js is my attempt at doing something as close as possible using Jake's proposed way. I've asked for his feedback on this code, so until he has a chance to feedback, take it with a grain of salt. In any case, the code is certainly simpler, but it's missing a KEY COMPONENT: it's NOT able to assure what my script loader code does. That is, a.js might run long before b.js runs, whereas in my implementation, there should be almost no gaps, because a.js doesn't run until b.js is loaded and ready to go. Jake suggested a hack to address this use-case which is based on the idea of hiding the whole page while scripts load with gaps in between. This hack is not only terribly ugly, but it also misses a big point of my motivation for that use-case. The point is NOT can we hide stuff visually, it's can we make sure stuff doesn't run until EVERYTHING is ready to run. Moreover, as I note in the code comments, it is impossible/impractical for a generalized script loader to be able to determine all or parts of a page that it should hide, and under what conditions. The script loader is agnostic of what it's loading, and it certainly is supposed to be as unobtrusive to the hosting page as possible, so it's out of the question to consider that a script loader would go and do nuclear-level things like hiding the document element. The key thing that's missing in Jake's proposal that's necessary to address this use-case is that there's no way to be notified that all the scripts have finished pre-loading. Instead, his approach obfuscates when things finish loading by simply letting the script element internally listen for loads of its dependencies. This is what I mean when I keep saying chicken-and-the-egg, because I want to know everything's finished preloading BEFORE I start the execution cursor, but in Jake's world, I can't know stuff is finished loading until after I observe that it's running. * ex2-getify.js is a more complex script loader, that takes into account the ability to have sub-groups of scripts, where within the sub-group, ASAP execution order is desired, and serial-request-order execution order is desired across the various sub-groups. Simply stated: All of C, D, E, and F scripts load in parallel. When it comes to execution, C.js runs, then a sub-group of D.js and E.js will run, where within the sub-group, either D or E runs first, ASAP (they don't block each other), and then when both have run, finally, F.js executes. This scenario is quite common: I load jquery.js, then I load 4 jquery plugins (which are independent), then I load my page's app.js code runs. jquery.js is the firs to execute, then the 4 plugins run in ASAP order, then when they're all done, finally my app.js code executes. Also, this more complex script loader listens for `script.onerror` events, and if it detects one, it aborts any of the rest of the execution. Any such error handling is trivial in my loader, because I am always fully in control over which script is loading at any given time. *
[whatwg] Default draggable elements
Regarding elements that are draggable by default: The spec says: img elements and a elements with an href attribute have their draggable attribute set to true by default. I've noticed that in IE and Firefox, an object tag embedding an image also defaults to draggable. It does not default to draggable in Blink/WebKit. Should the spec be amended to include this special case? Blink/WebKit also make input[image] elements default to draggable (no other browser does this). I'm not really sure why, but can I confirm that this won't be in the spec? I'd like to remove it from Blink at least. Daniel
Re: [whatwg] Script preloading
On browser preloading: There seems to an inherent conflict between 'indiscriminate' Pre-parsers/ PreloadScanner and responsive design for mobile. Responsive designs mostly implies that everything needed for a full screen desktop is provided in markup to all devices. Isn't the Pre-parsers/PreloadScanner's inability to take into account the display[none:yes] factor be a potential significant blow to 'mobile' performance. Use case: What if I have a set of images in an element set as display:none; only designated to be show on desktop or tablet screens and not on mobile phone? What if I have an inline script in that node? Isn't the PreloadScanner loading a lot more than I need, a problem here? In addition to the need to preload, with responsive design taken into consideration, and for lack of not being able to remove part of the body before the browser parses the document. I see an increasing potential need for the ability to indicate to the browser not to load selective assets before DOMReady and suppress such preload. Bruno On 7/11/13 8:23 AM, Alex Russell slightly...@google.com wrote: Here's the Plus URL without the googler cruft: https://plus.google.com/u/1/+IlyaGrigorik/posts/8AwRUE7wqAE On Thu, Jul 11, 2013 at 3:47 PM, Jake Archibald jaffathec...@gmail.comwrote: On 10 July 2013 17:37, Jake Archibald jaffathec...@gmail.com wrote: On 10 July 2013 16:39, Kyle Simpson get...@gmail.com wrote: I personally don't care about scripts being discoverable by pre-parsers. I have done testing and am not convinced that something appearing earlier (in markup) leads to better performance than allowing my script loading logic to load things when I want, and just relying on the browser to do that as quickly as possible. Pre-parsers can kick in before a page is actually opened, but script cannot be executed. Let me dig up some numbers on the benefits of this report back. Here it is: https://plus.sandbox.google.com/+IlyaGrigorik/posts/8AwRUE7wqAE ~20% improvement.
Re: [whatwg] Resource loading in browsing context-less Documents
On Wed, 19 Dec 2012, Boris Zbarsky wrote: On 12/19/12 12:55 PM, Ian Hickson wrote: On Wed, 19 Dec 2012, Boris Zbarsky wrote: On 12/19/12 12:37 PM, Ian Hickson wrote: Yes, just not an active one. OK. I don't think we want to activate links in unloaded documents, personally That's probably reasonable... Do you have a test case? :-) Not offhand. I could write one if I had to, I guess... do I have to? ;) You don't. http://www.hixie.ch/tests/adhoc/html/navigation/iframe/002.html I've updated the spec to check the document's active state, not the browsing context presence. Also for area.click(), input type=image.click(), input type=submit.click(), input type=reset.click(), and button.click(), and for menuitems that point to those elements. Let me know if I missed anything. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
