Re: [whatwg] Proposal: Allow disabling of default scroll restoration behavior
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 introducing new objects just for the purpose of grouping some properties if they don't serve a purpose on their own. 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 History interface is fine. Majid
Re: [whatwg] Proposal: Allow disabling of default scroll restoration behavior
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 History interface is fine. I personally prefer flatter structures, but you're correct that there's precedent for both and given a 1:1 relationship without setter it does seem rather harmless. -- https://annevankesteren.nl/
Re: [whatwg] Proposal: Allow disabling of default scroll restoration behavior
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 not valuable enough to introduce a new interface then putting these on the History interface is fine. I personally prefer flatter structures, but you're correct that there's precedent for both and given a 1:1 relationship without setter it does seem rather harmless. FWIW, I also think that just history.scrollRestoration would be fine, better even. Given the generic name options, any future additions to it would still have the same names as if they're added directly to the History interface, I'm guessing. If the StateOptions interface could be implemented with no internal reference back to its owning History object it seems pretty harmless, a mere holder of values, but it'll look pretty weird if no additions are actually made to it in the future. Philip
Re: [whatwg] preload=metadata elements don't necessarily fire canplay
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 mobile Firefox we don't guarantee any of those things. So I suggest we revamp preload as follows: preload=none: the goal readyState is HAVE_NOTHING. preload=loadedmetadata: the goal readyState is HAVE_METADATA. preload=metadata: the goal readyState is HAVE_METADATA (or some higher value if needed for Web compatbility). preload=loadeddata: the goal readyState is HAVE_CURRENT_DATA. preload=canplay: the goal readyState is HAVE_FUTURE_DATA. preload=canplaythrough: the goal readyState is HAVE_ENOUGH_DATA. (Thus the expectation for authors is that if you set preload=X then event X will eventually fire.) I would spec that while the autoplaying flag is true, the readyState of the element is limited to less than or equal to the goal readyState if there is one. (Note that the autoplaying flag value does not depend on the presence of the autoplay attribute.) Rob -- lbir ye,ea yer.tnietoehr rdn rdsme,anea lurpr edna e hnysnenh hhe uresyf toD selthor stor edna siewaoeodm or v sstvr esBa kbvted,t rdsme,aoreseoouoto o l euetiuruewFa kbn e hnystoivateweh uresyf tulsa rehr rdm or rnea lurpr .a war hsrer holsa rodvted,t nenh hneireseoouot.tniesiewaoeivatewt sstvr esn
Re: [whatwg] DOM Events Proposal: EventListenerOptions 'mayCancel' for improved scroll performance
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 of method like: boolean hasOnlyPassiveEventListeners(DOMString type) so the scroll system can query if all listeners have mayCancel: false to make the optimization. That would make event listeners observable. -- https://annevankesteren.nl/
Re: [whatwg] DOM Events Proposal: EventListenerOptions 'mayCancel' for improved scroll performance
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 browser systems use HiddenEventState.get(node).hasOnlyPassiveEventListeners(type). That's effectively what we'll have to implement internally, and if we don't expose it then we haven't explained the platform or given authors the ability to use this same optimization for their custom elements and events. If you actually want to expose the primitives browsers use around events you should advocate exposing the listeners. Since there's a whole bunch of optimizations browsers already make based on the presence/absence/type of those. But again, it's not entirely clear that's a good idea. -- https://annevankesteren.nl/
