Re: Proposed W3C Charter: Devices and Sensors Working Group
On Fri, May 4, 2018 at 2:07 AM, L. David Baron wrote: > On the flip side, sensor APIs are offered by mobile (and to some > degree desktop) operating systems and widely used by apps running on > them, and there's clear demand for having them on the Web. So I > think it seems worth having a clear venue for that discussion, which > would suggest that it's good to have the discussion in the scope of > the working group. This is true for a number of APIs not offered by the web, many of which don't have standardization efforts or a viable path to be exposed (or were standardized and then dropped due to issues, e.g., batteries). > I'm inclined to think that if we want to suggest changes to address > this security/privacy issue, we should be suggesting clarifying the > success criteria for the working group so that these issues are > clearly considered, and making it more explicitly OK for the group > to decide not to produce some of its deliverables. > > The final paragraph of section "1. Goals" already says a bit here, > as does the third paragraph of "2.1 Success Criteria", but perhaps > there's more to say, perhaps by making not producing a spec > explicitly OK in both "2.1 Success Criteria" and "3. Deliverables"? > And perhaps something in there should also explicitly mention the > difficulty of properly informing the user in order to obtain > informed consent for the real risks underlying the sensors, or > something like that? > > Or do you instead think that some of the deliverables should be > removed from the charter because they're not likely to succeed? If > so, which? I hadn't looked in detail yet, but they're doing quite a lot of APIs. Of those Generic Sensor API Geolocation Sensor might be the least controversial as its a new API for an existing feature, but I have not looked in detail whether this is a straight mapping or not. If Google's Layered APIs initiative (https://github.com/drufball/layered-apis) is successful that might also be a better way to go about things. Wake Lock API We've explored this for FxOS. In terms of mozilla/standards-positions I guess this would be non-harmful. Battery Status API We've unshipped this: harmful. Network Information API I'm pretty sure Mozillians have raised issues with this in the past and we don't intend to ship it. I suspect harmful. DeviceOrientation Event specification We ship this on Android I think, but per earlier dev-platform threads we're not exactly happy with it. Proximity Sensor Ambient Light Sensor Accelerometer Gyroscope Magnetometer Orientation Sensor These are the ones my initial comment was for. As I understand it the proposed defense is to restrict these to foreground top-level browsing contexts without user prompt. It's unclear to what extent they are throttled. If they are throttled, they are less or not useful for AR/VR. If they are not throttled, they are an interesting fingerprinting vector. It's unclear to me how a standardization group is going to help resolve that and I don't think we'd want them to make that trade-off for us. There's also Vibration API and HTML Media Capture and I'm not sure what the state of those is. Neither seems particularly problematic. Hope that helps, -- https://annevankesteren.nl/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
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 figure out whether there is a problem with the spec or trying to justify Google shipping a particular behavior. I'm not quite sure which hat he's wearing here. He does seem to have misunderstood that there is a problem to fix. But I assume the way forward here is to help the WG find a solution that works. What is the advantage of explaining the situation to Alex? As a TAG member, he can work with the TAG to explain to the WG that their current spec is not acceptable, assuming he's convinced on that. With his Google hat on, he can make similar arguments internally about Chrome's implementation. So if there is in fact a problem still remaining, convincing Alex that it's there is pretty valuable. Having him convinced it doesn't exist is actively harmful as far as getting it fixed goes. Should specifications instead just focus on observable behavior, and leave it to implementations to optimize and to reclaim resources that are no longer required? Generally speaking, yes. That said, specifications should be really clear on which resources are no longer required, if possible. Are you aware of any guidance I could reference, if advocating this? (The WG has been very keen to make this normative.) If there is no difference in observable behavior, what would a normative requirement mean? And if there _is_ a difference in observable behavior, then of course the actual observable behavior that implementors need to implement needs to be specced normatively; this doesn't require saying anything about GC. Perhaps it would be best to just have an informative section explaining design decisions made for the sake of making resource reclamation possible, such as lack of graph introspection. This would definitely be useful. Perhaps it would also be helpful to have some informative reminders to implementations re what GC must not affect. Yes, that would be helpful. If the whole normative AudioNode lifetime section were dropped then this would clearly be an implementation issue rather than a spec issue. Assuming there is no observable behavior involved (other than memory usage), right? The history here is: Thank you for the summary. That was helpful. One thing I'm not 100% clear on at this point: are there spec issues that can lead to observable GC, or are we just talking about implementation bugs that make GC observable now? -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
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 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 resolved the > > security question around high-resolution sensors. If I haven't missed > > anything, I suggest we say we're still skeptical about exposing these > > to the web. > > Yea, I'm concerned about this as well. On the flip side, sensor APIs are offered by mobile (and to some degree desktop) operating systems and widely used by apps running on them, and there's clear demand for having them on the Web. So I think it seems worth having a clear venue for that discussion, which would suggest that it's good to have the discussion in the scope of the working group. I'm inclined to think that if we want to suggest changes to address this security/privacy issue, we should be suggesting clarifying the success criteria for the working group so that these issues are clearly considered, and making it more explicitly OK for the group to decide not to produce some of its deliverables. The final paragraph of section "1. Goals" already says a bit here, as does the third paragraph of "2.1 Success Criteria", but perhaps there's more to say, perhaps by making not producing a spec explicitly OK in both "2.1 Success Criteria" and "3. Deliverables"? And perhaps something in there should also explicitly mention the difficulty of properly informing the user in order to obtain informed consent for the real risks underlying the sensors, or something like that? Or do you instead think that some of the deliverables should be removed from the charter because they're not likely to succeed? If so, which? -David -- π L. David Baron http://dbaron.org/ π π’ Mozilla https://www.mozilla.org/ π Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914) signature.asc Description: PGP signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
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 F2F resolution]] comment would > resolve the issue, and so I expect not. > > [[March F2F resolution]] > https://github.com/WebAudio/web-audio-api/issues/1471# > issuecomment-376223916 I wonder what that resolution entails since the spec changes haven't happened yet. However, it sounds like it's heading in the wrong direction. Rather than trying to fix the description of AudioNode lifetimes, the entire section should be deleted. He does seem to have misunderstood that there is a problem to fix. > But I assume the way forward here is to help the WG find a > solution that works. What is the advantage of explaining the > situation to Alex? > AIUI If you can't convince someone on the WG that there is problem to fix, but you can convince someone on the TAG, then they can require the WG to fix it. I'm happy to query the F2F resolution, but I wonder which is the > best way to resolve this. > > Is having web specifications try to describe object lifetimes > helpful, or is it just over-prescribing? > I think it's very dangerous. If those descriptions are normative then it's easy to accidentally make GC observable. If they're not normative then they confuse implementors and users into accidentally treating them as normative. Should specifications instead just focus on observable behavior, > and leave it to implementations to optimize and to reclaim > resources that are no longer required? > Yes. People need to understand that GC is purely an optimization. Perhaps it would be best to just have an informative section > explaining design decisions made for the sake of making resource > reclamation possible, such as lack of graph introspection. Perhaps > it would also be helpful to have some informative reminders to > implementations re what GC must not affect. > Yes. > If the whole normative AudioNode lifetime section were dropped > then this would clearly be an implementation issue rather than a > spec issue. > Yes! Maybe I can help by writing a blog post or something... Rob -- Su ot deraeppa sah dna Rehtaf eht htiw saw hcihw, efil lanrete eht uoy ot mialcorp ew dna, ti ot yfitset dna ti nees evah ew; deraeppa efil eht. Efil fo Drow eht gninrecnoc mialcorp ew siht - dehcuot evah sdnah ruo dna ta dekool evah ew hcihw, seye ruo htiw nees evah ew hcihw, draeh evah ew hcihw, gninnigeb eht morf saw hcihw taht. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
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 updates for the Recommendation > # with previously unspecified features. > > mean? I think it means that the group is supposed to publish a new Recommendation each year (i.e., do maintenance work on the spec), and can add new features to each one, all within the current charter. I admit "previously unspecified features" is awkward wording, though. -David -- π L. David Baron http://dbaron.org/ π π’ Mozilla https://www.mozilla.org/ π Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914) signature.asc Description: PGP signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
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 > resources that are no longer required? > > Are you aware of any guidance I could reference, if advocating > this? (The WG has been very keen to make this normative.) Without digging too far into this specific case, I can attempt to offer some answers to the general questions: There is design guidance here, in a document published by the W3C Technical Architecture Group: https://w3ctag.github.io/design-principles/#js-gc that garbage collection should not be observable. Ensuring that GC isn't observable sometimes does require normative descriptions of minimum object lifetimes, such as in https://github.com/w3c/permissions/issues/170 , but generally normative descriptions of maximum object lifetimes shouldn't be needed. That said, in general it's useful for specifications to give informative explanations of the design decisions that led to the current specification (since that helps future maintenance of the specification, and also likely helps implementors contribute to that maintenance). It's also generally useful for specifications to give informative implementation advice when there are things worth pointing out that an implementor might not realize immediately. I'd like to specifications have both sorts of informative sections substantially more often than they do today. > Perhaps it would be best to just have an informative section > explaining design decisions made for the sake of making resource > reclamation possible, such as lack of graph introspection. Perhaps > it would also be helpful to have some informative reminders to > implementations re what GC must not affect. These both sound useful, as I mentioned above. -David -- π L. David Baron http://dbaron.org/ π π’ Mozilla https://www.mozilla.org/ π Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914) signature.asc Description: PGP signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
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 situations where the output sound depends on GC timing? Thank you for taking a look, Boris. I'm quite unclear how any of the changes proposed in the [[March F2F resolution]] comment would resolve the issue, and so I expect not. [[March F2F resolution]] https://github.com/WebAudio/web-audio-api/issues/1471#issuecomment-376223916 > If so, that doesn't sound acceptable. It also sounds to me like > Alex Russell in > https://github.com/WebAudio/web-audio-api/issues/1471#issuecomment-362604396 > didn't believe there was an observable sound difference possible. > If one is possible, we should communicate this to him very > clearly The spec says that when a node is deleted, it will disconnect itself from other nodes. This disconnection definitely can lead to observable sound differences, if the node can be deleted. The spec is unclear on whether a node with observable connections can be deleted, but there is certainly reason to interpret it in this way and members of the working group were doing so. If anything, the March F2F resolution seems to reinforce this view. I was also quite unclear as to the point of Alex's comment. 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. I'm not clear as to exactly what he was referring with "@joeberkovitz's change to cause the spec to not discuss GC", but changing the spec to not discuss GC would certainly resolve the issue. My take-away was that Alex was advocating no behavior changes on GC. He does seem to have misunderstood that there is a problem to fix. But I assume the way forward here is to help the WG find a solution that works. What is the advantage of explaining the situation to Alex? I'm happy to query the F2F resolution, but I wonder which is the best way to resolve this. 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 resources that are no longer required? Are you aware of any guidance I could reference, if advocating this? (The WG has been very keen to make this normative.) Perhaps it would be best to just have an informative section explaining design decisions made for the sake of making resource reclamation possible, such as lack of graph introspection. Perhaps it would also be helpful to have some informative reminders to implementations re what GC must not affect. If the whole normative AudioNode lifetime section were dropped then this would clearly be an implementation issue rather than a spec issue. The history here is: Initially the #lifetime-AudioNode section was only informative, providing some hints to the implementation re situations when GC must not be performed. These were not a complete list. At the same time, implementations had bugs that made GC observable, but this was not usually noticed in general Web Audio usage. These implementation bugs were fixable. An API/model was designed to support [[dynamic AudioWorkletNode lifetime]]. While not directly saying so at the time AFAIK, this API/model essentially depends on the implementation bugs to work as intended. This was stated much [[later]]. WG pressure in response to the [[dynamic AudioWorkletNode lifetime]] led to the #lifetime-AudioNode section being made [[normative]]. Subsequent additions were made to make it more comprehensive. This made the existing implementation bugs very much spec bugs. The bugs are now very noticeable in typical AudioWorkletNode usage. [[dynamic AudioWorkletNode lifetime]] https://github.com/WebAudio/web-audio-api/pull/959#issuecomment-260979231 [[later]] https://github.com/WebAudio/web-audio-api/issues/1453#issuecomment-349340594 [[normative]] https://github.com/WebAudio/web-audio-api/pull/1161#issuecomment-284499700 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
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 + before enabling prefs on features. I don't see a flag "qa-verify" in bugzilla; was this possibly a typo for "qe-verify"? Thanks, JK ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
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 associated feature flags, nor is it > trying to get more features to ship behind flags than currently do. It's > just trying to rationalize a single, more managable process for those that > *do* ship behind flags. > > /a I agree that not every single feature is appropriate to ship behind a feature flag, since the cost to maintain parallel implementations can be huge, and has implications on things like the size of the application and updates. In addition, if you look at e10s/stylo/webrender we've set up parallel testing infrastructure, which needs to be maintained for quite a while even after we've enabled the feature. We did however consider the benefits to be worth the complexity for even the very large and complex projects mentioned above, and there are many downsides and risks to not using a phased roll-out approach (which can be done without feature flags), so I'd be interested in continuing this discussion in a separate thread. For this specific proposal, the only change I'd suggest is that we should move away from the term "Pref Flip" in favor of "Feature Flag", since (as evidenced in this thread so far) the latter is the more standard industry term. I also think there's an argument to be made that the pref system on Firefox Desktop is not the right system for implementing feature flags in general, but I'll leave that for a separate thread as well. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
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 Python3 to version 3.6.5. * Updated nodejs to version 8.11.1 & npm version 5.6.0. * Re-arranged the directory structure so more components live within a centralized /bin directory, which is particularly useful for additional tools people may want to easily put somewhere in their PATH. * Other updates to various included components. - Mercurial updated to version 4.5.3. - The fsmonitor Mercurial extension is now enabled by default. Full Release Notes: https://docs.google.com/document/d/1OIJC7_-Y2xZh7CkXmi0fvz75f4ABP_W9-l0gZrAgJ1g/edit?usp=sharing Enjoy! -Ryan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
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 flags than currently do. It's just trying to rationalize a single, more managable process for those that *do* ship behind flags. /a ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
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 nascent bug-handling > mini-site: > > https://github.com/mozilla/bug-handling/blob/master/ > policy/feature-flags.md > > 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 + before enabling prefs on features. > > We'll be going over this at two upcoming meetings, with Reese's and JoeH's > teams. > > There are two, known open questions to resolve on the policy: > > * Features developed over multiple releases with individual patches not > verifiable by external testing (passing unit tests, but not integration > tests) such as Hello and WebRTC > * Features are often turned on in Nightly, ignoring prefs using compiler > directives, and kept off in Beta and Release. Is this the right thing to > do, or should we be flipping prefs from on to off when going from Nightly > to Beta and forwards? > Not all features are feasible to ship behind feature flags. Fennec features that interact with the OS directly, in particular, can sometimes just be all or nothing; and I would anticipate that things that interact directly with newer App stores (iOS features, say, or Windows Store features in the future) will become more common. We can't have a policy that fights against that trend. Nick ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
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 chance the DNS servers so that they point to the new hosting at netlify.com. This should be painless. However as part of the process we also need to generate new TLS certificates, and we can do this only once the DNS switch is done. That's why we'll have a small downtime until the new certificates are set up. In case of a bigger issue we'll rollback to the old hosting and postpone the switch. Please follow Bug 1455605 to know more. Have a nice day ! ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
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 >> support or oppose it. > > Perhaps I've missed something, but I feel like we never resolved the > security question around high-resolution sensors. If I haven't missed > anything, I suggest we say we're still skeptical about exposing these > to the web. Yea, I'm concerned about this as well. -tom ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
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: https://telemetry.mozilla.org/new-pipeline/dist.html#!cumulative=0&end_date=2018-04-30&keys=__none__!__none__!__none__&max_channel_version=nightly%252F61&measure=USE_COUNTER2_DEPRECATED_FileLastModifiedDate_PAGE&min_channel_version=null&processType=*&product=Firefox&sanitize=1&sort_keys=submissions&start_date=2018-03-12&table=0&trim=1&use_submission_date=0 Currently only Chrome and Firefox support this attribute. Firefox bug: 1458883. Chrome bug: https://bugs.chromium.org/p/chromium/issues/detail?id=839372 WPT: https://github.com/w3c/web-platform-tests/pull/10821 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
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 semantic nature of the web than we are happy with, so we think that avenues like DOM ChangeList are more fruitful avenue right now. Iβd like to thank Victor for his work on thinking though these ideas and the innovative proposal. Thanks for your interest. Joe On Tue, May 1, 2018 at 11:35 AM Victor Porof wrote: > Hello again :) > > Appreciate the great feedback so far! > > So I'd like to clear a few things up. There are many unknowns here which > need exploring before moving further. Particularly we want to retain as > much of the semantic model of the web while still allowing native-like > frame rates. > > I'd like to spend some time breaking the document up and listing things we > can do to preserve as much of the semantic model as we can, so please hold > off for a bit while I do that. > > Thanks everyone! > Victor > > > On Mon, Apr 30, 2018 at 7:03 PM, Victor Porof wrote: > >> Hey folks, >> >> Last quarter I've been drafting a roadmap to explore the advantages of a >> new web API, fundamentally different from the DOM. It's aiming to expose >> similar core web features, but with predictible cost and performance, in a >> declarative immediate-mode manner. >> >> This research was driven by a desire to reconcile the growing set of >> differences between today's development practices and existing browser >> APIs. At the very least, "the UI is a function of state" is a preferred >> abstraction trend, different from what browsers directly provide yet >> incredibly prevalent among modern frameworks, so it's worth discussing the >> implications. >> >> "Project Metalhead" is a proposed vector to address that disconnect. It's >> an alternative to canvas 2D and WebGL, which: >> * retains accessibility and internationalisation >> * efficiently renders a direct mapping of existing CSS primitives >> * supports form controls with native look and feel >> * makes it easier for web apps to live inside web workers >> * is specifically designed to work well with frameworks employing a >> virtual DOM (e.g. React) >> * can give Mozilla the driving seat for the next round of web performance >> wins >> >> The proposed core graphics API is just a subset of the bigger >> architectural solution. Investigation is required in order to understand >> exactly how accessibility, layout and other existing browser behaviour can >> be a concrete part of this new API. Prior research has given possible but >> not definitive answers towards making sure there's no room for unintended >> loss of user control. >> >> Obviously such a vector takes us into currently unknown territory, which >> I'd like us to explore before moving further. I've written a document >> describing the roadmap, along with details about a proof of concept >> technical implementation in more detail: >> https://docs.google.com/document/d/1YLM1_jlTKYvNa04rEHWw6RBEFQO5aAd8vd-S3yXJjI8 >> There's a lot of info there, so be sure to check out the FAQ, alternatives >> and implementation. The document is open to everyone at Mozilla, but if you >> need access to it let me know. >> >> Here's a video showcasing the expected performance improvements in >> action: https://www.youtube.com/watch?v=kDrUfmXLrIU >> >> Among other things, the above demo is showing WebRender rendering content >> running in browsers other than Firefox, powered by a proof of concept of >> the proposed API. This approach intends to mimic a real world native >> implementation across various browsers, instead of just a simple polyfill. >> >> I'd love getting some opinions and a roadmap review for this. Even though >> what we have right now is a technically flawed proof of concept >> implementation and incomplete solution, is it worth pursuing this further? >> >> If anyone's interested, I'd also be happy to have a conversation on vidyo >> about how everything works in more detail. >> >> Thanks! >> Victor >> >> *This proposal has been circulating outside of browser-arch last week; in >> the hopes of getting broader feedback I'm posting it here instead. >> Apologies if you've seen it already.* >> > > ___ > firefox-dev mailing list > firefox-...@mozilla.org > https://mail.mozilla.org/listinfo/firefox-dev > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
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 resolved the security question around high-resolution sensors. If I haven't missed anything, I suggest we say we're still skeptical about exposing these to the web. -- https://annevankesteren.nl/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
