Re: Request for feedback: Streams API
On 12/04/2013 06:27 PM, Feras Moussa wrote: The editors of the Streams API have reached a milestone where we feel many of the major issues that have been identified thus far are now resolved and incorporated in the editors draft. The editors draft [1] has been heavily updated and reviewed the past few weeks to address all concerns raised, including: 1. Separation into two distinct types -ReadableByteStream and WritableByteStream 2. Explicit support for back pressure management 3. Improvements to help with pipe( ) and flow-control management 4. Updated spec text and diagrams for further clarifications There are still a set of bugs being tracked in bugzilla. We would like others to please review the updated proposal, and provide any feedback they may have (or file bugs). Thanks. -Feras [1] https://dvcs.w3.org/hg/streams-api/raw-file/tip/Overview.htm So per https://www.w3.org/Bugs/Public/show_bug.cgi?id=24054 it is not clear to me why the API is heavily Promise based. Event listeners tend to work better with stream like APIs. (The fact the Promises are hip atm is not a reason to use them for everything ;) ) -Olli
Re: File API: closed Blob objects
On Fri, Dec 13, 2013 at 6:30 PM, Jonas Sicking jo...@sicking.cc wrote: What does FormData do if reading from a Blob fails due to IO error? Crash. Same for XMLHttpRequest's send() method. Do you know what implementations do for the latter? -- http://annevankesteren.nl/
[Bug 24114] New: [imports]: add support for async loading
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24114 Bug ID: 24114 Summary: [imports]: add support for async loading Product: WebAppsWG Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P2 Component: Component Model Assignee: dglaz...@chromium.org Reporter: bmcqu...@google.com QA Contact: public-webapps-bugzi...@w3.org CC: espr...@gmail.com, m...@w3.org, morr...@google.com, public-webapps@w3.org Blocks: 20683 Resources imported via link rel=import are not parser blocking, but are typically render blocking. Render blocking but not parser blocking is the right default behavior, as the primary use case for link rel=import is to load content (e.g. custom elements) needed to render that document. However, a web developer may wish to load an import without blocking rendering. Use cases: * developer wishes to prefetch a custom element that is not needed to render the initial view, but which will be needed once the user interacts with the web app. developer would like the resource to be loaded and processed once it is available, but does not want rendering of the page to block on the load of that component. * developer uses a web component that can be sufficiently styled before being upgraded using :unresolved, and thus it is not necessary to block rendering on that component. This only works well for components whose size is known before their custom element has finished loading; else a reflow happens when the component loads and the element changes size. In these cases, it is preferable that the user of the page not have to wait for the import to finish downloading before they are able to see the other content in the web app display on the screen. However, it is desirable that once the import finishes downloading, that import should be processed and loaded into the document (i.e. this isn't just a prefetch of content into the browser cache), so it is fully loaded and available by the time the web app needs it (thus it's also important that these elements fire a load event so developers know when they are available for use). Thus, we propose that, like script async, we add support for link rel=import async to address this use case. At a high level, developers should think of these similarly: I want to load this script/import but I don't want its load to block the rest of the content on the page from rendering. There is a key difference between script async and link async: script async indicates that the script should not block the parser. link rel=import is already spec'd to not block the parser by default, async or not. However, since imports are intended to block rendering by default, link async rel=import indicates that the browser should not block rendering on the load of the imported resource. I am not aware of render-blocking behavior being spec'd as part of HTML5, and this is probably for good reason: it is up to each user agent (browser) to decide when and what to paint during the course of a web page load. However, in practice, all browsers I'm aware of block rendering on the load of pending stylesheets, and similarly, will block rendering on the load of pending imports. Thus, link async is an indicator to the user agent that the load of the imported resource should not block rendering. In a conversation with dglazkov and esprehn, we proposed that link async apply not only to imports, but also to stylesheets. The spec'd behavior should be the same in each case: an import or stylesheet with an async attribute should not block rendering of the page. Whether to spec this as should not or must not block rendering is unclear: at first glance, should not seems appropriate. However, if spec'd as should not and one UA decides not to implement this behavior (they allow async imports to block rendering) then developers will likely abandon this technique and resort to JavaScript workaround that don't work particularly well (i.e. loading the import after a requestAnimationFrame callback, which has various drawbacks). Thus, in order to provide a way to load stylesheets and imports without blocking render that is guaranteed to work across browser vendors, my inclination would be to spec this behavior as must not block rendering while being loaded. -- You are receiving this mail because: You are on the CC list for the bug.
Re: File API: closed Blob objects
On Thu, Dec 12, 2013 at 9:07 AM, Anne van Kesteren ann...@annevk.nl wrote: See https://www.w3.org/Bugs/Public/show_bug.cgi?id=24072 for context. What's the use case for close()? If we are to have close(), let's define it in such a way that once you invoke it the Blob represents the empty byte sequence. This way other code that takes and operates on Blob objects does not have to special case closed Blob objects, but can just treat them as Blob objects that happen to be empty. Also, you can close() a Blob while an async XHR is taking place on it. That shouldn't affect the running operation. It also means you can say xhr.open(GET, blobURL); blob.close(); and have it work sensibly--the UA can throw away the data as soon as all current operations on it have completed. This could be handled by synchronously taking a reference to the underlying Blob data during the open() call. (There are other issues about blob URLs that need this, too, such as if a blob URL is revoked at various times during fetch.) If this is handled as part of parsing a URL string to a logical URL object, and if that's done synchronously, that could take care of a number of issues without any special casing. -- Glenn Maynard
Re: Refactoring SharedWorkers out of Web Workers W3C spec
On 12/12/13 16:20, James Graham wrote: On 12/12/13 15:13, Boris Zbarsky wrote: On 12/11/13 8:42 AM, Arthur Barstow wrote: [IR] http://www.w3.org/wiki/Webapps/Interop/WebWorkers Looking at this link, there are passes marked for obviously incorrect tests (e.g. see https://www.w3.org/Bugs/Public/show_bug.cgi?id=24077 which says that http://w3c-test.org/web-platform-tests/master/workers/interfaces/DedicatedWorkerGlobalScope/postMessage/second-argument-null.html should fail in any conformant UA, but it's marked as passing in Opera and Chrome. So presumably we will need to rerun the tests in all UAs again once all the bugs have been fixed, yes? Yes. I have found another couple of trivial bugs in the tests which I will fix up. I will also have a got at fixing Ms2ger's test runner to work in a better way, sort out some way to automate the visual output, and hopefully we can generate a new implementation report with minimal effort. So, I made a sample implementation report [1] using an in-browser test runner based on Ms2ger's earlier work (see public-test-infra for more details). The browsers are those that happened to be on my computer. I don't intend for anyone to take these results as authoritative, and more work is needed, but it is much better than editing a wiki. And has revealed yet more bugs in the tests. In time we can use this approach in collaboration with vendors to fully automate generating implementation reports. [1] http://hoppipolla.co.uk/410/workers.html
Re: Refactoring SharedWorkers out of Web Workers W3C spec
On 12/16/13 11:20 AM, ext James Graham wrote: On 12/12/13 16:20, James Graham wrote: On 12/12/13 15:13, Boris Zbarsky wrote: On 12/11/13 8:42 AM, Arthur Barstow wrote: [IR] http://www.w3.org/wiki/Webapps/Interop/WebWorkers Looking at this link, there are passes marked for obviously incorrect tests (e.g. see https://www.w3.org/Bugs/Public/show_bug.cgi?id=24077 which says that http://w3c-test.org/web-platform-tests/master/workers/interfaces/DedicatedWorkerGlobalScope/postMessage/second-argument-null.html should fail in any conformant UA, but it's marked as passing in Opera and Chrome. So presumably we will need to rerun the tests in all UAs again once all the bugs have been fixed, yes? Yes. I have found another couple of trivial bugs in the tests which I will fix up. I will also have a got at fixing Ms2ger's test runner to work in a better way, sort out some way to automate the visual output, and hopefully we can generate a new implementation report with minimal effort. So, I made a sample implementation report [1] using an in-browser test runner based on Ms2ger's earlier work (see public-test-infra for more details). The browsers are those that happened to be on my computer. I don't intend for anyone to take these results as authoritative, and more work is needed, but it is much better than editing a wiki. And has revealed yet more bugs in the tests. In time we can use this approach in collaboration with vendors to fully automate generating implementation reports. [1] http://hoppipolla.co.uk/410/workers.html James - this is excellent! Did you run the tests via http://www.w3c-test.org/testrunner/workers/? What would it take to include Travis's IE results? -Thanks, ArtB
Re: File API: closed Blob objects
On Mon, Dec 16, 2013 at 10:16 AM, Anne van Kesteren ann...@annevk.nlwrote:
On Mon, Dec 16, 2013 at 4:07 PM, Glenn Maynard gl...@zewt.org wrote:
What I meant is that it would be good for the above pattern to work, and
not
cause an IO error.
Can't you always get an IO error? User removes the file, some kind of
hard drive failure, etc.
Sure. I mean that it shouldn't fail at all. We should enable this as a
pattern:
function doSomething(url)
{
var xhr = new XMLHttpRequest();
xhr.open(GET, url);
xhr.send();
xhr.onload = complete_request;
}
...
function foo()
{
var blob = createSomeBlob();
var url = URL.createObjectURL(blob);
doSomething(url);
URL.revokeObjectURL(url); // or use autorevoke, but this should work too
blob.close();
}
Where the author of foo() doesn't know anything about the internals of
doSomething. If this throws an IO error then it won't work, since closing
the blob will cause doSomething's request to fail. You'd have to either
add a callback mechanism so foo() can call close() later, which you
shouldn't need to do for an API that simply takes a URL.
This way, you call close() to indicate that you're done with the instance
of the blob. The browser can't actually discard the underlying data
immediately, but it knows that it can as soon as the XHR fetch finishes.
This would be undetectable from scripts and the blob would still be
unusable for the script immediately.
--
Glenn Maynard
Re: Refactoring SharedWorkers out of Web Workers W3C spec
On 16/12/13 16:43, Arthur Barstow wrote: On 12/16/13 11:20 AM, ext James Graham wrote: On 12/12/13 16:20, James Graham wrote: On 12/12/13 15:13, Boris Zbarsky wrote: On 12/11/13 8:42 AM, Arthur Barstow wrote: [IR] http://www.w3.org/wiki/Webapps/Interop/WebWorkers Looking at this link, there are passes marked for obviously incorrect tests (e.g. see https://www.w3.org/Bugs/Public/show_bug.cgi?id=24077 which says that http://w3c-test.org/web-platform-tests/master/workers/interfaces/DedicatedWorkerGlobalScope/postMessage/second-argument-null.html should fail in any conformant UA, but it's marked as passing in Opera and Chrome. So presumably we will need to rerun the tests in all UAs again once all the bugs have been fixed, yes? Yes. I have found another couple of trivial bugs in the tests which I will fix up. I will also have a got at fixing Ms2ger's test runner to work in a better way, sort out some way to automate the visual output, and hopefully we can generate a new implementation report with minimal effort. So, I made a sample implementation report [1] using an in-browser test runner based on Ms2ger's earlier work (see public-test-infra for more details). The browsers are those that happened to be on my computer. I don't intend for anyone to take these results as authoritative, and more work is needed, but it is much better than editing a wiki. And has revealed yet more bugs in the tests. In time we can use this approach in collaboration with vendors to fully automate generating implementation reports. [1] http://hoppipolla.co.uk/410/workers.html James - this is excellent! Did you run the tests via http://www.w3c-test.org/testrunner/workers/? What would it take to include Travis's IE results? No, this is based on a new-ish tool that itself depends on the self-hosted-tests changes [1]. If Travis can make the results available in the same JSON format the tool uses then we can incorporate them directly; having a common, machine-writable format is the essential point of this work. However I would suggest that he waits until we fix the broken tests and land the self-hosted-tests changes and test runner / report generator. If people are interesting in speeding this process up, the most valuable thing they can do is help finish the review at [1]. [1] https://critic.hoppipolla.co.uk/r/368
Contributions Re: Call for Exclusions: DOM Parsing and Serialization
On Fri, 13 Dec 2013 16:42:20 +0400, Anne van Kesteren ann...@annevk.nl wrote: On Thu, Dec 12, 2013 at 6:31 PM, Charles McCathie Nevile cha...@yandex-team.ru wrote: It's unclear what you think we should be doing differently. Well, for instance, that when I point something out that was missed I am not directed to submit my feedback again, elsewhere. Hmm. That isn't what happened: [[[ On 12/10/13 10:54 AM, ext Anne van Kesteren wrote: On Tue, Dec 10, 2013 at 3:42 PM, Arthur Barstow art.bars...@nokia.com wrote: During the CfC, I only recall one technical comment and Travis created bug [23936] for that comment and he noted that comment will be considered as a `LC comment`. It seems the technical comment about it blatantly contradicting the DOM Standard went lost somehow. It's not ready for Last Call. Well, it certainly wouldn't be the first time we've had more than one LC ... Anyhow, if the bug doesn't capture your concern(s), please update it. ]]] i.e. we believe the editor is tracking your feedback, we hope we have correctly interpreted it, and in case we haven't you have a pointer to correct us. You're not directed to submit it again, we're trying our best to ensure that we don't misunderstand and fail to deal with it adequately. So I still think there is a misunderstanding here rather than a real problem - but if I am wrong, I'm happy to keep trying to find out what the problem that we should solve is. (Please note that I am not trying to pick on you. In this particular instance I think we have ended up wasting more of everyone's, and in particular each others', time than we needed to, by not being very clear in the first place. And for my fault in that I apologise). cheers -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: New manifest spec - ready for FPWD?
On Monday, December 9, 2013 at 10:51 PM, Mounir Lamouri wrote: On Wed, Dec 4, 2013, at 10:03, Marcos Caceres wrote: From the research we’ve done, none of the proprietary solutions currently do this. I’ve added this as a feature request [1] so we can see how much interest there is. I think it is exaggerated to say that pages rely on the user seeing the page title. I tend to agree (particularly for apps that have been added to the home screen). Apps that want to display their own name (e.g., Google’s Authenticator app on iOS does this) can do that with HTML. Having said that, there are other contexts where showing the title makes sense (in a task switcher - or when organizing tabs). But that’s generally handled by the OS. It is very uncommon to be able to read more than a couple of words and depending on your browser/system you might not even see the page title at all (the case for me because I rarely have less than a dozen tabs open). I think the back button and reload buttons might be critical to be able to run some apps while the page title is simply a nice to have. Yeah, I think I’m reaching the same conclusion. I’ll keep looking for other examples and document them here: https://github.com/w3c/manifest/issues/89
