[whatwg] [Fetch spec] Link to CORS FAQ wiki
Anne, The commit on the W3C CORS spec in May 2012 [1] has moved various useful texts explaining decisions made and reasons to the CORS FAQ wiki page [2]. The Fetch spec [3] inherited the CORS concepts/algorithms but seems didn't inherit stuff in the FAQ. Could you please try to guide readers of the Fetch spec to reach the contents placed at the FAQ wiki page (e.g. a link) or import them to the Fetch spec as p class=note/ps? [1] https://dvcs.w3.org/hg/cors/rev/5d553e422c6f [2] http://www.w3.org/wiki/CORS [3] http://fetch.spec.whatwg.org/
Re: [whatwg] [Fetch spec] Link to CORS FAQ wiki
I asked this question because I spent much time to understand the reason why credentials are omitted for preflight requests. But it seems the current Fetch spec has a different algorithm than the W3C CORS spec. The commit https://github.com/whatwg/fetch/commit/adec3d2bf35726b46dd6c0079ff01dba8e154711 has removed the definition of user credentials. Is this intentional? Before it, user credentials was defined as cookies, HTTP authentication, and client-side SSL certificates. Now the latest Fetch spec doesn't mention client certificates. If this is intentional, the CORS FAQ is not useful to understand the current Fetch spec. I dug history but couldn't find the root reason. http://dev.w3.org/cvsweb/2006/waf/access-control/Overview.src.html#rev1.262 This revision defined what credentials means clearly in response to Maciej's question http://www.w3.org/2008/webapps/track/issues/114. It started mentioning client certificates explicitly. If the reason is just to prevent distributed credentials search, don't client certificates which is not controlled by scripts need to be omitted? Is that the reason you've removed the definition of user credentials and controlling only cookies and authentication entries? http://dev.w3.org/cvsweb/2006/waf/access-control/Overview.src.html#rev1.181 This revision added a (clarification?) text (No credentials, ...) to explicitly prohibit adding any credential to the preflight request. http://dev.w3.org/cvsweb/2006/waf/access-control/Overview.src.html#rev1.174 This revision added a step to reuse original request headers after some filtering with a text (The request headers are not included ...). http://dev.w3.org/cvsweb/2006/waf/access-control/Overview.src.html#rev1.132 The reason why script-provided credentials are omitted is explained from this revision. I understand this. Thanks
Re: [whatwg] Notifications: the ability to specify notifications behavior
On Fri, Aug 15, 2014 at 1:37 AM, Robert Bindar robertbin...@gmail.com wrote: We can not say accurately if the default will always be false because the platform may or may not support the behavior, or it might be overridden by a user defined setting. Well, if we introduce new dictionary members they will default to false. So I guess what Jonas was asking for is that we should think of names that make sense given that. Of course, they will just be hints anyway due to platform conventions and user overrides. -- http://annevankesteren.nl/
Re: [whatwg] Notifications: the ability to specify notifications behavior
On Fri, Aug 15, 2014 at 1:54 AM, Michael Henretty michael.henre...@gmail.com wrote: On this note, it would be useful if content could query the UA for the default behaviors of any notifications it would send. Also, it would be nice to know which of these behaviors could be overridden by the behavior options. Uhm, what about fingerprinting, privacy, etc? -- http://annevankesteren.nl/
Re: [whatwg] How to determine content-type of file: protocol
于 2014/8/14 21:23, Nils Dagsson Moskopp 写道: duanyao duan...@ustc.edu writes: On 07/28/2014 22:08, Gordon P. Hemsley wrote: On 07/28/2014 08:01 AM, duanyao wrote: On 07/28/2014 06:34, Gordon P. Hemsley wrote: Sorry for the delay in responding. Your message fell through the cracks in my e-mail filters. On 07/17/2014 08:26 AM, duanyao wrote: Hi, My first question is about a rule in MIME Sniffing specification (http://mimesniff.spec.whatwg.org): 5.1 Interpreting the resource metadata ... If the resource is retrieved directly from the file system, set supplied-type to the MIME type provided by the file system. As far as I know, no main-stream file systems record MIME type for files. Does the spec actually want to say provided by the operating system or provided by the file name extension? Yeah, you've hit a known (though apparently unrecorded) bug in the spec, originally pointed out to me by Boris Zbarsky via IRC many months ago. The intent here is basically just whatever the computer says it is—whether that be via the file system, the operating system, or whatever, and whether it uses magic bytes, file extensions, or whatever. In other words, feel free to read that as the correct behavior is undefined/unknown at this point. Thanks for the explanation. Recently, file: protocol becomes more and more important due to the popularity of packaged web applications, including PhoneGap app, Chrome app, Firefox OS app, Window 8 HTML app, etc (not all of them use file: protocol directly, but underlying mechanisms are similar). So If we can't specify a interoperable way to determine a local file's mime type, porting of packaged web applications can be problematic in some situations (actually my team already hit this). I know that currently there is no standard way to determine a local file's mime type, this may be one of the reason that mimesniff spec has not defined a behavior here. Well, the most basic reason is because I never delved into how it actually works, because I was primarily concerned with HTTP connections. It's possible that there is no interoperable way to determine a local file's MIME type, but see below. I'd like to propose a simple way to resolve this problem: For mime types that has already been standardized by IANA and used in web standards, determine a local file's supplied-type according to its file extension. This list could include htm, html, xhtml, xml, svg, css, js, ipeg, ipg, png, mp4, webm, woff, etc. Otherwise, UAs can determine supplied-type by any means. I think this rule should resolve most of the interoperability problems, and largely maintain compatibility with current UAs' implementations. There is already a standard in place to detect file types on the operating system level: http://www.freedesktop.org/wiki/Specifications/shared-mime-info-spec/ http://cgit.freedesktop.org/xdg/shared-mime-info/ I could just refer to that and be done with it. Do you think that would work? (That specification has complex rules for detecting files, including magic bytes and whatnot, and is already used on a number of Linux distros and probably other operating systems.) Maybe no. (1) it's a standard of *nix desktops, I doubt MS widows will adopt it, I see this as pure speculation. MS Windows never have a similar mechanism like freedesktop. It can only determine mime-type from filename extension, not file content; and the mapping between extension and type is not even shipped with Windows itself -- it relies on installed applications to register extensions and mime-types. See http://stackoverflow.com/questions/3442607/mime-types-in-the-windows-registry . Do you have any clue that Windows will change this in near furture? and maybe it's a bit heavy for mobile OS; Widely used mobile operating systems are based on Unix (e.g. iOS, Android). Based on your measurements, how long does file(1) take? Android does have a mime-type database and can guess mime-type from both extension and content, i.e. java.net.URLConnection.guessContentTypeFromName(String filename) java.net.URLConnection.guessContentTypeFromStream(java.io.InputStream in) However, iOS doesn't have such things, and can only guess from extension. See http://stackoverflow.com/questions/1363813/how-can-you-read-a-files-mime-type-in-objective-c Not to mention windows phone. Sniffing mime-type from file content and using mime-type database is always much slower than guessing from extension, because much more data are required to read from disk, and much more CPU cycles are needed to analyze these data. This is why web servers only guess types from extensions. Also because browsers already implemented mime-type sniffing, it's a waste to do it twice. However, if most mobile OSs would ship with mime-type database in future and browsers are willing to use it, I'm OK. (2) many packaged web apps are ported from (and share codes with) normal web apps, and most web servers simply deduce mime
Re: [whatwg] [Fetch spec] Link to CORS FAQ wiki
On Fri, Aug 15, 2014 at 9:01 AM, Takeshi Yoshino tyosh...@google.com wrote: I asked this question because I spent much time to understand the reason why credentials are omitted for preflight requests. I think that was because it was a new type of request and we generally consider sending credentials cross-origin by default to be a mistake. But it seems the current Fetch spec has a different algorithm than the W3C CORS spec. The commit https://github.com/whatwg/fetch/commit/adec3d2bf35726b46dd6c0079ff01dba8e154711 has removed the definition of user credentials. Is this intentional? Before it, user credentials was defined as cookies, HTTP authentication, and client-side SSL certificates. Now the latest Fetch spec doesn't mention client certificates. If this is intentional, the CORS FAQ is not useful to understand the current Fetch spec. Not having a generic term like user credentials was intentional. However, this is an outstanding bug: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26556 It's a bit unclear to me how to accurately word the requirements. It seems like it will have to remain somewhat vague. Apologies for the time it cost you to look into this. I recommend having a cursory glance at the list of open bugs next time. I'm somewhat hesitant to include a direct link to the FAQ. There are several inaccuracies there and unlike what was predicted in May 2012, it never got maintained by the web community. If it was mostly about the credentials bit from the FAQ then yes, we need to explain that in the current specification, once we have all agreed how those things should work in detail. -- http://annevankesteren.nl/
Re: [whatwg] [Fetch spec] Link to CORS FAQ wiki
On Fri, Aug 15, 2014 at 7:09 PM, Anne van Kesteren ann...@annevk.nl wrote: On Fri, Aug 15, 2014 at 9:01 AM, Takeshi Yoshino tyosh...@google.com wrote: I asked this question because I spent much time to understand the reason why credentials are omitted for preflight requests. I think that was because it was a new type of request and we generally consider sending credentials cross-origin by default to be a mistake. But it seems the current Fetch spec has a different algorithm than the W3C CORS spec. The commit https://github.com/whatwg/fetch/commit/adec3d2bf35726b46dd6c0079ff01dba8e154711 has removed the definition of user credentials. Is this intentional? Before it, user credentials was defined as cookies, HTTP authentication, and client-side SSL certificates. Now the latest Fetch spec doesn't mention client certificates. If this is intentional, the CORS FAQ is not useful to understand the current Fetch spec. Not having a generic term like user credentials was intentional. However, this is an outstanding bug: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26556 It's a bit unclear to me how to accurately word the requirements. It seems like it will have to remain somewhat vague. Ah, Ryan has already done it. Thanks. I'll join there... Apologies for the time it cost you to look into this. I recommend having a cursory glance at the list of open bugs next time. I'm somewhat hesitant to include a direct link to the FAQ. There are several inaccuracies there and unlike what was predicted in May 2012, it never got maintained by the web community. If it was mostly about the credentials bit from the FAQ then yes, we need to explain that in the current specification, once we have all agreed how those things should work in detail. -- http://annevankesteren.nl/
Re: [whatwg] [Fetch spec] Link to CORS FAQ wiki
On Fri, Aug 15, 2014 at 7:12 PM, Takeshi Yoshino tyosh...@google.com wrote: On Fri, Aug 15, 2014 at 7:09 PM, Anne van Kesteren ann...@annevk.nl wrote: On Fri, Aug 15, 2014 at 9:01 AM, Takeshi Yoshino tyosh...@google.com wrote: I asked this question because I spent much time to understand the reason why credentials are omitted for preflight requests. I think that was because it was a new type of request and we generally consider sending credentials cross-origin by default to be a mistake. I see. Fair enough, and so we could revisit it now. But it seems the current Fetch spec has a different algorithm than the W3C CORS spec. The commit https://github.com/whatwg/fetch/commit/adec3d2bf35726b46dd6c0079ff01dba8e154711 has removed the definition of user credentials. Is this intentional? Before it, user credentials was defined as cookies, HTTP authentication, and client-side SSL certificates. Now the latest Fetch spec doesn't mention client certificates. If this is intentional, the CORS FAQ is not useful to understand the current Fetch spec. Not having a generic term like user credentials was intentional. However, this is an outstanding bug: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26556 It's a bit unclear to me how to accurately word the requirements. It seems like it will have to remain somewhat vague. Ah, Ryan has already done it. Thanks. I'll join there... Apologies for the time it cost you to look into this. I recommend having a cursory glance at the list of open bugs next time. I'm somewhat hesitant to include a direct link to the FAQ. There are several inaccuracies there and unlike what was predicted in May 2012, Yeah, it needs update as you say. it never got maintained by the web community. If it was mostly about the credentials bit from the FAQ then yes, we need to explain that in the current specification, once we have all agreed how those things should work in detail. OK! -- http://annevankesteren.nl/
[whatwg] Notification's click event should be cancelable
Hi, in order to prevent whatever default action Notification's click event has (for example focus the tab which initiated the Notification), the click event should be cancelable so that .preventDefault() can be called. Some background https://bugzilla.mozilla.org/show_bug.cgi?id=874050mark=25-26#c25 https://bugzilla.mozilla.org/show_bug.cgi?id=1009190#c0 -Olli
Re: [whatwg] Proposal: Wake Lock API
On Thu, 14 Aug 2014, at 11:00, Jonas Sicking wrote: I am however more worried about that only having a request() and a release() function means that pages that contain multiple independent subsystems will have to make sure that they don't stomp on each other's locks. Simply counting request() calls vs. release() calls helps, but doesn't fully solve the problem. It's very easy to accidentally call release too many times, in response to some UI action for example. An alternative design would be something like x = new WakeLock(display); x.request(); x.release(); Extra calls of either request() or release() are ignored, but pages can create any number of WakeLocks of the same type. It seems that we already discussed using an object and this solution was dismissed because of this model being error-prone. It's also not clear how this solution is superior than the current solution [1] with regards to multiple releases or requests. In [1], if you call .request() or .release() multiple time, the promise reacts appropriately. Typically, if you try to release() an un-hold lock, it will reject the promise. Is that something you are not satisfied with? [1] http://w3c.github.io/wake-lock/ ? -- Mounir
Re: [whatwg] Notifications: the ability to specify notifications behavior
On Aug 15, 2014 1:57 AM, Anne van Kesteren ann...@annevk.nl wrote: On Fri, Aug 15, 2014 at 1:37 AM, Robert Bindar robertbin...@gmail.com wrote: We can not say accurately if the default will always be false because the platform may or may not support the behavior, or it might be overridden by a user defined setting. Well, if we introduce new dictionary members they will default to false. So I guess what Jonas was asking for is that we should think of names that make sense given that. Of course, they will just be hints anyway due to platform conventions and user overrides. That's not necessarily true. Dictionary members default to absent if they don't have a default value. So we could treat default as different from both true and false. But it tends to make for a confusing API to treat optional boolean arguments as different from false. / Jonas
Re: [whatwg] exposing dependencies + weights (aka, priorities) to web developers
Hey, Thanks for writing this up! So to the extent we are simply exposing http/2 semantics, this spec seems pretty clear. Two questions that I have that aren't answered by the http/2 spec: - What do we expect the browser to do with priorities set cross domain. Eg, if I express that a.com/foo.js depends on b.com/bar.js, does the browser do anything about this. What if b.com/bar.js depends on a.com/blah.js. Would we tell a.com that foo.js depends on blah.js? - Developers might have something they would want to speculatively fetch only if http/2 is being used (and therefore they know the resource won't compete for bandwidth with other resources). Maybe this could be solved by simply allowing the user to tell if the browser supports http/2. A more advanced solution could be to allow the user to say don't send this fetch request unless it's over http/2. One other thing I didn't see any mention of in the write up -- it could be useful to change priority while the request is in flight. http/2 supports this, so it'd be great if this spec could expose it. On Thu, Aug 14, 2014 at 6:16 PM, Ilya Grigorik igrigo...@gmail.com wrote: (followup / continuation of [1]) Trying to hash out some ideas for how to connect Fetch and the new transport capabilities of HTTP/2. Would love to hear everyone's thoughts: https://docs.google.com/document/d/1jSpWc6jkrUoYtGWcxev9Blkkv9RhoO1XtqinBvXqhgY/edit ig [1] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2014-July/297257.html
Re: [whatwg] resource hints and separating download from processing
On Mon, 11 Aug 2014, Ilya Grigorik wrote: On Mon, Aug 11, 2014 at 12:57 PM, Ian Hickson i...@hixie.ch wrote: I hope to be able to post more concrete proposals soon, it's currently blocked on my understanding how I should be integrating HTML with ES6. Any bugs or threads that I can follow to track progress? I'd love to help if I can. My understanding of ES6 is mostly being helped by discussions on #whatwg and e-mail threads to es-discuss. Two high-level cases: (a) optimizing load sequence of page that's currently being loaded (b) optimizing page load of a (potential) future navigation For (a), we need to expose preconnect and preload, such that the developer and/or server (e.g. CDN accelerator) can tell the browser which hosts it should connect to, which resources it should load (+ with which priority, order), etc. Also, note that preload separates download from processing, which is an important feature - e.g. fetch CSS but don't evaluate it. Preload is straight forward, sure. How much does preconnect within a page actually help? Isn't just declaring the URLs enough? I don't really see how you expect this to be used or exposed. For (b), we're talking about a speculative hint, hence we attach a probability to the hint and let the UA decide if it has enough resources / time / etc, to execute it, and how far it is willing to go with response processing. The ability to tell a page what subsequent resources will be necessary (prerendering) seems pretty straight-forward too, sure. That's mostly a solved problem with rel=prerender, no? Anything we add to make fetching more powerful will automatically be exposed to that too, presumably. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] exposing dependencies + weights (aka, priorities) to web developers
On Fri, Aug 15, 2014 at 8:38 AM, Ben Maurer ben.mau...@gmail.com wrote: Hey, Thanks for writing this up! So to the extent we are simply exposing http/2 semantics, this spec seems pretty clear. Two questions that I have that aren't answered by the http/2 spec: - What do we expect the browser to do with priorities set cross domain. Eg, if I express that a.com/foo.js depends on b.com/bar.js, does the browser do anything about this. What if b.com/bar.js depends on a.com/blah.js. Would we tell a.com that foo.js depends on blah.js? Sure, the browser will take this into account in some ways, but not others. I wouldn't think about it too much, because given the level of the primitive being provided, this is an abstraction boundary that authors shouldn't cross. But yes, the browsers will leverage the information somewhat. More or less depending on the circumstances. Sorry for being vague :) If you need more exact controls, we probably need to expose lower level primitives. - Developers might have something they would want to speculatively fetch only if http/2 is being used (and therefore they know the resource won't compete for bandwidth with other resources). Maybe this could be solved by simply allowing the user to tell if the browser supports http/2. A more advanced solution could be to allow the user to say don't send this fetch request unless it's over http/2. Well, your server already knows about the http/2 support from the ALPN negotation, so it can emit different client code based on that. But if you want the logic to be in the client, then yes, the client must be able to detect http/2 support. There have been proposals on public-web-perf@ for that, and this reminds me that I promised Google web devs to push again for this. So, yeah, we should do that. One other thing I didn't see any mention of in the write up -- it could be useful to change priority while the request is in flight. http/2 supports this, so it'd be great if this spec could expose it. +1, although I don't know if Ilya was trying to subsume everything into this doc. On Thu, Aug 14, 2014 at 6:16 PM, Ilya Grigorik igrigo...@gmail.com wrote: (followup / continuation of [1]) Trying to hash out some ideas for how to connect Fetch and the new transport capabilities of HTTP/2. Would love to hear everyone's thoughts: https://docs.google.com/document/d/1jSpWc6jkrUoYtGWcxev9Blkkv9RhoO1XtqinBvXqhgY/edit ig [1] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2014-July/297257.html
Re: [whatwg] exposing dependencies + weights (aka, priorities) to web developers
On Thu, 14 Aug 2014, Ilya Grigorik wrote: Trying to hash out some ideas for how to connect Fetch and the new transport capabilities of HTTP/2. It would be great to get a set of use cases describing what your proposal is addressing, since that would more easily let people evaluate whether it's worth doing, and if so, whether this proposal does it. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] exposing dependencies + weights (aka, priorities) to web developers
Some cases I can think of off the top of my head: - A website has a page where media is the primary content. It would like to make sure that media is downloaded before JS (example: you go to flicker.com/my-image, the browser should probably prioiritize that image over a pice of javascript that is not critical to the user's interaction with the page). - A website knows there's a piece of Javascript code that the user might need if they click on a part of the page. The developer would like to have the user download it, but not at the expense of other resources. - A website is prefetching photos in a photo album and would like to make sure these images are lower priority than images the user is actually viewing. On Fri, Aug 15, 2014 at 9:17 AM, Ian Hickson i...@hixie.ch wrote: On Thu, 14 Aug 2014, Ilya Grigorik wrote: Trying to hash out some ideas for how to connect Fetch and the new transport capabilities of HTTP/2. It would be great to get a set of use cases describing what your proposal is addressing, since that would more easily let people evaluate whether it's worth doing, and if so, whether this proposal does it. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] meta referrer as always-origin
Hi All, Right now the meta referrer spec has two separate features: You can specify a origin policy which enables sending just the origin whenever a referrer is sent. You can also specify always in order to override UA policies like don't send referrer when navigating from https to http sites. However you currently can't combine the two. I.e. if you want to override UA policies, you are forced to send the whole URL string. This seems counter intuitive since that's when you might really want to just send the origin. Could we introduce a always-origin value for meta referrer which combines the origin and always policies? / Jonas
Re: [whatwg] resource hints and separating download from processing
On Fri, Aug 15, 2014 at 9:26 AM, Ian Hickson i...@hixie.ch wrote: Two high-level cases: (a) optimizing load sequence of page that's currently being loaded (b) optimizing page load of a (potential) future navigation For (a), we need to expose preconnect and preload, such that the developer and/or server (e.g. CDN accelerator) can tell the browser which hosts it should connect to, which resources it should load (+ with which priority, order), etc. Also, note that preload separates download from processing, which is an important feature - e.g. fetch CSS but don't evaluate it. Preload is straight forward, sure. How much does preconnect within a page actually help? Isn't just declaring the URLs enough? I don't really see how you expect this to be used or exposed. It's often the case that you don't know the exact URL you want to fetch (e.g. the URL is generated based on local client context, etc), but you know that you *will* connect to a certain host - lots of third party widgets, fonts, etc, fall into this category. As a concrete example: - link href='https://fonts.googleapis.com/css?family=Open+Sans' rel='stylesheet' - above stylesheet is dynamic and returns a pointer to a UA optimized font file that lives on https://fonts.gstatic.com As a result, I know that I'll need a connection to https://fonts.gstatic.com, but I don't know the exact URL. Also, because we're talking HTTPS, we're looking at up to 4 RTTs (DNS, TCP, TLS), which can easily translate to 1s+ on mobile connections. Issuing an early preconnect allows us to hide some or all of this latency. Another example is improving performance of redirect click trackers, see example 2: https://igrigorik.github.io/resource-hints/#preconnect For (b), we're talking about a speculative hint, hence we attach a probability to the hint and let the UA decide if it has enough resources / time / etc, to execute it, and how far it is willing to go with response processing. The ability to tell a page what subsequent resources will be necessary (prerendering) seems pretty straight-forward too, sure. That's mostly a solved problem with rel=prerender, no? Anything we add to make fetching more powerful will automatically be exposed to that too, presumably. Solved in the sense that we have the attributed listed in the HTML spec. Not solved in the sense that current implementations of prerender can (and need to) be significantly improved - e.g. how they handle different content types, how they handle resource contention, how the developer can communicate the context/probability of using the hinted resource, the APIs available to invoke these actions (dynamic scheduling/canceling, HTTP headers), and so on. Further, now that we have multiple implementations (Chrome, IE, and FF has started working on it), we need a common spec such that we can deliver a consistent API and experience. That said, I think we're on the same page... I'm just arguing that X will subsume resource hints is not entirely true: we still need to define how preconnect/preload/prerender need to behave, which APIs they will expose, what guarantees they will provide, and so on. None of that is currently spec'ed, which is the gap I'm trying to fill. ig
Re: [whatwg] resource hints and separating download from processing
On Fri, 15 Aug 2014, Ilya Grigorik wrote: - link href='https://fonts.googleapis.com/css?family=Open+Sans' rel='stylesheet' - above stylesheet is dynamic and returns a pointer to a UA optimized font file that lives on https://fonts.gstatic.com Ah, yeah, that's an excellent example. Thanks. That said, I think we're on the same page... I'm just arguing that X will subsume resource hints is not entirely true: we still need to define how preconnect/preload/prerender need to behave, which APIs they will expose, what guarantees they will provide, and so on. None of that is currently spec'ed, which is the gap I'm trying to fill. I totally agree that more detailed specs for rel=prerender, rel=preconnect, and rel=prefetch/preload/subresource would be useful. I may end up speccing the latter, but what I'm doing doesn't so far have any direct impact on the former two. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal: Wake Lock API
On Fri, Aug 15, 2014 at 6:14 AM, Mounir Lamouri mou...@lamouri.fr wrote: On Thu, 14 Aug 2014, at 11:00, Jonas Sicking wrote: I am however more worried about that only having a request() and a release() function means that pages that contain multiple independent subsystems will have to make sure that they don't stomp on each other's locks. Simply counting request() calls vs. release() calls helps, but doesn't fully solve the problem. It's very easy to accidentally call release too many times, in response to some UI action for example. An alternative design would be something like x = new WakeLock(display); x.request(); x.release(); Extra calls of either request() or release() are ignored, but pages can create any number of WakeLocks of the same type. It seems that we already discussed using an object and this solution was dismissed because of this model being error-prone. Where was this discussed? Why was it considered more error prone? Was it related to the patterns discussed at http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2014-August/297431.html It's also not clear how this solution is superior than the current solution [1] with regards to multiple releases or requests. In [1], if you call .request() or .release() multiple time, the promise reacts appropriately. The problem arises when you have several semi-independent pieces of code within a single page. Given that request() and release() is likely going to happen in response to very different UI events or IO events, it makes it fairly easy to accidentally have unbalanced calls. Consider for example a lock which is released either when a video reaches its end, when the user presses the pause button, or when the user close the dialog in which the video is rendered. It seems quite easy to end up with a race where if the user close the dialog right when the video ends, that release() would get called twice. Or if the user pause the video first and then close the dialog that release() would get called twice. If there's only one subsystem of the page that uses a display lock, then this is not a big deal. The extra call to release() would cause an rejection, but hopefully that won't break the page. However if there are multiple subsystems that all use a display lock, it would mean that those subsystems might stomp on each other's attempts at holding a display lock. The effect would be that the display lock is released too early. I don't care strongly about this though. It's pretty easy for pages to write a wrapper around the currently proposed API to implement the API that I'm proposing. / Jonas
