[whatwg] How to add html5 browser support

Hi, I'm taking online class to program a browser from scratch. How do I add Html5 support? Thank you. -Brian Jones

Re: [whatwg] deprecating

lemented by all vendors, which would certainly be an > improvement over the current situation. Its a bit optimistic especially in the security area to think that if you remove a security component it is going to magically re-appear. Anyway, let's leave that discussion to the TAG. Still I t

Re: [whatwg] deprecating

> On 2 Sep 2015, at 14:56, Philip Jägenstedt wrote: > > On Wed, Sep 2, 2015 at 1:00 PM, henry.st...@bblfish.net > wrote: >> >>> On 1 Sep 2015, at 19:56, Ian Hickson wrote: >>> >>> As far as I can tell, therefore, things here are

Re: [whatwg] VIDEO and pitchAdjustment

I'm an implementer (to the fullest extent that one can be one by modifying existing open source), just following the convention of this list of stating my use case. The use case reflects reality since it was implemented last year. On Mon, Aug 31, 2015 at 12:04 PM, Domenic Denicola

Re: [whatwg] deprecating

> On 1 Sep 2015, at 19:56, Ian Hickson <i...@hixie.ch> wrote: > > On Tue, 1 Sep 2015, henry.st...@bblfish.net wrote: >> >> As the WhatWG only recenly moved to Github members here may not have >> noticed that has been deprecated. >> >> I opened htt

Re: [whatwg] deprecating

On Wed, Sep 2, 2015 at 1:00 PM, henry.st...@bblfish.net wrote: > >> On 1 Sep 2015, at 19:56, Ian Hickson wrote: >> >> As far as I can tell, therefore, things here are working exactly as one >> should expect. > > Indeed: they seem to be working as one would

Re: [whatwg] VIDEO and pitchAdjustment

> On Sep 1, 2015, at 4:03 , Robert O'Callahan wrote: > > On Tue, Sep 1, 2015 at 8:02 PM, Kevin Marks wrote: > >> QuickTime supports full variable speed playback and has done for well over >> a decade. With bidirectionally predicted frames you need a

Re: [whatwg] VIDEO and pitchAdjustment

On Tue, Sep 1, 2015 at 10:55 AM, David Singer wrote: > > > On Sep 1, 2015, at 10:47 , Yay295 wrote: > > > > On Tue, Sep 1, 2015 at 11:30 AM, David Singer wrote: > > > On Sep 1, 2015, at 4:03 , Robert O'Callahan >

Re: [whatwg] VIDEO and pitchAdjustment

On Tue, Sep 1, 2015 at 11:57 AM, David Singer wrote: > > > On Sep 1, 2015, at 11:36 , Kevin Marks wrote: > > > I suppose the browser could generate this data the first time it reads > through the video. It would use a lot less memory. Though that sounds

Re: [whatwg] VIDEO and pitchAdjustment

> On Sep 1, 2015, at 11:36 , Kevin Marks wrote: > > I suppose the browser could generate this data the first time it reads > > through the video. It would use a lot less memory. Though that sounds like > > a problem for the browsers to solve, not the standard. > > There

Re: [whatwg] VIDEO and pitchAdjustment

On Tue, Sep 1, 2015 at 11:30 AM, David Singer wrote: > > On Sep 1, 2015, at 4:03 , Robert O'Callahan > wrote: > >> On Tue, Sep 1, 2015 at 8:02 PM, Kevin Marks > wrote: > >> QuickTime supports full variable speed playback and has

Re: [whatwg] VIDEO and pitchAdjustment

> On Sep 1, 2015, at 10:47 , Yay295 wrote: > > On Tue, Sep 1, 2015 at 11:30 AM, David Singer wrote: > > On Sep 1, 2015, at 4:03 , Robert O'Callahan wrote: > >> On Tue, Sep 1, 2015 at 8:02 PM, Kevin Marks wrote: >

Re: [whatwg] deprecating

On Tue, 1 Sep 2015, henry.st...@bblfish.net wrote: > > As the WhatWG only recenly moved to Github members here may not have > noticed that has been deprecated. > > I opened https://github.com/whatwg/html/issues/67 to give space for the > discussion. It is a pitty that

Re: [whatwg] VIDEO and pitchAdjustment

On Wed, Sep 2, 2015 at 5:30 AM, David Singer wrote: > On Sep 1, 2015, at 4:03 , Robert O'Callahan wrote: > > How about a hard but realistic (IMHO) case: 4K video (4096 x 2160), 25 > fps, > > keyframe every 10s. Storing all those frames takes 250 x 4096 x

Re: [whatwg] VIDEO and pitchAdjustment

QuickTime supports full variable speed playback and has done for well over a decade. With bidirectionally predicted frames you need a fair few buffers anyway, so generalising to full variable wait is easier than posters above claim - you need to work a GOP at a time, but memory buffering isn't the

[whatwg] deprecating

As the WhatWG only recenly moved to Github members here may not have noticed that has been deprecated. I opened https://github.com/whatwg/html/issues/67 to give space for the discussion. It is a pitty that this was closed so quickly ( within an hour ) without giving members and the public

Re: [whatwg] VIDEO and pitchAdjustment

On Mon, Aug 31, 2015 at 9:48 PM, Domenic Denicola wrote: > From: Eric Carlson [mailto:eric.carl...@apple.com] > >> FWIW, Safari supports negative playback rates on the desktop and on iOS. >> >> ... >> >> The crash Garrett noted in Safari 8 is a bug that “only" happens with

Re: [whatwg] VIDEO and pitchAdjustment

On Tue, Sep 1, 2015 at 8:02 PM, Kevin Marks wrote: > QuickTime supports full variable speed playback and has done for well over > a decade. With bidirectionally predicted frames you need a fair few buffers > anyway, so generalising to full variable wait is easier than

Re: [whatwg] VIDEO and pitchAdjustment

On Fri, Aug 28, 2015 at 11:17 AM, Domenic Denicola wrote: > From: Robert O'Callahan > >> According to the spec it should work, but it's very low priority for us and >> implementing it would be very inefficient as Yay295 describes. So I don't >> think it's going to happen in Firefox in the

Re: [whatwg] VIDEO and pitchAdjustment

On 8/31/15, Michael Enright wrote: > On Fri, Aug 28, 2015 at 11:17 AM, Domenic Denicola wrote: >> From: Robert O'Callahan >> >>> According to the spec it should work, but it's very low priority for us >>> and >>> implementing it would be very inefficient as Yay295 describes.

Re: [whatwg] VIDEO and pitchAdjustment

To be clear: Everyone can imagine use cases for playing videos backward. However, so far the only statements we have about implementations are negative. My subthread was more concerned with making the spec reflect current reality. If you can convince implementers to support backward videos,

Re: [whatwg] VIDEO and pitchAdjustment

> On Aug 31, 2015, at 12:04 PM, Domenic Denicola wrote: > > My subthread was more concerned with making the spec reflect current reality. > If you can convince implementers to support backward videos, then that's > separate, and we can change the spec again. > FWIW,

Re: [whatwg] VIDEO and pitchAdjustment

From: Eric Carlson [mailto:eric.carl...@apple.com] > FWIW, Safari supports negative playback rates on the desktop and on iOS. > > ... > > The crash Garrett noted in Safari 8 is a bug that “only" happens with MSE > content. That's really helpful, thanks. Combined with Edge's keyframes-only

Re: [whatwg] HTML spec now on GitHub

For convenience: https://github.com/whatwg/html :) (https://svn.whatwg.org/ still refers to the SVN repo.) -- Jens Oliver Meiert http://meiert.com/en/ ✎ The Little Book of HTML/CSS Frameworks: http://meiert.com/frameworks

Re: [whatwg] Inline SVG: Embedded vs. Metadata Content Distinction (Was: Fwd: Allow Select SVG Elements In head)

On Sat, Aug 29, 2015 at 12:51 AM, Hugh Guiney hugh.gui...@gmail.com wrote: Bueller...? Bueller...? This request is almost 5 years old now, but it is even more relevant today, now that web developers are increasingly embracing SVG for purposes of responsive design and accommodating HiDPI

Re: [whatwg] VIDEO and pitchAdjustment

On Sat, Aug 29, 2015 at 8:18 AM, James Ross ja...@james-ross.co.uk wrote: Support is certainly poor; Internet Explorer/Trident and Edge both support negative playback rates on desktop (I haven’t tested mobile) but do so by simply showing the key frames as they are reached in reverse, in my

[whatwg] Inline SVG: Embedded vs. Metadata Content Distinction (Was: Fwd: Allow Select SVG Elements In head)

it here. Is this something the SVG WG is willing to do? Thanks! -Hugh -- Forwarded message -- From: Ian Hickson i...@hixie.ch Date: Mon, Dec 6, 2010 at 9:35 PM Subject: Re: [whatwg] Allow Select SVG Elements In head To: Hugh Guiney hugh.gui...@gmail.com Cc: whatwg wha

[whatwg] FW: VIDEO and pitchAdjustment

From: Domenic Denicola From: whatwg [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Robert O'Callahan According to the spec it should work, but it's very low priority for us and implementing it would be very inefficient as Yay295 describes. So I don't think it's going to happen

Re: [whatwg] VIDEO and pitchAdjustment

From: whatwg [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Robert O'Callahan According to the spec it should work, but it's very low priority for us and implementing it would be very inefficient as Yay295 describes. So I don't think it's going to happen in Firefox in the forseeable

Re: [whatwg] VIDEO and pitchAdjustment

On Fri, Aug 28, 2015 at 12:17 PM, Domenic Denicola d...@domenic.me wrote: From: whatwg [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Robert O'Callahan According to the spec it should work, but it's very low priority for us and implementing it would be very inefficient as Yay295

Re: [whatwg] VIDEO and pitchAdjustment

On Sat, Aug 29, 2015 at 8:27 AM, Robert O'Callahan rob...@ocallahan.org wrote: On Sat, Aug 29, 2015 at 8:18 AM, James Ross ja...@james-ross.co.uk wrote: Support is certainly poor; Internet Explorer/Trident and Edge both support negative playback rates on desktop (I haven’t tested mobile) but

[whatwg] VIDEO and pitchAdjustment

It would be useful to have pitch adjustment for VIDEO element. There is playbackRate, to control playback speed — useful!* And there is vv.mozPreservesPitch, in Firefox, which can be set to false, so that pitch will adjust to the speed of the video, sort of like old analog gear (tapes and

[whatwg] HTML spec now on GitHub

Just a heads-up to those of you who like to follow the nitty gritty of spec development here: The HTML spec has joined the other WHATWG specs on GitHub, rather than being alone in the svn.whatwg.org SVN repository. This will enable other WHATWG editors to also contribute to the HTML spec, so

Re: [whatwg] VIDEO and pitchAdjustment

On Thu, Aug 27, 2015 at 12:02 PM, Garrett Smith dhtmlkitc...@gmail.com wrote: Negative playbackRate, to watch videos backwards, currently crashes Safari 8; Firefox 40 says not implemented. I think it would be entertaining for example, to watch things like cars uncrashing. Should this work?

Re: [whatwg] VIDEO and pitchAdjustment

On Fri, Aug 28, 2015 at 6:02 AM, Garrett Smith dhtmlkitc...@gmail.com wrote: It would be useful to have pitch adjustment for VIDEO element. There is playbackRate, to control playback speed — useful!* And there is vv.mozPreservesPitch, in Firefox, which can be set to false, so that pitch will

Re: [whatwg] VIDEO and pitchAdjustment

On 8/27/15, Robert O'Callahan rob...@ocallahan.org wrote: On Fri, Aug 28, 2015 at 6:02 AM, Garrett Smith dhtmlkitc...@gmail.com wrote: It would be useful to have pitch adjustment for VIDEO element. There is playbackRate, to control playback speed — useful!* And there is vv.mozPreservesPitch,

Re: [whatwg] Worker requestAnimationFrame

We build a major HTML5 game engine, and I feel the deadline approach is unsuitable for gaming. Games often do heavy CPU work to run the game logic before drawing. (Please do not drag me in to arguments over time stepping; stepping less often than rAF does not look smooth, and stepping more often

Re: [whatwg] Worker requestAnimationFrame

On Thu, Aug 20, 2015 at 11:02 PM, Ashley Gullen ash...@scirra.com wrote: We have tried to implement half-vsync rate ourselves in the past by simply ignoring alternate rAFs, but in practice it looked terrible - I guess we broke implementation-defined heuristics that expect every rAF call to do

Re: [whatwg] Worker requestAnimationFrame

Sounds great to me. I agree this is an important scenario. *Ian*, thoughts? Is anyone actively working on worker-thread canvas in blink at the moment? Note that Ian's CompositorWorker prototype https://docs.google.com/document/d/18GGuTRGnafai17PDWjCHHAvFRsCfYUDYsi720sVPkws/edit# currently

Re: [whatwg] Worker requestAnimationFrame

On Wed, Aug 19, 2015 at 10:13 AM, Rick Byers rby...@chromium.org wrote: Sounds great to me. I agree this is an important scenario. *Ian*, thoughts? Is anyone actively working on worker-thread canvas in blink at the moment? Work not yet started, but it is in my queue. On Tue, Aug 18,

Re: [whatwg] Worker requestAnimationFrame

On Thu, Aug 20, 2015 at 4:21 AM, Ian Vollick voll...@chromium.org wrote: On Wed, Aug 19, 2015 at 7:36 AM Justin Novosad ju...@google.com wrote: On Wed, Aug 19, 2015 at 10:13 AM, Rick Byers rby...@chromium.org wrote: Sounds great to me. I agree this is an important scenario. *Ian*,

Re: [whatwg] Worker requestAnimationFrame

On Wed, Aug 19, 2015 at 5:14 PM, Robert O'Callahan rob...@ocallahan.org wrote: On Thu, Aug 20, 2015 at 4:21 AM, Ian Vollick voll...@chromium.org wrote: On Wed, Aug 19, 2015 at 7:36 AM Justin Novosad ju...@google.com wrote: On Wed, Aug 19, 2015 at 10:13 AM, Rick Byers rby...@chromium.org

[whatwg] Worker requestAnimationFrame

For OffscreenCanvas we need a way for a Worker to draw once per composited frame. I suggest we create DedicatedWorkerGlobalScope.requestAnimationFrame(callback) that works similarly to Window.requestAnimationFrame. To reduce latency for applications such as VR, I'd like to run the callback after

Re: [whatwg] [whartwg] Video processing ability for MediaStreamTrack

Hi, all, Thanks for Anne's feedback. After irc with Anne, we got some consensus. 1. addVideoProcessor() doesn't need to check duplicates due to it will create a new MST. So the worker will append to the new created MST. It means every MST will contain only one video processor. I will explicitly

Re: [whatwg] Order of popstate event and scroll restoration - interop issue

On 11/08/15 15:08, Majid Valipour wrote: According to HTML5 spec persisted user state (scroll, scale, form values, etc) should be restored before dispatching popstate event. (See steps 9 and 14 in history traversal algorithm[1]). Gecko and IE follow the spec order for scroll position but in

Re: [whatwg] Order of popstate event and scroll restoration - interop issue

On Wed, Aug 12, 2015 at 11:47 PM Jonas Sicking jo...@sicking.cc wrote: On Wed, Aug 12, 2015 at 3:31 AM, Olli Pettay o...@pettay.fi wrote: There are two options to get an interop solution: Option 1. Change the spec to reverse order, making the workaround supported officially. Does

Re: [whatwg] Order of popstate event and scroll restoration - interop issue

On Wed, Aug 12, 2015 at 12:37 PM, Majid Valipour maji...@chromium.org wrote: Does anybody know if there was any specific reasons behind the current order? Are the reasons you discovered yourself not sufficient? They are pretty compelling but was wondering if there is anything I am

Re: [whatwg] Order of popstate event and scroll restoration - interop issue

On Wed, Aug 12, 2015 at 3:31 AM, Olli Pettay o...@pettay.fi wrote: There are two options to get an interop solution: Option 1. Change the spec to reverse order, making the workaround supported officially. Does anybody know if there was any specific reasons behind the current order? If we

Re: [whatwg] Order of popstate event and scroll restoration - interop issue

/Archives/Public/public-whatwg-archive/2015May/0063.html [4] https://html.spec.whatwg.org/multipage/browsers.html#traverse-the-history [5] https://crbug.com/444094

Re: [whatwg] Order of popstate event and scroll restoration - interop issue

Does anybody know if there was any specific reasons behind the current order? Are the reasons you discovered yourself not sufficient? They are pretty compelling but was wondering if there is anything I am missing. I guess the question is whether Chrome can still change at this point

Re: [whatwg] [whartwg] Video processing ability for MediaStreamTrack

On Fri, Aug 7, 2015 at 8:56 AM, Chia-Hung Tai c...@mozilla.com wrote: http://chiahungtai.github.io/mediacapture-worker/ Given that removeVideoProcessor() does not take arguments, should addVideoProcessor() not check for duplicates? VideoProcessEventThe looks like a typo. The events don't

[whatwg] APIs to interrogate default outgoing HTTP headers, i.e. Accept-Encoding

I posted this at http://discourse.wicg.io/ a long time ago and forgot to email the list about it, so here goes... ## original post There's currently no good way to determine whether or not a browser / environment supports GZIP-deflated content entirely from the front-end. Servers can interrogate

Re: [whatwg] [whartwg] Video processing ability for MediaStreamTrack

I'm incredibly excited to see this moving forward.

Re: [whatwg] APIs to interrogate default outgoing HTTP headers, i.e. Accept-Encoding

Ron Waldon jokeyrh...@gmail.com writes: I posted this at http://discourse.wicg.io/ a long time ago and forgot to email the list about it, so here goes... ## original post There's currently no good way to determine whether or not a browser / environment supports GZIP-deflated content

Re: [whatwg] APIs to interrogate default outgoing HTTP headers, i.e. Accept-Encoding

On Tue, 11 Aug 2015 at 08:31 Nils Dagsson Moskopp n...@dieweltistgarnichtso.net wrote: I do not understand that use case. It reads incredibly convoluted to me. The UA controls the transport anyway – it should not make any practical difference to a script how the data is transmitted. My use

Re: [whatwg] APIs to interrogate default outgoing HTTP headers, i.e. Accept-Encoding

Ron Waldon jokeyrh...@gmail.com writes: On Tue, 11 Aug 2015 at 08:31 Nils Dagsson Moskopp n...@dieweltistgarnichtso.net wrote: I do not understand that use case. It reads incredibly convoluted to me. The UA controls the transport anyway – it should not make any practical difference to a

[whatwg] [whartwg] Video processing ability for MediaStreamTrack

Hi, all, This is Chia-hung Tai from Mozilla. I would like to discuss a extension specification[1] based on Media Capture and Stream. This specification is based on a project called FoxEye[2]. You can check the use cases in [3]. I already sent an email to public-webrtc mailing list[4]. But it is

Re: [whatwg] input type=number for year input

Could you explain how „format“ would work if the content of the element can not be formated like that? How could attributes be re-formated? Cameron Jones cmhjo...@gmail.com writes: On Wed, Feb 19, 2014 at 11:38 AM, Nils Dagsson Moskopp n...@dieweltistgarnichtso.net wrote: Qebui Nehebkau

Re: [whatwg] New feature: better integration with browser find interface

David Young dyo...@pobox.com writes: On Mon, Jun 22, 2015 at 11:57:46PM -0700, Mitar wrote: Hi! Followup to this proposal. So after more than half year browsers still have issues searching in dynamic apps. Google Docs can still only intercept ctrl-f, but for people who uses menu search

Re: [whatwg] Maven like dependency management for browsers

On 8/7/15, Behrang Saeedzadeh behran...@gmail.com wrote: Hi Sebastien, Guys — On Sun, Aug 2, 2015 at 10:38 PM Sébastien Cevey seb.ce...@guardian.co.uk wrote: [...] Versions can be specified either at the top-level config, or even at the import level, e.g.:

Re: [whatwg] preload=metadata elements don't necessarily fire canplay

On Thu, Jul 16, 2015 at 8:44 PM, Philip Jägenstedt phil...@opera.com wrote: OK, so perhaps file two bugs for each of those things and continue discussion there? I filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=28956. Rob -- lbir ye,ea yer.tnietoehr rdn rdsme,anea lurpr edna e

Re: [whatwg] preload=metadata elements don't necessarily fire canplay

On Thu, Jul 16, 2015 at 4:32 AM, Robert O'Callahan rob...@ocallahan.org wrote: On Thu, Jul 16, 2015 at 1:59 AM, Philip Jägenstedt phil...@opera.com wrote: On Wed, Jul 15, 2015 at 12:43 AM, Robert O'Callahan rob...@ocallahan.org wrote: On Tue, Jul 14, 2015 at 11:24 PM, Philip Jägenstedt

Re: [whatwg] Proposal: Allow disabling of default scroll restoration behavior

On Mon, Jul 13, 2015 at 5:56 PM, Majid Valipour maji...@google.com wrote: On Mon, Jul 13, 2015 at 10:55 AM Philip Jägenstedt phil...@opera.com If the StateOptions interface could be implemented with no internal reference back to its owning History object it seems pretty harmless, a mere holder

Re: [whatwg] preload=metadata elements don't necessarily fire canplay

On Thu, Jul 16, 2015 at 1:59 AM, Philip Jägenstedt phil...@opera.com wrote: On Wed, Jul 15, 2015 at 12:43 AM, Robert O'Callahan rob...@ocallahan.org wrote: On Tue, Jul 14, 2015 at 11:24 PM, Philip Jägenstedt phil...@opera.com wrote: Basically a I trust the browser to decide and promise

Re: [whatwg] preload=metadata elements don't necessarily fire canplay

On Wed, Jul 15, 2015 at 12:43 AM, Robert O'Callahan rob...@ocallahan.org wrote: On Tue, Jul 14, 2015 at 11:24 PM, Philip Jägenstedt phil...@opera.com wrote: Basically a I trust the browser to decide and promise not to assume anything state? The auto state is already suitable named and

Re: [whatwg] Proposal: Two changes to iframe@sandbox

On Thu, Jul 9, 2015 at 5:28 PM, Daniel Veditz dved...@mozilla.com wrote: On Mon, Jul 6, 2015 at 2:47 AM, Mike West mk...@google.com wrote: I've dropped the opener/openee-disowning behavior from my proposal, and renamed the sandboxing keyword to `allow-popups-to-escape-sandbox` in

Re: [whatwg] preload=metadata elements don't necessarily fire canplay

On Tue, Jul 14, 2015 at 10:33 PM, Philip Jägenstedt phil...@opera.com wrote: I see, is this a policy that's applied even with a single video in a page, or is it something like a limit on the total number of players that can be created, or limits on how much stuff (decoders) they set up

Re: [whatwg] preload=metadata elements don't necessarily fire canplay

On Tue, Jul 7, 2015 at 11:56 AM, Robert O'Callahan rob...@ocallahan.org wrote: On Tue, Jul 7, 2015 at 9:41 PM, Philip Jägenstedt phil...@opera.com wrote: Unsurprisingly, I like this, as it's basically what Presto did. However, I think preload=metadata should reach HAVE_CURRENT_DATA, because

Re: [whatwg] preload=metadata elements don't necessarily fire canplay

On Tue, Jul 14, 2015 at 3:15 AM, Robert O'Callahan rob...@ocallahan.org wrote: 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

Re: [whatwg] preload=metadata elements don't necessarily fire canplay

On Tue, Jul 14, 2015 at 8:51 PM, Philip Jägenstedt phil...@opera.com wrote: Would it solve the same practical problems if auto were redefined to mean that the goal readyState is HAVE_ENOUGH_DATA? Probably. Is there a reason it doesn't do this in mobile Firefox? We don't want a page with

Re: [whatwg] preload=metadata elements don't necessarily fire canplay

On Tue, Jul 14, 2015 at 1:08 PM, Robert O'Callahan rob...@ocallahan.org wrote: On Tue, Jul 14, 2015 at 10:33 PM, Philip Jägenstedt phil...@opera.com wrote: I see, is this a policy that's applied even with a single video in a page, or is it something like a limit on the total number of players

Re: [whatwg] preload=metadata elements don't necessarily fire canplay

On Tue, Jul 14, 2015 at 11:57 AM, Robert O'Callahan rob...@ocallahan.org wrote: On Tue, Jul 14, 2015 at 8:51 PM, Philip Jägenstedt phil...@opera.com wrote: Would it solve the same practical problems if auto were redefined to mean that the goal readyState is HAVE_ENOUGH_DATA? Probably.

Re: [whatwg] preload=metadata elements don't necessarily fire canplay

On Tue, Jul 14, 2015 at 1:17 PM, Robert O'Callahan rob...@ocallahan.org wrote: On Tue, Jul 14, 2015 at 11:13 PM, Philip Jägenstedt phil...@opera.com wrote: If the behavior could be made interoperable for when resources are not a problem, that would be a good start at least. The spec can say

Re: [whatwg] preload=metadata elements don't necessarily fire canplay

On Tue, Jul 14, 2015 at 11:13 PM, Philip Jägenstedt phil...@opera.com wrote: If the behavior could be made interoperable for when resources are not a problem, that would be a good start at least. The spec can say that the browser should at least try to ready HAVE_ENOUGH_DATA for preload=auto,

Re: [whatwg] preload=metadata elements don't necessarily fire canplay

On Tue, Jul 14, 2015 at 11:24 PM, Philip Jägenstedt phil...@opera.com wrote: Basically a I trust the browser to decide and promise not to assume anything state? The auto state is already suitable named and defined for that, so if implementing auto as anything other than try to reach

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

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

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

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

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

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

Re: [whatwg] DOM Events Proposal: EventListenerOptions 'mayCancel' for improved scroll performance

nobody wants to write code in their JavaScript engine implementation that is aware of concepts like the DOM, events, methods specifically named preventDefault, etc. -Original Message- From: whatwg [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Ashley Gullen Sent: Sunday, July 12

Re: [whatwg] DOM Events Proposal: EventListenerOptions 'mayCancel' for improved scroll performance

On Sat, Jul 11, 2015 at 11:41 PM, Rick Byers rby...@chromium.org wrote: What Anne describes is perfect! I'm not hung up on the value of cancelable itself - some internal bit on Event that makes preventDefault a no-op (or event throw) during listener invocation is fine with me (and I agree -

Re: [whatwg] DOM Events Proposal: EventListenerOptions 'mayCancel' for improved scroll performance

On Sat, Jul 11, 2015 at 11:40 PM, Anne van Kesteren ann...@annevk.nl wrote: On Sat, Jul 11, 2015 at 11:41 PM, Rick Byers rby...@chromium.org wrote: What Anne describes is perfect! I'm not hung up on the value of cancelable itself - some internal bit on Event that makes preventDefault a

Re: [whatwg] DOM Events Proposal: EventListenerOptions 'mayCancel' for improved scroll performance

On 7/12/15 12:47 PM, Ashley Gullen wrote: 1. Yes: statically references e.preventDefault 2. Maybe: some dynamic reference like e[str] 3: No: no dynamic references, and no static references to e.preventDefault Assuming the maybe case is rare Is there data supporting this assumption? I would

Re: [whatwg] DOM Events Proposal: EventListenerOptions 'mayCancel' for improved scroll performance

Is it not possible for Javascript engines to statically determine if preventDefault() is called by an event handler? For example: function myHandler(e) { // does e.preventDefault occur anywhere in this body? }; target.addEventListener(scroll, myHandler); If none of the added event handlers

Re: [whatwg] Proposal: Allow disabling of default scroll restoration behavior

On Fri, Jul 10, 2015 at 1:54 PM, Majid Valipour maji...@chromium.org wrote: On Mon, Jun 29, 2015 at 5:20 PM Jonas Sicking jo...@sicking.cc wrote: FWIW I still prefer an API like history.scrollRestoration = 'manual'; The main reason is that it seems to me that pushState/replaceState has a

Re: [whatwg] DOM Events Proposal: EventListenerOptions 'mayCancel' for improved scroll performance

Generally nobody wants to write code in their JavaScript engine implementation that is aware of concepts like the DOM, events, methods specifically named preventDefault, etc. -Original Message- From: whatwg [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Ashley Gullen Sent: Sunday

Re: [whatwg] Proposal: Allow disabling of default scroll restoration behavior

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

Re: [whatwg] Proposal: Allow disabling of default scroll restoration behavior

On Sat, Jul 11, 2015 at 10:51 AM, Anne van Kesteren ann...@annevk.nl wrote: On Fri, Jul 10, 2015 at 10:54 PM, Majid Valipour maji...@chromium.org wrote: Minor bikeshed: I have put scrollRestoration on history.options instead of directly history itself in order to use history.options as an

Re: [whatwg] Proposal: Allow disabling of default scroll restoration behavior

On Fri, Jul 10, 2015 at 10:54 PM, Majid Valipour maji...@chromium.org wrote: Minor bikeshed: I have put scrollRestoration on history.options instead of directly history itself in order to use history.options as an interface to contain any other restoration related attributes which have similar

Re: [whatwg] DOM Events Proposal: EventListenerOptions 'mayCancel' for improved scroll performance

On Sat, Jul 11, 2015 at 8:19 PM, Domenic Denicola d...@domenic.me wrote: I'm not sure that actually matters though, since canceling inside setTimeout(,0) shouldn't have much affect besides changing `e.defaultPrevented`. So maybe it's OK. It's fine. The code that dispatches an event and then

Re: [whatwg] DOM Events Proposal: EventListenerOptions 'mayCancel' for improved scroll performance

On Fri, Jul 10, 2015 at 9:12 PM, Rick Byers rby...@chromium.org wrote: 1) Should we extend the existing addEventListener API or change the API names (and perhaps other things) completely. https://github.com/RByers/EventListenerOptions/issues/18 It seems most other DOM peers are okay with

Re: [whatwg] DOM Events Proposal: EventListenerOptions 'mayCancel' for improved scroll performance

From: Anne van Kesteren [mailto:ann...@annevk.nl] 2) Should mayCancel=false listeners always get an Event with cancelable=false, or is this just a hint such that all listeners still get the same event with the same properties. https://github.com/RByers/EventListenerOptions/issues/2 I was

Re: [whatwg] DOM Events Proposal: EventListenerOptions 'mayCancel' for improved scroll performance

[On vacation now with only a phone - so apologies for the brevity and top-posting] What Anne describes is perfect! I'm not hung up on the value of cancelable itself - some internal bit on Event that makes preventDefault a no-op (or event throw) during listener invocation is fine with me (and I

Re: [whatwg] DOM Events Proposal: EventListenerOptions 'mayCancel' for improved scroll performance

Let me try to summarize the primary debate around this API so far. There are (at least) two major questions which I think block creating a proper pull request for suggesting concrete changes to the spec: 1) Should we extend the existing addEventListener API or change the API names (and perhaps

Re: [whatwg] Proposal: Allow disabling of default scroll restoration behavior

as an interface to contain any other restoration related attributes which have similar semantics (e.g., recorder scroll position, scale restoration, recorded scale). Majid [1] https://lists.w3.org/Archives/Public/public-whatwg-archive/2015Apr/0123.html

Re: [whatwg] DOM Events Proposal: EventListenerOptions 'mayCancel' for improved scroll performance

On Thu, Jul 9, 2015 at 3:44 PM, Rick Byers rby...@chromium.org wrote: On Thu, Jul 9, 2015 at 9:39 AM, Rick Byers rby...@chromium.org wrote: On Thu, Jul 9, 2015 at 9:05 AM, James Ross w3c-20040...@james-ross.co.uk wrote: Date: Thu, 9 Jul 2015 14:42:07 +0200 From: phil...@opera.com I

Re: [whatwg] DOM Events Proposal: EventListenerOptions 'mayCancel' for improved scroll performance

proposal in the form of a pull-request and move all issue tracking to whatwg/dom. There's probably no point in doing that until we have an agreement on the basic API shape, right? Fair. -- https://annevankesteren.nl/

Re: [whatwg] DOM Events Proposal: EventListenerOptions 'mayCancel' for improved scroll performance

On Thu, Jul 9, 2015 at 9:49 AM, Philip Jägenstedt phil...@opera.com wrote: On Thu, Jul 9, 2015 at 3:44 PM, Rick Byers rby...@chromium.org wrote: On Thu, Jul 9, 2015 at 9:39 AM, Rick Byers rby...@chromium.org wrote: On Thu, Jul 9, 2015 at 9:05 AM, James Ross

<    2   3   4   5   6   7   8   9   10   11   >