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
(way behind, slowly catching up...)
On Thu, Nov 21, 2013 at 2:21 PM, Daniel Buchner dan...@mozilla.com 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:
link rel=import elements=x-foo, x-bar /
+1. I think this
On Fri, Feb 15, 2013 at 3:06 AM, Anne van Kesteren ann...@annevk.nl 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
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, where