Re: Device Orientation API future

On Wednesday, January 3, 2018 at 2:43:43 PM UTC-8, Martin Thomson wrote: > On Thu, Jan 4, 2018 at 2:52 AM, Blair MacIntyre > wrote: > > I was more concerned about the idea (or, at least what I though might be > > suggested) that you only get orientation if they give location permission. > > This

Re: Proposed W3C Charter: Second Screen Working Group

Without the protocol pieces, this remains vendor-specific. We should comment on this and make it clear that we think that definition of a generic protocol for interacting with the second display has not been given sufficient priority. Allowing this to proceed without a generic protocol would be b

Re: Device Orientation API future

On Thu, Jan 4, 2018 at 1:09 PM, Blair MacIntyre wrote: > We could chat about it, sure; how do you envision it working without > breaking old websites? With the understanding that this is purely spitballing... We would stop providing events (or provide them with extremely low frequency [1]), bu

Re: Intent to unship: navigator.registerContentHandler()

Jonathan, Le 4 janv. 2018 à 00:15, Jonathan Kingston a écrit : > Firefox has an implementation that only can be used to allow a web page to > handle RSS feeds. in Firefox 8, the feeds panel was removed from Firefox. It created a bit of bad press. Some people have developed add-ons to cope wit

Re: Proposed W3C Charter: Second Screen Working Group

The SecondScreen WG intended to move the protocol development to CG, and will possibly move to IETF after the incubation phase. The revised charter is trying to associate the work of CG to the timeline of Presentation API development. At the meantime, WG will tackle the testability issue found whi

Re: Device Orientation API future

We could chat about it, sure; how do you envision it working without breaking old websites? > On Jan 3, 2018, at 5:43 PM, Martin Thomson wrote: > > On Thu, Jan 4, 2018 at 2:52 AM, Blair MacIntyre > wrote: >> I was more concerned about the idea (or, at least what I though might be >> suggeste

Proposed W3C Charter: Second Screen Working Group

The W3C is proposing a revised charter for: Second Screen Working Group https://w3c.github.io/secondscreen-charter/ https://lists.w3.org/Archives/Public/public-new-work/2017Dec/.html Mozilla has the opportunity to send comments or objections through Friday, January 52. (Sorry for faili

Re: Refactoring proposal for the observer service

On 01/04/2018 12:30 AM, Ben Kelly wrote: On Wed, Jan 3, 2018 at 5:09 PM, Gabriele Svelto wrote: So after validating my approach in that bug (which is almost ready) I've thought that it might be time to give the observer service the same treatment. First of all we'd have a list of topics (I've

Re: Refactoring proposal for the observer service

This is really interesting, thanks for looking at this! On 03/01/2018 22:09, Gabriele Svelto wrote: This would have quite a few coding benefits: - It would make it far easier to retire/rename a topic, since ... JS would throw. Why would it? I think it would pass undefined (as the topic wouldn

Re: Device Orientation API future

On Thu, Jan 4, 2018 at 2:52 AM, Blair MacIntyre wrote: > I was more concerned about the idea (or, at least what I though might be > suggested) that you only get orientation if they give location permission. > This seems overkill: even if I know what the data means, I can see uses of > orientation

Re: Refactoring proposal for the observer service

On Wed, Jan 3, 2018 at 5:09 PM, Gabriele Svelto wrote: > So after validating my approach in that bug (which is almost ready) I've > thought that it might be time to give the observer service the same > treatment. First of all we'd have a list of topics (I've picked YAML for > the list but it coul

Re: Refactoring proposal for the observer service

On Wed, Jan 3, 2018 at 5:09 PM, Gabriele Svelto wrote: > - It would make trivially simple to document the topics, their subjects > and payloads. Potentially this could even be integrated with our > generated documentation and code search tools making developer lives a > lot easier. +1. Not having

Re: Refactoring proposal for the observer service

That would be great! On 03/01/18 23:09, Gabriele Svelto wrote: > TL;DR this is a proposal to refactor the observer service to use a > machine-generated list of integers for the topics (disguised as enums/JS > constants) instead of arbitrary strings. > _

Refactoring proposal for the observer service

TL;DR this is a proposal to refactor the observer service to use a machine-generated list of integers for the topics (disguised as enums/JS constants) instead of arbitrary strings. Long version: I've been working on bug 1348273 [1] in an attempt to gather all our crash annotations into a machine-

Re: Intent to implement: support CSS paint-order for HTML text

On 12/24/2017 04:54 PM, James Graham wrote: On 24/12/2017 13:13, Emilio Cobos Álvarez wrote: On 12/24/2017 02:01 PM, Jonathan Kew wrote: Tests - Is this feature fully tested by web-platform-tests? No, as it is not yet spec'd (see above). I propose to land a basic mozilla reftest along with the

Re: Intent to unship: navigator.registerContentHandler()

> I like the approach of disabling a feature (behind a pref) in non-Release (Beta and Nightly) for a few releases, to see what surfaces in bug reports. This is reasonable, it is the approach we will be taking with the device sensors. Obviously it takes a little more work however I'm guessing the

Re: Intent to unship: navigator.registerContentHandler()

Hi Jonathan, > On Jan 3, 2018, at 9:15 AM, Jonathan Kingston wrote: > There is a small risk of breakage that we could decide to delay and instead > implement telemetry. However if the site is feature testing rather than > user agent testing there shouldn't be an issue here. As this API throws > e

Re: Device Orientation API future

On Wed, Jan 3, 2018 at 7:48 AM, Jonathan Kingston wrote: > For GPS we only ever talk about "location", I still don't think that is a > far stretch from head/position tracking. > ​Users aren't going to understand why their tilt-the-tablet labyrinth game needs to know they're in Brighton in order

Re: Device Orientation API future

I would tend to think that GPS location is more sensitive then device orientation, and so exposing device orientation if they’ve given location perms seems like a good avenue to explore, yes. I was more concerned about the idea (or, at least what I though might be suggested) that you only get o

Re: Device Orientation API future

When the language for the permission prompt isn't going to be clear about what the user is exposing (screen, camera and mic) we should be talking about risks. For GPS we only ever talk about "location", I still don't think that is a far stretch from head/position tracking. On Wed, Jan 3, 2018 at

Intent to unship: navigator.registerContentHandler()

I am suggesting the removal of navigator.registerContentHandler API used to register a web page to handle content types. Firefox has an implementation that only can be used to allow a web page to handle RSS feeds.

Re: overly strict eslint rules

On 24/12/2017 22:07, Masatoshi Kimura wrote: I got the following error when I tried it just now: As far as I know, it should work fine with the latest version of MozillaBuild. If it doesn't, please file a bug in Testing:Lint and we'll take a look. --

Re: Device Orientation API future

I don’t think tying orientation to GPS is really a viable approach. The main use case for the orientation API, I think, is not AR; it’s 360 images and videos, and “cardboard VR”, right now. > On Jan 1, 2018, at 5:01 PM, Martin Thomson wrote: > > The suggestion that was made in the past was

Re: overly strict eslint rules

On Wed, Jan 3, 2018 at 4:43 AM, Mark Banner wrote: > On 24/12/2017 19:41, Ben Kelly wrote: > >> But I also see rules about cosmetic things like what kind of quotes must >> be >> used for strings. >> AFAICT this kind of rule does not have any tangible safety benefit. Its >> purely a cosmetic styl

Re: overly strict eslint rules

On 24/12/2017 19:41, Ben Kelly wrote: But I also see rules about cosmetic things like what kind of quotes must be used for strings. AFAICT this kind of rule does not have any tangible safety benefit. Its purely a cosmetic style choice. I don't see why we should bounce patches out of the tree if