Re: [whatwg] URL: file URL C| quirk
On 7/8/2013 8:33 PM, Alex Bishop wrote: I imagine that it’s an early Netscape implementation detail that escaped into the wild. Given that I can still remember pipes in file URLs 15+ years later, I would not be surprised if other people rely on this working. I am certain that we must continue to support this in Firefox in some cases (URLs passed in on the command line or via DDE). I am not sure what we'd break by removing support for it for URLs in general. Unless there is a compelling reason not to support this in general, I'd like to keep it. --BDS
Re: [whatwg] Adding 2D Canvas features (Was: Grouping in canvas 2d)
Conversely, if it helps to bring the spec closer to the implementations, one thing we do not intend to implement in Chrome is the automatic high-DPI canvas scaling (ie., auto-doubling of backing stores, getImageDataHD(), putImageDataHD(), etc). I believe Apple has also announced that they are dropping support for this in Safari 7. Stephen On Fri, Jun 28, 2013 at 3:30 PM, Tom Wiltzius wiltz...@chromium.org wrote: The only major Canvas2D features being actively developed in Chromium right now are: - having a canvas context alpha attribute - text decoration - compositing and blending - canvas access in workers (easily referenced from http://www.chromestatus.com/features) It is concerning to me that the list of other unimplemented features that aren't being worked on could block the standardization of the above (all of which have been discussed on this list at one point, but not all of which are in the spec yet). How can we help reconcile this discrepancy? On Fri, Jun 14, 2013 at 11:54 AM, Rik Cabanier caban...@gmail.com wrote: I agree that hit regions should be high on the priority list. They've been in the spec for a while and are absolutely required for accessibility. I will try to follow up on this feature with the browsers. We recently added a basic Path object to WebKit and I know that mozilla is looking at the path object. At this point, I wouldn't ask to add begin/endLayer to the spec. Instead, we will talk to the browser vendors and work on implementing the feature. Just putting it in the spec is not enough to get an implementation... On Fri, Jun 14, 2013 at 10:42 AM, Ian Hickson i...@hixie.ch wrote: On Fri, 14 Jun 2013, Brian Salomon wrote: As an implementor, we would prefer the layer approach. This would have lower overhead in Chromium/Skia. We can make better decisions about caching and deferred rendering. It also seems like a really handy API for devs, especially the ability to inherit the graphics state. Would the spec have anything to say about beginLayer()/endLayer() balancing, especially with respect to RAF? I have no ojection to adding this to the spec, but right now the spec has a bunch of features that aren't implemented, and there's a long list of other features people want that aren't yet specced. I'm very hesitant to get the spec further and further away from implementations. For example, here are some of the bug numbers for canvas feature requests: 11399 canvas Locking individual color channels (e.g. drawing to alpha only) 21835 canvas Path object should have a way to add paths keeping only the union given a fill rule 21939 canvas Path objects would be much more useful if their individual commands (moveTo, lineTo, etc.) could be inspected from JavaScript [...] 8794canvas lineWidth = 'hairline' 11739 canvas clearPath() that clears pixels the way clearRect() does, but using a path 9236canvas Detecting the intersection of Path objects 9235canvas perspective transformations 18751 canvas a way to get the coordinate of the last point in a path 21346 canvas Have ImageBitmap expose height and width attributes (Bugs accessible from https://www.w3.org/Bugs/Public/) There's also the printCallback API proposal from Mozilla: http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Sep/0371.html Adding a parameter to drawImage for sprite sheets to avoid bleeding, proposal from Chrome: http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Dec/0088.html Stroke alignment: http://lists.w3.org/Archives/Public/public-whatwg-archive/2010Jul/0238.html Page flipping instead of double buffering: http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Jan/0073.html Inner shadows: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-November/038079.html Plus, as I mentioned, things in the spec that aren't implemented widely: Right now, the things in the spec that aren't widely implemented are the things that were needed for accessibility (hit regions) and the things that are the basis for some of the most-requested features (Paths). I think before we add more features, it's important that we figure out which browsers want to implement which features, and that we start with the highest priority ones. -- Ian Hickson U+1047E)\._.,--,'``. fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Notifications: reviving Notification objects
On Sun, Mar 31, 2013 at 10:33 AM, Anne van Kesteren ann...@annevk.nl wrote:
There are a couple of scenarios http://notifications.spec.whatwg.org/
does not address at the moment.
A) User navigates to chat site. Chat site creates a notification from
a chat with P while the user does something else. User closes chat
site and then navigates to chat site at a later point.
B) Instead of navigating to the chat site at a later point, the user
opens the notification center and clicks the notification.
C) User navigates to chat site at a later point, but with a view that
does not show the chat with P. User then opens the notification center
and clicks the notification.
B and C both require some deeper architectural changes. Some kind of
event page/worker that can be notified as we've been discussing. Once
that is in place we can address those use cases.
A requires being able to get the notifications associated with a
certain site. That can also be useful in case multiple windows are
open of the same site and can help workers and pages coordinate once
we enable notifications in workers.
The idea to address A is:
Notification.get({tag})
which returns a Promise which is fulfilled with an array of
Notification objects for which tag is tag or all Notification objects
if no tag is defined. The objects are origin-scoped. The reason a
promise is used is because getting notifications may be a
cross-process operation.
--
http://annevankesteren.nl/
Re: [whatwg] Adding 2D Canvas features (Was: Grouping in canvas 2d)
Yes, those should be taken out. On Tue, Jul 9, 2013 at 8:40 AM, Stephen White senorbla...@chromium.orgwrote: Conversely, if it helps to bring the spec closer to the implementations, one thing we do not intend to implement in Chrome is the automatic high-DPI canvas scaling (ie., auto-doubling of backing stores, getImageDataHD(), putImageDataHD(), etc). I believe Apple has also announced that they are dropping support for this in Safari 7. Stephen On Fri, Jun 28, 2013 at 3:30 PM, Tom Wiltzius wiltz...@chromium.orgwrote: The only major Canvas2D features being actively developed in Chromium right now are: - having a canvas context alpha attribute - text decoration - compositing and blending - canvas access in workers (easily referenced from http://www.chromestatus.com/features) It is concerning to me that the list of other unimplemented features that aren't being worked on could block the standardization of the above (all of which have been discussed on this list at one point, but not all of which are in the spec yet). How can we help reconcile this discrepancy? On Fri, Jun 14, 2013 at 11:54 AM, Rik Cabanier caban...@gmail.com wrote: I agree that hit regions should be high on the priority list. They've been in the spec for a while and are absolutely required for accessibility. I will try to follow up on this feature with the browsers. We recently added a basic Path object to WebKit and I know that mozilla is looking at the path object. At this point, I wouldn't ask to add begin/endLayer to the spec. Instead, we will talk to the browser vendors and work on implementing the feature. Just putting it in the spec is not enough to get an implementation... On Fri, Jun 14, 2013 at 10:42 AM, Ian Hickson i...@hixie.ch wrote: On Fri, 14 Jun 2013, Brian Salomon wrote: As an implementor, we would prefer the layer approach. This would have lower overhead in Chromium/Skia. We can make better decisions about caching and deferred rendering. It also seems like a really handy API for devs, especially the ability to inherit the graphics state. Would the spec have anything to say about beginLayer()/endLayer() balancing, especially with respect to RAF? I have no ojection to adding this to the spec, but right now the spec has a bunch of features that aren't implemented, and there's a long list of other features people want that aren't yet specced. I'm very hesitant to get the spec further and further away from implementations. For example, here are some of the bug numbers for canvas feature requests: 11399 canvas Locking individual color channels (e.g. drawing to alpha only) 21835 canvas Path object should have a way to add paths keeping only the union given a fill rule 21939 canvas Path objects would be much more useful if their individual commands (moveTo, lineTo, etc.) could be inspected from JavaScript [...] 8794canvas lineWidth = 'hairline' 11739 canvas clearPath() that clears pixels the way clearRect() does, but using a path 9236canvas Detecting the intersection of Path objects 9235canvas perspective transformations 18751 canvas a way to get the coordinate of the last point in a path 21346 canvas Have ImageBitmap expose height and width attributes (Bugs accessible from https://www.w3.org/Bugs/Public/) There's also the printCallback API proposal from Mozilla: http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Sep/0371.html Adding a parameter to drawImage for sprite sheets to avoid bleeding, proposal from Chrome: http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Dec/0088.html Stroke alignment: http://lists.w3.org/Archives/Public/public-whatwg-archive/2010Jul/0238.html Page flipping instead of double buffering: http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Jan/0073.html Inner shadows: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-November/038079.html Plus, as I mentioned, things in the spec that aren't implemented widely: Right now, the things in the spec that aren't widely implemented are the things that were needed for accessibility (hit regions) and the things that are the basis for some of the most-requested features (Paths). I think before we add more features, it's important that we figure out which browsers want to implement which features, and that we start with the highest priority ones. -- Ian Hickson U+1047E)\._.,--,'``. fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] URL: relative file URL starting with c: quirk
On Mon, Jul 8, 2013 at 6:23 PM, Peter Kasting pkast...@google.com wrote: Given how unlikely it is that someone will have registered a scheme handler for the one-character drive letters, the Chrome/IE behavior seems more forgiving and more likely what the author wants, to me. But it also forks the semantics of generic URLs, or at least when the base URL happens to be a file URL. Those kind of exceptions are not exactly ideal. In particular treating an absolute URL as a relative URL under certain circumstances seems bad. -- http://annevankesteren.nl/
Re: [whatwg] URL: relative file URL starting with c: quirk
On Tue, Jul 9, 2013 at 10:57 AM, Anne van Kesteren ann...@annevk.nl wrote: On Mon, Jul 8, 2013 at 6:23 PM, Peter Kasting pkast...@google.com wrote: Given how unlikely it is that someone will have registered a scheme handler for the one-character drive letters, the Chrome/IE behavior seems more forgiving and more likely what the author wants, to me. But it also forks the semantics of generic URLs, or at least when the base URL happens to be a file URL. Those kind of exceptions are not exactly ideal. In particular treating an absolute URL as a relative URL under certain circumstances seems bad. I don't see this as a security risk, and if the behavior is desirable, it seems fairly well-scoped in terms of specifying it. PK
[whatwg] Script preloading
A topic that regularly comes up is script loading.
I sent an e-mail responding to related feedback last year, though it
didn't get any replies to the script loading parts of it:
http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Dec/0221.html
It seems that people want something that:
- Lets them download scripts but not execute them until needed.
- Lets them have multiple interdependent scripts and have the browser
manage their ordering.
- Do all this without having to modify existing scripts.
I must admit to not really understanding these requirements (script
execution can be made more or less free if they are designed to just
expose some functions, for example, and it's trivial to set up a script
dependency mechanism for scripts to run each other in order, and there's
no reason browsers can't parse scripts off the main thread, etc). But
since everyone else seems to think these are issues, let's ignore that.
The proposals I've seen so far for extending the spec's script preloading
mechanisms fall into two categories:
- provide some more control over the mechanisms already there, e.g.
firing events at various times, adding attributes to make the script
loading algorithm work differently, or adding methods to trigger
particular parts of the algorithm under author control.
- provide a layer above the current algorithm that provides strong
semantics, but that doesn't have much impact on the loading algorithm
itself.
I'm very hesitant to do the first of these, because the algorithm is _so_
complicated that adding anything else to it is just going to result in
bugs in browsers. There comes a point where an algorithm just becomes so
hard to accurately test that it's a lost cause.
The second seems more feasible, though.
Would something like this, based on proposals from a variety of people in
the past, work for your needs?
1. Add a dependencies attribute to script that can point to other
scripts to indicate that execution of this script should be delayed
until all other scripts that are (a) earlier in the tree order and (b)
identified by this attribute have executed.
script id=jquery src=jquery.js async/script
script id=shims src=shims.js async/script
script dependencies=shims jquery src=myscript.js async/script
This would download jquery.js, shims.js, and myscript.js ASAP, without
blocking anything else, and would then run jquery.js and shims.js ASAP,
in any order, and then once both have executed, it would execute
myscript.js.
2. Add an whenneeded boolean content attribute, a markNeeded() method,
and an internal is-needed flag (initially false) to the script
element. When a script is about to execute, if its whenneeded=
attribute is set, but its is-needed flag is not, then delay
execution. Calling markNeeded() on a script that has a whenneeded
boolean but that has not executed yet first causes the markNeeded()
method on all the script's dependencies to be called, and then causes
this script to become ready to execute.
script id=jquery src=jquery.js async whenneeded/script
script id=shims src=shims.js async whenneeded/script
script id=myscript dependencies=shims jquery src=myscript.js
async whenneeded/script
This would download jquery.js, shims.js, and myscript.js ASAP, and then
wait for further instructions.
document.getElementById('myscript').markNeeded();
This would then cause the scripts to execute, first jquery.js and
shims.js (in any order), and then myscript.js. If any hadn't finished
downloading yet, it would first wait for that to finish.
(We could make markNeeded() return a promise, too.)
Is there a need for delaying the download of a script as well? (If so, we
could change whenneeded= to have values, like whenneeded=execute vs
whenneeded=download or something.)
Is there something this doesn't handle which it would need to handle?
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Script preloading
This is a long and complicated topic with lots of history. Please bear with the length of my reply. It seems that people want something that: - Lets them download scripts but not execute them until needed. - Lets them have multiple interdependent scripts and have the browser manage their ordering. - Do all this without having to modify existing scripts. I think it's important to note that the primary motivation here is performance. If all I cared about was serial loading (and the performance of that was irrelevant), I could, with today's mechanisms, load one script at a time, only when I was ready to execute it, and if there were multiple scripts, do so in the correct order. The fly in in the ointment is if I need to load multiple scripts at once, specifically if those come from different locations (one is jQuery from the CDN, another is a plugin from my server), and for performance reasons I want these scripts to load in parallel, but their execution order still matters. Now, if THAT was the only concern, the new (well, 2 years old now) `async=false` (or, as I call it, ordered async) mechanism would be enough. But it's not. Because there's only one ordered async queue, which means all such scripts have to go into the same bucket, and it's all or nothing for preserving execution order. What if I want to load jQuery, then I want (in ASAP order) for 4 independent plugins to run? Ordered async will run jQuery, then each plugin in request order, which might make one small plugin wait much longer than it needs to for an earlier plugin. Here, it's a performance issue because a plugin like a calendar widget might not appear and render as early as it could otherwise, because some other non-related plugin is coming from a slow location but was requested first. Very quickly, ordered async starts to not be sufficient for various use-cases. It's like the 75% solution, but the 25% are still a concern, performance wise. I must admit to not really understanding these requirements (script execution can be made more or less free if they are designed to just expose some functions, for example, and it's trivial to set up a script dependency mechanism for scripts to run each other in order, and there's no reason browsers can't parse scripts off the main thread, etc). But since everyone else seems to think these are issues, let's ignore that. In an ideal world, we could tell everyone hey, there's a new mandate, rewrite all your code by XYZ deadline. Kthxbai. That's not how it works. The fact is that the web platform and the browsers move MUCH quicker than legacy content. This is, and always has been, a question of if you think we should just wait around for years and years until every script we care about (but don't control since we didn't author it) gets rewritten, and while that's happening, web performance in this area just can't be addressed? I maintain still that we can and should fix the platform so we have more options than just tough luck. The proposals I've seen so far for extending the spec's script preloading mechanisms fall into two categories: - provide some more control over the mechanisms already there, e.g. firing events at various times, adding attributes to make the script loading algorithm work differently, or adding methods to trigger particular parts of the algorithm under author control. - provide a layer above the current algorithm that provides strong semantics, but that doesn't have much impact on the loading algorithm itself. I'm very hesitant to do the first of these, because the algorithm is _so_ complicated that adding anything else to it is just going to result in bugs in browsers. There comes a point where an algorithm just becomes so hard to accurately test that it's a lost cause. Can you please elaborate on how either of the two prominent proposals that Nicholas Zakas and I detailed years ago here are insufficient in that they fall into your first category? http://wiki.whatwg.org/wiki/Script_Execution_Control My proposal was to standardize what IE4-10 did, which is to start loading a script even if it's not in the DOM, but not execute it until it's in the DOM. Then, you monitor an event to know if one or more scripts have finished this preloading, and then you can decide if and when and in what order to add the corresponding script elements to the DOM to allow execution to proceed. The spec already suggests the core of this: For performance reasons, user agents may start fetching the script as soon as the attribute is set, instead, in the hope that the element will be inserted into the document. Either way, once the element is inserted into the document, the load must have started. If the UA performs such prefetching, but the element is never inserted in the document, or the src attribute is dynamically changed, then the user agent will not execute the script, and the fetching
Re: [whatwg] Script preloading
On 7/9/13, Ian Hickson i...@hixie.ch wrote:
A topic that regularly comes up is script loading.
Yes, for years it has come up.
I jumped on the topic around 2009 here and on comp.lang.javascript to
add the idea about chain of responsibility to this solution.
The chain of responsibility pattern is not new, and some examples
include FilterChain and in Apache ANT. The concept seems to apply well
to this context.
I sent an e-mail responding to related feedback last year, though it
didn't get any replies to the script loading parts of it:
http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Dec/0221.html
It seems that people want something that:
- Lets them download scripts but not execute them until needed.
- Lets them have multiple interdependent scripts and have the browser
manage their ordering.
- Do all this without having to modify existing scripts.
I must admit to not really understanding these requirements (script
execution can be made more or less free if they are designed to just
expose some functions, for example, and it's trivial to set up a script
dependency mechanism for scripts to run each other in order, and there's
no reason browsers can't parse scripts off the main thread, etc). But
That is a good point and it is a good approach.
since everyone else seems to think these are issues, let's ignore that.
The proposals I've seen so far for extending the spec's script preloading
mechanisms fall into two categories:
- provide some more control over the mechanisms already there, e.g.
firing events at various times, adding attributes to make the script
loading algorithm work differently, or adding methods to trigger
particular parts of the algorithm under author control.
- provide a layer above the current algorithm that provides strong
semantics, but that doesn't have much impact on the loading algorithm
itself.
I'm very hesitant to do the first of these, because the algorithm is _so_
complicated that adding anything else to it is just going to result in
bugs in browsers. There comes a point where an algorithm just becomes so
hard to accurately test that it's a lost cause.
The second seems more feasible, though.
Would something like this, based on proposals from a variety of people in
the past, work for your needs?
1. Add a dependencies attribute to script that can point to other
scripts to indicate that execution of this script should be delayed
until all other scripts that are (a) earlier in the tree order and (b)
identified by this attribute have executed.
script id=jquery src=jquery.js async/script
script id=shims src=shims.js async/script
script dependencies=shims jquery src=myscript.js async/script
Why limit depends to be used by only scripts to refer only to other scripts?
If you put link depends=idref on style then stylesheet evaluation
could be deferred, too.
I explained some cases about why this is desirable here:
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-February/018435.html
The test cases I'd posted aren't live, but they did show some
confusion at the time regarding load order of resources. Surety of
misunderstanding seemed to be what caused the idea to be so
offhandedly dismissed.
This would download jquery.js, shims.js, and myscript.js ASAP, without
blocking anything else, and would then run jquery.js and shims.js ASAP,
in any order, and then once both have executed, it would execute
myscript.js.
2. Add an whenneeded boolean content attribute, a markNeeded() method,
A disabled/execute was mentioned here, before:
http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Apr/0158.html
document.getElementById('myscript').markNeeded();
I'd rather call execute() than tell Mark he's needed.
This would then cause the scripts to execute, first jquery.js and
shims.js (in any order), and then myscript.js. If any hadn't finished
downloading yet, it would first wait for that to finish.
(We could make markNeeded() return a promise, too.)
Or use a callback. Blocking on resource loading is bad.
--
Garrett
Twitter: @xkit
personx.tumblr.com
Re: [whatwg] Script preloading
But I'd settle for anything, no matter how complex, as long as it actually solves the many use cases. Your proposed option has potential, as long as the missing event part is addressed. It seems to me that from an IE-perspective, the only missing piece is the event itself. Well, strictly speaking, IE4-10 had a suitable event already, as you surely know. Unfortunately, IE11 has, currently, removed those event handlings, as they are non-standard. I wrote this blog post a few days ago begging the IE11 team to bring them back: http://blog.getify.com/ie11-please-bring-real-script-preloading-back/ I know it was passed on to at least a few of the decision makers there, but I've not heard anything official in response yet. Any update? :) As it stands, the IE version of real preloading is in limbo and in danger of dying, as it's quite neutered without some event. IF we could act quickly enough to standardize some preloading approach, even if that were different than how IE did it before, *maybe* it could make it into IE11 before final release? I dunno. Just one final side note on the above linked-to proposals (Zakas's and mine). Over 2 years ago, I implemented feature-detects in LABjs script loader for both of those proposals. Of course, the `readyState` one actually works in IE4-10 and works beautifully I might add. In head-to-head loading tests I've done from time to time, the IE real preloading mechanism often beats out the good-but-not-great ordered async of the other modern browsers. The `preload` one doesn't currently work of course (it's just dormant code for now), but I thought it to be a sufficiently good enough proposal, and likely enough to eventually happen, that I put in those few lines of code to LABjs, as speculative future-proofing. The LABjs source code uses a feature-detect for the real preloading by looking for the existence of the preload Boolean DOM attribute. After thinking about it for a bit, I'm not sure I understand why that attribute is necessary. I believe the reason that Nicholas suggested that the attribute needed to be there was two-fold: 1) he was concerned about the implicit nature of IE's behavior by sort of indirectly preloading simply by developer non-action (not inserting into the DOM). Adding a positive attribute to a tag to say yes, I want this preload-and-defer-execution behavior was certainly more explicit, and opt-in, and thus maybe more attractive, since it had perhaps less potential to create accidental problems for legacy content or developer ignorance. 2) it makes for a simple/effective feature-detect. :) Whatever mechanism we do have, we need a feature detect for it, obviously. `preload in document.createElement(script)` is nice and clean and semantic. The IE way, I detect by looking at the readyState and noticing its initial value, which was an IE only behavior. Opera was the only other browser to support `script.readyState` (but NOT support the actual preloading concept), but Opera's version of the property has a different initial value. I asked an Opera developer specifically and he asserted that Opera would not ever have an occasion to change that initial value to the same as IE's unless they were also matching IE's preloading behavior. Thus, we avoided (tenuously, in the absence of standards) any false-positives on that feature detect. If I were to only introduce the event handler (onpreload) it seems to address the use cases, but then your 2+ year old dormant code would stay dormant :( I'm not nearly as concerned about dormant code staying dormant forever. I made the judgement call back then that the extra ~100 gzip-bytes were worth it if a future day ever came that it just magically worked. I'd love it, for LABjs' sake, if whatever was standardized was one of the two approaches, either one. But even if we standardized a third option, and I had to change LABjs, that would be FAR BETTER in my mind than never addressing this use case at all, especially in light of IE11 sort of retreating on this topic (either intentionally or not). --Kyle
Re: [whatwg] Script preloading
I just joined the list and glad this subject is brought up. I have been wrestling pretty hard with script loading issues lately. I'd say that having the browser manage script interdependency is probably a bad and cumbersome way to solve these issues. I'll try to explain, talk about the defer approach, as well as critical IE bugs that relate to this very subject. I think one of the reason that people may ask for this Interdependency feature, is due to the weakness of the platform they use, its plugins or the poor management of such script (with often poorly conceived plugins not takign dependency into account), which too often has the approach of loading all scripts at all times regardless of the page context. What's important to keep in mind, is that if you must have the browser managing the interdependency, by association, you also have to manage it at the app/platform level properly in the first place. Which seems awfully redundant... And would probably lead to more page bloat or bad programming habits. As Kyle Simpson said, the primary motivation here is performance. Putting scripts at the bottom, while preserving the scripts order has performance drawbacks. And 'async', while good for independent scripts such as social media apis, is not really a good tools for dependency management. My main issue against using external script loaders like LABjs and others, has always been that if the browser must download a script first, before starting to download the dependencies. It presents a drawback already, for delayed the scripts by the script loader's latency and download time (at least for the first uncached page load) similarly to having scripts at the bottoms. What we truly want is keep the order while loading script in a non-blocking way. Why not simply load all such scripts early in the head with 'defer', which preserves the dependency order as determined by your app. Using 'defer' in head scripts is actually a very good way to preserve script order with non-blocking scripts. And by loading the scripts very early in the head, the possibility of a incurred significant delay of DOMContentLoaded, for an eventual large script not yet downloaded, is minimal to none. In that sense, I think that too much focus has been placed on 'async', with 'defer' having been extremely overlooked as such an adequate method to non-blocking script loading with dependencies preserved. 'defer' after all, is partly designed to guarantees that scripts execute in the order they were specified and be delayed until document.readyState = interactive; I sadly know there is a big hurdle for using 'defer' right now with interdependencies, mainly with this IE9 bug http://bugs.jquery.com/ticket/11310 Debunked in further details here (coincidentally, in part by Kyle Simpson): https://github.com/h5bp/lazyweb-requests/issues/42 And may I get into further IE hate when it comes to the 'interactive' state inconsistencies, by pointing to this very recent bug report I've had to file: https://connect.microsoft.com/IE/feedback/details/792880/document-readystat e-interactive-firing-too-early-misfiring-in-ie11-9-and-10 Or should I beg the question, as to why it took my initiative yesterday after almost a year of the problem being reported by others on github in multiple occasions, to have this looked at so that IE11's final release get it right, or not, who knows... This problem exist since IE7! Is that really the best Microsoft can do? There is something really wrong with the fixing process here. That, or too big of a disconnect between those who test and those who are supposed to fix things. Or it is that developers are too fed up with those bugs, having to find ways around them, to find the energy to report them appropriately? Thankfully, the IE7-9 'defer' bug is has been fixed in IE10. Yet it's likely postponing proper use of 'defer' for another what? 5 years?. Thanks to Microsoft once again for holding the internet back and make our life harder? Is that all we can come up with? I would actually advocate to petition Microsoft to release patches for IE8, IE9 and IE10 for these particular stupid overlooked bugs, which some days honestly make me want to kill myself. I understand that in some areas, older browsers cannot add or remove features to the same major release for good reasons. But it's a real problem if bugs of this kind ( which wouldn't break any site if fixed now), cannot be fixed on older browsers using regular Windows updates. The idea that a browser is set in stone on release, and cannot be touched become a real issue to progress. Aren't those two particular bugs good example of thing that should be fixed and applied along security patches? And not have to wait 5 to 10 years coping with buggy browsers for no good reasons I can think of. I would also strongly favor restoring the previous spec portion of 'defer' which allow to have defer on inline script blocks (i.e. if the src attribute is not present). I don't know
Re: [whatwg] Script preloading
I have been wrestling pretty hard with script loading issues lately. I'd say that having the browser manage script interdependency is probably a bad and cumbersome way to solve these issues. What do you mean by having the browser manage script interdependency? As far as I am aware, this thread and these feature requests are not about the browser managing script interdependencies… in fact, quite the opposite. What we're asking and hoping for is a facility that allows the app code to manage the dependencies and the loading order, while only relying on the browser to do the actual loading for us the way it always has. The only part of that puzzle that's missing is a way to tell the browser to pause between finishing-loading and starting-executing. Asking for such a mechanism has really nothing to do with offloading dependency management to the browser to handle. It's empowering the app code to be more in control, not less. I think one of the reason that people may ask for this Interdependency feature, is due to the weakness of the platform they use, Again, I think you may possibly be misunderstanding the goal of what's being asked for. But I'll agree with you that there's a weakness. The weakness, IMO, is in the web platform itself, in not giving us more fine-grained control over script loading. That is why we keep having this discussion every 6 months or so for the least several years. The use-cases never go away, and the hacks we use to deal with them never get any less ugly. And 'async', while good for independent scripts such as social media apis, is not really a good tools for dependency management. Again, possibly a case of misunderstanding or missed context from previous conversations. When I bring up async, I'm not talking about script async in markup as you suggest, but actually `script.async = false` being set on dynamcially created script elements (in code). async=false (aka ordered async) is a relatively new feature added to the platform about 2.5 years ago that gives us async parallel loading, but the browser automatically enforces execution order to be request order, instead of ASAP order. async=false is actually a good feature. The problem is not the feature itself, but that it's only part of what we needed. My main issue against using external script loaders like LABjs and others, has always been that if the browser must download a script first, before starting to download the dependencies. It presents a drawback already, for delayed the scripts by the script loader's latency and download time (at least for the first uncached page load) similarly to having scripts at the bottoms. For LABjs' part, I never suggest to people to load LABjs in a separate file. I suggest that people use a bootstrap type code file, which would be a single .js file they load with a single script tag in their markup, and it contains all the bare-minimum code necessary to bootstrap the page/app. It would include the code for LABjs, also the $LAB chains for loading other scripts, even basic event handling or other bootstrap type logic. Moreover, the extra ~2k of gzip-bytes that LABjs costs (even if it's a separate file, but especially if it's included in another bootstrap file) is almost always made up for in savings by being able to take advantage of consistent parallel loading of scripts. If your page only has 3-5k of JS on it, then you shouldn't use a script loader. But if you're like most sites, and you're loading 100-300k of JS, then a tiny 2k of JS for loading optimization is not even a drop in the ocean. Lastly, I advocate the techniques of deferring certain parts of your scripts to not loading during page-load at all, but instead post-loading or on-demand loading at later times. This amounts to needing to have the ability to do dynamic loading during the lifetime of the page. Markup alone is never enough for that. You have to have a script loader of some sort. So, I advocate that a tiny but powerful script loader that you use for BOTH uses is a win. You use the same script loading techniques for page-load loading as you do for on-demand loading. Consistency of toolset here makes coding and maintenance easier in the long run. Why not simply load all such scripts early in the head with 'defer', As you mention below, defer is horribly buggy and unreliable. The chances of IE8+ (not to mention IE6-8) being patched to have better defer are roundable to zero. 'defer' in head scripts is actually a very good way to preserve script order with non-blocking scripts. But it only works for external scripts (as you note below), and it only works for markup loading during page-load, and gives no answer for dynamic/on-demand loading later. As such, by design, it's insufficient for the use-cases presented. I would actually advocate to petition Microsoft to release patches for IE8, IE9 and IE10 for these particular stupid overlooked bugs
