Re: [webcomponents] HTML Parsing and the element

On Wed, Apr 18, 2012 at 2:54 PM, Dimitri Glazkov wrote: > On Wed, Apr 18, 2012 at 2:31 PM, James Graham wrote: >> On Wed, 18 Apr 2012, Dimitri Glazkov wrote: >> Wouldn't it make more sense to host the template contents as normal descendants of the template element and to make templating

Re: [webcomponents] HTML Parsing and the element

On Wed, Apr 18, 2012 at 2:31 PM, James Graham wrote: > On Wed, 18 Apr 2012, Dimitri Glazkov wrote: > >>> Wouldn't it make more sense to host the template contents as normal >>> descendants of the template element and to make templating APIs accept >>> either template elements or document fragments

Re: [webcomponents] HTML Parsing and the element

On Wed, 18 Apr 2012, Dimitri Glazkov wrote: Wouldn't it make more sense to host the template contents as normal descendants of the template element and to make templating APIs accept either template elements or document fragments as template input?  Or to make the template elements have a cloneA

Re: [webcomponents] HTML Parsing and the element

On Wed, Apr 18, 2012 at 9:32 AM, Dimitri Glazkov wrote: > On Wed, Apr 18, 2012 at 7:49 AM, Henri Sivonen wrote: >> On Tue, Apr 3, 2012 at 1:21 AM, Dimitri Glazkov >> wrote: >>> Perhaps lost among other updates was the fact that I've gotten the >>> first draft of HTML Templates spec out: >>> >>>

Re: Request for FormData.remove() method

On 18.4.2012 6:50, David Sickmiller wrote: Hi, I must admit I am ignorant of the W3C process for drafting the XMLHttpRequest, but I see that the webpage says to send feedback to this address, so I am writing this email to submit my feedback. The "new FormData(form)" constructor is an espec

Re: [webcomponents] HTML Parsing and the element

On Wed, Apr 18, 2012 at 7:49 AM, Henri Sivonen wrote: > On Tue, Apr 3, 2012 at 1:21 AM, Dimitri Glazkov wrote: >> Perhaps lost among other updates was the fact that I've gotten the >> first draft of HTML Templates spec out: >> >> http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/templates/ind

Re: [webcomponents] HTML Parsing and the element

On Wed, Apr 18, 2012 at 8:46 AM, Anne van Kesteren wrote: > On Wed, 18 Apr 2012 16:49:55 +0200, Henri Sivonen wrote: >> When implementing this, making embedded content inert is probably the >> most time-consuming part and just using a document fragment as a >> wrapper isn't good enough anyway, si

Re: [CORS] Applying preflight cache to an entire domain?

On Wed, 18 Apr 2012 18:34:42 +0200, Monsur Hossain wrote: Ah thank you! I agree that url canonicalization is a difficult issue to solve. FWIW, I was envisioning something much simpler. The CORS spec makes it clear that cache lookup should be done by origin and request url. So instead of spec

Re: [CORS] Applying preflight cache to an entire domain?

Ah thank you! I agree that url canonicalization is a difficult issue to solve. FWIW, I was envisioning something much simpler. The CORS spec makes it clear that cache lookup should be done by origin and request url. So instead of specifying a url to this Access-Control-Policy-Path header, it would

Re: [webcomponents] HTML Parsing and the element

On Wed, Apr 18, 2012 at 7:49 AM, Henri Sivonen wrote: > On Tue, Apr 3, 2012 at 1:21 AM, Dimitri Glazkov wrote: >> Perhaps lost among other updates was the fact that I've gotten the >> first draft of HTML Templates spec out: >> >> http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/templates/ind

Re: [webcomponents] HTML Parsing and the element

On Wed, 18 Apr 2012 16:49:55 +0200, Henri Sivonen wrote: When implementing this, making embedded content inert is probably the most time-consuming part and just using a document fragment as a wrapper isn't good enough anyway, since for example img elements load their src even when not inserted i

Re: [webcomponents] HTML Parsing and the element

On Tue, Apr 3, 2012 at 1:21 AM, Dimitri Glazkov wrote: > Perhaps lost among other updates was the fact that I've gotten the > first draft of HTML Templates spec out: > > http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/templates/index.html "Once parsed, the template contents must not be in t

Re: [CORS] Applying preflight cache to an entire domain?

On Tue, 17 Apr 2012 23:35:16 +0200, Monsur Hossain wrote: Hi there. The CORS spec currently indicates that the preflight cache should store preflight responses for a particular origin/request url pair. That means that multiple requests to different urls on the same domain will always trigger

Re: Request for FormData.remove() method

On Wed, 18 Apr 2012 06:50:45 +0200, David Sickmiller wrote: (I'm removing cue text from text input fields.) Could you elaborate on what "cue text" is? It kind of sounds like you want to use but I'm not entirely sure. -- Anne van Kesteren http://annevankesteren.nl/

[CORS] Applying preflight cache to an entire domain?

Hi there. The CORS spec currently indicates that the preflight cache should store preflight responses for a particular origin/request url pair. That means that multiple requests to different urls on the same domain will always trigger a preflight, even if the preflight response is exactly the same

Request for FormData.remove() method

Hi, I must admit I am ignorant of the W3C process for drafting the XMLHttpRequest, but I see that the webpage says to send feedback to this address, so I am writing this email to submit my feedback. The "new FormData(form)" constructor is an especially handy way to slurp in all the data for

[XHR] Authentication prompt during send()

Hi All, I'm attempting to understand some (thankfully consistent) behavior that I am seeing across browsers that, to my interpretation, does not follow the XMLHttpRequest specification (Level 2 Working Draft). Hopefully you can provide some guidance or point me in the appropriate direction.