On Mon, Jan 4, 2016 at 9:12 AM, Anne van Kesteren wrote:
> We have three more seats at this point, allocated on the basis of
> first come, first served.
>
If any are still available, I'd like to reserve one as well :)
Would it be possible to meet the security goals without assuming that the
response body is part of the package? See [1] for background on why that's
beneficial.. at least for performance side of the story. I'm picturing a
package description where each resource has a SRI token, plus a signature
to
http://lists.w3.org/Archives/Public/public-whatwg-archive/2014Aug/0081.html
- I recently got some good offline feedback on the proposal, need to update
it, stay tuned.
http://lists.w3.org/Archives/Public/public-whatwg-archive/2014Aug/0177.html
- related~ish, may be of interest.
ig
On Tue, Sep 30
(way behind, slowly catching up...)
On Thu, Nov 21, 2013 at 2:21 PM, Daniel Buchner wrote:
> Steve and I talked at the Chrome Dev Summit today and generated an idea
> that may align the stars for our async/sync needs:
>
>
>
+1. I think this is the right default: async by default, and the wrong
On Fri, Feb 15, 2013 at 3:06 AM, Anne van Kesteren wrote:
> Just to be clear. I understand why we'd want this. I'm a) wondering
> why it'll be successful this time given it has the same
> characteristics as ping="" b) asking about the desired timeframe given
> the highly likely introduction of a
A lot of the discussion so far focused on the async analytics beacon +
unload use case. However, while this is an important case to consider,
let's not constrain this proposal to "on unload" case only.
Effectively, what we want is a generic "send this request sometime later, I
don't care when", wh