Re: [HTML Imports]: Sync, async, -ish?
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 block on the script tag then we have a race between the
querySelector and the import, fail.
To me the async solution is on the script, just like it is today load
events:
var link = document.querySelector('link[rel=import]');
link.addEventListener('load', function() {
var content = link.import.querySelector('#imported-content');
document.getElementById('import-container').appendChild(content.cloneNode(true));
}
Now the script still blocks but it is short and just registers a handler.
When the link loads it is executed. Here the dependency is correctly set by
the script tag.
But I don't see a 'load' event in the Import spec,
http://www.w3.org/TR/html-imports/
jjb
On Mon, Nov 18, 2013 at 1:40 PM, Dimitri Glazkov wrote:
> 'Sup yo!
>
> There was a thought-provoking post by Steve Souders [1] this weekend that
> involved HTML Imports (yay!) and document.write (boo!), which triggered a
> Twitter conversation [2], which triggered some conversations with Arv and
> Alex, which finally erupted in this email.
>
> Today, HTML Imports loading behavior is very simply defined: they act like
> stylesheets. They load asynchronously, but block
Re: [HTML Imports]: Sync, async, -ish?
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 Imports. And I have a bit less sympathy for that argument. You can totally build fully asynchronous HTML Imports-based documents, if you follow these two simple rules: 1) Don't put scripts after imports in main document 2) Use custom elements As an example: index.html: ... .. my-ad.html:
Re: [HTML Imports]: Sync, async, -ish?
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.getElementById('import-container').appendChild(content.cloneNode(true));
>
>
> If we don't block on the script tag then we have a race between the
> querySelector and the import, fail.
>
> To me the async solution is on the script, just like it is today load
> events:
>
>
>
> var link = document.querySelector('link[rel=import]');
>
>
> link.addEventListener('load', function() {
> var content = link.import.querySelector('#imported-content');
>
> document.getElementById('import-container').appendChild(content.cloneNode(true));
>
>
> }
>
>
> Now the script still blocks but it is short and just registers a handler.
> When the link loads it is executed. Here the dependency is correctly set by
> the script tag.
>
> But I don't see a 'load' event in the Import spec,
> http://www.w3.org/TR/html-imports/
>
The link element already has a generic "load" event in the HTML spec:
http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#attr-link-crossorigin(I
tried to get as close as possible to the actual line without
overshooting).
> jjb
>
>
> On Mon, Nov 18, 2013 at 1:40 PM, Dimitri Glazkov wrote:
>
>> 'Sup yo!
>>
>> There was a thought-provoking post by Steve Souders [1] this weekend that
>> involved HTML Imports (yay!) and document.write (boo!), which triggered a
>> Twitter conversation [2], which triggered some conversations with Arv and
>> Alex, which finally erupted in this email.
>>
>> Today, HTML Imports loading behavior is very simply defined: they act
>> like stylesheets. They load asynchronously, but block
Re: [HTML Imports]: Sync, async, -ish?
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 components I include are not overly large, I want them to load before the first render and avoid getting FUCd or having to write a plethora of special CSS for the not-yet-upgraded custom element case. Make the intended/majority case easy, and put the onus on the less common cases to think about more complex asset arrangement. - Daniel On Nov 20, 2013 10:22 AM, "Dimitri Glazkov" wrote: > 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 Imports. And I have a bit less sympathy > for that argument. > > You can totally build fully asynchronous HTML Imports-based documents, if > you follow these two simple rules: > 1) Don't put scripts after imports in main document > 2) Use custom elements > > As an example: > > index.html: > > ... > > .. > > my-ad.html: >
Re: [HTML Imports]: Sync, async, -ish?
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 the technology in alternate ways. > I disagree, but happily the current API seems to handle the alternative just fine. The case Steve raise is covered and IMO correctly, now that you have pointed out that link supports load event. His original example must block and if he wants it not to block it's on him to hook the load event. > For my bit, as long as the size of the components I include are not overly > large, I want them to load before the first render and avoid getting FUCd > or having to write a plethora of special CSS for the not-yet-upgraded > custom element case. > According to my understanding, you are likely to be disappointed: the components are loaded asynchronously and on a slow network with a fast processor we will render page HTML before the component arrives. We should expect this to be the common case for the foresable future. jjb > Make the intended/majority case easy, and put the onus on the less common > cases to think about more complex asset arrangement. > > - Daniel > On Nov 20, 2013 10:22 AM, "Dimitri Glazkov" wrote: > >> 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 Imports. And I have a bit less >> sympathy for that argument. >> >> You can totally build fully asynchronous HTML Imports-based documents, if >> you follow these two simple rules: >> 1) Don't put scripts after imports in main document >> 2) Use custom elements >> >> As an example: >> >> index.html: >> >> ... >> >> .. >> >> my-ad.html: >>
Re: [HTML Imports]: Sync, async, -ish?
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 burden the overwhelming use-case to service folks who intend to use the technology in alternate ways. > > I disagree, but happily the current API seems to handle the alternative just fine. The case Steve raise is covered and IMO correctly, now that you have pointed out that link supports load event. His original example must block and if he wants it not to block it's on him to hook the load event. >> >> For my bit, as long as the size of the components I include are not overly large, I want them to load before the first render and avoid getting FUCd or having to write a plethora of special CSS for the not-yet-upgraded custom element case. > > According to my understanding, you are likely to be disappointed: the components are loaded asynchronously and on a slow network with a fast processor we will render page HTML before the component arrives. We should expect this to be the common case for the foresable future. > There is, of course, the case of direct document.register() invocation from a script tag, which will/should block to ensure all elements in original source are upgraded. My only point, is that we need to be realistic - both cases are valid and there are good reasons for each. Might we be able to let imports load async, even when a script proceeds them, if we added a *per component type* upgrade event? (note: I'm not talking about a perf-destroying per component instance event) > jjb >> >> Make the intended/majority case easy, and put the onus on the less common cases to think about more complex asset arrangement. >> >> - Daniel >> >> On Nov 20, 2013 10:22 AM, "Dimitri Glazkov" wrote: >>> >>> 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 Imports. And I have a bit less sympathy for that argument. >>> >>> You can totally build fully asynchronous HTML Imports-based documents, if you follow these two simple rules: >>> 1) Don't put scripts after imports in main document >>> 2) Use custom elements >>> >>> As an example: >>> >>> index.html: >>> >>> ... >>> >>> .. >>> >>> my-ad.html: >>>
Re: [HTML Imports]: what scope to run in
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 downsides:
>> * Libraries can easily collide with each other by trying to insert
>> themselves into the global using the same property name.
>> * It means that the library is forced to hardcode the property name
>> that it's accessed through, rather allowing the page importing the
>> library to control this.
>> * It makes it harder for the library to expose multiple entry points
>> since it multiplies the problems above.
>> * It means that the library is more fragile since it doesn't know what
>> the global object that it runs in looks like. I.e. it can't depend on
>> the global object having or not having any particular properties.
>>
>>
>> Or for that matter, prototypes of any builtin type such as Array.
>>
>> * Internal functions that the library does not want to expose require
>> ugly anonymous-function tricks to create a hidden scope.
>>
>>
>> IMO, this is the biggest problem.
>>
>> Many platforms, including Node.js and ES6 introduces modules as a way
>> to address these problems.
>>
>>
>> Indeed.
>>
>> At the very least, I would like to see a way to write your
>> HTML-importable document as a module. So that it runs in a separate
>> global and that the caller can access exported symbols and grab the
>> ones that it wants.
>>
>> Though I would even be interested in having that be the default way of
>> accessing HTML imports.
>>
>>
>> Yes! I support that.
>>
>> I don't know exactly what the syntax would be. I could imagine something
>> like
>>
>> In markup:
>>
>>
>> Once imported, in script:
>> new $('mylib').import.MyCommentElement;
>> $('mylib').import.doStuff(12);
>>
>> or
>>
>> In markup:
>>
>>
>> Once imported, in script:
>> new MyCommentElement;
>> doStuff(12);
>>
>>
>> How about this?
>>
>> In the host document:
>>
>>
>> foo1.bar();
>> foo2();
>>
>>
>> In foo.js:
>> module foo1 {
>> export function bar() {}
>> }
>> function foo2() {}
>
>
>
> Inline module syntax was removed and will not be included in the ES6 module
> specification. Furthermore, the example you've illustrated here isn't
> entirely valid, but the valid parts are already covered within the scope of
> ES6 modules:
>
> // in some HTML...
>
> import {foo1, foo2} from "foo";
>
> foo1();
> foo2();
>
>
> // foo.js
> export function foo1() {}
> export function foo2() {}
>
>
> (note that foo2 isn't exported in your example, so would be undefined)
>
> Rick
>
I thought if an identifier wasn't exported trying to import it would
result in fast failure (SyntaxError)?
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/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 streams, the close() method does not provide a data-completion hook (all-data-flushed-to-destination), unlike the close method that resolved the Promise returned by read(). 2. Pipe(): the readable Steam (the one that provides the pipe() method) is neutered in case of I/O error, but the state change of the writeable stream is not indicated. What if the write operation failed? Section 3.2: 1. Shouldn't a FileWrite also be capable of consuming a Stream? (Like XHR-pipe-to-FileWriter) 2. Shouldn't an XMLHttpRequest also be capable of consuming a Stream? (eg. chunked PUT/POST)? br. —FiX PS: My request to join this group is pending, so please Cc me in any reply/comment you may have until membership is fixed.
Re: [HTML Imports]: what scope to run in
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.
> >>
> >> On Nov 18, 2013, at 4:14 PM, Jonas Sicking wrote:
> >>
> >> This has several downsides:
> >> * Libraries can easily collide with each other by trying to insert
> >> themselves into the global using the same property name.
> >> * It means that the library is forced to hardcode the property name
> >> that it's accessed through, rather allowing the page importing the
> >> library to control this.
> >> * It makes it harder for the library to expose multiple entry points
> >> since it multiplies the problems above.
> >> * It means that the library is more fragile since it doesn't know what
> >> the global object that it runs in looks like. I.e. it can't depend on
> >> the global object having or not having any particular properties.
> >>
> >>
> >> Or for that matter, prototypes of any builtin type such as Array.
> >>
> >> * Internal functions that the library does not want to expose require
> >> ugly anonymous-function tricks to create a hidden scope.
> >>
> >>
> >> IMO, this is the biggest problem.
> >>
> >> Many platforms, including Node.js and ES6 introduces modules as a way
> >> to address these problems.
> >>
> >>
> >> Indeed.
> >>
> >> At the very least, I would like to see a way to write your
> >> HTML-importable document as a module. So that it runs in a separate
> >> global and that the caller can access exported symbols and grab the
> >> ones that it wants.
> >>
> >> Though I would even be interested in having that be the default way of
> >> accessing HTML imports.
> >>
> >>
> >> Yes! I support that.
> >>
> >> I don't know exactly what the syntax would be. I could imagine something
> >> like
> >>
> >> In markup:
> >>
> >>
> >> Once imported, in script:
> >> new $('mylib').import.MyCommentElement;
> >> $('mylib').import.doStuff(12);
> >>
> >> or
> >>
> >> In markup:
> >>
> >>
> >> Once imported, in script:
> >> new MyCommentElement;
> >> doStuff(12);
> >>
> >>
> >> How about this?
> >>
> >> In the host document:
> >>
> >>
> >> foo1.bar();
> >> foo2();
> >>
> >>
> >> In foo.js:
> >> module foo1 {
> >> export function bar() {}
> >> }
> >> function foo2() {}
> >
> >
> >
> > Inline module syntax was removed and will not be included in the ES6
> module
> > specification. Furthermore, the example you've illustrated here isn't
> > entirely valid, but the valid parts are already covered within the scope
> of
> > ES6 modules:
> >
> > // in some HTML...
> >
> > import {foo1, foo2} from "foo";
> >
> > foo1();
> > foo2();
> >
> >
> > // foo.js
> > export function foo1() {}
> > export function foo2() {}
> >
> >
> > (note that foo2 isn't exported in your example, so would be undefined)
> >
> > Rick
> >
>
> I thought if an identifier wasn't exported trying to import it would
> result in fast failure (SyntaxError)?
>
Yes, my statement above is incorrect.
Rick
[Bug 23878] New: figure out termination of requests when documents become inactive
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 Status: NEW Severity: normal Priority: P2 Component: XHR Assignee: ann...@annevk.nl Reporter: hst...@mozilla.com QA Contact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org In https://github.com/whatwg/xhr/pull/3 annevk says "I guess we'll have to decide what kind of fetch termination happens here though.". This bug is just a reminder to make that decision happen. -- You are receiving this mail because: You are on the CC list for the bug.
Re: [HTML Imports]: what scope to run in
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 consent to is what is the best way to do it. One option
is to introduce new primitive like jorendorff's element.
People are also seeing that HTML imports could be another option. So
the conversation could be about which is better, or whether we need
both or not.
If you just want to namespace the script, HTML Imports might be overkill because
* An import is HTML and HTML isn't JS developer friendly in some
cases. Think about editor integration for example. Application
developers will prefer .js rather than .html as the container of their
code.
* Given above, HTML imports introduces an indirection with
>> >>
>> >> Once imported, in script:
>> >> new $('mylib').import.MyCommentElement;
>> >> $('mylib').import.doStuff(12);
>> >>
>> >> or
>> >>
>> >> In markup:
>> >>
>> >>
>> >> Once imported, in script:
>> >> new MyCommentElement;
>> >> doStuff(12);
>> >>
>> >>
>> >> How about this?
>> >>
>> >> In the host document:
>> >>
>> >>