On Sun, Jul 12, 2015 at 1:51 PM Anne van Kesteren ann...@annevk.nl wrote:
On Sun, Jul 12, 2015 at 7:49 PM, Jonas Sicking jo...@sicking.cc wrote:
I think we've already made that assumption given that history.state
already relies on this.
Good point. I'm still somewhat skeptical of
On Mon, Jul 13, 2015 at 3:58 PM, Majid Valipour maji...@chromium.org wrote:
It is only used as way to group properties (perhaps similar to
ValidityState?) and to keep History interface clean and stack-like. If that
is not valuable enough to introduce a new interface then putting these on
the
On Mon, Jul 13, 2015 at 4:26 PM, Anne van Kesteren ann...@annevk.nl wrote:
On Mon, Jul 13, 2015 at 3:58 PM, Majid Valipour maji...@chromium.org wrote:
It is only used as way to group properties (perhaps similar to
ValidityState?) and to keep History interface clean and stack-like. If that
is
Apart from the problems already discussed here, there is currently no
specced or interoperably implemented way to set a preload value that
guarantees HAVE_CURRENT_DATA, HAVE_FUTURE_DATA or HAVE_ENOUGH_DATA will be
reached ... auto may do one of those things, but it doesn't have to, and
in fact on
On Sun, Jul 12, 2015 at 11:52 PM, Elliott Sprehn espr...@chromium.org wrote:
This is what I had in mind as well. Also it occurs to me there's a missing
primitive here for how the browser knows that all listeners have mayCancel:
false so it can make this optimization. EventTarget needs some kind
On Mon, Jul 13, 2015 at 8:09 AM, Elliott Sprehn espr...@chromium.org wrote:
Without such a function there's no primitive to explain how the scrolling
and touch systems utilize this mayCancel bit unless we're saying the browser
stores hidden state for event listeners in some WeakMap and all the
