Hi Francois,Thanks for the feedback.
> From: francois-xavier.kowal...@hp.com
> To: public-webapps@w3.org
> Date: Wed, 20 Nov 2013 20:30:47 +
> Subject: Comments on version web-apps specs from 2013-10-31
>
> Hello
>
> I have a few comments on:
> https://dvcs.w3.org/hg/streams-api/raw-file/ti
On Wed, Nov 20, 2013 at 7:34 PM, Ryosuke Niwa wrote:
> On Nov 21, 2013, at 10:41 AM, Hajime Morrita wrote:
> > Seems like almost everyone agrees that we need better way to
> > modularize JavaScript, and ES6 modules are one of the most promising
> > way to go. And we also agree (I think) that we
On Nov 21, 2013, at 10:41 AM, Hajime Morrita wrote:
> Seems like almost everyone agrees that we need better way to
> modularize JavaScript, and ES6 modules are one of the most promising
> way to go. And we also agree (I think) that we need a way to connect
> ES6 modules and the browser.
>
> What
I'd frame the problem in a slightly different way.
Seems like almost everyone agrees that we need better way to
modularize JavaScript, and ES6 modules are one of the most promising
way to go. And we also agree (I think) that we need a way to connect
ES6 modules and the browser.
What we don't cons
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23878
Bug ID: 23878
Summary: figure out termination of requests when documents
become inactive
Product: WebAppsWG
Version: unspecified
Hardware: Other
OS: All
On Wed, Nov 20, 2013 at 12:38 PM, Brian Di Palma wrote:
> On Tue, Nov 19, 2013 at 10:16 PM, Rick Waldron
> wrote:
> >
> >
> >
> > On Mon, Nov 18, 2013 at 11:26 PM, Ryosuke Niwa wrote:
> >>
> >> We share the concern Jonas expressed here as I've repeatedly mentioned
> on
> >> another threads.
> >
Hello
I have a few comments on:
https://dvcs.w3.org/hg/streams-api/raw-file/tip/Overview.htm from 2013-10-31.
Apologies wether it is not the latest version: It took me some time to
figure-out where was the right forum to send these comments to.
Section 2.1.3:
1. Close(): For writeable stre
On Tue, Nov 19, 2013 at 10:16 PM, Rick Waldron wrote:
>
>
>
> On Mon, Nov 18, 2013 at 11:26 PM, Ryosuke Niwa wrote:
>>
>> We share the concern Jonas expressed here as I've repeatedly mentioned on
>> another threads.
>>
>> On Nov 18, 2013, at 4:14 PM, Jonas Sicking wrote:
>>
>> This has several d
On Nov 20, 2013 11:07 AM, "John J Barton"
wrote:
>
>
>
>
> On Wed, Nov 20, 2013 at 10:41 AM, Daniel Buchner
wrote:
>>
>> Dimitri: right on.
>>
>> The use of script-after-import is the forcing function in the blocking
scenario, not imports.
>
> Yes.
>>
>> Let's not complicate the new APIs and burd
On Wed, Nov 20, 2013 at 10:41 AM, Daniel Buchner wrote:
> Dimitri: right on.
>
> The use of script-after-import is the forcing function in the blocking
> scenario, not imports.
>
Yes.
> Let's not complicate the new APIs and burden the overwhelming use-case to
> service folks who intend to use th
Dimitri: right on.
The use of script-after-import is the forcing function in the blocking
scenario, not imports. Let's not complicate the new APIs and burden the
overwhelming use-case to service folks who intend to use the technology in
alternate ways.
For my bit, as long as the size of the compo
On Wed, Nov 20, 2013 at 9:51 AM, John J Barton
wrote:
> Another alternative:
>
> First let's agree that Souder's example must block:
>
>
>
> ...
>
>
>
> var link = document.querySelector('link[rel=import]');
> var content = link.import.querySelector('#imported-content');
> document.getElementB
John's commentary just triggered a thought in my head. We should stop
saying that HTML Imports block rendering. Because in reality, they don't.
It's the scripts that block rendering.
Steve's argument is not about HTML Imports needing to be async. It's about
supporting legacy content with HTML Impo
Another alternative:
First let's agree that Souder's example must block:
...
var link = document.querySelector('link[rel=import]');
var content = link.import.querySelector('#imported-content');
document.getElementById('import-container').appendChild(content.cloneNode(true));
If we don't bl
14 matches
Mail list logo
