Re: Should web specifications try to describe object lifetimes? [was Intent to implement: AudioWorklet]

On 5/3/18 6:21 PM, Karl Tomlinson wrote: I didn't understand why he was highlighting "order of object tear-down", nor why he was implying that only "VERY fine-grained" knowledge was a problem. Alex, depending on whether he's speaking with his TAG hat or Google hat on, is either trying to

Re: Proposed W3C Charter: Devices and Sensors Working Group

On Thursday 2018-05-03 09:26 -0500, Tom Ritter wrote: > On Thu, May 3, 2018 at 2:00 AM, Anne van Kesteren wrote: > > On Thu, May 3, 2018 at 12:51 AM, L. David Baron wrote: > >> Please reply to this thread if you think there's something we should > >> say as

Re: Should web specifications try to describe object lifetimes? [was Intent to implement: AudioWorklet]

I read the threads you referenced and the latest spec, and I think you're absolutely right about everything :-). On Fri, May 4, 2018 at 10:21 AM, Karl Tomlinson wrote: > Thank you for taking a look, Boris. I'm quite unclear how any of > the changes proposed in the [[March

Re: Proposed W3C Charter: Timed Text Working Group

On Thursday 2018-05-03 08:56 +0200, Anne van Kesteren wrote: > On Thu, May 3, 2018 at 12:42 AM, L. David Baron wrote: > > Timed Text Working Group > > https://www.w3.org/2018/04/proposed-tt-charter-2018.html > > What does > > # The Group is expected to produce annual

Re: Should web specifications try to describe object lifetimes? [was Intent to implement: AudioWorklet]

On Friday 2018-05-04 10:21 +1200, Karl Tomlinson wrote: > Is having web specifications try to describe object lifetimes > helpful, or is it just over-prescribing? > > Should specifications instead just focus on observable behavior, > and leave it to implementations to optimize and to reclaim >

Should web specifications try to describe object lifetimes? [was Intent to implement: AudioWorklet]

Boris Zbarsky writes: > On 5/2/18 5:21 AM, Karl Tomlinson wrote: >> [[AudioNode Lifetime]] https://github.com/WebAudio/web-audio-api/issues/1471 > > I've read through that thread, but I'm still a little unclear on > where thing stand. With the latest proposal, can there be > observable

Re: New Policy: Marking Bugzilla bugs for features riding behind a pref

On 03/05/2018 00:57, Emma Humphries wrote: To summarize, when you are releasing a feature that "rides behind a flag", on the bug for the feature: * set the behind-pref flag to + * set the qa-verify flag to ? * note the bug in the Firefox Feature Trello board We expect qa-verify to be set to

Re: New Policy: Marking Bugzilla bugs for features riding behind a pref

On Thu, May 3, 2018 at 11:57 AM, Adam Roach wrote: > On 5/3/18 12:18 PM, Nicholas Alexander wrote: >> >> Not all features are feasible to ship behind feature flags. > > > I'm pretty sure the proposed policy isn't intended to change anything > regarding features that ship without

Announcing MozillaBuild 3.2 Release

MozillaBuild 3.2 is a minor update to version 3.1.1 mostly focusing on updating a few of the bundled components to newer versions. https://ftp.mozilla.org/pub/mozilla/libraries/win32/MozillaBuildSetup-Latest.exe Important changes since version 3.1.1: * Updated Python2 to version 2.7.15 and

Re: New Policy: Marking Bugzilla bugs for features riding behind a pref

On 5/3/18 12:18 PM, Nicholas Alexander wrote: Not all features are feasible to ship behind feature flags. I'm pretty sure the proposed policy isn't intended to change anything regarding features that ship without associated feature flags, nor is it trying to get more features to ship behind

Re: New Policy: Marking Bugzilla bugs for features riding behind a pref

On Wed, May 2, 2018 at 4:57 PM, Emma Humphries wrote: > Hello, > > We control enabling many features and changes to Firefox using preferences. > > Program and Release management as well as PI need a better view of this. > > We've written a new policy which you can read on our

Re: Maintenance work on perf-html.io, planned for May 3 at 8am PDT, small downtime planned

hi, This is now over. Please contact  Markus, Greg or myself if you find anything not working properly after the switch. Have a nice end of day ! -- Julien Le 02/05/2018 à 16:50, Julien Wajsberg a écrit : Hi, Tomorrow we'll move perf-html.io to a new home. As part of this switch we'll

Re: Proposed W3C Charter: Devices and Sensors Working Group

On Thu, May 3, 2018 at 2:00 AM, Anne van Kesteren wrote: > On Thu, May 3, 2018 at 12:51 AM, L. David Baron wrote: >> Please reply to this thread if you think there's something we should >> say as part of this charter review, or if you think we should >>

Intent to unship: File.lastModifiedDate

This attribute is not part of the FileAPI spec and it has been marked as deprecated in bug 1048291 the 31st of May 2016. It's currently used by the 0.01% of the pages:

Re: Intent to explore: A declarative low level graphics API that has a simple mapping to CSS

We’ve evaluated the Metalhead proposal and decided not to proceed with it. Metalhead proposed a really interesting architecture that could plug into existing web frameworks to increase frame rates, however by by-passing the DOM, the proposal had the potential to be misused to remove more of the

Re: Proposed W3C Charter: Devices and Sensors Working Group

On Thu, May 3, 2018 at 12:51 AM, L. David Baron wrote: > Please reply to this thread if you think there's something we should > say as part of this charter review, or if you think we should > support or oppose it. Perhaps I've missed something, but I feel like we never

Re: Proposed W3C Charter: Timed Text Working Group

On Thu, May 3, 2018 at 12:42 AM, L. David Baron wrote: > Timed Text Working Group > https://www.w3.org/2018/04/proposed-tt-charter-2018.html What does # The Group is expected to produce annual updates for the Recommendation # with previously unspecified features. mean?