This is a Call for Consensus (CfC) to publish a LCWD of DOM Parsing and
Serialization, using the following ED as the basis:
https://dvcs.w3.org/hg/innerhtml/raw-file/tip/index.html
This CfC satisfies the group's requirement to record the group's
decision to request advancement for this
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23450
Simon Pieters sim...@opera.com changed:
What|Removed |Added
Status|RESOLVED|REOPENED
On Mon, 18 Nov 2013 20:28:06 +0800, Arthur Barstow art.bars...@nokia.com
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
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23780
Anne ann...@annevk.nl changed:
What|Removed |Added
Status|NEW |RESOLVED
Blocks|
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
https://www.w3.org/Bugs/Public/show_bug.cgi?id=21264
Anne ann...@annevk.nl changed:
What|Removed |Added
Status|NEW |RESOLVED
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
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
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
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,
On Mon, 18 Nov 2013 20:00:00 +0800, Arthur Barstow art.bars...@nokia.com
wrote:
This is a Call for Consensus (CfC) to publish a LCWD of DOM Parsing and
Serialization, using the following ED as the basis:
https://dvcs.w3.org/hg/innerhtml/raw-file/tip/index.html
Please do...
cheers
I'll restart the CfC when Travis is ready.
From: ext Travis Leitheadmailto:travis.leith...@microsoft.com
Sent: 11/18/2013 2:28 PM
To: Webapps WGmailto:public-webapps@w3.org
Subject: RE: publish LCWD of DOM Parsing and Serialization; deadline November
25
If
'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
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
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
On Mon, Nov 18, 2013 at 2:33 PM, Scott Miles sjmi...@google.com 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
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
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
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
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
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,
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23450
Arun a...@mozilla.com changed:
What|Removed |Added
Status|REOPENED|RESOLVED
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 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
johnjbar...@johnjbarton.comwrote:
On Mon, Nov 18, 2013 at 3:06 PM, Scott Miles sjmi...@google.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
two minor comments
- add semicolons to lines of the example code in the introduction section?
- 2nd paragraph in the conformance section, quote must?
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
On Mon, Nov 18, 2013 at 9:10 PM, Dimitri Glazkov dglaz...@chromium.org 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
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
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
30 matches
Mail list logo
