Re: [HTML Imports]: Sync, async, -ish?

2013-11-20 Thread Dimitri Glazkov
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:
link rel=import href=my-ad.html
...
my-ad/my-ad
..

my-ad.html:
script
document.register(my-ad, ... );
...

There won't be any rendering blocked here. The page will render, then when
my-add.html loads, it will upgrade the my-ad element to display the
punch-the-monkey thing.

:DG


Re: [HTML Imports]: Sync, async, -ish?

2013-11-20 Thread Daniel Freedman
On Wed, Nov 20, 2013 at 9:51 AM, John J Barton
johnjbar...@johnjbarton.comwrote:

 Another alternative:

 First let's agree that Souder's example must block:

 link rel=import href=import.php

  ...

 div id=import-container/div
 script
 var link = document.querySelector('link[rel=import]');
 var content = link.import.querySelector('#imported-content');
 document.getElementById('import-container').appendChild(content.cloneNode(true));
 /script

 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:

 div id=import-container/div
 script
 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));


 }
 /script

 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 dglaz...@google.comwrote:

 '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 script from
 executing. Some peeps seem to frown on that and demand moar async.

 I am going to claim that there are two distinct uses of link rel=import:

 1) The import is the most important part of the document. Typically, this
 is when the import is the underlying framework that powers the app, and the
 app simply won't function without it. In this case, any more async will be
 all burden and no benefit.

 2) The import is the least important of the document. This is the +1
 button case. The import is useful, but sure as hell doesn't need to take
 rendering engine's attention from presenting this document to the user. In
 this case, async is sorely needed.

 We should address both of these cases, and we don't right now -- which is
 a problem.

 Shoot-from-the-hip Strawman:

 * The default behavior stays currently specified
 * The async attribute on link makes import load asynchronously
 * Also, consider not blocking rendering when blocking script

 This strawman is intentionally full of ... straw. Please provide a better
 strawman below:
 __
 __
 __

 :DG

 [1]:
 http://www.stevesouders.com/blog/2013/11/16/async-ads-with-html-imports/
 [2]: https://twitter.com/codepo8/status/401752453944590336





Re: [HTML Imports]: Sync, async, -ish?

2013-11-20 Thread Daniel Buchner
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 dglaz...@google.com 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:
 link rel=import href=my-ad.html
 ...
 my-ad/my-ad
 ..

 my-ad.html:
 script
 document.register(my-ad, ... );
 ...

 There won't be any rendering blocked here. The page will render, then when
 my-add.html loads, it will upgrade the my-ad element to display the
 punch-the-monkey thing.

 :DG



Re: [HTML Imports]: Sync, async, -ish?

2013-11-20 Thread John J Barton
On Wed, Nov 20, 2013 at 10:41 AM, Daniel Buchner dan...@mozilla.com 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 dglaz...@google.com 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:
 link rel=import href=my-ad.html
 ...
 my-ad/my-ad
 ..

 my-ad.html:
 script
 document.register(my-ad, ... );
 ...

 There won't be any rendering blocked here. The page will render, then
 when my-add.html loads, it will upgrade the my-ad element to display the
 punch-the-monkey thing.

 :DG




Re: [HTML Imports]: Sync, async, -ish?

2013-11-20 Thread Daniel Buchner
On Nov 20, 2013 11:07 AM, John J Barton johnjbar...@johnjbarton.com
wrote:




 On Wed, Nov 20, 2013 at 10:41 AM, Daniel Buchner dan...@mozilla.com
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 dglaz...@google.com 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:
 link rel=import href=my-ad.html
 ...
 my-ad/my-ad
 ..

 my-ad.html:
 script
 document.register(my-ad, ... );
 ...

 There won't be any rendering blocked here. The page will render, then
when my-add.html loads, it will upgrade the my-ad element to display the
punch-the-monkey thing.

 :DG




Re: [HTML Imports]: what scope to run in

2013-11-20 Thread Brian Di Palma
On Tue, Nov 19, 2013 at 10:16 PM, Rick Waldron waldron.r...@gmail.com wrote:



 On Mon, Nov 18, 2013 at 11:26 PM, Ryosuke Niwa rn...@apple.com 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 jo...@sicking.cc 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:
 link rel=import href=... id=mylib

 Once imported, in script:
 new $('mylib').import.MyCommentElement;
 $('mylib').import.doStuff(12);

 or

 In markup:
 link rel=import href=... id=mylib import=MyCommentElement doStuff

 Once imported, in script:
 new MyCommentElement;
 doStuff(12);


 How about this?

 In the host document:
 link ref=import href=foo.js import=foo1 foo2
 script
 foo1.bar();
 foo2();
 /script

 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...
 script
 import {foo1, foo2} from foo;

 foo1();
 foo2();
 /script

 // 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

2013-11-20 Thread Kowalski, Francois-Xavier
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

2013-11-20 Thread Rick Waldron
On Wed, Nov 20, 2013 at 12:38 PM, Brian Di Palma off...@gmail.com wrote:

 On Tue, Nov 19, 2013 at 10:16 PM, Rick Waldron waldron.r...@gmail.com
 wrote:
 
 
 
  On Mon, Nov 18, 2013 at 11:26 PM, Ryosuke Niwa rn...@apple.com 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 jo...@sicking.cc 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:
  link rel=import href=... id=mylib
 
  Once imported, in script:
  new $('mylib').import.MyCommentElement;
  $('mylib').import.doStuff(12);
 
  or
 
  In markup:
  link rel=import href=... id=mylib import=MyCommentElement
 doStuff
 
  Once imported, in script:
  new MyCommentElement;
  doStuff(12);
 
 
  How about this?
 
  In the host document:
  link ref=import href=foo.js import=foo1 foo2
  script
  foo1.bar();
  foo2();
  /script
 
  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...
  script
  import {foo1, foo2} from foo;
 
  foo1();
  foo2();
  /script
 
  // 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

2013-11-20 Thread bugzilla
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

2013-11-20 Thread Hajime Morrita
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 module 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 script
src=... and will be slower than directly loading .js files.
 * HTML imports will work well with module-ish thing and it makes
the spec small as it gets off-loaded module loading responsibility.
This seems good modularization of the feature.

HTML Imports make sense only if you need HTML fragments and/or
stylesheets, but people need modularization regardless they develop
Web Components or plain JS pieces. I think the web standard should
help both cases and module or something similar serves better for
that purpose.

Does this make sense?

--
morrita



On Thu, Nov 21, 2013 at 7:00 AM, Rick Waldron waldron.r...@gmail.com wrote:



 On Wed, Nov 20, 2013 at 12:38 PM, Brian Di Palma off...@gmail.com wrote:

 On Tue, Nov 19, 2013 at 10:16 PM, Rick Waldron waldron.r...@gmail.com
 wrote:
 
 
 
  On Mon, Nov 18, 2013 at 11:26 PM, Ryosuke Niwa rn...@apple.com 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 jo...@sicking.cc 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:
  link rel=import href=... id=mylib
 
  Once imported, in script:
  new $('mylib').import.MyCommentElement;
  $('mylib').import.doStuff(12);
 
  or
 
  In markup:
  link rel=import href=... id=mylib import=MyCommentElement
  doStuff
 
  Once imported, in script:
  new MyCommentElement;
  doStuff(12);
 
 
  How about this?
 
  In the host document:
  link ref=import href=foo.js import=foo1 foo2
  script
  foo1.bar();
  foo2();
  /script
 
  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...
  script
  import {foo1, foo2} from foo;
 
  foo1();
  foo2();
  /script
 
  // 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






-- 
morrita



Re: [HTML Imports]: what scope to run in

2013-11-20 Thread Ryosuke Niwa
On Nov 21, 2013, at 10:41 AM, Hajime Morrita morr...@google.com 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 we don't consent to is what is the best way to do it. One option
 is to introduce new primitive like jorendorff's module 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.

This is a nice summary.

 * Given above, HTML imports introduces an indirection with script
 src=... and will be slower than directly loading .js files.

This is not the case when you're defining components/custom elements in the 
imported document
because you want both templates, styles, and inline scripts to define those 
custom elements in one HTML document.

 * HTML imports will work well with module-ish thing and it makes
 the spec small as it gets off-loaded module loading responsibility.
 This seems good modularization of the feature.

But authors have to opt-in to benefit from such modularization mechanisms.

 HTML Imports make sense only if you need HTML fragments and/or
 stylesheets, but people need modularization regardless they develop
 Web Components or plain JS pieces. I think the web standard should
 help both cases and module or something similar serves better for
 that purpose.

I'm fine with saying that link[rel=import] is a simple include and module 
element is the way to include modularized HTML and JS files. That, however, 
raises a question as to whether we really need two very similar mechanism to 
accomplish the same thing.

- R. Niwa




Re: [HTML Imports]: what scope to run in

2013-11-20 Thread John J Barton
On Wed, Nov 20, 2013 at 7:34 PM, Ryosuke Niwa rn...@apple.com wrote:

 On Nov 21, 2013, at 10:41 AM, Hajime Morrita morr...@google.com 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 we don't consent to is what is the best way to do it. One option
  is to introduce new primitive like jorendorff's module 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.

 This is a nice summary.

  * Given above, HTML imports introduces an indirection with script
  src=... and will be slower than directly loading .js files.

 This is not the case when you're defining components/custom elements in
 the imported document
 because you want both templates, styles, and inline scripts to define
 those custom elements in one HTML document.


And in this model, the 'inline script' can use module, meaning that the
JS is modular and relies on modular JS. In this way the two specification
work together.

Earlier I suggested a way to combine these specifications from the other
direction, inventing a small extension to ES module-loader,
System.component(), where JS drives the load of an HTML import.



  * HTML imports will work well with module-ish thing and it makes
  the spec small as it gets off-loaded module loading responsibility.
  This seems good modularization of the feature.

 But authors have to opt-in to benefit from such modularization mechanisms.


As I argued for modularity support previously, I also think there is a
strong case for non-modular forms as well: early adoption, test cases,
simple pages, purely declarative markup sites, future innovations.
 Enforcing modularization is likely, based on history, to lead to fewer
uses even much less that the amount of opt-in to a less rigid solution.
Just consider JavaScript vs every other solution for Web scripting, or HTML
vs XML.



  HTML Imports make sense only if you need HTML fragments and/or
  stylesheets, but people need modularization regardless they develop
  Web Components or plain JS pieces. I think the web standard should
  help both cases and module or something similar serves better for
  that purpose.

 I'm fine with saying that link[rel=import] is a simple include and module
 element is the way to include modularized HTML and JS files. That, however,
 raises a question as to whether we really need two very similar mechanism
 to accomplish the same thing.


The module element remains a rumor to my knowledge and this rumor has it
as a JS only feature. The rest of the module specification is far along,
but again only JS. The story for HTML is well represented...by the HTML
Import system.

The strength of the HTML Import story is declarative include of a complete
HTML sub-document, something we have never enjoyed as a common technology.
Its weakness in my mind is lack of advanced JS features like modules and
dynamic loading; these I see as great additions to be made by the JS
leaders.

I don't see two similar mechanisms for the same goal, but two cooperating
specifications with different strengths that combine nicely. At least on
paper, we need more empirical work with the combination to be sure.

HTH,
jjb


RE: Comments on version web-apps specs from 2013-10-31

2013-11-20 Thread Feras Moussa
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/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().The version of the spec 
 you linked doesn't differentiate writeable/readable streams, but is something 
 we are considering adding in a future version. I don't quite understand what 
 you're referring to here. close is independent of future reads - you can call 
 a read after close, and once EOF is reached, the promise is resolved and you 
 get a result with eof=true.
 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?Are you asking 
 what the chain of error propagation is when multiple streams are chained?
 
 Section 3.2:
 1. Shouldn't a FileWrite also be capable of consuming a Stream? (Like 
 XHR-pipe-to-FileWriter)Yes, I think so - this is a use case we can add.
 2. Shouldn't an XMLHttpRequest also be capable of consuming a Stream? 
 (eg. chunked PUT/POST)?Section 5.4 covers this - support for posting a 
 Stream. That said, this is a section I think will need to be flushed out more.
 
 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.