Re: [whatwg] Zip archives as first-class citizens
On Thu, Aug 29, 2013 at 2:14 AM, Mark Nottingham m...@mnot.net wrote: I'm sure you've thought about this more than I have, but can you humour me and dig in a bit here? Thanks Mark, I had not fully explored this one yet! If I wanted to link *within* the HTML, it could still be a href=#test, correct? That would be ideal, yes. Couldn't that be done by saying that for URIs inside a ZIP file, the base URI is effectively an authority-less scheme? E.g., for foo.html the base uri would be zip://foo.html. Having thought about this some I think this would require pretty invasive model changes, probably prohibitively so. * Resources that can contain subresources (HTML, CSS, JavaScript, workers, ...) would need to have an outer and inner location. If you have e.g. a href=#test updating the address bar to #path=test.htmlid=test is somewhat magic. For a href=other.html it'd be pretty magic too. * For origin comparison you'd have to look at the outer location. Either a sub-scheme or zip-path is a lot simpler as the changes are limited to URL and Fetch rather than most end points, URL, and Fetch. I *think* the end effect here would be that from the inside, HTML, CSS and JS wouldn't have to be changed to be zipped. Given the above I think that's not true. Unless you mean resources, not specifications, in which case that could probably be correct. From the outside, if you want to link *into* a zip file, you have to be aware of its structure, but that's really always going to be the case, isn't it? Yes, that's correct. -- http://annevankesteren.nl/
Re: [whatwg] Zip archives as first-class citizens
On Wed, Aug 28, 2013 at 5:36 PM, Boris Zbarsky bzbar...@mit.edu wrote: I think this comes back to use cases. If the idea of having the zip is here is stuff that should live in its own world, then we do not want easy ways to get out of it via relative URIs. If the idea is to have here is a fancy way of representing a directory then relative URIs should Just Work across the zip boundary, like they would for any other directory. Which model are we working with here? Or some other one that doesn't match either of those two? I thought it was the former. It seems other relative URLs are likely mistakes and would not make the zip archive easily portable. Turning them into network errors and requiring base in the HTML or absolute URLs seems fine. -- http://annevankesteren.nl/
Re: [whatwg] Zip archives as first-class citizens
On Wed, Aug 28, 2013 at 6:10 PM, Matthew Kaufman matt...@matthew.at wrote: This sounds like a great opening for a discussion about the pros and cons of doing such a thing. But until such a discussion has happened, isn't it a little premature to worry about the URL details? Those are not details. What has been proposed thus far is a pretty major change architecturally. It seems very important to go through that exercise. I'd start with things like what is the fallback when using a browser behind an enterprise firewall that blocks all zip files? and what potential security vulnerabilities do we create by having the browser download a zip file and parse the contents? and maybe how does this influence the design of memory-constrained browsers? I recommend providing concrete feedback. -- http://annevankesteren.nl/
Re: [whatwg] Zip archives as first-class citizens
On 28 August 2013 14:32, Anne van Kesteren ann...@annevk.nl wrote: * Using a sub-scheme (zip) with a zip-path (after !): zip:http://www.example.org/zip!image.gif * Introducing a zip-path (after %!): http://www.example.org/zip%!image.gif * Using media fragments: http://www.example.org/zip#path=image.gif High-level drawbacks: * Sub-scheme: requires changing the URL syntax with both sub-scheme and zip-path. * Zip-path: requires changing the URL syntax. * Fragments: fail to work well for URLs relative to a zip archive. I prefer the zip-path. It works with relative urls in out of the zip. Causing a network error in existing browsers is a shame. It'd be great if older browsers requested a url which included the zip location the file within, so the server could unpack the zip and deliver the right file. Whereas modern browsers would request the zip handle the unpacking clientside. Although I guess that would break a load of stuff. Is this syntax compatible with datauris? As in, will I be able to build a datauri of a zip containing a 2x2 png and access the png directly? Feels like a nice feature-detect. If I navigate to something within a zip file, how is it rendered? I'm assuming content-type isn't stored within a zip file (am I wrong?), so how can the browser differentiate a text file from an html file from a pdf etc etc. Will CORS headers on the zip apply to all it's contents? I guess they would. I have some higher-level concerns, feels like we're introducing an anti-pattern: Right now if I request a page it'll progressively render as assets are downloaded, the html will render before it's fully downloaded, as will images etc. As Eric Uhrhane points out, this can't happen with zip. If my CSS is in a zip with JS and images, page rendering is blocked on the whole zip rather than just the CSS. Also, if I change any file within my zip, the whole zip gets a cache-miss next time the user visits, rather than just the files that changed. As we get new protocols which reduce the request overhead, it'll be faster to transfer lots of smaller files that can cache and execute independently. A zip file feels a step backwards. I understand the ES modules use-case, but I think that's better solved with an ES module-specific use of the url fragment, eg combined-file.js#module-identifier. As for nested zip archives. Andrea suggested we should support this, but that would require zip-path to be a sequence of paths. I think we never went to allow relative URLs to escape the top-most zip archive. But I suppose we could support in a way that %!test.zip!test.html Why don't we want urls to escape the topmost zip archive? Nested zip support sounds fair, but why is the 2nd zip boundary ! rather than %!? Eg: img src=zipfile%!cat.gif Would the above work if the current url is http://whatever.com/zip%!index.html, making the image url http://whatever.com/zip%!zipfile%!cat.gif Cheers, Jake.
Re: [whatwg] Zip archives as first-class citizens
Regarding fallback: - when zip files are blocked by a firewall - when light browsers don't have enough resource to load a big zip file - when browser don't support a specific package format (jar, tgz...) In the solution mentioned with link tag and a pack: like scheme link id=pack1 rel=package src=/pack1.zip type=application/zip title=My app global resources ... img src=pack:pack1/graph1.png The browser could probably try an alternative url, per resource originally meant to be packed, like GET /pack1.zip/graph1.png Accept: image/* It would be up to the server using packages to make this alternative link available And it would still work with media fragments using the query form GET /pack1.zip/graph1.png?xywh=160,120,320,240 On 29 août 2013, at 12:02, Alexandre Morgaut wrote: Such concept make me think to something I already saw long time ago: - http://limi.net/articles/resource-packages/ - http://unscriptable.com/2010/08/03/firefoxs-proposed-resource-packages-spec-sucks/ - http://people.mozilla.com/~jlebar/respkg/ I liked the possibility to declare link resources to refer to, you were potentially able to load multiple archives depending of the layer logic of the app/site the same way you would do with image sprites or concatenated JS files ex: - framework layer - app / site layer - interface / page layer Using the packages attribute made in my opinion this granularity still possible but harder With link tags you were able to put distinct ones in HTML templates while you can't with the packages attribute Regarding internal links there is an existing scheme used in MHTML: cid: and mid: - http://tools.ietf.org/html/rfc2557 - http://tools.ietf.org/html/rfc2392 (note: a scheme to consider for the URL API?) But they may not be the best one to use I looked also at the res: microsoft scheme but their use of # to target sub resource is an issue preventing good support of media fragments It also has a bad history with security issues - http://msdn.microsoft.com/en-us/library/aa767740(v=vs.85).aspx - http://support.microsoft.com/kb/220830 - http://ha.ckers.org/blog/20070721/res-protocol-local-file-enumeration/ Something I'd find interesting would be have a package or resources link type able to link to few standard archive formats (zip, jar, tar, tgz...) to be decided (gz already standard in HTTP) ex: link id=pack1 rel=package src=/pack1.zip type=application/zip title=My app global resources and then be able to refer to any of the package file via the link tag id using a global package specific scheme ex: img src=pack:pack1/graph1.png Media fragments should still work on such URL but it might be required, or at least recommended, to specify the MIME type in the tag as it won't be provided by HTTP. Of course the browser can still automatically define it from the extension if not specified as the HTTP server does img src=pack:pack1/graph1.png#xywh=160,120,320,240 or a bit safer img src=pack:pack1/graph1.png#xywh=160,120,320,240 type=image/png If we don't to create a new scheme, - the cid: one may be used considering the Content-ID as defined by the link id + the sub resource path img src=cid:pack1/graph1.png - the mid: one may be used considering the Message-ID as defined by the link id and the Content-ID as the sub resource path img src=mid:pack1/graph1.png It would mean creating a RFC updating the 2392 RFC instead of creating a new one from scratch - an issue being that cid: and mid: don't expect fragments and I think that nothing prevent a Content-ID to contain a # in a MIME mail or MHTML file, so the URL API may have little more complex check to do to correctly fill the URL object properties (current context, existing package link in header...) For such solution the link rel attribute value and the URL scheme name should meet a global adoption. I think that we should try to make them much related to each other if possible Another point I found interesting to think of: The same way debuggers like Web Inspector allow to inspect cookies and web storages, they should be able to list packages, list them by id used as keys and show: - their size - their archive format - their description (from the title attribute) - the list of their files (preferably supporting internal folder hierarchy) On 28 août 2013, at 15:32, Anne van Kesteren wrote: A couple of us have been toying around with the idea of making zip archives first-class citizens on the web. What we want to support: * Group a bunch of JavaScript files together in a single resource and refer to them individually for upcoming JavaScript modules. * Package a bunch of related resources together for a game or applications (e.g. icons). * Support self-contained packages, like Flash-ads or Flash-based games. Using zip archives for this makes sense as it has broad tooling support. To lower adoption cost no special
Re: [whatwg] Zip archives as first-class citizens
On 8/29/13 8:19 AM, Jake Archibald wrote: Is this syntax compatible with datauris? data:text/html,%!foo is handled identically in Presto, Blink, WebKit, and Gecko (no Trident to test in right this second, sorry), and shows the text. So if the proposed syntax were applied here it would change behavior... Which comes back to my concern with the zip-path approach. Is it supposed to work for all schemes? Some schemes? All-but-data:? Only data: that has application/zip type? Something else? If I navigate to something within a zip file, how is it rendered? I'm assuming content-type isn't stored within a zip file (am I wrong?) You're not. so how can the browser differentiate a text file from an html file from a pdf etc etc. The same way they do for file://: by looking at the file extension. This is a pretty serious issue, by the way, because file extensions differ by OS configuration, so we get interop issues. Good catch. :( Also, if I change any file within my zip, the whole zip gets a cache-miss next time the user visits, rather than just the files that changed. Yep. -Boris
Re: [whatwg] Zip archives as first-class citizens
On Thu, Aug 29, 2013 at 1:15 PM, Alexandre Morgaut alexandre.morg...@4d.com wrote: In the solution mentioned with link tag and a pack: like scheme link id=pack1 rel=package src=/pack1.zip type=application/zip title=My app global resources I don't think adding a level of indirection is a good idea. I think the added complexity is the reason this proposal failed the last time and I don't see a reason to revive it. -- http://annevankesteren.nl/
Re: [whatwg] Script preloading
On Aug 29, 2013 1:21 AM, Jonas Sicking jo...@sicking.cc wrote: Hi Ryosuke, Based on the feedback here, it doesn't sound like you are a huge fan of the original proposal in this thread. At this point, has any implementation come out in support of the proposal in this thread as a preferred solution over noexecute/execute()? The strongest support I've seen in this thread, though I very well could have missed some, is it's better than status quo. Is that the case? / Jonas On Wed, Aug 28, 2013 at 7:43 PM, Ryosuke Niwa rn...@apple.com wrote: On Jul 13, 2013, at 5:55 AM, Andy Davies dajdav...@gmail.com wrote: On 12 July 2013 01:25, Bruno Racineux br...@hexanet.net wrote: 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. The pre-loader is a tradeoff, it's aiming to increase network utilisation by speculatively downloading resources it can discover. Some of the resources downloaded may be not be used but with good design and mobile first approaches hopefully this number can be minimised. Even if some unused resources get downloaded how much it matter? It matters a lot when you only have GSM wireless connection, and barely loading anything at all. By starting the downloads earlier, connections will be opened sooner, and the TCP congestion window to grow sooner. Of course this has to be balanced against visitors who might be paying to download those unused bytes, and whether the unused resources are blocking something on the critical path from being downloaded (believe some preloaders can re-prioritise resources if they need them before the preloader has downloaded them) Exactly. I'd to make sure whatever API we come up gives enough flexibility for the UAs to decide whether a given resource needs to be loaded immediatley. On Jul 12, 2013, at 11:56 AM, Kyle Simpson get...@gmail.com wrote: My scope (as it always has been) put simply: I want (for all the reasons here and before) to have a silver bullet in script loading, which lets me load any number of scripts in parallel, and to the extent that is reasonable, be fully in control of what order they run in, if at all, responding to conditions AS THE SCRIPTS EXECUTE, not merely as they might have existed at the time of initial request. I want such a facility because I want to continue to have LABjs be a best-in-class fully-capable script loader that sets the standard for best-practice on-demand script loading. Because of the different network conditions and constraints various devices have, I'm wary of any solution that gives the full control over when each script is loaded. While I'm sure large corporations with lots of resources will get this right, I don't want to provide a preloading API that's hard to use for ordinary Web developers. On Jul 15, 2013, at 7:55 AM, Kornel Lesiński kor...@geekhood.net wrote: There's a very high overlap between module dependencies and script dependencies proposal. I think at very least it would be useful to define script dependencies in terms of ES6 modules, or even abandon markup solution to avoid duplicating features. ES6 modules however do not solve the performance problem. In fact they would benefit from UA having a list of all dependencies up front (otherwise file's dependencies can only be discovered after that file is loaded, which costs as many RTTs as the height of the dependency tree). So I think that eventually ES6 modules + link[rel=subresource] could be the answer. The link would expose URLs to (pre)load for performance, but modules would handle actual loading/execution for flexibility and reliability. Yes, we should definitely consider how this preloading API works with ES6 modules. On Jul 22, 2013, at 3:22 PM, Jonas Sicking jo...@sicking.cc wrote: Having the load event anytime we are done with a network request also seems beneficial. Rather than having most APIs use load whereas this would use preload. Generally speaking load means loaded and processed. The 'noexecute' flag would change what the and processed piece includes. I don't think it'll be confusing if the script had noexecute. We can even call it noautoexecute if we wanted. But I'm fine either way here. The same question and risk of confusion seems to exist with the whenneeded attribute. In general whenneeded seems very similar to noexecute, but with a little bit more stuff done automatically, for better or worse. I like the simplicity of noexecute and excute(). However, I'm a little worried that it doesn't provide any information as to how important a given script is. So Web browsers have no choice but to request all scripts immediately. I'd like to eventually provide APIs that allow
Re: [whatwg] Zip archives as first-class citizens
On Thu, Aug 29, 2013 at 1:19 PM, Jake Archibald jaffathec...@gmail.com wrote: Causing a network error in existing browsers is a shame. It'd be great if older browsers requested a url which included the zip location the file within, so the server could unpack the zip and deliver the right file. Whereas modern browsers would request the zip handle the unpacking clientside. Although I guess that would break a load of stuff. Picking something that could occur in paths seems problematic. Is this syntax compatible with datauris? As in, will I be able to build a datauri of a zip containing a 2x2 png and access the png directly? Feels like a nice feature-detect. Yes, if we decide zip-path over sub-scheme we should support it for all URLs, much like fragment is. If I navigate to something within a zip file, how is it rendered? I'm assuming content-type isn't stored within a zip file (am I wrong?), so how can the browser differentiate a text file from an html file from a pdf etc etc. Using the file extension and no sniffing of any sorts, falling back to application/octet-stream. That determines the Content-Type. Whether the loading context (e.g. img) ignores that is up to the loading context. https://etherpad.mozilla.org/zipurls outlines this. Will CORS headers on the zip apply to all it's contents? I guess they would. It would make sense to forward them, agreed. We'd have to add that to the Fetch layer when constructing a response. Right now if I request a page it'll progressively render as assets are downloaded, the html will render before it's fully downloaded, as will images etc. As Eric Uhrhane points out, this can't happen with zip. If my CSS is in a zip with JS and images, page rendering is blocked on the whole zip rather than just the CSS. Also, if I change any file within my zip, the whole zip gets a cache-miss next time the user visits, rather than just the files that changed. As we get new protocols which reduce the request overhead, it'll be faster to transfer lots of smaller files that can cache and execute independently. A zip file feels a step backwards. A great server setup will be better, agreed. I don't think we can assume everyone will have one. Also, to some extent we'll have to figure out how people will want to deploy this new primitive and then see if there's ways to improve that. I expect this would be used by less-capable ad-servers, assets for games, toying with EPUB and OOXML, etc. I understand the ES modules use-case, but I think that's better solved with an ES module-specific use of the url fragment, eg combined-file.js#module-identifier. I don't really see how that would work. ES modules are standalone files and don't have dedicated syntax other than import/export. For ES modules it would maybe work to only support extracting a file out of zip archive, but even in ES modules you'd want to reference other modules that might be in the zip archive. And you'd definitely want to do that for CSS. Why don't we want urls to escape the topmost zip archive? It seems more likely to me that would be a mistake than actually intended. But it depends on what use case you envision as Boris pointed out earlier. You can always point elsewhere by using a base or absolute URL though. Nested zip support sounds fair, but why is the 2nd zip boundary ! rather than %!? My idea was to indicate in the URL what the topmost zip archive is. It doesn't matter much though, it could be the same. Eg: img src=zipfile%!cat.gif Would the above work if the current url is http://whatever.com/zip%!index.html, making the image url http://whatever.com/zip%!zipfile%!cat.gif Sure. -- http://annevankesteren.nl/
Re: [whatwg] Zip archives as first-class citizens
On 8/29/13 9:02 AM, Anne van Kesteren wrote: Using the file extension and no sniffing of any sorts Why? -Boris
Re: [whatwg] Zip archives as first-class citizens
On Thu, Aug 29, 2013 at 2:26 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 8/29/13 9:02 AM, Anne van Kesteren wrote: Using the file extension and no sniffing of any sorts Why? Doing a mixture of sniffing and labeling has not served us very well. We cannot rely solely on sniffing because of CSS and SVG. We can rely solely on a standardized mapping table of extension to Content-Type. (Sniffing can still happen if the endpoint does sniffing of course, unless we decide to add the no-sniff header here I suppose...) -- http://annevankesteren.nl/
Re: [whatwg] Zip archives as first-class citizens
On 8/29/13 9:32 AM, Anne van Kesteren wrote: Doing a mixture of sniffing and labeling has not served us very well. We cannot rely solely on sniffing because of CSS and SVG. We can rely solely on a standardized mapping table of extension to Content-Type. Ah, ok, the extension table is standardized, not gotten from the OS? OK, that works. -Boris
Re: [whatwg] Zip archives as first-class citizens
On Thu, Aug 29, 2013 at 2:37 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 8/29/13 9:32 AM, Anne van Kesteren wrote: Doing a mixture of sniffing and labeling has not served us very well. We cannot rely solely on sniffing because of CSS and SVG. We can rely solely on a standardized mapping table of extension to Content-Type. Ah, ok, the extension table is standardized, not gotten from the OS? OK, that works. Of course. As I said to Jake, draft details in: https://etherpad.mozilla.org/zipurls -- http://annevankesteren.nl/
Re: [whatwg] Zip archives as first-class citizens
On Thu, 29 Aug 2013 15:02:48 +0200, Anne van Kesteren ann...@annevk.nl wrote: On Thu, Aug 29, 2013 at 1:19 PM, Jake Archibald jaffathec...@gmail.com wrote: Causing a network error in existing browsers is a shame. It seems to fail to resolve in IE10. It works in Gecko/WebKit/Blink/Presto: the %! is requested literally. However, both Apache and IIS seems to return 400 Bad Request. It'd be great if older browsers requested a url which included the zip location the file within, so the server could unpack the zip and deliver the right file. Whereas modern browsers would request the zip handle the unpacking clientside. Although I guess that would break a load of stuff. Picking something that could occur in paths seems problematic. I'm not sure why it's more problematic than something than could occur in the fragment. For instance, the string $zip= is not present at all in http://webdevdata.org/ data set 18/06/2013. So maybe we could use a string like that in the path and have a graceful fallback path in legacy browsers that work in existing servers. -- Simon Pieters Opera Software
Re: [whatwg] Zip archives as first-class citizens
On Wed, Aug 28, 2013 at 12:25 PM, Eric Uhrhane er...@chromium.org wrote: Broken files don't work, and I'm OK with that. I'm saying that legal zips can have multiple directories, where the definitive one is last in the file, so it's not a good format for streaming. If you're saying that you want to change the format to make an earlier directory definitive, that's going to break compat for the existing archives everywhere, and would be confusing enough that we should just go with a different archive format that doesn't require changes. Or at least don't call it zip when you're done messing with the spec. I'm saying that if the directories are out of sync, the filenames are going to be broken in existing clients already. We should only try to guarantee that files always work if their internal data is consistent. If their records are out of sync, then we should only ensure that the files work the same in all browsers, even if there are some files that won't work nicely as a result. That said, we don't actually have use cases or a feature proposal for streaming from ZIPs, so it's hard to make any further analysis. The feature we're discussing here doesn't need streaming, only random access. It wouldn't read the whole ZIP, it would just read the end of the file to grab the central directory (which gives you the information you need to decide what to read from there). (The access patterns of having to read the central directory first aren't ideal for optimizing away fetches, since Content-Range has no way of saying give me the last 64K of the file so you have to ask for the size first, but I'd rather that than introducing a new archive format into the wild...) -- Glenn Maynard
Re: [whatwg] Script preloading
When Kyle and I originally started pushing for a way to preload JavaScript many moons ago, the intent was very simple: to allow the downloading of JavaScript and execution of JavaScript to be separate. The idea being that you should be able to preload scripts that you'll need later without incurring the cost of parsing and execution at that point in time. There are many examples of people doing this, the most famous being the Gmail mobile approach of loading JavaScript in comments and then pulling that code out and eval()ing it. I still feel very strongly that this pattern is a necessary evolution of how we should be able to load scripts into web pages. I just want a flag that says don't execute this now and a method to say okay, execute this now. Allowing that flag to be set both in HTML and JavaScript is ideal. The question of dependency management is, in my mind, a separate issue and one that doesn't belong in this layer of the web platform. HTML isn't the right spot for a dependency tree to be defined for scripts (or anything else). To me, that is a problem to be solved within the ECMAScript world much the way CSS has @import available from within CSS code. I think the use cases other than the initial one (preload/execute later) are best relegated to script loaders and are very tied to a current way of thinking about loading JavaScript. I'd rather provide a simple, low-level piece of functionality that make the job of script loaders easier by providing a reliable API and then let the dependency management use cases be addressed outside of HTML. Other random thoughts: * whenneeded is a very strange name for that attribute. It doesn't really tell me anything, as opposed to preload, noexecute, or future. How do I know when it will be needed? * I like execute() as the way to run the script in question. -N On Thu, Aug 29, 2013 at 5:58 AM, Brian Kardell bkard...@gmail.com wrote: On Aug 29, 2013 1:21 AM, Jonas Sicking jo...@sicking.cc wrote: Hi Ryosuke, Based on the feedback here, it doesn't sound like you are a huge fan of the original proposal in this thread. At this point, has any implementation come out in support of the proposal in this thread as a preferred solution over noexecute/execute()? The strongest support I've seen in this thread, though I very well could have missed some, is it's better than status quo. Is that the case? / Jonas On Wed, Aug 28, 2013 at 7:43 PM, Ryosuke Niwa rn...@apple.com wrote: On Jul 13, 2013, at 5:55 AM, Andy Davies dajdav...@gmail.com wrote: On 12 July 2013 01:25, Bruno Racineux br...@hexanet.net wrote: 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. The pre-loader is a tradeoff, it's aiming to increase network utilisation by speculatively downloading resources it can discover. Some of the resources downloaded may be not be used but with good design and mobile first approaches hopefully this number can be minimised. Even if some unused resources get downloaded how much it matter? It matters a lot when you only have GSM wireless connection, and barely loading anything at all. By starting the downloads earlier, connections will be opened sooner, and the TCP congestion window to grow sooner. Of course this has to be balanced against visitors who might be paying to download those unused bytes, and whether the unused resources are blocking something on the critical path from being downloaded (believe some preloaders can re-prioritise resources if they need them before the preloader has downloaded them) Exactly. I'd to make sure whatever API we come up gives enough flexibility for the UAs to decide whether a given resource needs to be loaded immediatley. On Jul 12, 2013, at 11:56 AM, Kyle Simpson get...@gmail.com wrote: My scope (as it always has been) put simply: I want (for all the reasons here and before) to have a silver bullet in script loading, which lets me load any number of scripts in parallel, and to the extent that is reasonable, be fully in control of what order they run in, if at all, responding to conditions AS THE SCRIPTS EXECUTE, not merely as they might have existed at the time of initial request. I want such a facility because I want to continue to have LABjs be a best-in-class fully-capable script loader that sets the standard for best-practice on-demand script loading. Because of the different network conditions and constraints various devices have, I'm wary of any solution that gives the full control over when each script is loaded. While I'm sure large corporations with lots of resources will get this right, I don't want to provide a preloading API
Re: [whatwg] Script preloading
On 27 August 2013 22:55, Ian Hickson i...@hixie.ch wrote: On Tue, 9 Jul 2013, Bruno Racineux wrote: 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. This doesn't seem like it handles all the use cases (e.g. T and U). Worth noting that defer is busted in IE9 and below, to the point where it's unusable https://github.com/h5bp/lazyweb-requests/issues/42 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 why this html4 functionality was removed from html5? Well, primarily because basically nobody implemented it, but also, because it's not clear what the point is. Why would you need it? I like my scripts to be inert, as in have no impact on the page (like jquery). I use a small inline script to start the work needed for that page, meaning I know the starting point for all JS interacting with the page is somewhere in an inline script. This is much easier to maintain than scripts that trigger themselves ondomready depending on what they see in the DOM. I'd have liked defer (to work in IE and) to work on scripts without src. In your proposal, does this work?… script src=whatever.js whenneeded/script ... script needs=whatever.js activateTheAlmightyWebsockets(); /script On Mon, 15 Jul 2013, Kornel Lesiński wrote: ES6 modules however do not solve the performance problem. In fact they would benefit from UA having a list of all dependencies up front (otherwise file's dependencies can only be discovered after that file is loaded, which costs as many RTTs as the height of the dependency tree). So I think that eventually ES6 modules + link[rel=subresource] could be the answer. The link would expose URLs to (pre)load for performance, but modules would handle actual loading/execution for flexibility and reliability. The ES6 module doesn't address some of the use cases above, as far as I can tell (e.g. Q, U) and require a lot of work to handle some of the others. But it seems important that anything we add to HTML be designed to work with ES6 modules on the long run. There seems to be a lack of data on how modules would work in the browser. Eg, when/if they block further rendering. Or is that in the doc I'm just not getting my head around it? It'd be great if modules can solve these but also give the UA all the requirements up front (or maybe that's the job of HTTP2). On Wed, 10 Jul 2013, Jake Archibald wrote: If dependencies took a CSS selector it could be: script dependencies=.cms-core src=cmd-plugin.js/script Now the number of scripts with class cms-core can change between versions of the CMS but the plugin still waits for them all. No ID generation needed. Using a selector is an interesting idea. It makes it harder to detect and prevent loops, but not fatally so. I'm not sure it's possible to get into loops with this. I imagined dependency resolution to happen once, on element creation or adding to document (whichever happens latest). So with: script src=a.js needs=script[src=b.js]/script script src=b.js needs=script[src=a.js]/script …the first script would have zero dependencies, because the selector matches zero elements. The second would depend on the first, so the execution order is a.js, b.js. The thing I like about the selector thing is you can very easily get (almost) async=false behaviour: script src=a.js needs=script/script script src=b.js needs=script/script script src=c.js needs=script/script script elements get a new whenneeded= attribute, which delays the execution of the script until the script element's execute() method is called. (This essentially provides the same as the preload suggestions.) execute() should return a promise that resolves when the script successfully downloads and executes. Also, should there be an event on the script element when the script has downloaded, but not executed (like IE used to have)? (there's probably a better name than whenneeded, but I can't think of one right now) script elements also get a new needs= attribute, which takes a list of URLs. A script won't run (even if you call execute()) until all the script src= elements referenced by its needs= attribute are themselves ready to run. For example: script src=b.js needs=a.js/script script src=a.js async/script It seems weird to refer to needs by url, but still require script elements for those needs, I'd rather use IDs (or selectors yey!). Also, I'm not sure we need to deal
Re: [whatwg] Proposal: API to ask the user for a file
On Mon, 29 Apr 2013, Jonas Sicking wrote: I think all modern browsers intentionally let webpages create custom UIs for input type=file by completely hiding the input and then rendering a custom UI using various div and span tags. When the custom UI is clicked the page calls myInputElement.click() in order to bring up the file picker UI. Gecko contains some anti-annoyance protections as to prevent the page from spawning file picker dialogs indefinitely. This is done by hooking up input type=file.click() to popup blocking infrastructure. Turns out input type=file.click() wasn't specced yet. I've now specced it, along with hooking it up to the popup-blocking logic. So the API being requested here is actually available. But in a really ugly way through the HTMLInputElement interface. But I don't really buy the argument that we should supply a new one because the existing API isn't reliably available. If the current API is problematic because there is no way to check if it works, then I'd prefer to add a way to check if it works, rather than adding a whole new API. Yeah. On Wed, 1 May 2013, JC wrote: I guess I should have mention too that the existing API is not only unreliable but also very inconvenient. Since the trick depends on the changed event Yeah, it's weird that the dialog doesn't block script (since the dialog is modal). But I would imagine that any new API we added for this would actually be worse in this regard; we'd probably end up with a Promise-based entirely async, non-modal UI. and there's no official way to clear the list of files selected the last time, in order to ensure that the event is fired if the same file is selected again the element has to be removed and replaced by a new one every time the user selects a file That will be resolved once this is fixed: https://www.w3.org/Bugs/Public/show_bug.cgi?id=22682 -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] maxlength= feedback
On Fri, 28 Jun 2013, Steve Hoeksema wrote:
The current whatwg standard [1] states that maxlength is not a valid
attribute for input[type=number].
I built a form and tested it in Firefox, which honours the maxlength
attribute, and then found that Chrome did not.
I thought this was a bug, so I reported it to Chromium [2], who
determined it was not a bug and referred me to whatwg.
I'm wondering if there is a rationale for not supporting maxlength on a
number field, and if not, how I can go about having the standard
changed?
Just set the max= attribute instead.
On Fri, 28 Jun 2013, Steve Hoeksema wrote:
In my specific case, a numeric code with a maximum length.
Say it's 4 digits, and I'm using Chrome. I can put max=, but the
browser still allows me to type 12345. It won't allow me to submit the
form, and it highlights it as an error, but I can still enter it. Using
a maxlength means I can't even enter 12345, and it's obvious that it
will only accept 4 digits.
If you have a numeric code (i.e. is different than 0) then
type=number is the wrong type; you should instead use:
input type=text pattern=[0-9]{4} maxlength=4 inputmode=numeric
Using input[type=text] is not desirable because (e.g.) it pops up a
alphabetical keyboard on iOS instead of a numeric keyboard.
That's fixed by inputmode=numeric.
On Fri, 28 Jun 2013, Jukka K. Korpela wrote:
People want to [specify maxlength on type=number] to cover old browsers
that do not support type=number. Such browsers ignore both the type
attribute and the max attribute, so to impose *some* limits, people
would use maxlength.
That will work, yes. It's not conforming, because that way validators will
warn you that what you're doing isn't going to work going forward.
Generally speaking, though, even with legacy browsers, if you're asking
for a _number_ then maxlength= isn't useful. Supposed you want a number
between 0 and . Well, 0 and 0.00 are the same number,
even though one is longer than 4 digits.
On Mon, 19 Aug 2013, Ryosuke Niwa wrote:
Why is the maxlength attribute of the input element specified to
restrict the length of the value by the code-unit length?
That's either what most browsers seemed to do when I tested it, or it was
the most consistent thing to specify based on other things that were
consistently implemented (e.g. the .textLength attribute's behaviour).
This is counter intuitive for users and authors who typically intend to
restrict the length by the number of composed character sequences.
There's actually a number of possible things people might intuitively
expect it to do -- count graphemes, count Unicode code points, count
composed characters, count monospace width, count bytes, etc. It's not
clear to me that there's one answer, nor that, in fact, most authors have
any idea that there are so many answers to the question how long is my
string.
On Mon, 19 Aug 2013, Ryosuke Niwa wrote:
Also,
http://www.whatwg.org/specs/web-apps/current-work/multipage/common-input-element-attributes.html#the-maxlength-attribute
says if the input element has a maximum allowed value length, then the
code-unit length of the value of the element's value attribute must be
equal to or less than the element's maximum allowed value length.
This doesn't seem to match the behaviors of existing Web browsers
That's authoring conformance criteria, not implementation conformance
criteria.
On Tue, 20 Aug 2013, Jukka K. Korpela wrote:
Apparently because in the DOM, character effectively means code
unit. In particular, the .value.length property gives the length in
code units.
Specifically, UTF-16 code units.
In fact, this is the current shipping behavior of Safari and Chrome.
And IE, but not Firefox. Here's a simple test:
input maxlength=2 value=#x10400;
On Firefox, you cannot add a character to the value, since the length is
already 2. On Chrome and IE, you can add even a second non-BMP
character, even though the length then becomes 4. I don't see this as
particularly logical, though I'm looking this from the programming point
of view, not end user view.
Which version of IE? I wonder if this changed at some point.
Interestingly, an attempt like input pattern=.{0,42} to limit the
amount of *characters* to at most 42 seems to fail. (Browsers won't
prevent from typing more, but the control starts matching the :invalid
selector if you enter characters that correspond to more than 42 code
units.) The reason is apparently that . means any character in the
sense any code point, counting a non-BMP character as two.
This is inherited from JavaScript.
On Thu, 22 Aug 2013, Charles McCathie Nevile wrote:
The basic question is whether a validator should flag input
maxlength=2 value=abc as a conformance error or not. It seems to
me like it should.
Why? It seems that it generally works in browsers, and has for
Re: [whatwg] datalist element example and option element content model
On Thu, 18 Jul 2013, Kurosawa Takeshi wrote: I noticed inconsistency between datalist element example and option element content model. In a datalist element's code example, there are option elements which don't specify label attribute and are empty. http://www.whatwg.org/specs/web-apps/current-work/multipage/the-button-element.html#the-datalist-element label Sex: input name=sex list=sexes datalist id=sexes option value=Female option value=Male /datalist /label However option element section prohibits such condition. The label content attribute, if specified, must not be empty. If the attribute is not specified, then the element itself must not be empty. http://www.whatwg.org/specs/web-apps/current-work/multipage/the-button-element.html#the-option-element My question is which one is correct: the code example or the option element section. I corrected the spec on this in response to the bug you filed: On Sat, 17 Aug 2013, Kurosawa Takeshi wrote: Bug 22994 - Clarify option element's label must be a non empty string. https://www.w3.org/Bugs/Public/show_bug.cgi?id=22994 If you could respond to comment 3 on that bug, that'd be great. Note that if you post to this list, there's no point also filing a bug. I'll get to the feedback either way eventually. Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Forms: input type=file and directory tree picking
On Fri, 2 Aug 2013, Jonathan Watt wrote: I'm working on Mozilla's implementation of input type=file to allow the user to pick a directory. The idea would be that the files in that directory and its subdirectories would be added to the HTMLInputElement.files FileList. This seems to be dangerous in that it makes it really easy for the user to select a single item that expands into tens of thousands if not millions of files on a remote disk, which then all have to be synchronously enumerated to get the count so that code can then itself enumerate through the entire list. The advantage of avoiding the need for the 'directory' attribute would be that directory picking would work for existing content with input type=file multiple without needing to be changed. One disadvantage would be that existing content may depend on the file names in the FileList being unique. I would have liked the file names to still be unique, by prefixing the names with the relevant parts of the subpaths (that is, if I select foo.txt and bar/ which contains another foo.txt, .files would contain foo.txt and bar/foo.txt), but I think that ship sailed (and now the spec explicitly requires otherwise). We would change the File interface to add a 'path' property, which would be the path (without the file name) of the file relative to the directory that was picked. That might work. Currently authors can use HTMLInputElement.click() to open a system file picker. To give content the ability to open a system directory picker we'd add a corresponding .openDirectoryPicker() function. So you wouldn't be able to pick a file and a directory as in the example above? That seems unfortunate... In my prototype implementation it took around 30 seconds to build the FileList for a directory of 200,000 files with a top end SSD Wow. That's... not great in a UI. so depending on what the page is doing, directory picking could take some time. To allow content authors with styled input to provide feedback to users during scans of large directory trees we plan to have openDirectoryPicker return a ProgressPromise: https://github.com/slightlyoff/Promises/blob/master/ProgressFuture.idl We'd then fire progress events at the promise specifying how many files had been processed so far. I feel very uncomfortable with the idea that we'd intentionally have an expensive API like this. But I guess I don't really know what the use cases are, so it's hard to evaluate. Anyway, I don't have a better suggestion right now. What has the implementation experience been like so far? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Forms: input type=file and directory tree picking
On Thu, Aug 29, 2013 at 1:20 PM, Ian Hickson i...@hixie.ch wrote: On Fri, 2 Aug 2013, Jonathan Watt wrote: I'm working on Mozilla's implementation of input type=file to allow the user to pick a directory. The idea would be that the files in that directory and its subdirectories would be added to the HTMLInputElement.files FileList. This seems to be dangerous in that it makes it really easy for the user to select a single item that expands into tens of thousands if not millions of files on a remote disk, which then all have to be synchronously enumerated to get the count so that code can then itself enumerate through the entire list. We don't have to do any enumeration synchronously. It can all happen off the main thread. The .click() API is asynchronous. The advantage of avoiding the need for the 'directory' attribute would be that directory picking would work for existing content with input type=file multiple without needing to be changed. One disadvantage would be that existing content may depend on the file names in the FileList being unique. I would have liked the file names to still be unique, by prefixing the names with the relevant parts of the subpaths (that is, if I select foo.txt and bar/ which contains another foo.txt, .files would contain foo.txt and bar/foo.txt), but I think that ship sailed (and now the spec explicitly requires otherwise). We discussed this. However many people has expressed that they expect the .name property to only contain the leaf name. Trying to tell people that the name is unique and may or may not include pieces of path has lead to lots of confusion. Instead we'll ensure that path+name is unique. At least unique within a single selection. We're planning on eventually letting users bring up filepickers multiple times and select additional files each time. Currently authors can use HTMLInputElement.click() to open a system file picker. To give content the ability to open a system directory picker we'd add a corresponding .openDirectoryPicker() function. So you wouldn't be able to pick a file and a directory as in the example above? That seems unfortunate... Unfortunately most OSs doesn't have support for filepickers that can select either a file or a directory. / Jonas
Re: [whatwg] Forms: input type=file and directory tree picking
On Thu, 29 Aug 2013, Jonas Sicking wrote: On Thu, Aug 29, 2013 at 1:20 PM, Ian Hickson i...@hixie.ch wrote: On Fri, 2 Aug 2013, Jonathan Watt wrote: I'm working on Mozilla's implementation of input type=file to allow the user to pick a directory. The idea would be that the files in that directory and its subdirectories would be added to the HTMLInputElement.files FileList. This seems to be dangerous in that it makes it really easy for the user to select a single item that expands into tens of thousands if not millions of files on a remote disk, which then all have to be synchronously enumerated to get the count so that code can then itself enumerate through the entire list. We don't have to do any enumeration synchronously. It can all happen off the main thread. The .click() API is asynchronous. It's asynchronous to the JS, sure, but at the end of the day the user can't get any work done until it's complete. It's synchronous as far as the user is concerned. So you wouldn't be able to pick a file and a directory as in the example above? That seems unfortunate... Unfortunately most OSs doesn't have support for filepickers that can select either a file or a directory. True. From a UI perspective it's kind of weird that the user has to decide which he wants, though. Similarly, from an authoring perspective, I don't understand how I would decide whether to show a multiple file picker or a directory picker. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Forms: input type=file and directory tree picking
On Thu, Aug 29, 2013 at 2:45 PM, Ian Hickson i...@hixie.ch wrote: On Thu, 29 Aug 2013, Jonas Sicking wrote: On Thu, Aug 29, 2013 at 1:20 PM, Ian Hickson i...@hixie.ch wrote: On Fri, 2 Aug 2013, Jonathan Watt wrote: I'm working on Mozilla's implementation of input type=file to allow the user to pick a directory. The idea would be that the files in that directory and its subdirectories would be added to the HTMLInputElement.files FileList. This seems to be dangerous in that it makes it really easy for the user to select a single item that expands into tens of thousands if not millions of files on a remote disk, which then all have to be synchronously enumerated to get the count so that code can then itself enumerate through the entire list. We don't have to do any enumeration synchronously. It can all happen off the main thread. The .click() API is asynchronous. It's asynchronous to the JS, sure, but at the end of the day the user can't get any work done until it's complete. It's synchronous as far as the user is concerned. Sure. The alternative is that the user attaches each file separately. Which, while means smaller synchronous actions, is not really a better UX. In other words, synchronousness is not the only design constraint here. So you wouldn't be able to pick a file and a directory as in the example above? That seems unfortunate... Unfortunately most OSs doesn't have support for filepickers that can select either a file or a directory. True. From a UI perspective it's kind of weird that the user has to decide which he wants, though. Similarly, from an authoring perspective, I don't understand how I would decide whether to show a multiple file picker or a directory picker. You display two buttons in the website UI, one for pick file and one for pick directory. We don't really have a choice as long as we live under the two constraints of: * Websites wants to do their own pick UI * OSs can't display pickers which allow picking either a file or a directory. / Jonas
Re: [whatwg] Subsequent access to empty string URLs (Was: Base URL’s effect on an empty @src element)
On Wed, 1 May 2013, Leif Halvard Silli wrote: If @src is empty (and there is no base url) a 'subsequent access' via a contextual menu, such as 'Show/Open image' or 'Save/Download image' has no effect in Firefox20, Opera12, IE10. Whereas Safari/Chrome do provide a contextual menu item for those features. (And the UA results are the same - except with regard to Firefox, also if there *is* a base URL.) If the src= attribute is empty, then there's no image, so all these UI options are kinda pointless no? A special detail is the last paragraph of section '2.5.3 Dynamic changes to base URLS'[1] which implies that a change to the base URL should (even when @src is empty, one must assume, not?) affect the @src URL so that a 'subsequent access' via context menu could be used to e.g. open the image resource set by the base URL. Is it meaningful? If the img src= is empty, the base URL has no effect, per spec. What if @cite or @longdesc are empty? Personally, I think it would be simplest to handle at least @longesc - but probably @cite too - the same way that @src is handled. The relevance to subsequent access to empty @src is that @longdesc and @cite tend, from users’ point of view, to be subsequently accessed (e.g. via context menu). Per spec, longdesc= has no effect. The cite= is explictly called out in the Dynamic changes to base URLs section and the logic that involves the cite= attribute doesn't look to see if it's empty, so I don't see any particular complication there. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] Handling of invalid UTF-8
In the spec preview it had a section about UTF-8 decoding and the handling of invalid byte sequences, http://dev.w3.org/html5/spec-preview/infrastructure.html#utf-8 . But I have noticed this section has been removed from the current version. So what algorithm is used for handling of invalid UTF-8 byte sequences? Or this no longer part of the HTML 5 specification? My testing on firefox and chrome seems to indicate that they follow the algorithm of replacing the first byte of an invalid sequence with the replacement character http://en.wikipedia.org/wiki/Replacement_character � (U+FFFD) and then continue with the parsing of the next byte.
Re: [whatwg] Forms: input type=file and directory tree picking
On Thu, Aug 29, 2013 at 5:06 PM, Jonas Sicking jo...@sicking.cc wrote: We don't have to do any enumeration synchronously. It can all happen off the main thread. The .click() API is asynchronous. It's asynchronous to the JS, sure, but at the end of the day the user can't get any work done until it's complete. It's synchronous as far as the user is concerned. Sure. The alternative is that the user attaches each file separately. Which, while means smaller synchronous actions, is not really a better UX. In other words, synchronousness is not the only design constraint here. The alternative is to provide an interface that explores the supplied directory on-demand, as the page needs it, rather than greedily scanning the entire directory before giving it to script. Scanning a large directory tree in advance is almost never what applications or users want. A static file list isn't a sensible API for recursively exposing directory trees. -- Glenn Maynard
Re: [whatwg] Handling of invalid UTF-8
On Thu, Aug 29, 2013 at 5:29 PM, Cameron Zemek grom...@gmail.com wrote: In the spec preview it had a section about UTF-8 decoding and the handling of invalid byte sequences, http://dev.w3.org/html5/spec-preview/infrastructure.html#utf-8 . But I have noticed this section has been removed from the current version. So what algorithm is used for handling of invalid UTF-8 byte sequences? Or this no longer part of the HTML 5 specification? http://www.whatwg.org/specs/web-apps/current-work/#dependencies has a reference to the Encoding spec, which is where the UTF-8 decoding logic lives now: http://encoding.spec.whatwg.org/#utf-8 -- Glenn Maynard
Re: [whatwg] Handling of invalid UTF-8
On Fri, 30 Aug 2013, Cameron Zemek wrote: In the spec preview it had a section about UTF-8 decoding and the handling of invalid byte sequences, http://dev.w3.org/html5/spec-preview/infrastructure.html#utf-8 You really don't want to be using that as a reference. It's a very out of date copy of a fork of the spec. On Thu, 29 Aug 2013, Glenn Maynard wrote: http://www.whatwg.org/specs/web-apps/current-work/#dependencies has a reference to the Encoding spec, which is where the UTF-8 decoding logic lives now: http://encoding.spec.whatwg.org/#utf-8 Right, the HTML standard (http://whatwg.org/html) now uses the Encoding standard (http://encoding.spec.whatwg.org/) to define UTF-8 processing. Let us know if you see anything wrong with either of these specs! Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Script preloading
On Aug 29, 2013, at 8:37 AM, Nicholas Zakas standa...@nczconsulting.com wrote: When Kyle and I originally started pushing for a way to preload JavaScript many moons ago, the intent was very simple: to allow the downloading of JavaScript and execution of JavaScript to be separate. The idea being that you should be able to preload scripts that you'll need later without incurring the cost of parsing and execution at that point in time. There are many examples of people doing this, the most famous being the Gmail mobile approach of loading JavaScript in comments and then pulling that code out and eval()ing it. I still feel very strongly that this pattern is a necessary evolution of how we should be able to load scripts into web pages. I just want a flag that says don't execute this now and a method to say okay, execute this now. Allowing that flag to be set both in HTML and JavaScript is ideal. The question of dependency management is, in my mind, a separate issue and one that doesn't belong in this layer of the web platform. HTML isn't the right spot for a dependency tree to be defined for scripts (or anything else). To me, that is a problem to be solved within the ECMAScript world much the way CSS has @import available from within CSS code. But why do you want an ability to say don't execute this now if there were no dependencies? Loading an extra script file that's not needed immediately can add few hundred of milliseconds to the total page load time over a slow network connection. To put it another way, I don't see why anyone wants to load a script and not execute it other than for the purpose of avoiding the network request at a later time. However, if that were the main purpose of providing such a functionality, then we also need to address the issue of this load request needing to have a lower priority than other load requests that are vital for the page. In fact, we might want to avoid sending the request of a script file altogether if the user isn't going to interact the parts of the page that needs such a script. - R. Niwa
Re: [whatwg] Script preloading
On Tue, Aug 27, 2013 at 4:55 PM, Ian Hickson i...@hixie.ch wrote:
IMHO, if you have to write a script to solve use cases like these, you
haven't really solved the use cases. It seems that the opportunity we have
here is to provide a feature or set of features that addresses these use
cases directly, so that anyone can use them without much work.
This is especially true for a module loader, which will be used to deal
with interactions between scripts written by different parties. If the
platform doesn't provide a standard, universal way to do this, then people
will keep rolling their own incompatible solutions. That's bearable for
self-contained code used by a module, but it doesn't make sense for the
piece that handles the cross-vendor interactions.
Anyway, the idea of only providing basic building blocks and making people
roll their own solutions isn't the web's design philosophy at all, so I
don't think it's a valid objection.
script whenneeded=jit is a special mode where instead of running once
the script's dependencies are met, it additionally waits until all the
scripts that depend on _it_ are ready to run. (Just in time exection.)
(The default is whenneeded=asap, as soon as possible exection.)
This mode seems to be specifically for this use case:
[Use-case U:] I have a set of script A.js, B.js, and C.js. B
relies on A, and C relies on B. So they need to execute strictly in that
order. [Now], imagine they progressively render different parts of a
widget. [...] I only want to execute A, B and C once all 3 are preloaded
and ready to go. It's [...] about minimizing delays between them, for
performance PERCEPTION.
This one seems uncommon, and less like a dependency use case than the
others. How often is this wanted? Is it too inconvenient to just mark
them all @whenneeded, and say something like:
document.querySelector(#C).execute(function() {
A.render();
B.render();
C.render();
});
That does require the modules render in a function, and not when the script
is first executed. I don't know how much of a burden that is for this
case.
Alternatively, if an event is fired when a script's dependencies have been
met, then you could mark all three scripts @whenneeded, and call
(#C).execute() once C's dependencies have been met.
Maybe the jit feature isn't a big deal, but it seems like a bit of an
oddball for a narrow use case.
You can manually increase or decrease a dependency count on script
elements by calling incDependencies() and decDependencies().
Will a @defer dependency effectively defer all scripts that depend on it?
incDependencies() and decDependencies() may be hard to debug, since if
somebody messes up the counter, it's hard to tell whose fault it is. A
named interface could help with this: script.addDependency(thing); /*
script.dependencies is now [thing] */ script.removeDependency(thing);
On Thu, Aug 29, 2013 at 10:37 AM, Nicholas Zakas
standa...@nczconsulting.com wrote:
The question of dependency management is, in my mind, a separate issue and
one that doesn't belong in this layer of the web platform. HTML isn't the
right spot for a dependency tree to be defined for scripts (or anything
else). To me, that is a problem to be solved within the ECMAScript world
much the way CSS has @import available from within CSS code.
This would serialize script loading, because you wouldn't know a script's
dependencies until you've actually fetched the script. That would make
page loads very slow.
I think the use cases other than the initial one (preload/execute later)
are best relegated to script loaders
I disagree. See above.
(Please remember to trim quotes.)
--
Glenn Maynard
Re: [whatwg] Script preloading
On 8/29/13, Nicholas Zakas standa...@nczconsulting.com wrote: When Kyle and I originally started pushing for a way to preload JavaScript many moons ago, the intent was very simple: to allow the downloading of JavaScript and execution of JavaScript to be separate. The idea being that you should be able to preload scripts that you'll need later without incurring the cost of parsing and execution at that point in time. There are many examples of people doing this, the most famous being the Gmail mobile approach of loading JavaScript in comments and then pulling that code out and eval()ing it. Ian mentioned the idea of exporting a module, and that idea requires only a function expression to return an object. This requires the parsing of one function -- the outermost function -- which can be evaluated later. Some examples of this include the Russian Doll Pattern (Cornford) Module Pattern (Crockford), IIFE (?), and function rewriting (me). For more on this, see Kangax' article: http://kangax.github.io/nfe/ (Kangax seems to have gotten bored at conquering javascript these days). I still feel very strongly that this pattern is a necessary evolution of how we should be able to load scripts into web pages. I just want a flag that says don't execute this now and a method to say okay, execute this now. Allowing that flag to be set both in HTML and JavaScript is ideal. The question of dependency management is, in my mind, a separate issue and one that doesn't belong in this layer of the web platform. HTML isn't the right spot for a dependency tree to be defined for scripts (or anything else). To me, that is a problem to be solved within the ECMAScript world much the way CSS has @import available from within CSS code. Dependency issues include problems from having to block for scripts, document.write, fouc. Problems arising with dependency stem give rise to the need of deferring and executing scripts. The problem is that the program needs to run a script during a certain condition. And if that condition is not met, then the script resource isn't needed at all. This could useful for a situation where there are a few different components on a page, say each component requires 100k of script and 10k of CSS. But the user will probably only use one of those three components and might very well use none at all. I have worked on pages like that, with sidebars, pickers, and panels, and I wanted something like this. As Ryosuke pointed out, the idea is to declare the script in the page and then use script to determine when it should load. My previous post on building a dependency tree delves into the idea that CSS and JS can be declared to depend on stuff being loaded. That feature makes it obvious as to why they're in the source code, to the human reader. Regards, -- Garrett Twitter: @xkit personx.tumblr.com
[whatwg] pagehide vs pagevis
On Tue, 28 May 2013, Brady Eidson wrote: The “unload a document” steps apparently don’t allow for the pagehide event to have “persisted” set to false. Hm, yeah, it should only be set to true if /salvageable/ is true. Fixed. In the original design of these events and in WebKit’s implementation, pagehide with persisted “true” means the page is being suspended into the page cache, and it might be restored later. In these cases, the page does not receive a traditional unload event, as it’s being suspended, not unloaded. I don't understand how you can know if you are going to fire the 'unload' event. I think the way the spec describes it makes more sense, which is that you always fire pagehide and you always fire unload, but if any unload handlers were triggered, then you don't suspend. pagehide with persisted “false” means the page is is being traditionally torn down. Right (salvageable is false). The spec’s description of PageTransitionEvent.persisted says Returns false if the page is newly being loaded (and the load event will fire). Otherwise, returns true.” That text is geared towards pageshow and completely neglects pagehide. Yeah, that description was kinda lame. Fixed. By the way, when the spec doesn't match implementations, it's usually a far better bet that it's just unintentionally wrong, than that there is a nefarious plot to ruin everything. :-) On Tue, 28 May 2013, Brady Eidson wrote: I'm sorry, who's page cache are you talking about? Page caches are (AFAIK) not really fleshed out in any spec Actually the HTML spec defines the page cache as thoroughly (I think) as any spec can. (Really everything but the eviction mechanism, but that is intentionally a UA-specific thing.) and the WebKit page cache *intends* to represent a 100% inert page. This includes the inability to receive events. Any exceptions in practice are a bug for us that we would strive to patch. A DOM node can always receive an event. The event handlers of DOM nodes in inactive documents might not be able to run, though. I don't think the HTML spec is very clear about this right now. (It blocks tasks, but I don't think it blocks event handlers.) I guess this would have to be in DOM, really. I filed this so we make sure to track this: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23095 On Wed, 29 May 2013, Brady Eidson wrote: Got it. Then it sounds like Gecko’s page cache and WebKit’s page cache are divergent in this regard. Which is perfectly fine, as such a browser feature isn’t spec’d anyways. It is. :-) I’ve provided our rationale for changing this, and I’m formally asking the WHATWG community if there’s any rationale for *not* changing this I don't think you can formally ask anything here. You can ask, but there cannot be anything more or less formal about it. :-) On Wed, 29 May 2013, Brady Eidson wrote: I see in the HTML spec that the step *before* firing pagehide is “set the Document’s page showing flag to false,” but I can’t find language that says pagehide fires *before* the page is actually hidden, and unload fires *after* the page is actually hidden. Since they fire synchronously, and rendering happens between tasks, they both fire when the page is in the same on-screen rendered state. I don't think there's a black-box way of telling whether there remains pixels of the page on the screen or not when either fires. pageshow is a history traversal event, and not a visibility event. I don’t see a guarantee in any spec that “pageshow” comes after the document is actually visible. Indeed. In fact in some UAs, e.g. those that use audio instead of video to display the page, the page will never be visible. I don't really see why it matters whether the Page Visibility spec fires its event before or after pagehide, though. First, since pagehide currently always has persisted set to true (in the spec and in Gecko), it doesn’t actually describe whether or not the page is going in to the page cache. It can be false (now, in the spec) when you are definitely not going into the cache, but it can also be true when you're not (e.g. if WebSockets get killed after pagehide and unload), and it can also be true when you go into the cache and are immediately evicted without notice, which is much the same as not going into the cache. So true is no guarantee of anything. Second, imagining a world where pagehide allows persisted to differ between true or false, to know that a “hidden” corresponds with a “page going in to the page cache”, you still have to listen to both events to know the whole situation. Third, is the difference between 4 states and 5 states really appreciable? I don't really understand these questions. On Thu, 30 May 2013, Brady Eidson wrote: Bucket 1 - “Pages not going in to the page cache” Let me ask you this - Are there any (reasonable) pages in the wild that (reasonably)
