[CORS] Applying preflight cache to an entire domain?

2012-04-18 Thread Monsur Hossain
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 for those urls. If a server only accepts a set of well defined http
methods and http headers, then issuing the preflight on different requests
is redundant.

I was wondering if there could be a way for the server to indicate what
scope the preflight applies to? For example, the default could still be to
cache per origin/request-url, but maybe the server could set a special
Access-Control-Max-Age-Scope: domain response header to indicate that the
preflight response can be used for any request to the domain. Has anything
like this been considered?

Thanks,
Monsur


Request for FormData.remove() method

2012-04-18 Thread David Sickmiller

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 a given form.  As the documentation describes, the 
algorithm for constructing the form data set is quite intricate -- it 
takes 3 pages to describe.


I have an application where I need to change or remove field values that 
were received from the user, before they are submitted using an XHR.  
(I'm removing cue text from text input fields.)  It would be ideal to 
call some sort of FormData.remove() (or perhaps removeAllByName) 
method.  Unfortunately, no function like that is defined in the FormData 
interface.  The most obvious alternative is to re-implement the 3-page 
algorithm to construct the form data set, and then add my 
application-specific twist.  That's not a simple task to get perfect.


I can think of a few workarounds, but none are great.  I could change 
the field values before constructing FormData, but that would be visible 
to the user, and I would need to revert the field values if the user 
needs to continue interacting with the form (e.g. to fix an error 
reported by the server).  A slightly better workaround would be to 
change or remove the field names before constructing FormData, because 
that would not be visible to the user.  However, it would still require 
un-doing and still feels like a hack.


In contrast, adding additional fields to FormData after construction is 
simple; just call FormData.append().


Here's my proposal for a FormData.removeAllByName() method:

   fd.removeAllByName(name)

 * Removes all name/value pairs matching the specified name.
 * Returns a number indicating how many name/value pairs were removed.

Thank you,
David



Re: Request for FormData.remove() method

2012-04-18 Thread Anne van Kesteren
On Wed, 18 Apr 2012 06:50:45 +0200, David Sickmiller  
davesickmil...@gmail.com 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 input placeholder=Name here... name=name but I'm not entirely  
sure.



--
Anne van Kesteren
http://annevankesteren.nl/



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

2012-04-18 Thread Anne van Kesteren
On Tue, 17 Apr 2012 23:35:16 +0200, Monsur Hossain mon...@gmail.com  
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 a preflight, even if the preflight response is exactly the
same for those urls. If a server only accepts a set of well defined http
methods and http headers, then issuing the preflight on different  
requests

is redundant.

I was wondering if there could be a way for the server to indicate what
scope the preflight applies to? For example, the default could still be  
to cache per origin/request-url, but maybe the server could set a special
Access-Control-Max-Age-Scope: domain response header to indicate that  
the preflight response can be used for any request to the domain. Has  
anything like this been considered?


Yes.

http://lists.w3.org/Archives/Public/public-appformats/2008May/0039.html


--
Anne van Kesteren
http://annevankesteren.nl/



Re: [webcomponents] HTML Parsing and the template element

2012-04-18 Thread Henri Sivonen
On Tue, Apr 3, 2012 at 1:21 AM, Dimitri Glazkov dglaz...@chromium.org 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 the document tree.

That's surprising, radical and weird.  Why are the template contents
hosted in a document fragment that the template element points to
using a non-child property?  Why aren't the template contents simply
hosted as a subtree rooted at the template element?

This also breaks the natural mapping between XML source and the DOM in
the XML case.

This weirdness also requires a special case to the serialization algorithm.

If the document fragment wasn't there and the contents of the template
were simply children of template element, the parsing algorithm
changes would look rather sensible.

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 cloneAsFragment() method if the
template fragment is designed to be cloned as the first step anyway?

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 into the DOM tree. Currently, Gecko
can make imbedded content inert on a per-document basis.  This
capability is used for documents returned by XHR, createDocument and
createHTMLDocument. It looks like the template proposal will involve
computing inertness from the ancestor chain (template ancestor or
DocumentFragment marked as inert as an ancestor).  It's unclear to me
what the performance impact will be.

-- 
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/



Re: [webcomponents] HTML Parsing and the template element

2012-04-18 Thread Anne van Kesteren

On Wed, 18 Apr 2012 16:49:55 +0200, Henri Sivonen hsivo...@iki.fi 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 into the DOM tree. Currently, Gecko
can make imbedded content inert on a per-document basis.  This
capability is used for documents returned by XHR, createDocument and
createHTMLDocument. It looks like the template proposal will involve
computing inertness from the ancestor chain (template ancestor or
DocumentFragment marked as inert as an ancestor).  It's unclear to me
what the performance impact will be.


FYI, now there's dialog and a global inert= attribute so if those  
features stay template should presumably just hook into them.



--
Anne van Kesteren
http://annevankesteren.nl/



Re: [webcomponents] HTML Parsing and the template element

2012-04-18 Thread Dimitri Glazkov
On Wed, Apr 18, 2012 at 7:49 AM, Henri Sivonen hsivo...@iki.fi wrote:
 On Tue, Apr 3, 2012 at 1:21 AM, Dimitri Glazkov dglaz...@chromium.org 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 the document tree.

 That's surprising, radical and weird.  Why are the template contents
 hosted in a document fragment that the template element points to
 using a non-child property?  Why aren't the template contents simply
 hosted as a subtree rooted at the template element?

In terms of weirdness, this is not much different from the textarea,
script, or xmp. It does change the existing behavior, so anyone using
a template tag today will suddenly find no child nodes -- that part
_is_ a bit surprising.

However, moving this into a separate document fragment allows us to
easily define the boundaries of intertness. If you look at the spec,
the document fragment is indeed created from a separate document is
inert (like createHTMLDocument case):
http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/templates/index.html#dfn-template-contents-initialization.


 This also breaks the natural mapping between XML source and the DOM in
 the XML case.

True.


 This weirdness also requires a special case to the serialization algorithm.

True.


 If the document fragment wasn't there and the contents of the template
 were simply children of template element, the parsing algorithm
 changes would look rather sensible.

Great!


 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 cloneAsFragment() method if the
 template fragment is designed to be cloned as the first step anyway?

 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 into the DOM tree. Currently, Gecko
 can make imbedded content inert on a per-document basis.  This
 capability is used for documents returned by XHR, createDocument and
 createHTMLDocument. It looks like the template proposal will involve
 computing inertness from the ancestor chain (template ancestor or
 DocumentFragment marked as inert as an ancestor).  It's unclear to me
 what the performance impact will be.

Right, ancestor-based inertness is exactly what we avoid with sticking
the parsed contents into a document fragment from an inert document.
Otherwise, things get hairy quick.

:DG


 --
 Henri Sivonen
 hsivo...@iki.fi
 http://hsivonen.iki.fi/



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

2012-04-18 Thread Monsur Hossain
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 be just one of three values:

   - url - (default behavior) Cache lookup is done by origin and request
   url, as the spec indicates now
   - origin - Cache lookup is done by origin only. Preflight response
   applies to any request from this origin.
   - any - Cache lookup applies to *any* origin making requests to the
   domain.

This would fit in with the current preflight caching model while still
allowing some flexibility to servers implementing CORS.

Thanks,
Monsur


On Wed, Apr 18, 2012 at 7:16 AM, Anne van Kesteren ann...@opera.com wrote:

 On Tue, 17 Apr 2012 23:35:16 +0200, Monsur Hossain mon...@gmail.com
 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 a preflight, even if the preflight response is exactly the
 same for those urls. If a server only accepts a set of well defined http
 methods and http headers, then issuing the preflight on different requests
 is redundant.

 I was wondering if there could be a way for the server to indicate what
 scope the preflight applies to? For example, the default could still be
 to cache per origin/request-url, but maybe the server could set a special
 Access-Control-Max-Age-Scope: domain response header to indicate that
 the preflight response can be used for any request to the domain. Has
 anything like this been considered?


 Yes.

 http://lists.w3.org/Archives/**Public/public-appformats/**
 2008May/0039.htmlhttp://lists.w3.org/Archives/Public/public-appformats/2008May/0039.html


 --
 Anne van Kesteren
 http://annevankesteren.nl/



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

2012-04-18 Thread Anne van Kesteren
On Wed, 18 Apr 2012 18:34:42 +0200, Monsur Hossain mon...@gmail.com  
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 specifying a url to this Access-Control-Policy-Path header, it
would be just one of three values:

   - url - (default behavior) Cache lookup is done by origin and  
request

   url, as the spec indicates now
   - origin - Cache lookup is done by origin only. Preflight response
   applies to any request from this origin.
   - any - Cache lookup applies to *any* origin making requests to the
   domain.

This would fit in with the current preflight caching model while still
allowing some flexibility to servers implementing CORS.


The reason why we wanted it scoped was because people had concerns about  
giving any URL on a server control over which other resources would end up  
being shared. The scenarios typically involved large organizations with  
many different teams operating on a single origin. If one of those teams  
thinks sharing with everyone is fine, the rest can be comprised. And such  
a mistake is rather easy to make.


Another general concern that has been frequently raised and why the  
specification has so many flags for enabling additional features such as  
headers and methods, is that people easily shoot themselves in the foot.  
Your proposal makes it rather easy for them to shoot themselves in the  
foot.



--
Anne van Kesteren
http://annevankesteren.nl/



Re: [webcomponents] HTML Parsing and the template element

2012-04-18 Thread Tab Atkins Jr.
On Wed, Apr 18, 2012 at 8:46 AM, Anne van Kesteren ann...@opera.com wrote:
 On Wed, 18 Apr 2012 16:49:55 +0200, Henri Sivonen hsivo...@iki.fi 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 into the DOM tree. Currently, Gecko
 can make imbedded content inert on a per-document basis.  This
 capability is used for documents returned by XHR, createDocument and
 createHTMLDocument. It looks like the template proposal will involve
 computing inertness from the ancestor chain (template ancestor or
 DocumentFragment marked as inert as an ancestor).  It's unclear to me
 what the performance impact will be.

 FYI, now there's dialog and a global inert= attribute so if those
 features stay template should presumably just hook into them.

Different concept of 'inertness', unless I'm greatly mistaken.

The @inert attribute turns off all user interaction - mouse, tabs,
access keys, etc. - with the elements in the subtree.

The inertness that the template element wants is preventing network
requests and such, so that it's friendly to templating systems that
want to produce templated urls in img/etc that get some of their
pieces filled in upon instantiation.

~TJ



Re: [webcomponents] HTML Parsing and the template element

2012-04-18 Thread Tab Atkins Jr.
On Wed, Apr 18, 2012 at 7:49 AM, Henri Sivonen hsivo...@iki.fi wrote:
 On Tue, Apr 3, 2012 at 1:21 AM, Dimitri Glazkov dglaz...@chromium.org 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 the document tree.

 That's surprising, radical and weird.  Why are the template contents
 hosted in a document fragment that the template element points to
 using a non-child property?  Why aren't the template contents simply
 hosted as a subtree rooted at the template element?

As Dimitri says, it can make inertness a little simpler to explain.

It also prevents APIs like querySelector from accidentally grabbing
the contents of a template when they *intend* to grab the real DOM
produced from the template.

~TJ

 This also breaks the natural mapping between XML source and the DOM in
 the XML case.

 This weirdness also requires a special case to the serialization algorithm.

 If the document fragment wasn't there and the contents of the template
 were simply children of template element, the parsing algorithm
 changes would look rather sensible.

 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 cloneAsFragment() method if the
 template fragment is designed to be cloned as the first step anyway?

 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 into the DOM tree. Currently, Gecko
 can make imbedded content inert on a per-document basis.  This
 capability is used for documents returned by XHR, createDocument and
 createHTMLDocument. It looks like the template proposal will involve
 computing inertness from the ancestor chain (template ancestor or
 DocumentFragment marked as inert as an ancestor).  It's unclear to me
 what the performance impact will be.

 --
 Henri Sivonen
 hsivo...@iki.fi
 http://hsivonen.iki.fi/




Re: Request for FormData.remove() method

2012-04-18 Thread Bronislav Klučka



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 especially handy way to 
slurp in all the data for a given form.  As the documentation 
describes, the algorithm for constructing the form data set is quite 
intricate -- it takes 3 pages to describe.


I have an application where I need to change or remove field values 
that were received from the user, before they are submitted using an 
XHR.  (I'm removing cue text from text input fields.)  It would be 
ideal to call some sort of FormData.remove() (or perhaps 
removeAllByName) method.  Unfortunately, no function like that is 
defined in the FormData interface.  The most obvious alternative is to 
re-implement the 3-page algorithm to construct the form data set, and 
then add my application-specific twist.  That's not a simple task to 
get perfect.
Agreed, being able to work with FormData as an object (setters, getters, 
deleters) would be improvement... so far we only have setters


any get(DOMString name)
method to retrieve FormData value

DOMString name(number index)
to get FormData name at particular index (function could return empty 
string if there is no name at that index),

var i = 0;
while (name = formData.name(i++)) { doSomething(formData.get(name)); }

or maybe even count property to get the number of names

FormData can be useful not only to be sent via XHR, but essentially to 
hold form values easily, e.g. you can have settings form (that you do 
not need to send any where = you do not need to store it or you store it 
in e.g. IndexDb), then get this settings and alter application according 
to this settings... Instead of doing exactly the same, but manually


Brona



Re: [webcomponents] HTML Parsing and the template element

2012-04-18 Thread Rafael Weinstein
On Wed, Apr 18, 2012 at 9:32 AM, Dimitri Glazkov dglaz...@chromium.org wrote:
 On Wed, Apr 18, 2012 at 7:49 AM, Henri Sivonen hsivo...@iki.fi wrote:
 On Tue, Apr 3, 2012 at 1:21 AM, Dimitri Glazkov dglaz...@chromium.org 
 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 the document tree.

 That's surprising, radical and weird.  Why are the template contents
 hosted in a document fragment that the template element points to
 using a non-child property?  Why aren't the template contents simply
 hosted as a subtree rooted at the template element?

 In terms of weirdness, this is not much different from the textarea,
 script, or xmp. It does change the existing behavior, so anyone using
 a template tag today will suddenly find no child nodes -- that part
 _is_ a bit surprising.

 However, moving this into a separate document fragment allows us to
 easily define the boundaries of intertness. If you look at the spec,
 the document fragment is indeed created from a separate document is
 inert (like createHTMLDocument case):
 http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/templates/index.html#dfn-template-contents-initialization.


 This also breaks the natural mapping between XML source and the DOM in
 the XML case.

 True.

I've created a bug against the spec to make clear that the XML parser
will be unchanged WRT the template element.

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



 This weirdness also requires a special case to the serialization algorithm.

 True.


 If the document fragment wasn't there and the contents of the template
 were simply children of template element, the parsing algorithm
 changes would look rather sensible.

 Great!


 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 cloneAsFragment() method if the
 template fragment is designed to be cloned as the first step anyway?

 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 into the DOM tree. Currently, Gecko
 can make imbedded content inert on a per-document basis.  This
 capability is used for documents returned by XHR, createDocument and
 createHTMLDocument. It looks like the template proposal will involve
 computing inertness from the ancestor chain (template ancestor or
 DocumentFragment marked as inert as an ancestor).  It's unclear to me
 what the performance impact will be.

 Right, ancestor-based inertness is exactly what we avoid with sticking
 the parsed contents into a document fragment from an inert document.
 Otherwise, things get hairy quick.

 :DG


 --
 Henri Sivonen
 hsivo...@iki.fi
 http://hsivonen.iki.fi/



Re: [webcomponents] HTML Parsing and the template element

2012-04-18 Thread James Graham

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 cloneAsFragment() method if the
template fragment is designed to be cloned as the first step anyway?

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 into the DOM tree. Currently, Gecko
can make imbedded content inert on a per-document basis.  This
capability is used for documents returned by XHR, createDocument and
createHTMLDocument. It looks like the template proposal will involve
computing inertness from the ancestor chain (template ancestor or
DocumentFragment marked as inert as an ancestor).  It's unclear to me
what the performance impact will be.


Right, ancestor-based inertness is exactly what we avoid with sticking
the parsed contents into a document fragment from an inert document.
Otherwise, things get hairy quick.



I am also pretty scared of tokenising stuff like it is markup but then 
sticking it into a different document. It seems like very surprising 
behaviour. Have you considered (and this may be a very bad idea) exposing 
the markup inside the template as a text node, but exposing the 
corresponding DOM as an IDL attribute on the HTMLTemplateElement (or 
whatever it's called) interface?