Re: Intent to implement and ship: DOMTokenList.prototype.supports

Le 4 mai 2016 à 05:24, Boris Zbarsky a écrit : > In practice, this is the set of values I'm claiming we support: > "import" (if IsImportEnabled()), "prefetch", "dns-prefetch", "stylesheet", > "next", "alternate", "preconnect", "icon". Anything else I'm missing? Do we > do

Re: Intent to implement and ship: DOMTokenList.prototype.supports

On 5/3/16 7:20 PM, Domenic Denicola wrote: Does Firefox support "next" in some interesting way? Yes. We treat it as an alias for "prefetch". I, uh, have no idea why we included "next" but not "prev". The theory, presumably, is that people typically go forward through things in order.

Re: Intent to implement and ship: DOMTokenList.prototype.supports

On Tuesday, May 3, 2016 at 4:24:26 PM UTC-4, Boris Zbarsky wrote: > In practice, this is the set of values I'm claiming we > support: "import" (if IsImportEnabled()), "prefetch", "dns-prefetch", > "stylesheet", "next", "alternate", "preconnect", "icon". Anything else > I'm missing? Do we do

Re: Intent to implement and ship: DOMTokenList.prototype.supports

On 5/3/16 4:38 PM, smaug wrote: Do we need "import" ever? Is IsImportEnabled() ever true? I guess that will be removed once we remove import related code. Seems plausible. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org

Re: Intent to implement and ship: DOMTokenList.prototype.supports

Ok to me, given that adding the API to the platform is supported by other browser vendors too. (Though it is a bit mystery to me why DOMTokenList.supports is considered fine when it is pretty much similar feature to Node.isSupported and that one was considered harmful to the platform. But

Intent to implement and ship: DOMTokenList.prototype.supports

Summary: A way to feature-detect which values of various tokenlist attributes actually do something. Useful for things like which iframe sandbox tokens are supported, or what "rel" values for are supported. Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1257849 Link to Standard: If only

Re: Intent to implement and ship: rel="noopener" on links

On 4/25/16 10:47 PM, Boris Zbarsky wrote: Ah. Perhaps we should hold off on doing this until https://bugzilla.mozilla.org/show_bug.cgi?id=1257849 is fixed then. And the window.open thing would still not be detectable, so people would probably start assuming the anchor bit implied the window

Re: Intent to implement and ship: IIRFilterNode

Thanks for the replies, Dan and Roy. A first order filter node with AudioParam inputs seems a likely future addition AFAIK. Even with that though, having a way to apply a custom biquad without needing to decompose into multiple textbook filters is useful I think. And I agree that implementing

Re: Intent to implement and ship: IIRFilterNode

On Wed, Apr 27, 2016 at 6:35 PM, Karl Tomlinson wrote: > Daniel Minor writes: > > > Summary: This provides an alternative to using BiquadFilterNode when > > odd-order filters are required or automation is not needed. It is part of > > the Web Audio spec and is already

Re: Intent to implement and ship: IIRFilterNode

Daniel Minor writes: > Summary: This provides an alternative to using BiquadFilterNode when > odd-order filters are required or automation is not needed. It is part of > the Web Audio spec and is already implemented in Blink. Thanks for looking at this, Daniel. I fear that high order filters

Intent to implement and ship: IIRFilterNode

Summary: This provides an alternative to using BiquadFilterNode when odd-order filters are required or automation is not needed. It is part of the Web Audio spec and is already implemented in Blink. Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1265408 Link to standard:

Re: Intent to implement and ship: rel="noopener" on links

On 4/25/16 10:31 PM, Domenic Denicola wrote: On Monday, April 25, 2016 at 2:09:07 PM UTC-4, Boris Zbarsky wrote: 1) This is not feature-detectible, as far as I can see. So it's not clear to me that sites will know they can use this, short of relying on browser sniffing. If you implement

Re: Intent to implement and ship: rel="noopener" on links

On Monday, April 25, 2016 at 2:09:07 PM UTC-4, Boris Zbarsky wrote: > 1) This is not feature-detectible, as far as I can see. So it's not > clear to me that sites will know they can use this, short of relying on > browser sniffing. If you implement DOMTokenList.prototype.supports, it should

Re: Intent to implement and ship: rel="noopener" on links

On 4/25/16 2:57 PM, Tanvi Vyas wrote: Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1267339 I think you meant to link to bug https://bugzilla.mozilla.org/show_bug.cgi?id=1222516 here. Er... right you are. Too many identical-looking tabs. ;) -Boris

Re: Intent to implement and ship: rel="noopener" on links

Very cool! Thanks for implementing. On 4/25/16 11:09 AM, Boris Zbarsky wrote: Summary: The idea is to be able to write Go there and not have "someone-I-don't-trust" be able to get hold of your window via window.opener. This is already possible with rel="noreferrer", but that also

Intent to implement and ship: rel="noopener" on links

Summary: The idea is to be able to write Go there and not have "someone-I-don't-trust" be able to get hold of your window via window.opener. This is already possible with rel="noreferrer", but that also prevents sending a referrer, which is undesirable in cases like search engine

Intent to implement and ship: text-combine-upright: all

Summary: According to some people from Japanese ebook companies, text-combine-upright (a.k.a horizontal-in-vertical, or tate-chu-yoko) is a must for Japanese vertical layout. Without the proper support of this feature, a book may not be considered complete, and thus cannot be sold online. This is

Intent to implement and ship: fetch() cache control API

*Summary*: This API allows a web page to specify how the resources it fetches interact with the browser HTTP cache. *Bug*: https://bugzilla.mozilla.org/show_bug.cgi?id=1120715 *Link to standard*: https://fetch.spec.whatwg.org/ *Platform coverage*: All platforms *Estimated or target release*:

Intent to implement and ship: IDBKeyRange.includes()

*Summary*: This simple API allows one to test whether a given key is included in an IDBKeyRange *Bug*: https://bugzilla.mozilla.org/show_bug.cgi?id=1251498 *Link to standard*: http://w3c.github.io/IndexedDB/#dom-idbkeyrange-includes *Platform coverage*: All platforms *Estimated or target release*:

Intent to implement and ship: fetch() referrer and referrer policy APIs

*Summary*: These APIs allow a web page to specify a referrer and a referrer policy when fetching a resource. *Bug*: https://bugzilla.mozilla.org/show_bug.cgi?id=1184549 *Link to standard*: https://fetch.spec.whatwg.org/ *Platform coverage*: All platforms *Estimated or target release*: Firefox 47

Re: Intent to implement and ship: FIDO U2F API

By the way, I just got informed (from Google) that TLS Channel ID, even if activated on Google servers (including appspot), is only enforced for few users for now (even If I am not sure how they do that :) ) So Firefox users should not be blocked for that reason :) They seem to agree you

Re: Intent to implement and ship: FIDO U2F API

Hi, Great news about you making progress on this ! Since I read here and there that you are working with Firefox & Chrome U2F support consistency in mind, what's your take on TLS Channel ID (Token Binding) support inside Firefox ? It is a recommended feature for FIDO U2F client (Firefox here)

Re: Intent to implement and ship: FIDO U2F API

On Fri, Feb 5, 2016 at 3:22 PM, Fred Le Tamanoir wrote: > Hi, > > Great news about you making progress on this ! > > Since I read here and there that you are working with Firefox & Chrome U2F > support consistency in mind, what's your take on TLS Channel ID (Token >

Re: Intent to implement and ship: FIDO U2F API

On Monday, February 8, 2016 at 10:54:36 PM UTC+1, Ryan Sleevi wrote: > On Mon, Feb 8, 2016 at 1:13 PM, Frederic Martin wrote: > > > > 1) From a security architect perspective. This is an official > > recommendation that makes sens to prevent MITM attacks. FIDO U2F was > > created to

Re: Intent to implement and ship: FIDO U2F API

Hi, thanx for the answer. Quoting Dirk Balfanz (one of the TLS Channel ID specifications author, a few days ago on FIDO DEV forum): "the new spec that replaces ChannelID is called "Token Binding", and is in the process of being standardized by the IETF

Re: Intent to implement and ship: FIDO U2F API

On Mon, Feb 8, 2016 at 1:13 PM, Frederic Martin wrote: > > 1) From a security architect perspective. This is an official recommendation > that makes sens to prevent MITM attacks. FIDO U2F was created to > minimize/eliminate that kind of risk. U2F itself addresses phishing. Token Binding

Re: Intent to implement and ship: FIDO U2F API

On Mon, Feb 8, 2016 at 10:13 PM, Frederic Martin wrote: > Hi, > > thanx for the answer. > > Quoting Dirk Balfanz (one of the TLS Channel ID specifications author, a > few days ago on FIDO DEV forum): > > "the new spec that replaces ChannelID is called "Token Binding",

Re: Intent to implement and ship: FIDO U2F API

All, We're making progress on implementing FIDO U2F in Firefox. The effort is split into a number of bugs at present. First, a quick rundown of where we are: * The tracking bug for U2F support is Bug 1065729. * Bug 1198330 is to implement USB HID support in Firefox. * Bug 1231681 implements the

Re: Intent to implement and ship: FIDO U2F API

On Wednesday, December 2, 2015 at 2:23:28 AM UTC+1, Richard Barnes wrote: > The FIDO Alliance has been developing standards for hardware-based > authentication of users by websites [1]. Their work is getting significant > traction, so the Mozilla Foundation has decided to join the FIDO Alliance.

Re: Intent to implement and ship: WebKitCSSMatrix

On 1/14/16 9:09 PM, L. David Baron wrote: It seems to me this is important to have behind a preference that is specific to new webkit-prefixed features, given the compatibility risks of shipping support for some but not all webkit-prefixed features. (It's possible it could be the same

Re: Intent to implement and ship: WebKitCSSMatrix

On Thursday 2016-01-14 14:06 -0800, William Chen wrote: > *Summary*: WebKitCSSMatrix has been available for years in WebKit based > browsers and has seen widespread usage on the web. This feature is > currently available in Chrome, Safari and Edge. Mike Taylor has been > working on standardizing

Re: Intent to implement and ship: WebKitCSSMatrix

Ship it! On Thu, Jan 14, 2016 at 2:06 PM, William Chen wrote: > *Summary*: WebKitCSSMatrix has been available for years in WebKit based > browsers and has seen widespread usage on the web. This feature is > currently available in Chrome, Safari and Edge. Mike Taylor has been >

Intent to implement and ship: WebKitCSSMatrix

*Summary*: WebKitCSSMatrix has been available for years in WebKit based browsers and has seen widespread usage on the web. This feature is currently available in Chrome, Safari and Edge. Mike Taylor has been working on standardizing the feature and it is being implemented in Gecko to improve web

Re: Intent to implement and ship: FIDO U2F API

I'm no longer directly involved with the FIDO Alliance, so I can't speak to the FIDO 2.0 timelines, but my general experience there plus at the W3C tells me that it will some time before the new APIs stabilize. I hope that this won't dissuade Mozilla from beginning work on implementing U2F

Re: Intent to implement and ship: FIDO U2F API

On 12/04/2015 06:56 PM, smaug wrote: Looks like the spec could be made implementable by fixing https://fidoalliance.org/specs/fido-u2f-v1.0-nfc-bt-amendment-20150514/fido-u2f-javascript-api.html#high-level-javascript-api "provide a namespace object u2f of the following interface" doesn't mean

Re: Intent to implement and ship: FIDO U2F API

Looks like the spec could be made implementable by fixing https://fidoalliance.org/specs/fido-u2f-v1.0-nfc-bt-amendment-20150514/fido-u2f-javascript-api.html#high-level-javascript-api "provide a namespace object u2f of the following interface" doesn't mean anything, so either there is supposed

Re: Intent to implement and ship: FIDO U2F API

On 12/02/2015 11:37 PM, Frederic Martin wrote: As I said in the other email, I don't understand how this could be implemented when the spec has left the >key piece undefined, as far as I see. You are completely right ! For now, FIDO 2 is currently being written (far far far from finished)

Re: Intent to implement and ship: FIDO U2F API

ched the API in > Chrome 40 [3], for all HTTP and HTTPS origins, without an Intent to > Implement / Intent to Ship. > > So, speaking solely on my behalf and not that of my employer, sorry that > Chrome put Firefox in this position of "old and busted" and "new hotness", >

Re: Intent to implement and ship: FIDO U2F API

Hi All, great news ! TL;DR version: -- I love U2F, I love Firefox FIDO U2F is here to stay. FIDO 2.0 do not exist and will not replace U2F. FIDO U2F is really great. Please implement FIDO U2F. Please please please implement TLS Channel ID Binding support (important part of FIDO U2F

Re: Intent to implement and ship: FIDO U2F API

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/02/2015 03:48 PM, Richard Barnes wrote: > I think we would treat this just like we treat other early-stage > things that get shipped, gradually turning it off when the real > thing shows up. That would mean only shipping it on Nightly and maybe

Re: Intent to implement and ship: FIDO U2F API

On 12/2/15 8:53 AM, Ms2ger wrote: I don't remember what the current conventional wisdom about prefixing is, but I would be open to shipping with a prefix if people thought that would ease pain in the eventual transition. No. Nonononononononono. This is the conventional wisdom. Prefixes end

Re: Intent to implement and ship: FIDO U2F API

On 02.12.2015 18:53, Robert O'Callahan wrote: > On Wed, Dec 2, 2015 at 9:37 AM, Eric Rescorla wrote: > >> Are you thinking of something like WebUSB? >> (https://reillyeon.github.io/webusb/)? This is something we've looked at >> a bit but we're still trying to wrap our heads around

Re: Intent to implement and ship: FIDO U2F API

On Wed, Dec 2, 2015 at 9:53 AM, Robert O'Callahan wrote: > On Wed, Dec 2, 2015 at 9:37 AM, Eric Rescorla wrote: > >> Are you thinking of something like WebUSB? >> (https://reillyeon.github.io/webusb/)? This is something we've looked at >> a bit but we're

Re: Intent to implement and ship: FIDO U2F API

HTTPS origins, without an Intent to Implement / Intent to Ship. So, speaking solely on my behalf and not that of my employer, sorry that Chrome put Firefox in this position of "old and busted" and "new hotness", with "damned either way" as the result. I'm trying

Re: Intent to implement and ship: FIDO U2F API

On Wednesday, December 2, 2015 at 1:17:46 PM UTC-8, smaug wrote: > I don't understand how 1) could be implemented when the spec has left the key > piece undefined, as far as I see. > As the spec puts it "This specification does not describe how such a port is > made available to RP web pages, as

Re: Intent to implement and ship: FIDO U2F API

On 12/02/2015 03:23 AM, Richard Barnes wrote: The FIDO Alliance has been developing standards for hardware-based authentication of users by websites [1]. Their work is getting significant traction, so the Mozilla Foundation has decided to join the FIDO Alliance. Work has begun in the W3C to

Re: Intent to implement and ship: FIDO U2F API

>As I said in the other email, >I don't understand how this could be implemented when the spec has left the >>key piece undefined, as far as I see. You are completely right ! For now, FIDO 2 is currently being written (far far far from finished) and can't be implemented, so let's focus on

Re: Intent to implement and ship: FIDO U2F API

On 12/2/15 6:48 AM, Richard Barnes wrote: My initial intent was to propose implementing [1], then implementing [2] when it's ready. After all, there's a lot in common, and as you say, the W3C version will be much nicer. This seems like like a strange path to take. Why implement both? From

Re: Intent to implement and ship: FIDO U2F API

Le jeudi 3 décembre 2015 01:28:51 UTC+1, Justin Dolske a écrit : > On 12/2/15 6:48 AM, Richard Barnes wrote: > > > My initial intent was to propose implementing [1], then implementing [2] > > when it's ready. After all, there's a lot in common, and as you say, >the > > W3C version will be much

Re: Intent to implement and ship: FIDO U2F APIU

On 12/2/15 5:42 PM, Ryan Sleevi wrote: On Wednesday, December 2, 2015 at 1:17:46 PM UTC-8, smaug wrote: I don't understand how 1) could be implemented when the spec has left the key piece undefined, as far as I see. As the spec puts it "This specification does not describe how such a port is

Re: Intent to implement and ship: FIDO U2F API

Le mercredi 2 décembre 2015 23:43:00 UTC+1, Ryan Sleevi a écrit : > On Wednesday, December 2, 2015 at 1:17:46 PM UTC-8, smaug wrote: > > I don't understand how 1) could be implemented when the spec has left the > > key piece undefined, as far as I see. > > As the spec puts it "This specification

Re: Intent to implement and ship: FIDO U2F API

On Wednesday, December 2, 2015 at 3:08:44 PM UTC-8, Frederic Martin wrote: > Sorry, but I don't understand why you are denying the evidence, anyone > at Fido alliance will confirm that even non-public FIDO 2 drafts are far > far far from finished. Regarding the glimpse that was published in W3c

Re: Intent to implement and ship: FIDO U2F API

this for google.com, and only for HTTPS, and that we were committed to the W3C member submission as the path forward, but as I was working to back up a citation to this, I found out that we submarine-launched the API in Chrome 40 [3], for all HTTP and HTTPS origins, without an Intent to Implement / Intent

Re: Intent to implement and ship: FIDO U2F API

On Wed, Dec 2, 2015 at 1:11 PM, Frederic Martin wrote: > > > There are probably other questions Mozilla Core Team should ask to > > > themselves : > > > > > > - Having a greater/larger HID Support, outside the FIDO U2F scope ? > > > (This allows web services to

Re: Intent to implement and ship: FIDO U2F API

> That said, I think we're in violent agreement that the specs are far, far, > far from finished - and I'm unclear whether we're in agreement that one is > under active development, while the other is a technological dead end which, > through a series of unfortunate events, happened to have

Intent to implement and ship: FIDO U2F API

The FIDO Alliance has been developing standards for hardware-based authentication of users by websites [1]. Their work is getting significant traction, so the Mozilla Foundation has decided to join the FIDO Alliance. Work has begun in the W3C to create open standards using FIDO as a starting

Re: Intent to implement and ship: FIDO U2F API

Any chance that the API can be made a little more JS friendly? First thing that stands out is the use of success/error callbacks rather than the use of Promises. Also the use of numeric codes, rather than string values, is a pattern that the web has generally moved away from. / Jonas On Tue,

Re: Intent to implement and ship: FIDO U2F API

Oh well. Bummer. / Jonas On Tue, Dec 1, 2015 at 5:36 PM, Richard Barnes wrote: > It's my understanding that U2F qua U2F is considered pretty much baked by > the developer community, and there's already code written to it. But these > concerns will be great for the W3C

Re: Intent to implement and ship: FIDO U2F API

It's my understanding that U2F qua U2F is considered pretty much baked by the developer community, and there's already code written to it. But these concerns will be great for the W3C group and the successor API. I've got a similar list started related to crypto and future-proofing. On Tue,

Re: Intent to implement and ship: FIDO U2F API

t we were committed to the W3C member submission as the path forward, but as I was working to back up a citation to this, I found out that we submarine-launched the API in Chrome 40 [3], for all HTTP and HTTPS origins, without an Intent to Implement / Intent to Ship. So, speaking solely on

Re: Intent to implement and ship: Performance.translateTime

On Thu, Nov 19, 2015 at 5:38 PM, Boris Zbarsky wrote: >> Though Service Workers do actually have a 'client' object which >> represent window objects. So we could enable passing those as global >> to the translate function. > > That's a good idea. Want to raise it with the

Re: Intent to implement and ship: Performance.translateTime

On Thu, Nov 19, 2015 at 2:48 PM, Boris Zbarsky wrote: > On 11/19/15 5:39 PM, Jonas Sicking wrote: >> >> This API doesn't seem to work for nested workers (which Blink doesn't >> implement), does it? Since there's no way in the window to get hold of >> a reference of a

Intent to implement and ship: Changes to Worker performance.now() zero time

Summary: Currently for a dedicated worker, we set its 0 time for performance.now() purposes to the zero time of its parent worker or window. The spec defines a different behavior, now that there is a spec for this. Consumers that rely on the timebases matching right now can use translateTime

Re: Intent to implement and ship: Performance.translateTime

On 11/19/15 5:39 PM, Jonas Sicking wrote: This API doesn't seem to work for nested workers (which Blink doesn't implement), does it? Since there's no way in the window to get hold of a reference of a sub-sub-worker. While true, there is also no way to directly get a message from a

Intent to implement and ship: text-emphasis

Summary: It implements emphasis marks which are symbols next to each character to emphasize a piece of text. It is mainly used in East Asian documents. Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1225012 Link to standard: https://drafts.csswg.org/css-text-decor-3/#emphasis-marks Platform

Re: Intent to implement and ship: window.orientation and orientationchange event

On Tue, Oct 20, 2015 at 2:49 AM, Mounir Lamouri wrote: > Should we add this to the Screen Orientation specification? I think so yes. / Jonas ___ dev-platform mailing list dev-platform@lists.mozilla.org

Re: Intent to implement and ship: window.orientation and orientationchange event

FWIW, this is the usage of window.orientation in the wild recorded by Chrome: https://www.chromestatus.com/metrics/feature/timeline/popularity/285 However, Google's internal tools allow me to see the repartition between platforms and this seen a lot by Chrome Android users. Should we add this to

Re: Intent to implement and ship: window.orientation and orientationchange event

On 10/20/15 6:12 AM, Jonas Sicking wrote: On Tue, Oct 20, 2015 at 2:49 AM, Mounir Lamouri wrote: Should we add this to the Screen Orientation specification? I think so yes. I also think so. In my mind the Compat Standard should be transitional in nature, rather than

Re: Intent to implement and ship: HTMLElement.innerText

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/19/2015 06:02 AM, Robert O'Callahan wrote: > https://bugzilla.mozilla.org/show_bug.cgi?id=264412 > > Webkit, Blink and Trident have been shipping this for years without > a spec and with poor interop. We held off on implementing it since > you

Re: Intent to implement and ship: HTMLElement.innerText

On Tue, Oct 20, 2015 at 1:18 AM, Ms2ger wrote: > Please submit tests to web-platform-tests and create a pull request to > the HTML standard. > Will do, after a decent interval to collect feedback. I wrote web-platform-tests to land with our implementation. Rob -- lbir ye,ea

Re: Intent to implement and ship: window.orientation and orientationchange event

As someone pushing for the ScreenOrientation API, I agree with this intent nonetheless. It *might* be worth warning about this property being inconsistent, and that it's better for users to use the ScreenOrientation API. But I think it's really only worth doing if this is something that other

Re: Intent to implement and ship: webkitMatchesSelector

On 10/19/15 12:46 PM, Anne van Kesteren wrote: On Mon, Oct 19, 2015 at 6:36 PM, Boris Zbarsky wrote: Summary: The web more or less depends on one of the prefixed versions of matchesSelector (being implemented). I think you mean matches() is being implemented, while the web

Intent to implement and ship: window.orientation and orientationchange event

*Summary*: window.orientation returns a value corresponding to the screen orientation. The orientationchange event is fired when the orientation of the viewport is changed. These features are non-standard but have been implemented by other browser vendors on mobile platforms leading to widespread

Intent to implement and ship: webkitMatchesSelector

Summary: The web more or less depends on one of the prefixed versions of matchesSelector (being implemented). We might as well implement the webkit one and drop the moz one. Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1216193 Standard:

Re: Intent to implement and ship: webkitMatchesSelector

On Mon, Oct 19, 2015 at 6:36 PM, Boris Zbarsky wrote: > Summary: The web more or less depends on one of the prefixed versions of > matchesSelector (being implemented). I think you mean matches() is being implemented, while the web depends on a prefixed version of

Intent to implement and ship: HTMLElement.innerText

https://bugzilla.mozilla.org/show_bug.cgi?id=264412 Webkit, Blink and Trident have been shipping this for years without a spec and with poor interop. We held off on implementing it since you can polyfill a better implementation in JS without much difficulty, but we have to implement something for

Re: Intent to implement and ship ::backdrop pseudo-element for Fullscreen API

On Sun, Oct 18, 2015 at 12:59 AM, Jean-Yves Perrier wrote: > On 16/10/2015 02:39, Xidorn Quan wrote: > >> Blink has shipped this pseudo-element unprefixed for modal >> element (but not yet for fullscreen) >> > I have a side question here: do we plan to support ::backdrop for

Re: Intent to implement and ship ::backdrop pseudo-element for Fullscreen API

On 16/10/2015 02:39, Xidorn Quan wrote: Blink has shipped this pseudo-element unprefixed for modal element (but not yet for fullscreen) I have a side question here: do we plan to support ::backdrop for modal in the future, or is it a Blink oddity. -- Jean-Yves Perrier Senior St. Project

Intent to implement and ship ::backdrop pseudo-element for Fullscreen API

Summary: This pseudo-element is rendered immediately below every fullscreen element, and covers the other part of the document by default. This is part of the effort to update our Fullscreen API implementation to the latest spec. And it is the last non-trivial part before I'm going to unprefix the

Re: Intent to Implement and Ship: Permissions API

On Wed, 2 Sep 2015, at 03:50, Ehsan Akhgari wrote: > On 2015-09-01 9:57 PM, Jonas Sicking wrote: > > But I agree that we should make it clear that we do not intend to > > implement a request API. > > There is actually a valid use case for a request API. It has become > clear that we need to

Re: Intent to Implement and Ship: Permissions API

On Mon, Aug 24, 2015 at 11:57 PM, Anne van Kesteren wrote: > On Sat, Aug 22, 2015 at 5:03 AM, Birunthan Mohanathas > wrote: >> Summary: The Permissions API allows a web application to be aware of >> the status of a given permission, to know whether it

Re: Intent to Implement and Ship: Permissions API

On 2015-09-01 9:57 PM, Jonas Sicking wrote: But I agree that we should make it clear that we do not intend to implement a request API. There is actually a valid use case for a request API. It has become clear that we need to expose pasting functionality to the Web, and the most natural way

Re: Intent to implement and ship

On 2015-08-26 10:08 AM, Adam Roach wrote: On 8/26/15 08:36, Ehsan Akhgari wrote: Have you considered the implications of making the alias falsey in conditions, similar to document.all? The issue with doing so is that we see code in the wild that looks like this: |var NativeRTCPeerConnection

Re: Intent to implement and ship

On 2015-08-25 5:45 PM, Martin Thomson wrote: Maybe some day we can remove the aliases by just backing out the patch that creates prefixed aliases, but that seems unlikely in the short term [1][2]. Do the aliases only work when you call them or can the webpage also detect them? IOW, what would

Re: Intent to implement and ship

On 8/26/15 08:36, Ehsan Akhgari wrote: Have you considered the implications of making the alias falsey in conditions, similar to document.all? The issue with doing so is that we see code in the wild that looks like this: |var NativeRTCPeerConnection = (window.webkitRTCPeerConnection ||

Re: Intent to implement and ship

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/26/2015 03:36 PM, Ehsan Akhgari wrote: Hmm, I see. Have you considered the implications of making the alias falsey in conditions, similar to document.all? No. No. Nononononono. Ms2ger -BEGIN PGP SIGNATURE-

Re: Intent to Implement and Ship: Permissions API

On Tue, Aug 25, 2015 at 2:12 AM, Anne van Kesteren ann...@annevk.nl wrote: 3) It seems the API is evolving in ways to also request permission without then directly using that permission. It's not clear that is a good idea. This is something that is already doable. If a webpage calls

Re: Intent to Implement and Ship: Permissions API

On Sat, Aug 22, 2015 at 5:03 AM, Birunthan Mohanathas birunt...@mohanathas.com wrote: Summary: The Permissions API allows a web application to be aware of the status of a given permission, to know whether it is granted, denied or if the user will be asked whether the permission should be

Re: Intent to Implement and Ship: Permissions API

On Tue, Aug 25, 2015 at 11:06 AM, Mounir Lamouri mou...@lamouri.fr wrote: Browsers internal implementation can change. The API will have to stay as it is in the long run. It's better to have an flexible API that would allow different implementation strategies. Even if you have only strings

Re: Intent to Implement and Ship: Permissions API

On Tue, 25 Aug 2015, at 07:57, Anne van Kesteren wrote: On Sat, Aug 22, 2015 at 5:03 AM, Birunthan Mohanathas birunt...@mohanathas.com wrote: Summary: The Permissions API allows a web application to be aware of the status of a given permission, to know whether it is granted, denied or if

Intent to implement and ship

WebRTC was shipped with a prefix. Bug 1155923 moves our codebase to non-prefixed names, but includes a patch to restore aliases with the prefix. Thus we will expose `RTCPeerConnection` and use that ourselves, but permit legacy code to use `mozRTCPeerConnection`. Maybe some day we can remove the

Re: Intent to implement and ship

On Tue, Aug 25, 2015 at 2:16 PM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote: On 2015-08-25 4:07 PM, Martin Thomson wrote: WebRTC was shipped with a prefix. Bug 1155923 moves our codebase to non-prefixed names, but includes a patch to restore aliases with the prefix. Thus we will expose

Re: Intent to implement and ship

On 2015-08-25 4:07 PM, Martin Thomson wrote: WebRTC was shipped with a prefix. Bug 1155923 moves our codebase to non-prefixed names, but includes a patch to restore aliases with the prefix. Thus we will expose `RTCPeerConnection` and use that ourselves, but permit legacy code to use

Re: Intent to Implement and Ship: Permissions API

On 2015-08-21 11:03 PM, Birunthan Mohanathas wrote: Hi, navigator.permissions.query has been Nightly-only for a few weeks. We are going to let it ride the trains. Other parts of the spec (such as Permissions.request) will be implemented when the spec is complete. Just to double check, do we

Re: Intent to Implement and Ship: Permissions API

On 24 August 2015 at 09:47, Ehsan Akhgari ehsan.akhg...@gmail.com wrote: Just to double check, do we support geolocation, notifications and push? Yep! ___ dev-platform mailing list dev-platform@lists.mozilla.org

Re: Intent to implement and ship: CSS and SVG filters for canvas 2D

Just to keep this thread moving forward: On Tue, Jun 16, 2015 at 2:35 AM, Markus Stange msta...@themasta.com wrote: On 2015-06-15 8:15 PM, Robert O'Callahan wrote: On Tue, Jun 16, 2015 at 11:23 AM, Robert O'Callahan rob...@ocallahan.org wrote: I think we're not quite there yet, but we're

Re: Intent to Implement and Ship: Permissions API

I'm less psyched about Permissions.request, but looking forward to having .query ship! Does it also work in workers? / Jonas On Sat, Aug 22, 2015 at 5:03 AM, Birunthan Mohanathas birunt...@mohanathas.com wrote: Hi, navigator.permissions.query has been Nightly-only for a few weeks. We are

Re: Intent to Implement and Ship: Permissions API

On 22 August 2015 at 06:24, Jonas Sicking jo...@sicking.cc wrote: Does it also work in workers? Not yet, that was left for bug 1193373. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform

Intent to Implement and Ship: Permissions API

Hi, navigator.permissions.query has been Nightly-only for a few weeks. We are going to let it ride the trains. Other parts of the spec (such as Permissions.request) will be implemented when the spec is complete. Summary: The Permissions API allows a web application to be aware of the status of a

Re: Intent to implement and ship: Unprivilaged WEBGL_debug_renderer_info

On Thursday, June 18, 2015 at 9:32:30 PM UTC+2, Chris Peterson wrote: It sounds like there are three use cases for WEBGL_debug_renderer_info: 1. Correlating GPU info with bug reports (e.g. YouTube). 2. Web content workarounds for GPU bugs. 3. Fingerprinting for user tracking. There are more

<    1   2   3   4   5   6   7   >