RE: CfC: publish Proposed Recommendation of Progress Events; deadline November 25

[Jungkee Song]

> 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

[Ryosuke Niwa]

On Nov 19, 2013, at 2:10 PM, Dimitri Glazkov  wrote:

> On Mon, Nov 18, 2013 at 8: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() {}
> 
> I think you just invented the  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?

> In fact, the list of concerns that Jonas listed is specifically addressed by 
> modules. So, my thinking is that why don't we leave imports alone and let the 
> modules solve these problems? HTML Imports is a higher-layer vehicle -- it 
> simply allows you to build a dependency tree out of HTML files. In turn, HTML 
> Imports use modules to apply proper scoping of scripts.

How does module work with HTML imports?  As far as I read the spec, the 
imported document can define (and only define) whatever module it wants to 
declare on the global scope of the host document.


On Nov 19, 2013, at 3:53 PM, Jonas Sicking  wrote:

> On Mon, Nov 18, 2013 at 9:10 PM, Dimitri Glazkov  
> wrote:
>> In fact, the list of concerns that Jonas listed is specifically addressed by
>> modules. So, my thinking is that why don't we leave imports alone and let
>> the modules solve these problems? HTML Imports is a higher-layer vehicle --
>> it simply allows you to build a dependency tree out of HTML files. In turn,
>> HTML Imports use modules to apply proper scoping of scripts. And everybody
>> is happy :)
> 
> Except as the specification is currently written, I don't see a way to
> do that. I.e. the only way the imported page can "communicate" back to
> the main page is by interacting with its global.


Same here.

- R. Niwa

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

[Jonas Sicking]

On Mon, Nov 18, 2013 at 9:10 PM, Dimitri Glazkov  wrote:
> In fact, the list of concerns that Jonas listed is specifically addressed by
> modules. So, my thinking is that why don't we leave imports alone and let
> the modules solve these problems? HTML Imports is a higher-layer vehicle --
> it simply allows you to build a dependency tree out of HTML files. In turn,
> HTML Imports use modules to apply proper scoping of scripts. And everybody
> is happy :)

Except as the specification is currently written, I don't see a way to
do that. I.e. the only way the imported page can "communicate" back to
the main page is by interacting with its global.

I definitely agree that we shouldn't re-invent modules. I think we
should take advantage of what ES6 already invents. But currently I
don't see how that's possible.

Feel free to provide an example showing that I'm wrong. I'm happy to
simply rely on ES6 modules if that's somehow possible. I just don't
see how that's possible with the current spec.

/ Jonas

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

[Dimitri Glazkov]

On Mon, Nov 18, 2013 at 8: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() {}
>

I think you just invented the  element:
https://github.com/jorendorff/js-loaders/blob/master/rationale.md#examples

In fact, the list of concerns that Jonas listed is specifically addressed
by modules. So, my thinking is that why don't we leave imports alone and
let the modules solve these problems? HTML Imports is a higher-layer
vehicle -- it simply allows you to build a dependency tree out of HTML
files. In turn, HTML Imports use modules to apply proper scoping of
scripts. And everybody is happy :)

:DG<

Re: CfC: publish Proposed Recommendation of Progress Events; deadline November 25

[Takeshi Yoshino]

two minor comments
- add semicolons to lines of the example code in the introduction section?
- 2nd paragraph in the conformance section, quote "must"?

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

[Ryosuke Niwa]

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() {}


On Nov 18, 2013, at 4:52 PM, Scott Miles  wrote:
> The HTMLImports we've been working with so far is not primarily about JS, 
> it's about HTML.
> There are already various ways to modularize JS, including requirejs, other 
> libs, and of course, ES6 modules.
> Isolation of globals has definite use cases, but it also has costs, and is 
> more intervention than is required for first-party use cases. It's been 
> argued (convincingly, from my perspective) that isolation can be successfully 
> implemented via a separate opt-in mechanism.

I understand your perspective but has anyone outside Google shared the same 
opinion?  If so, could you give us pointers (URL to a post, etc..)?

> I suggest that keeping HTMLImports as primitive as possible is a virtue on 
> almost all fronts.


Running scripts in the host document while keeping the rest in a separate 
document isn't exactly simple IMO.  If we kept a separate document & window 
object, then HTML imports behave more like an display:none iframe with 
automatic JS value binding.

There is a huge advantage in matching iframe's behavior here.

- R. Niwa

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

[Scott Miles]

I believe the primary issue here is 'synchronous with respect to
rendering'. Seems like you ignored this issue. See Brian's post.

Scott


On Mon, Nov 18, 2013 at 5:47 PM, John J Barton
wrote:

>
>
>
> On Mon, Nov 18, 2013 at 3:06 PM, Scott Miles  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 

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

[John J Barton]

On Mon, Nov 18, 2013 at 3:06 PM, Scott Miles  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 

[Bug 23450] Add Specification Note Describing "Save As" Behavior for File Objects

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=23450

Arun  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #11 from Arun  ---
(In reply to brmatthe from comment #9)
> Could we expand the guideline beyond Save As...? For example, there's the
> case where I'm viewing a page containing an img with a blob URL src and the
> Blob referenced by the URL is a File. If I drag that image to my desktop, it
> would be nice if the name of the resulting file in the filesystem took into
> account the File object's name attribute. Maybe something like:
> 
> "Note
> 
> A corollary to this is an optional implementation guideline: that user
> agents take into account the File's name attribute when copying the File's
> data to outside the user agent and a name for the data is needed, such as
> the default name in a Save As... dialog or the name used when saving the
> data without prompting the user for a name (for example, dragging an image
> to the desktop)."


This would be nice user agent behavior and is a great suggestion.  I recommend
filing respective browser bugs e.g. pick File Handling for Firefox:
https://bugzilla.mozilla.org/enter_bug.cgi?product=Firefox

(WebKit, Chromium, Chromium with cr-blink for Blink all have similar bug
databases).

An API spec. stops just short of this kind of prescription, and so this is no
longer under the purview of the File API.

(In reply to Simon Pieters from comment #10)

> That said, the note shouldn't use the word 'optional' since that's also an
> RFC2119 keyword. Otherwise it looks OK to me.

OK, I've removed 'optional' and marked it a non-normative guideline in the
note. RFC2119 formalism expunged!

-- 
You are receiving this mail because:
You are on the CC list for the bug.

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

[Scott Miles]

I've made similar comments on various threads, so sorry if you've heard
this song before, but here are some basic comments:

The HTMLImports we've been working with so far is not primarily about JS,
it's about HTML.
There are already various ways to modularize JS, including requirejs, other
libs, and of course, ES6 modules.
Isolation of globals has definite use cases, but it also has costs, and is
more intervention than is required for first-party use cases. It's been
argued (convincingly, from my perspective) that isolation can be
successfully implemented via a separate opt-in mechanism.

There are the principles that guide the design as it is now. You have lots
of interesting ideas there, but it feels like re-scoping the problem into a
declarative form of JS modules. I suggest that keeping HTMLImports as
primitive as possible is a virtue on almost all fronts.

Scott



On Mon, Nov 18, 2013 at 4:14 PM, Jonas Sicking  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 

[HTML Imports]: what scope to run in

[Jonas Sicking]

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 

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

[Scott Miles]

>> Scott, is that because of what I said above (why polymer has the exact
opposite desire)?

Yes. Plus some salt from the KISS principle.

>>  I feel like it is maybe valuable to think that we should worry about
how you express [dependencies] in JS

I guess I thought ES6 modules already went through all these issues. I'm
happy to let modules be The Way for handling JS dependencies. Imports can
provide an entree to modules *and* be a vehicle for my other stuff.

Scott

On Mon, Nov 18, 2013 at 3:56 PM, Brian Kardell  wrote:

> Mixed response here...
>
> >> I love the idea of making HTML imports *not* block rendering as the
> default behavior
> In terms of custom elements, this creates as a standard, the dreaded FOUC
> problem about which a whole different group of people will be blogging and
> tweeting... Right?  I don't know that the current solution is entirely
> awesome, I'm just making sure we are discussing the same fact.  Also, links
> in the head and links in the body both "work" though the spec disallows the
> later it is defacto - the former blocks, the later doesn't I think.
>  This creates some interesting situations for people that use something
> like a CMS where they don't get to own the head upfront.
>
> > 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.
>
> Scott, is that because of what I said above (why polymer has the exact
> opposite desire)?
>
> >  if we allow "Expressing the dependency in JS" then why doesn't 'async'
> (or 'sync') get us both what we want?
>
> Just to kind of flip this on its head a bit - I feel like it is maybe
> valuable to think that we should worry about how you express it in JS
> *first* and worry about declarative sugar for one or more of those cases
> after.  I know it seems the boat has sailed on that just a little with
> imports, but nothing is really final else I think we wouldnt be having this
> conversation in the first place.  Is it plausible to excavate an
> explantation for the imports magic and define a JS API and then see how we
> tweak that to solve all the things?
>
>
>

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

[Brian Kardell]

Mixed response here...

>> I love the idea of making HTML imports *not* block rendering as the
default behavior
In terms of custom elements, this creates as a standard, the dreaded FOUC
problem about which a whole different group of people will be blogging and
tweeting... Right?  I don't know that the current solution is entirely
awesome, I'm just making sure we are discussing the same fact.  Also, links
in the head and links in the body both "work" though the spec disallows the
later it is defacto - the former blocks, the later doesn't I think.
 This creates some interesting situations for people that use something
like a CMS where they don't get to own the head upfront.

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

Scott, is that because of what I said above (why polymer has the exact
opposite desire)?

>  if we allow "Expressing the dependency in JS" then why doesn't 'async'
(or 'sync') get us both what we want?

Just to kind of flip this on its head a bit - I feel like it is maybe
valuable to think that we should worry about how you express it in JS
*first* and worry about declarative sugar for one or more of those cases
after.  I know it seems the boat has sailed on that just a little with
imports, but nothing is really final else I think we wouldnt be having this
conversation in the first place.  Is it plausible to excavate an
explantation for the imports magic and define a JS API and then see how we
tweak that to solve all the things?

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

[Scott Miles]

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

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

>> 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, 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?

Scott

On Mon, Nov 18, 2013 at 2:58 PM, John J Barton
wrote:

>
>
>
> On Mon, Nov 18, 2013 at 2:33 PM, Scott Miles  wrote:
>
>> >> 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 ecosystem) and gee they ought to
> work great together.
>
>
>>
>>
>> >>  It would be the web dev's responsibility to confirm that the import
>> was done loading
>>
>> Our use cases almost always rely on imports to make our pages sane.
>> Requiring extra code to manage import readiness is a headache.
>>
>
> I think your app would be overall even more sane if the dependencies were
> expressed directly where they are needed. Rather than loading components
> A,B,C,D then some JS that uses B,C,F, just load the JS and let it pull B,
> C, F.  No more checking back to the list of  to compare to the JS
> needs.
>
>
>>
>> Dimitri's proposal above tries to be inclusive to both world views, which
>> I strongly support as both use-cases are valid.
>>
>
> 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 business. Expressing the dependency in JS
> avoids both of these issues.
>
> Just to point out: System.component()-ish need not be blocked by
> completing ES module details and my arguments only apply for JS dependent
> upon Web Components.
>
>
>>
>>
>> Scott
>>
>> On Mon, Nov 18, 2013 at 2:25 PM, Steve Souders wrote:
>>
>>> I love the idea of making HTML imports *not* block rendering as the
>>> default behavior. I believe this is what JJB is saying: make >> rel=import> NOT block 

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

[John J Barton]

On Mon, Nov 18, 2013 at 2:33 PM, Scott Miles  wrote:

> >> 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 ecosystem) and gee they ought to
work great together.


>
>
> >>  It would be the web dev's responsibility to confirm that the import
> was done loading
>
> Our use cases almost always rely on imports to make our pages sane.
> Requiring extra code to manage import readiness is a headache.
>

I think your app would be overall even more sane if the dependencies were
expressed directly where they are needed. Rather than loading components
A,B,C,D then some JS that uses B,C,F, just load the JS and let it pull B,
C, F.  No more checking back to the list of  to compare to the JS
needs.


>
> Dimitri's proposal above tries to be inclusive to both world views, which
> I strongly support as both use-cases are valid.
>

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 business. Expressing the dependency in JS
avoids both of these issues.

Just to point out: System.component()-ish need not be blocked by completing
ES module details and my arguments only apply for JS dependent upon Web
Components.


>
>
> Scott
>
> On Mon, Nov 18, 2013 at 2:25 PM, Steve Souders  wrote:
>
>> I love the idea of making HTML imports *not* block rendering as the
>> default behavior. I believe this is what JJB is saying: make > rel=import> NOT block 

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

[Scott Miles]

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

>>  It would be the web dev's responsibility to confirm that the import was
done loading

Our use cases almost always rely on imports to make our pages sane.
Requiring extra code to manage import readiness is a headache.

Dimitri's proposal above tries to be inclusive to both world views, which I
strongly support as both use-cases are valid.

Scott

On Mon, Nov 18, 2013 at 2:25 PM, Steve Souders  wrote:

> I love the idea of making HTML imports *not* block rendering as the
> default behavior. I believe this is what JJB is saying: make  rel=import> NOT block 

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

[John J Barton]

Maybe Steve's example[1] could be on JS rather than on components:

System.component("import.php", function(component) {
  var content = component.content

document.getElementById('import-container').appendChild(content.cloneNode(true));
});

Here we mimic System.load(jsId, success, error).  Then make  not
block 

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

[Dimitri Glazkov]

'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 

Canceled: CfC: publish LCWD of DOM Parsing and Serialization; deadline November 25

[Art.Barstow]

I'll restart the CfC when Travis is ready.

From: ext Travis Leithead
Sent: ‎11/‎18/‎2013 2:28 PM
To: Webapps WG
Subject: RE: publish LCWD of DOM Parsing and Serialization; deadline  November  
25

If possible, I'd like to delay this CfC, for a week--I have some major updates 
to the ED in-flight, and I want to make sure we base the CfC on the right ED 
content :-)

Hopefully this is workable to the group. Thanks!

-
From: Arthur Barstow [mailto:art.bars...@nokia.com]
Sent: Monday, November 18, 2013 4:00 AM

This is a Call for Consensus (CfC) to publish a LCWD of DOM Parsing and 
Serialization, using the following ED as the basis:

   

This CfC satisfies the group's requirement to "record the group's decision to 
request advancement" for this LCWD. Note the Process Document states the 
following regarding the significance/meaning of a LCWD:

[[
http://www.w3.org/2005/10/Process-20051014/tr.html#last-call

Purpose: A Working Group's Last Call announcement is a signal that:

* the Working Group believes that it has satisfied its relevant technical 
requirements (e.g., of the charter or requirements document) in the Working 
Draft;

* the Working Group believes that it has satisfied significant dependencies 
with other groups;

* other groups SHOULD review the document to confirm that these dependencies 
have been satisfied. In general, a Last Call announcement is also a signal that 
the Working Group is planning to advance the technical report to later maturity 
levels.
]]

Currently, this spec has one Editorial bug [18939] that is open and Travis will 
fix this before the LCWD is published.

If you have any comments or concerns about this CfC, please send them to 
public-webapps@w3.org by November 25 at the latest. Positive response is 
preferred and encouraged and silence will be considered as agreement with the 
proposal.

The proposed review period for this LC is 4 weeks.

Assuming this CfC passes, if there are any specific groups (e.g. HTMLWG, TAG, 
I18N, WAI, Privacy IG, Security IG, etc.) we should ask to review the LCWD, 
please let me know.

-Thanks, AB

[18939] 

 Original Message 
Subject: ACTION-701: Start a cfc to publish lcwd of dom parsing and
serialization (Web Applications Working Group)
Date:Mon, 11 Nov 2013 01:59:39 +
From:ext Web Applications Working Group Issue Tracker

Reply-To:Web Applications Working Group 
To:  



ACTION-701: Start a cfc to publish lcwd of dom parsing and serialization (Web 
Applications Working Group)

http://www.w3.org/2008/webapps/track/actions/701

On: Arthur Barstow
Due: 2013-11-18

If you do not want to be notified on new action items for this group, please 
update your settings at:
http://www.w3.org/2008/webapps/track/users/7672#settings

Re: CfC: publish LCWD of DOM Parsing and Serialization; deadline November 25

[Charles McCathie Nevile]

On Mon, 18 Nov 2013 20:00:00 +0800, Arthur Barstow   
wrote:


This is a Call for Consensus (CfC) to publish a LCWD of DOM Parsing and  
Serialization, using the following ED as the basis:


   


Please do...

cheers

This CfC satisfies the group's requirement to "record the group's  
decision to request advancement" for this LCWD. Note the Process  
Document states the following regarding the significance/meaning of a  
LCWD:


[[
http://www.w3.org/2005/10/Process-20051014/tr.html#last-call

Purpose: A Working Group's Last Call announcement is a signal that:

* the Working Group believes that it has satisfied its relevant  
technical requirements (e.g., of the charter or requirements document)  
in the Working Draft;


* the Working Group believes that it has satisfied significant  
dependencies with other groups;


* other groups SHOULD review the document to confirm that these  
dependencies have been satisfied. In general, a Last Call announcement  
is also a signal that the Working Group is planning to advance the  
technical report to later maturity levels.

]]

Currently, this spec has one Editorial bug [18939] that is open and  
Travis will fix this before the LCWD is published.


If you have any comments or concerns about this CfC, please send them to  
public-webapps@w3.org by November 25 at the latest. Positive response is  
preferred and encouraged and silence will be considered as agreement  
with the proposal.


The proposed review period for this LC is 4 weeks.

Assuming this CfC passes, if there are any specific groups (e.g. HTMLWG,  
TAG, I18N, WAI, Privacy IG, Security IG, etc.) we should ask to review  
the LCWD, please let me know.


-Thanks, AB

[18939] 

 Original Message 
Subject: 	ACTION-701: Start a cfc to publish lcwd of dom parsing and  
serialization (Web Applications Working Group)

Date:   Mon, 11 Nov 2013 01:59:39 +
From: 	ext Web Applications Working Group Issue Tracker  


Reply-To:   Web Applications Working Group 
To: 



ACTION-701: Start a cfc to publish lcwd of dom parsing and serialization  
(Web Applications Working Group)


http://www.w3.org/2008/webapps/track/actions/701

On: Arthur Barstow
Due: 2013-11-18

If you do not want to be notified on new action items for this group,  
please update your settings at:

http://www.w3.org/2008/webapps/track/users/7672#settings







--
Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
  cha...@yandex-team.ru Find more at http://yandex.com

RE: publish LCWD of DOM Parsing and Serialization; deadline November 25

[Travis Leithead]

If possible, I'd like to delay this CfC, for a week--I have some major updates 
to the ED in-flight, and I want to make sure we base the CfC on the right ED 
content :-)

Hopefully this is workable to the group. Thanks!

-
From: Arthur Barstow [mailto:art.bars...@nokia.com] 
Sent: Monday, November 18, 2013 4:00 AM

This is a Call for Consensus (CfC) to publish a LCWD of DOM Parsing and 
Serialization, using the following ED as the basis:

   

This CfC satisfies the group's requirement to "record the group's decision to 
request advancement" for this LCWD. Note the Process Document states the 
following regarding the significance/meaning of a LCWD:

[[
http://www.w3.org/2005/10/Process-20051014/tr.html#last-call

Purpose: A Working Group's Last Call announcement is a signal that:

* the Working Group believes that it has satisfied its relevant technical 
requirements (e.g., of the charter or requirements document) in the Working 
Draft;

* the Working Group believes that it has satisfied significant dependencies 
with other groups;

* other groups SHOULD review the document to confirm that these dependencies 
have been satisfied. In general, a Last Call announcement is also a signal that 
the Working Group is planning to advance the technical report to later maturity 
levels.
]]

Currently, this spec has one Editorial bug [18939] that is open and Travis will 
fix this before the LCWD is published.

If you have any comments or concerns about this CfC, please send them to 
public-webapps@w3.org by November 25 at the latest. Positive response is 
preferred and encouraged and silence will be considered as agreement with the 
proposal.

The proposed review period for this LC is 4 weeks.

Assuming this CfC passes, if there are any specific groups (e.g. HTMLWG, TAG, 
I18N, WAI, Privacy IG, Security IG, etc.) we should ask to review the LCWD, 
please let me know.

-Thanks, AB

[18939] 

 Original Message 
Subject:ACTION-701: Start a cfc to publish lcwd of dom parsing and 
serialization (Web Applications Working Group)
Date:   Mon, 11 Nov 2013 01:59:39 +
From:   ext Web Applications Working Group Issue Tracker 

Reply-To:   Web Applications Working Group 
To: 



ACTION-701: Start a cfc to publish lcwd of dom parsing and serialization (Web 
Applications Working Group)

http://www.w3.org/2008/webapps/track/actions/701

On: Arthur Barstow
Due: 2013-11-18

If you do not want to be notified on new action items for this group, please 
update your settings at:
http://www.w3.org/2008/webapps/track/users/7672#settings

Re: XMLHttpRequest.prototype.responseURL

[David Bruant]

Le 18/11/2013 08:29, Anne van Kesteren a écrit :

We discussed this briefly during TPAC. Currently you can only get to
the response URL if you are loading a document resource. The idea here
is to add a new property that exposes the response URL for any
resource. It will work the same way as status and statusText, as when
those are available we know we will no longer be redirected.

Anyone see a problem with adding this feature?

No problem.

Why not all also intermediary URLs if multiple redirects are followed?

David

Re: XMLHttpRequest.prototype.responseURL

[Julian Reschke]

On 2013-11-18 17:29, Anne van Kesteren wrote:

We discussed this briefly during TPAC. Currently you can only get to
the response URL if you are loading a document resource. The idea here
is to add a new property that exposes the response URL for any
resource. It will work the same way as status and statusText, as when
those are available we know we will no longer be redirected.

Anyone see a problem with adding this feature?

Prior discussion: https://www.w3.org/Bugs/Public/show_bug.cgi?id=15417


Providing the URI of the resource that the final HTTP request was 
submitted to sounds like a good idea.


That being said, how about giving the caller more control over whether 
redirects are followed at all? (yes, broken record :-)


Best regards, Julian

XMLHttpRequest.prototype.responseURL

[Anne van Kesteren]

We discussed this briefly during TPAC. Currently you can only get to
the response URL if you are loading a document resource. The idea here
is to add a new property that exposes the response URL for any
resource. It will work the same way as status and statusText, as when
those are available we know we will no longer be redirected.

Anyone see a problem with adding this feature?

Prior discussion: https://www.w3.org/Bugs/Public/show_bug.cgi?id=15417


-- 
http://annevankesteren.nl/

[Bug 21264] referrer source is wrong

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=21264

Anne  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #12 from Anne  ---
https://github.com/whatwg/xhr/commit/1898f6f8981e8f926dc42392c07137eeedf7094b

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 21264] referrer source is wrong

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=21264

Bug 21264 depends on bug 23780, which changed state.

Bug 23780 Summary: Check XMLHttpRequest and Notification don't break given the 
new script settings object stuff
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23780

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 23780] Check XMLHttpRequest and Notification don't break given the new script settings object stuff

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=23780

Anne  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Blocks||21264
 Resolution|--- |FIXED

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 23853] New: Please clarify the interpretation of the WebIDL undefined Date in the File constructor

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=23853

Bug ID: 23853
   Summary: Please clarify the interpretation of the WebIDL
undefined Date in the File constructor
   Product: WebAppsWG
   Version: unspecified
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: File API
  Assignee: a...@mozilla.com
  Reporter: cos...@gmail.com
QA Contact: public-webapps-bugzi...@w3.org
CC: public-webapps@w3.org

Step 3.3 in Section 7.1 of the File API says:

"If the lastModifiedDate member is provided, let d be set to the
lastModifiedDate dictionary member. If it is not provided, set d to the current
date and time (which is the equivalent of Date.now() [ECMA-262])."

The "lastModifiedDate" sub-section of Section 7.2 says:

"If the last modification date and time are not known, the attribute must
return the current date and time as a Date object."


WebIDL has the concept of "undefined Date", which I think translates to "new
Date(NaN)" in ECMAscript. According to 7.1 above, passing an undefined Date
into the lastModifiedDate attribute of the File constructor's FilePropertyBag
would require the File object to set it as its lastModifiedDate attribute, so
it would be returned as it is passed.

I think that "lastModifiedDate" already has a concept of unknown modification
date, defined in Section 7.2, and having undefined Dates would add confusion to
both users and browser developers. Can you please explicitly remove support for
undefined Dates?


The most reasonable solution that I could think of would be to change the first
sentence of Step 3.3 in Section 7.1 to

"If the lastModifiedDate member is provided, and is not the undefined Date, let
d be set to the lastModifiedDate dictionary member. Otherwise, set d to the
current date and time (which is the equivalent of Date.now() [ECMA-262])."

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Re: CfC: publish Proposed Recommendation of Progress Events; deadline November 25

[Charles McCathie Nevile]

On Mon, 18 Nov 2013 20:28:06 +0800, Arthur Barstow   
wrote:


The Implementation Report [ImplReprt] for the Progress Events CR [CR]  
indicates the CR's exit criteria have been met. As such, this is a Call  
for Consensus to publish a Proposed Recommendation of Progress Events  
using [CR] as the basis.


If you have any comments or concerns about this CfC, please reply to  
this e-mail by November 26 at the latest. Positive response is preferred  
and encouraged, and silence will be considered as agreement with the  
proposal.


please do.

chaals


-Thanks, AB

[ImplReprt] 
[CR] 

 Original Message 
Subject: 	ACTION-702: Start cfc to publish pr of progress events (Web  
Applications Working Group)

Date:   Mon, 11 Nov 2013 09:10:18 +
From: 	ext Web Applications Working Group Issue Tracker  


Reply-To:   Web Applications Working Group 
To: 



ACTION-702: Start cfc to publish pr of progress events (Web Applications  
Working Group)


http://www.w3.org/2008/webapps/track/actions/702

On: Arthur Barstow
Due: 2013-11-18

If you do not want to be notified on new action items for this group,  
please update your settings at:

http://www.w3.org/2008/webapps/track/users/7672#settings







--
Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
  cha...@yandex-team.ru Find more at http://yandex.com

[Bug 23450] Add Specification Note Describing "Save As" Behavior for File Objects

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=23450

Simon Pieters  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 CC||sim...@opera.com
 Resolution|FIXED   |---

--- Comment #6 from Simon Pieters  ---
[[
If a resource identified with a blob: URL is a File object, user agents must
use that file's name attribute, as if the response had a Content-Disposition
header with the filename parameter set to the File's name attribute [RFC6266].
]]

This seems good.

[[
In particular, "File Save As" behavior must use the File's name attribute as
the default name to save the file as.
]]

This seems bad. It's a different requirement than the first, but we actually
only want the first, I think. If you intended this sentence to be non-normative
describing the implications of the first requirement, then don't use 'must'
here.

I suggest you remove the second sentence and maybe add a note like "This means
that 'File Save As' takes the File's name attribute into account for the
default name to save the file as." or some such.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

CfC: publish Proposed Recommendation of Progress Events; deadline November 25

[Arthur Barstow]

The Implementation Report [ImplReprt] for the Progress Events CR [CR] 
indicates the CR's exit criteria have been met. As such, this is a Call 
for Consensus to publish a Proposed Recommendation of Progress Events 
using [CR] as the basis.


If you have any comments or concerns about this CfC, please reply to 
this e-mail by November 26 at the latest. Positive response is preferred 
and encouraged, and silence will be considered as agreement with the 
proposal.


-Thanks, AB

[ImplReprt] 
[CR] 

 Original Message 
Subject: 	ACTION-702: Start cfc to publish pr of progress events (Web 
Applications Working Group)

Date:   Mon, 11 Nov 2013 09:10:18 +
From: 	ext Web Applications Working Group Issue Tracker 


Reply-To:   Web Applications Working Group 
To: 



ACTION-702: Start cfc to publish pr of progress events (Web Applications 
Working Group)

http://www.w3.org/2008/webapps/track/actions/702

On: Arthur Barstow
Due: 2013-11-18

If you do not want to be notified on new action items for this group, please 
update your settings at:
http://www.w3.org/2008/webapps/track/users/7672#settings

CfC: publish LCWD of DOM Parsing and Serialization; deadline November 25

[Arthur Barstow]

This is a Call for Consensus (CfC) to publish a LCWD of DOM Parsing and 
Serialization, using the following ED as the basis:


  

This CfC satisfies the group's requirement to "record the group's 
decision to request advancement" for this LCWD. Note the Process 
Document states the following regarding the significance/meaning of a LCWD:


[[
http://www.w3.org/2005/10/Process-20051014/tr.html#last-call

Purpose: A Working Group's Last Call announcement is a signal that:

* the Working Group believes that it has satisfied its relevant 
technical requirements (e.g., of the charter or requirements document) 
in the Working Draft;


* the Working Group believes that it has satisfied significant 
dependencies with other groups;


* other groups SHOULD review the document to confirm that these 
dependencies have been satisfied. In general, a Last Call announcement 
is also a signal that the Working Group is planning to advance the 
technical report to later maturity levels.

]]

Currently, this spec has one Editorial bug [18939] that is open and 
Travis will fix this before the LCWD is published.


If you have any comments or concerns about this CfC, please send them to 
public-webapps@w3.org by November 25 at the latest. Positive response is 
preferred and encouraged and silence will be considered as agreement 
with the proposal.


The proposed review period for this LC is 4 weeks.

Assuming this CfC passes, if there are any specific groups (e.g. HTMLWG, 
TAG, I18N, WAI, Privacy IG, Security IG, etc.) we should ask to review 
the LCWD, please let me know.


-Thanks, AB

[18939] 

 Original Message 
Subject: 	ACTION-701: Start a cfc to publish lcwd of dom parsing and 
serialization (Web Applications Working Group)

Date:   Mon, 11 Nov 2013 01:59:39 +
From: 	ext Web Applications Working Group Issue Tracker 


Reply-To:   Web Applications Working Group 
To: 



ACTION-701: Start a cfc to publish lcwd of dom parsing and serialization (Web 
Applications Working Group)

http://www.w3.org/2008/webapps/track/actions/701

On: Arthur Barstow
Due: 2013-11-18

If you do not want to be notified on new action items for this group, please 
update your settings at:
http://www.w3.org/2008/webapps/track/users/7672#settings