RE: CfC: publish Proposed Recommendation of Progress Events; deadline November 25
Hi, I've prepared the PR-ready version of the Progress Events spec: https://dvcs.w3.org/hg/progress/raw-file/tip/TR/Overview.html Please use this version to review and give further comments during the CfC period, if any. Jungkee -Original Message- From: Jungkee Song [mailto:jungkee.s...@samsung.com] Sent: Tuesday, November 19, 2013 4:43 PM To: 'Takeshi Yoshino' Cc: 'public-webapps' Subject: RE: CfC: publish Proposed Recommendation of Progress Events; deadline November 25 From: Takeshi Yoshino [mailto:tyosh...@google.com] Sent: Tuesday, November 19, 2013 1:48 PM two minor comments - add semicolons to lines of the example code in the introduction section? This might not be an issue but I agree to add them. - 2nd paragraph in the conformance section, quote must? It looks better. I'll put together a PR-ready draft incorporating the above comments. Also, please note that there was a minor change [1] in the ED [2], a year ago, which I'll use as a base document for the PR-ready draft. Thanks! [1] https://dvcs.w3.org/hg/progress/rev/964030fa5727 [2] https://dvcs.w3.org/hg/progress/raw-file/tip/Overview.html -- Jungkee Song Samsung Electronics
Re: [HTML Imports]: what scope to run in
On Nov 19, 2013 2:22 AM, Ryosuke Niwa rn...@apple.com wrote:
On Nov 19, 2013, at 2:10 PM, Dimitri Glazkov dglaz...@chromium.org
wrote:
On Mon, Nov 18, 2013 at 8: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() {}
I think you just invented the module element:
https://github.com/jorendorff/js-loaders/blob/master/rationale.md#examples
Putting the backward compatibility / fallback behavior concern with
respect to the HTML parsing algorithm aside, the current proposal appears
to only support js files. Are you proposing to extend it so that it can
also load HTML documents just like link[rel=import] does?
I think james burke purposes something to that effect
https://gist.github.com/jrburke/7455354#comment-949905 (relevant bit is in
reply to me, comment #4 if i understand the question)
Re: XMLHttpRequest.prototype.responseURL
On Mon, Nov 18, 2013 at 6:23 PM, David Bruant bruan...@gmail.com wrote: Why not all also intermediary URLs if multiple redirects are followed? Because then the next request is about exposing intermediate response headers and bodies, etc. We need to figure out how to deal with redirects in a sane way. It's not clear to me if we're going to do that for XMLHttpRequest or just toss it in with the new fetch API. -- http://annevankesteren.nl/
[Bug 23853] Please clarify the interpretation of the WebIDL undefined Date in the File constructor
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23853 Arun a...@mozilla.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #18 from Arun a...@mozilla.com --- Marking this fixed: http://dev.w3.org/2006/webapi/FileAPI/#file-constructor (It's also fixed in the WebIDL: http://dev.w3.org/2006/webapi/FileAPI/#file and in the attribute definitions: http://dev.w3.org/2006/webapi/FileAPI/#file-attrs). This is probably the last open bug before RC, so anyone with time to give the draft a once-over is encouraged to do so. -- You are receiving this mail because: You are on the CC list for the bug.
Re: [HTML Imports]: what scope to run in
There seems to be some idea that HTML imports are supposed to do
everything. The primary use case for HTML imports is a way to import DOM
trees. Since HTML already have ways to embed CSS and script, HTML imports
can act as a container format. But do not let perfect be the enemy of good.
Lets not try to fix the issues of CSS and JS by make HTLM import try to
solve all of these at once.
To answer a few points.
You should be able to use module/script type=module inside an HTML
import. It will do the encapsulation (top level vars are not global
vars). Lets focus on solving this problem by itself. It is orthogonal to
importing HTML.
Different global scope. Modules do not provide a new global scope by
default. Why should script/module inside an HTML import do that? That seems
inconsistent. Also, having different Array/Function/Node etc causes issues
because code often expect the prototype to not be different.
James Burke also brought up the issue related to naming on the import side.
That works well for JS because the name that the importer choses does not
change the interface of the object [*]. However, the name of an element is
one of the most important parts of its interface. What happens when you
have multiple HTLM imports that imports the same custom element but with
different names and then these elements are moved between the documents?
Are we going to rename them to ensure that my x-foo is always an XFoo?
On Tue, Nov 19, 2013 at 5:13 AM, Brian Kardell bkard...@gmail.com wrote:
On Nov 19, 2013 2:22 AM, Ryosuke Niwa rn...@apple.com wrote:
On Nov 19, 2013, at 2:10 PM, Dimitri Glazkov dglaz...@chromium.org
wrote:
On Mon, Nov 18, 2013 at 8: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() {}
I think you just invented the module element:
https://github.com/jorendorff/js-loaders/blob/master/rationale.md#examples
Putting the backward compatibility / fallback behavior concern with
respect to the HTML parsing algorithm aside, the current proposal appears
to only support js files. Are you proposing to extend it so that it can
also load HTML documents just like link[rel=import] does?
I think james burke purposes something to that effect
https://gist.github.com/jrburke/7455354#comment-949905 (relevant bit is
in reply to me, comment #4 if i understand the question)
--
erik
[Bug 23601] Define a variable to replace with prejudice
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23601 Ian 'Hixie' Hickson i...@hixie.ch changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug.
Re: [HTML Imports]: what scope to run in
On Mon, Nov 18, 2013 at 7:14 PM, Jonas Sicking jo...@sicking.cc wrote: Hi All, Largely independently from the thread that Dimitri just started on the sync/async/-ish nature of HTML imports I have a problem with how script execution in the imported document works. Right now it's defined that any script elements in the imported document are run in the scope of the window of the document linking to the import. I.e. the global object of the document that links to the import is used as global object of the running script. This is exactly how script elements have always worked in HTML. However this is a pretty terrible way of importing libraries. Basically the protocol becomes here is my global, do whatever modifications you want to it in order to install yourself. 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. * Internal functions that the library does not want to expose require ugly anonymous-function tricks to create a hidden scope. Many platforms, including Node.js and ES6 introduces modules as a way to address these problems. It seems to me that we are repeating the same mistake again with HTML imports. Note that this is *not* about security. It's simply about making a more robust platform for libraries. This seems like a bad idea given that HTML imports essentially are libraries. 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 This isn't how node modules or ES6 modules work. A module designed for use with node can define properties on the `global` (ie. the object whose bound identifier is the word global) and this is the same global object making the require(...) call. ES6 modules are evaluated in the same global scope from which they are imported. Rick
Re: [HTML Imports]: what scope to run in
On Tue, Nov 19, 2013 at 2:07 PM, Rick Waldron waldron.r...@gmail.comwrote: On Mon, Nov 18, 2013 at 7:14 PM, Jonas Sicking jo...@sicking.cc wrote: Hi All, Largely independently from the thread that Dimitri just started on the sync/async/-ish nature of HTML imports I have a problem with how script execution in the imported document works. Right now it's defined that any script elements in the imported document are run in the scope of the window of the document linking to the import. I.e. the global object of the document that links to the import is used as global object of the running script. This is exactly how script elements have always worked in HTML. However this is a pretty terrible way of importing libraries. Basically the protocol becomes here is my global, do whatever modifications you want to it in order to install yourself. 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. * Internal functions that the library does not want to expose require ugly anonymous-function tricks to create a hidden scope. Many platforms, including Node.js and ES6 introduces modules as a way to address these problems. It seems to me that we are repeating the same mistake again with HTML imports. Note that this is *not* about security. It's simply about making a more robust platform for libraries. This seems like a bad idea given that HTML imports essentially are libraries. 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 This isn't how node modules or ES6 modules work. A module designed for use with node can define properties on the `global` (ie. the object whose bound identifier is the word global) and this is the same global object making the require(...) call. ES6 modules are evaluated in the same global scope from which they are imported. However ES6 modules do solve the list of downsides in Jonas' list. And ES6 modules create a scope so variables and functions declared in a module but not exported do not pollute the global object as a side-effect of declaration. I think ES6 modules for HTML imports provide a good compromise between current HTML import design (no modules just packaging) and total iframe-like encapsulation (many practical and design issues). Rick
Re: [HTML Imports]: what scope to run in
On Tue, Nov 19, 2013 at 5:27 PM, John J Barton johnjbar...@johnjbarton.comwrote: (snip) This isn't how node modules or ES6 modules work. A module designed for use with node can define properties on the `global` (ie. the object whose bound identifier is the word global) and this is the same global object making the require(...) call. ES6 modules are evaluated in the same global scope from which they are imported. However ES6 modules do solve the list of downsides in Jonas' list. And ES6 modules create a scope so variables and functions declared in a module but not exported do not pollute the global object as a side-effect of declaration. I think ES6 modules for HTML imports provide a good compromise between current HTML import design (no modules just packaging) and total iframe-like encapsulation (many practical and design issues). Yes, completely agree that they are the best solution—as long as their capabilities are understood and their use is specified within the bounds of those capabilities. Rick
Re: [HTML Imports]: Sync, async, -ish?
I sent this to Scott only by accident, then noticed when I realized I need to correct myself. First a softer version of my message to Scott: On Mon, Nov 18, 2013 at 5:53 PM, Scott Miles sjmi...@google.com wrote: I believe the primary issue here is 'synchronous with respect to rendering'. Seems like you ignored this issue. See Brian's post. Yes, I agree that issue should be discussed. Rendering synchrony makes a strong case against Dimitri's proposal (now I switch my earlier not-competing opinion). In my opinion, asynchronous component loading driven by dependencies gives the best user experience and simplest dev model. Second best is a synchronous model based on declaration order. Last is an asynchronous declarative model (quote because such solutions are not declarative). I guess you would agree that the best user experience occurs after the web components are loaded. So let's get there the fastest possible way: non blocking asynchronous i/o. After picking the fastest path, we get a bonus: we first render HTML5 content, anything our designers like: blank page, 'brought to you by ...', etc. Thus we get control of the load-time UI. The flash of unstyled content (FOUC) issue need not affect us because we use web components with proper dependences rather than a pile-of-div-s plus some independent JS. The synchronous solution takes longer to load and shows browser defined content in the meantime. Therefore the dependency-driven asynchronous solution has better user experience and a somewhat better dev model than declarative synchronous. The declarative synchronous model has three important advantages: it is simple to code, easy to reason about, and familiar. For the top- or application-level on simple pages I think these advantages are important, despite its failing in performance. A declarative asynchronous solution (async attribute on link tag) can be used to give the same user experience, but it loses on the development model. It gives developers no help in load order and it creates confusion by simulating imperative actions with declarative syntax. FOUC is a sign of the failing of this kind of solution: the unstyled content hits the rendering engine in the wrong order, before the JS that it depends upon. If our dependency design is correct, we only deliver useful content to the rendering engine. Scott On Mon, Nov 18, 2013 at 5:47 PM, John J Barton johnjbar...@johnjbarton.com wrote: On Mon, Nov 18, 2013 at 3:06 PM, Scott Miles sjmi...@google.com wrote: I'll assert that the primary use case for JS interacting with HTML components ought to be 'works well with JS modules'. You can happily define modules in your imports, those two systems are friends as far as I can tell. I've said this before, I've yet to hear the counter argument. Yes indeed. Dimitri was asking for a better solution, but I agree that both are feasible and compatible. But if you believe in modularity for Web Components then you should believe in modularity for JS Polymer team relies on Custom Elements for JS modularity. But again, this is not mutually exclusive with JS modules, so I don't see the problem. Steve's example concerns synchrony between script and link rel='import'. It would be helpful if you can outline how your modularity solution works for this case. Dimitri's proposal makes the async case much more difficult: you need both the link tag with async attribute then again you need to express the dependency with the clunky onload busines I believe you are making assumptions about the nature of link and async. There are ways of avoiding this problem, Yes I am assuming Steve's example, so again your version would be interesting to see. but it begs the question, which is: if we allow Expressing the dependency in JS then why doesn't 'async' (or 'sync') get us both what we want? I'm not arguing against any other solution that also works. I'm only suggesting a solution that always synchronizes just those blocks of JS that need order-of-execution and thus never needs 'sync' or 'async' and which leads us to unify the module story for the Web. jjb Scott On Mon, Nov 18, 2013 at 2:58 PM, John J Barton johnjbar...@johnjbarton.com wrote: On Mon, Nov 18, 2013 at 2:33 PM, Scott Miles sjmi...@google.comwrote: I love the idea of making HTML imports *not* block rendering as the default behavior So, for what it's worth, the Polymer team has the exact opposite desire. I of course acknowledge use cases where imports are being used to enhance existing pages, but the assertion that this is the primary use case is at least arguable. I'll assert that the primary use case for JS interacting with HTML components ought to be 'works well with JS modules'. Today, in the current state of HTML Import and JS modules, this sounds too hard. But if you believe in modularity for Web Components then you should believe in modularity for JS (or look at the Node
Re: [HTML Imports]: Sync, async, -ish?
Now a correction:
On Tue, Nov 19, 2013 at 4:25 PM, John J Barton
johnjbar...@johnjbarton.comwrote:
Last is an asynchronous declarative model (quote because such solutions
are not declarative).
Broadly I am advocating using ES6 modules with HTML imports. The
particular example I made up earlier was patterned after ES6 asynchronous
loading, here I repeat it:
script
System.component(import.php, function(component) {
var content = component.content
document.getElementById('import-container').appendChild(content.cloneNode(
true));
});
/script
How does this differ from Dimitri's
link rel=import async href=/imports/heart.html
Well not as much as I claimed before.
Both cases are parsed synchronously and cause subsequent loading. Both can
trigger module loading recursively, my made up version by wiring ES6 module
loading to allow inputs to be HTML Imports and Dimitri's version through
subimports.
The primary difference in this starting the load operation is the
callback. In my made up version the callback would follow the System.load()
pattern from ES6. In Dimtrii's version you have to have a separate script
tag with an event handler and an event triggered by the import.
If the application needs no callback, these two forms are draw on all
counts.
So the crux of a ES6-compatible solution is a JS loader supporting
component loading. If the JS in an HTML import does not import any JS
modules, then asynchronous module loading works, we just don't get JS
modularity.
So I'm back to these don't compete. I think integrating ES6 modules with
HTML Imports can be on ES6. The ES6 solution would be better for the
reasons I outlined previously but everything is better in the future.
jjb
