Re: Intent to Implement and Ship: CSS padding-block and padding-inline shorthands

On 1/14/19 12:58 PM, Mats Palmgren wrote: Link to standard: https://drafts.csswg.org/css-logical/#propdef-padding-inline Two quick questions on the spec: 1) 'padding-block-start' is defined as: Value: <‘padding-top’> while 'padding-block' is defined as: Value: <‘padding-left’>{1,2}

Intent to Implement and Ship: CSS padding-block and padding-inline shorthands

Summary: The padding-block CSS property is a shorthand for the padding-block-start/end properties (ditto -inline) Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1519847 Link to standard: https://drafts.csswg.org/css-logical/#propdef-padding-inline Platform coverage: All platforms

Re: Intent to implement and ship: Overflow media queries

On 1/2/19 5:18 PM, James Graham wrote: On 23/12/2018 10:59, Emilio Cobos Álvarez wrote: web-platform-tests: Minimal parsing tests are being added to:    https://wpt.fyi/results/css/mediaqueries/test_media_queries.html Unfortunately WPT has no way to test print preview or pagination right now

Re: Intent to implement and ship: Overflow media queries

On 23/12/2018 10:59, Emilio Cobos Álvarez wrote: web-platform-tests: Minimal parsing tests are being added to:   https://wpt.fyi/results/css/mediaqueries/test_media_queries.html Unfortunately WPT has no way to test print preview or pagination right now so the rest of reftests are Gecko-only.

Intent to implement and ship: Overflow media queries

Summary: More explicitly expose the kind of handling for overflowing content in media queries. Using a media expression instead of the print media type allows for more flexibility, see the bug description. Implementation wise, we already expose the same kind of information via @media print

Re: Intent to Implement and Ship: break-before, break-after, break-inside CSS properties

On 12/21/18 7:23 PM, Eric Shepherd (Sheppy) wrote: I just now saw this; as both a developer and as a writer on the MDN docs team, I can tell you this will really be fantastic to have, and I can’t wait! Not having control over breaks makes a lot of layout fail, especially when trying to use

Re: Intent to Implement and Ship: break-before, break-after, break-inside CSS properties

I just now saw this; as both a developer and as a writer on the MDN docs team, I can tell you this will really be fantastic to have, and I can’t wait! Not having control over breaks makes a lot of layout fail, especially when trying to use multiple columns or grids to do layout. On December 7,

Re: Intent to implement and ship: UTF-8 autodetection for HTML and plain text loaded from file: URLs

On Thu, Dec 13, 2018 at 1:14 AM Henri Sivonen wrote: > I changed the limit to 4 MB. SGTM. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: UTF-8 autodetection for HTML and plain text loaded from file: URLs

On Tue, Dec 11, 2018 at 10:08 AM Henri Sivonen wrote: > How about I change it to 5 MB on the assumption that that's still very > large relative to pre-UTF-8-era HTML and text file sizes? I changed the limit to 4 MB. -- Henri Sivonen hsivo...@mozilla.com

Intent to implement and ship: forced case-sensitive attribute selector matching

Summary: When matching CSS attribute selectors against HTML, some attribute names lead to case-sensitive value matching, while others use ASCII-case-insensitive matching. The proposed feature adds an 's' flag on attribute selectors that forces case-sensitive matching, just like the existing

Re: Intent to implement and ship: UTF-8 autodetection for HTML and plain text loaded from file: URLs

On Tue, Dec 11, 2018 at 2:24 AM Martin Thomson wrote: > This seems reasonable, but 50M is a pretty large number. Given the > odds of UTF-8 detection failing, I would have thought that this could > be much lower. Consider the case of a document of ASCII text with a copyright sign in the footer.

Re: Intent to implement and ship: UTF-8 autodetection for HTML and plain text loaded from file: URLs

This seems reasonable, but 50M is a pretty large number. Given the odds of UTF-8 detection failing, I would have thought that this could be much lower. What is the number in Chrome? I assume that other local sources like chrome: are expected to be annotated properly. On Mon, Dec 10, 2018 at

Intent to implement and ship: UTF-8 autodetection for HTML and plain text loaded from file: URLs

(Note: This isn't really a Web-exposed feature, but this is a Web developer-exposed feature.) # Summary Autodetect UTF-8 when loading HTML or plain text from file: URLs (only!). Some Web developers like to develop locally from file: URLs (as opposed to local HTTP server) and then deploy using a

Intent to Implement and Ship: break-before, break-after, break-inside CSS properties

Summary: Implement these properties to control breaks in the page, make page-break-{before,after} legacy shorthands of those. This work doesn't imply adding new layout functionality, just the style system rejiggering to make us comply with the spec and be compatible with other engines. Bug:

Re: Intent to implement and ship: Unprefix -moz-user-select, unship mozilla-specific values.

On Thu, Nov 29, 2018 at 6:27 AM Emilio Cobos Álvarez wrote: > Sorry for the lag replying to this. > > On 11/13/18 4:35 PM, James Graham wrote: > > On 11/11/2018 17:57, Emilio Cobos Álvarez wrote: > > > >> web-platform-tests: Test coverage for all the values is pre-existing. > >> There's

Re: Intent to implement and ship: Unprefix -moz-user-select, unship mozilla-specific values.

Sorry for the lag replying to this. On 11/13/18 4:35 PM, James Graham wrote: On 11/11/2018 17:57, Emilio Cobos Álvarez wrote: web-platform-tests: Test coverage for all the values is pre-existing. There's unfortunately little coverage in WPT, but a lot in our selection and contenteditable

Re: Intent to implement and ship: overflow-wrap: anywhere

Finally something what solving problem of missing "word-break: break-word" (https://jsfiddle.net/ofgd83um/80/) When it will be shipped to stable? ___ dev-platform mailing list dev-platform@lists.mozilla.org

Re: Intent to implement and ship: overflow-wrap: anywhere

Finally something can slove problem of missing "word-break: break-word" https://jsfiddle.net/ofgd83um/80/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: Unprefix -moz-user-select, unship mozilla-specific values.

On 11/11/2018 17:57, Emilio Cobos Álvarez wrote: web-platform-tests: Test coverage for all the values is pre-existing. There's unfortunately little coverage in WPT, but a lot in our selection and contenteditable tests. Can we upstream some of these tests to wpt? I don't know if there

Re: Intent to implement and ship: Unprefix -moz-user-select, unship mozilla-specific values.

On 11/12/18 2:36 AM, flor...@rivoal.net wrote: On Monday, November 12, 2018 at 2:57:14 AM UTC+9, Emilio Cobos Álvarez wrote: Summary: Unprefix the -moz-user-select property, so that it works without the -moz- prefix. We happen to be supporting the -webkit- prefixed version of the property,

Re: Intent to implement and ship: Unprefix -moz-user-select, unship mozilla-specific values.

On Monday, November 12, 2018 at 2:57:14 AM UTC+9, Emilio Cobos Álvarez wrote: > Summary: Unprefix the -moz-user-select property, so that it works > without the -moz- prefix. > > We happen to be supporting the -webkit- prefixed version of the > property, but other browsers support it also

Intent to implement and ship: Unprefix -moz-user-select, unship mozilla-specific values.

Summary: Unprefix the -moz-user-select property, so that it works without the -moz- prefix. We happen to be supporting the -webkit- prefixed version of the property, but other browsers support it also unprefixed, which causes a lot of confusion. As part of this work I'm also unshipping the

Re: Intent to implement and ship: overflow-wrap: anywhere

I think it's great, please go ahead. I just gave a talk about the various properties/values related to line breaking, and had multiple people tell me they were so sad that overflow-wrap:anywhere wasn't implemented yet. So I totally support implementing/shipping this.

Intent to implement and ship: overflow-wrap: anywhere

Summary: Implement a new keyword for the overflow-wrap / word-wrap properties (which are aliases) which affects min-content sizing. We tried to make break-word affect min-content sizing (see bug 1472386), but that was found not to be web-compatible. See

Re: Intent to implement and ship: img decode API support

Ah, my bad. Yes, if scripts are available, this is available. It doesn't allow you to do anything new, aside from forcing a decode to start (which you could do by adding the image to the DOM tree, assuming it is visible) and knowing when the decode has completed. The usual content restrictions

Re: Intent to implement and ship: img decode API support

On 11/7/18 11:15 AM, Andrew Osmond wrote: This is simply a new method for JS on image elements, so it should be unavailable. Script can run in sandboxed iframes, depending on sandboxing flags. It sounds like this feature is enabled by default in sandboxed iframes, as long as script is

Intent to implement and ship: img decode API support

Web authors would like a way to guarantee an image has been fully decoded and will display immediately when inserted into the DOM. Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1501794 Link to standard: https://html.spec.whatwg.org/multipage/embedded-content.html#dom-img-decode Platform

Re: Intent to implement and ship: CSS environment variables.

On Fri, Nov 2, 2018 at 5:26 PM Emilio Cobos Álvarez wrote: > This is mostly to prevent compat headache in mobile, hopefully prevent > other vendors from shipping new un-spec'd env variables, and encourage > people to use the fallback value if new environment variables are added > in the future.

Intent to implement and ship: CSS environment variables.

Summary: Implement the CSS env() function which allows to take a variable name and a fallback value. Note that this intent goes only for the CSS feature, not for the rest of the display cutout support, which is tracked in bug 1503656. This work would add support for four variables (the four

Re: Intent to implement and ship: New cookie jar policy to block storage access from tracking resources

Just a quick update: This new policy has now been made the new default in Nightly in https://bugzilla.mozilla.org/show_bug.cgi?id=1492563. On Fri, Sep 21, 2018 at 3:15 PM Steven Englehardt wrote: > Technical documentation for this is now available on MDN: >

Re: Intent to Implement and Ship: window.screenLeft and window.screenTop aliases

On 10/17/18 3:04 PM, Tom Ritter wrote: I believe that we fiddle these for Resist Fingerprinting; can you ensure the new values are similarly fiddled? Yeah, they reuse literally the same code path, so they also have the same fiddling for RFP. -- Emilio -tom On Tue, Oct 16, 2018 at 10:02

Re: Intent to Implement and Ship: window.screenLeft and window.screenTop aliases

I believe that we fiddle these for Resist Fingerprinting; can you ensure the new values are similarly fiddled? -tom On Tue, Oct 16, 2018 at 10:02 PM Emilio Cobos Álvarez wrote: > (Trying to be more disciplined about pinging dev-platform@ about > web-exposed changes, a few other emails will

Intent to Implement and Ship: window.screenLeft and window.screenTop aliases

(Trying to be more disciplined about pinging dev-platform@ about web-exposed changes, a few other emails will come up in a bit) Summary: I plan to add the screenLeft and screenTop properties to the window, as aliases of screenX and screenY respectively, mostly for compat with other engines.

Re: Intent to implement and ship: HTMLMarqueeElement

The next step for removing XBL in marquee will be to put the content inside of a UA Widget Shadow Root and then (ideally) drop the JS-implemented animation in favor of CSS animation. I expect that should be enough to fix https://bugzilla.mozilla.org/show_bug.cgi?id=306344. Brian > On Oct 14,

Re: Intent to implement and ship: HTMLMarqueeElement

Happy to see this coming. I'm (honestly) sort of a fan of , in a twisted sort of way. A fun reminder of the whimsy of the early days of the web, and amusing to use in certain types of examples. On Sun, Oct 14, 2018 at 8:30 PM Karl Dubost wrote: > > > Le 13 oct. 2018 à 02:56, Brian Grinstead a

Re: Intent to implement and ship: HTMLMarqueeElement

Le 13 oct. 2018 à 02:56, Brian Grinstead a écrit : > Summary: […] I intend to implement and ship HTMLMarqueeElement. Very cool. And a support on that, from a webcompat standpoint of view, because it seems a lot of Indian websites rely on it. The current implementation has "performance"

Re: Intent to implement and ship: text-transform: full-size-kana

On Saturday, October 13, 2018 at 9:21:35 PM UTC+9, Xidorn Quan wrote: > Summary: A new value of text-transform to convert small Kanas to their > full-size counterparts to increase legibility in the expense of accuracy, > usually when font size is small, e.g. in ruby. > > Bug:

Intent to implement and ship: text-transform: full-size-kana

Summary: A new value of text-transform to convert small Kanas to their full-size counterparts to increase legibility in the expense of accuracy, usually when font size is small, e.g. in ruby. Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1498148 Link to standard:

Re: Intent to implement and ship: HTMLMarqueeElement

On 10/12/18 1:56 PM, Brian Grinstead wrote: Summary: Motion is a key component of modern web design, and is the premier... Fire. The premier fire so we can have fire and motion [1]. Or maybe it's just a dumpster fire? ;) The proposed change looks great to me. -Boris [1]

Intent to implement and ship: HTMLMarqueeElement

Summary: Motion is a key component of modern web design, and is the premier... just kidding. Gecko currently ships as an HTMLDivElement with the web-exposed properties attached via in-content XBL [0][1]. As part of the process of removing in-content XBL, I intend to implement and ship

Re: Intent to implement and ship: WebP image support

On 11/10/2018 6:03 PM, Tom Ritter wrote: Are we bringing in a new third party library for this? (Seems like yes?) Who else uses it/audits it? Does anyone else fuzz it? Is it in OSS-fuzz? Are we fuzzing it? How does upstream behave? Do they cut releases or do they just have continual

Re: Intent to implement and ship: WebP image support

On Thu, Oct 11, 2018 at 5:43 PM Andrew Osmond wrote: > Is this feature restricted to secure contexts?: No, it isn't. This is not a > new API, instead it is just accepting more types of content via existing > channels. This isn't the rationale you're looking for. New formats would generally be

Re: Intent to implement and ship: WebP image support

Yes, that's part of it. Further, now that Edge has shipped it we can cause there to be a majority of vendors supporting it. Having WebP supported by all of the browsers changes the weight we put on the different advantages and disadvantages. For example, Firefox supporting WebP will allow now

Re: Intent to implement and ship: WebP image support

>Are we bringing in a new third party library for this? (Seems like yes?) libwebp (see https://bugzilla.mozilla.org/show_bug.cgi?id=1294490) >Who else uses it/audits it? Does anyone else fuzz it? Is it in OSS-fuzz? >Are we fuzzing it? http://developers.google.com/speed/webp - Chrome uses it.

Re: Intent to implement and ship: WebP image support

Are we bringing in a new third party library for this? (Seems like yes?) Who else uses it/audits it? Does anyone else fuzz it? Is it in OSS-fuzz? Are we fuzzing it? How does upstream behave? Do they cut releases or do they just have continual development and downstreams grab random versions of

Re: Intent to implement and ship: WebP image support

On 10/11/18 11:43 AM, Andrew Osmond wrote: We are facing a growing number of webcompat reports against our Gecko-derived Android offerings, where web developers assume Android and/or mobile implies support for WebP. In the past, I believe we objected to adding WebP for various reasons. Do we

Intent to implement and ship: WebP image support

WebP is an image format developed by Google, long supported by Chrome. We are facing a growing number of webcompat reports against our Gecko-derived Android offerings, where web developers assume Android and/or mobile implies support for WebP. In addition, Edge has now shipped WebP [1]. As such, I

Re: Intent to implement and ship: Referrer Policy for CSS

David > > On Fri, 5 Oct 2018 at 13:32, Christoph Kerschbaumer <mailto:ckers...@gmail.com>> wrote: > We just realized we have never sent an intent to implement and ship for > extending coverage of Referrer Policy to style sheets. Please accept my > apology for not

Re: Intent to implement and ship: Referrer Policy for CSS

> On Oct 5, 2018, at 4:20 PM, Boris Zbarsky wrote: > > On 10/5/18 8:31 AM, Christoph Kerschbaumer wrote: >> DevTools bug: No devtools support. > > Though it would be nice if we had devtools support for determining the > referrer policy that applied to a given request in general. Do you

Re: Intent to implement and ship: Referrer Policy for CSS

Are there web platform tests for this feature? David On Fri, 5 Oct 2018 at 13:32, Christoph Kerschbaumer wrote: > We just realized we have never sent an intent to implement and ship for > extending coverage of Referrer Policy to style sheets. Please accept my > apology for no

Intent to implement and ship: Referrer Policy for CSS

We just realized we have never sent an intent to implement and ship for extending coverage of Referrer Policy to style sheets. Please accept my apology for not sending the intent-email earlier. Anyway, we are planning to ship that extension of Referrer Policy coverage to CSS in Firefox 64. Bug

Re: Intent to implement and ship: New cookie jar policy to block storage access from tracking resources

Technical documentation for this is now available on MDN: https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Privacy/Storage_access_policy On Wed, Sep 19, 2018 at 10:24 PM Ehsan Akhgari wrote: > Hi everyone, > > This is a (belated) intent to implement, as well as an intent to ship, a >

Intent to implement and ship: getDisplayMedia()

Summary: Firefox has long supported screen capture through a proprietary non-standard extension of getUserMedia(). We intend to implement the standard getDisplayMedia() API, and eventually remove the old non-standard API. This exposes existing functionality in a standard way. Bug:

Intent to implement and ship: New cookie jar policy to block storage access from tracking resources

Hi everyone, This is a (belated) intent to implement, as well as an intent to ship, a new cookie jar policy to block storage access to tracking resources. This work has been under development for several months now and has been tracked in

Re: Intent to implement and ship: WebXR Device API in Firefox Nightly

Hi David, These are all great points, thanks for reviewing this. The intent is to not allow WebXR in any iframe (not just sandboxed ones), until the discussions have settled. I appreciate the feedback on the feature policy approach and how the origin would be presented to the user. Much of

Re: Intent to implement and ship: HTMLMediaElement.allowedToPlay

On Wednesday, August 8, 2018 at 4:58:28 PM UTC-7, Jan-Ivar Bruaroey wrote: > On 8/8/18 12:43 PM, Chris Pearce wrote: > > Hi Jib, > > > > I appreciate that you care passionately about our users' best interests. > > > > Seeing as you asked "why don't you just?"... Here's why we "didn't just"... >

Intent to implement and ship: flow-relative values for resize property

Summary: Add two values "block" and "inline" to resize property. Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1464786 Link to standard: https://drafts.csswg.org/css-logical/#resize Platform coverage: All platforms Estimated or target release: 63 Preference behind which this will be

Re: Intent to implement and ship: HTMLMediaElement.allowedToPlay

On 8/8/18 12:43 PM, Chris Pearce wrote: Hi Jib, I appreciate that you care passionately about our users' best interests. Seeing as you asked "why don't you just?"... Here's why we "didn't just"... On Tuesday, August 7, 2018 at 7:51:50 PM UTC-7, Jan-Ivar Bruaroey wrote: On 8/6/18 4:03 PM,

Re: Intent to implement and ship: HTMLMediaElement.allowedToPlay

On 8/8/18 12:53 PM, Boris Zbarsky wrote: On 8/8/18 12:43 PM, Chris Pearce wrote: On Tuesday, August 7, 2018 at 7:51:50 PM UTC-7, Jan-Ivar Bruaroey wrote: To clarify, I care about Netflix, which is why I question giving up on persisting autoplay for them, which is what allowedToPlay does. So

Re: Intent to implement and ship: HTMLMediaElement.allowedToPlay

On Wednesday, August 8, 2018 at 9:54:06 AM UTC-7, Boris Zbarsky wrote: > On 8/8/18 12:43 PM, Chris Pearce wrote: > > On Tuesday, August 7, 2018 at 7:51:50 PM UTC-7, Jan-Ivar Bruaroey wrote: > >> To clarify, I care about Netflix, which is why I question giving up on > >> persisting autoplay for

Re: Intent to implement and ship: HTMLMediaElement.allowedToPlay

On 8/8/18 1:00 PM, Chris Pearce wrote: Google weren't keen on that idea as it doesn't map well to their implicit MEI method. Right, that's the "hard problem" bit. Feels like we should maybe be able to find non-Google allies here, especially if we have some weasel-wording in the spec about

Re: Intent to implement and ship: HTMLMediaElement.allowedToPlay

On 8/8/18 12:43 PM, Chris Pearce wrote: On Tuesday, August 7, 2018 at 7:51:50 PM UTC-7, Jan-Ivar Bruaroey wrote: To clarify, I care about Netflix, which is why I question giving up on persisting autoplay for them, which is what allowedToPlay does. So I have a question. Would it be at all

Re: Intent to implement and ship: HTMLMediaElement.allowedToPlay

Hi Jib, I appreciate that you care passionately about our users' best interests. Seeing as you asked "why don't you just?"... Here's why we "didn't just"... On Tuesday, August 7, 2018 at 7:51:50 PM UTC-7, Jan-Ivar Bruaroey wrote: > On 8/6/18 4:03 PM, Jan-Ivar Bruaroey wrote: > > On 8/1/18 3:36

Re: Intent to implement and ship: HTMLMediaElement.allowedToPlay

On 8/6/18 4:03 PM, Jan-Ivar Bruaroey wrote: On 8/1/18 3:36 AM, Chris Pearce wrote: I think the only thing that you're missing is how vehemently some sites are in their desire to avoid the doorhanger prompt. No, I'm also missing why we should listen to them. If Netflix fights our doorhanger,

Re: Intent to implement and ship: WebXR Device API in Firefox Nightly

On Monday 2018-07-30 17:03 -0700, Kip Gilbert wrote: > Is this feature enabled by default in sandboxed iframes? > WebXR will not be enabled by default in sandboxed iframes. This will likely > be enabled later, by use of Feature Policy: > https://github.com/immersive-web/webxr/issues/86 >

Re: Intent to implement and ship: WebXR Device API in Firefox Nightly

Thank you; that will help the docs team very much as well. On Tue, Aug 7, 2018 at 11:30 AM, Boris Zbarsky wrote: > On 7/30/18 8:03 PM, Kip Gilbert wrote: > >> Link to standard: >> > > Kip, > > Could you please ensure that all the relevant .webidl files have links to > the relevant bits of the

Re: Intent to implement and ship: WebXR Device API in Firefox Nightly

On 7/30/18 8:03 PM, Kip Gilbert wrote: Link to standard: Kip, Could you please ensure that all the relevant .webidl files have links to the relevant bits of the standard at the top of the file (and on the individual interface definitions if there are multiple interfaces in the file)? See

Re: Intent to implement and ship: HTMLMediaElement.allowedToPlay

On 8/6/18 4:03 PM, Jan-Ivar Bruaroey wrote: whereas our plan for that was to ask users once, with a "remember=yes" prompt. For what it's worth, I've been getting this prompt a _lot_ recently; presumably I finally updated to a nightly that does the prompt. As a user, I have been tending to

Re: Intent to implement and ship: HTMLMediaElement.allowedToPlay

On 8/1/18 3:36 AM, Chris Pearce wrote: On Tuesday, July 31, 2018 at 9:05:03 AM UTC+12, Jan-Ivar Bruaroey wrote: On 7/29/18 10:39 PM, Chris Pearce wrote: Summary: HTMLMediaElement.allowedToPlay allows web authors to determine in advance of calling HTMLMediaElement.play() whether the

Re: Intent to implement and ship: HTMLMediaElement.allowedToPlay

On Tuesday, July 31, 2018 at 9:05:03 AM UTC+12, Jan-Ivar Bruaroey wrote: > On 7/29/18 10:39 PM, Chris Pearce wrote: > > Summary: HTMLMediaElement.allowedToPlay allows web authors to determine in > > advance of calling HTMLMediaElement.play() whether the HTMLMediaElement in > > its current state

Re: Intent to implement and ship: HTMLMediaElement.allowedToPlay

I don't think that Netflix would accept allowedToPlay == false for media which is the whole point of visiting a page. They probably wouldn't even check it then, instead allowing for the possibility that the user will be prompted or that it just won't autoplay if they expressed that preference.

Re: Intent to implement and ship: WebXR Device API in Firefox Nightly

On Monday, July 30, 2018 at 5:22:05 PM UTC-7, kgil...@mozilla.com wrote: > Correction: "As of 2019-10-01" should be "As of 2018-10-01"... > Also.. Should be "The implementation is expected to be completed for Firefox 66, but would be enabled as early as Firefox 65 if implementation goes

Re: Intent to implement and ship: WebXR Device API in Firefox Nightly

Correction: "As of 2019-10-01" should be "As of 2018-10-01"... On Monday, July 30, 2018 at 5:03:38 PM UTC-7, Kip Gilbert wrote: > Summary: > > The successor to WebVR 1.1, the WebXR Device API 1.0, is nearing > finalization. The WebXR Device API follows modern Web API patterns, is > extensible

Intent to implement and ship: WebXR Device API in Firefox Nightly

Summary: The successor to WebVR 1.1, the WebXR Device API 1.0, is nearing finalization. The WebXR Device API follows modern Web API patterns, is extensible additively for augmented reality, enables use within Web Workers, and solves many security problems for the VR and AR enabled web. The

Re: Intent to implement and ship: HTMLMediaElement.allowedToPlay

On 7/29/18 10:39 PM, Chris Pearce wrote: Summary: HTMLMediaElement.allowedToPlay allows web authors to determine in advance of calling HTMLMediaElement.play() whether the HTMLMediaElement in its current state would be allowed to play, or would be blocked by the browser's autoplay blocking

Intent to implement and ship: HTMLMediaElement.allowedToPlay

Summary: HTMLMediaElement.allowedToPlay allows web authors to determine in advance of calling HTMLMediaElement.play() whether the HTMLMediaElement in its current state would be allowed to play, or would be blocked by the browser's autoplay blocking policies. This is useful to web authors as if

Intent to implement and ship: Image decoding attribute

=1416328 Spec: https://html.spec.whatwg.org/multipage/images.html#image-decoding-hint Platform coverage: All Target release: 63 Preference: None Support in other engines: Safari has already shipped (see https://bugs.webkit.org/show_bug.cgi?id=179432), Chrome has issued its own intent to ship

Fwd: Intent to implement and ship: CSS prefers-reduced-motion media feature for Windows and MacOSX

I just realized that I did send below message only to Tom. :) -- Forwarded message -- From: Hiroyuki Ikezoe Date: Wed, Jul 25, 2018 at 6:59 AM Subject: Re: Intent to implement and ship: CSS prefers-reduced-motion media feature for Windows and MacOSX To: Tom Ritter Thank you

Re: Intent to implement and ship: CSS prefers-reduced-motion media feature for Windows and MacOSX

As far as I can tell the specification does not indicate any privacy concerns; even though this exposes a system preference. I'd request that if Resist Fingerprinting is enabled; the browser behaves as if the user has not set any preference. -tom On Tue, Jul 24, 2018 at 2:34 AM, Hiroyuki Ikezoe

Re: Intent to implement and ship: CSS prefers-reduced-motion media feature for Windows and MacOSX

On 7/24/18 3:34 AM, Hiroyuki Ikezoe wrote: Secure contexts: Yes Why? -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform

Intent to implement and ship: CSS prefers-reduced-motion media feature for Windows and MacOSX

Summary: By using CSS prefers-reduced-motion media feature, web developers can provide contents depending on a system setting that users want *motion-less* content. A WebKit blog post [1] might be useful to know this feature in more detail. Bugs:

Intent to implement and ship: import.meta in ES6 modules

In an ES6 module, |import.meta| is new syntax that evaluates to an object that provides module-specific metadata from by the host environment. Currently only the 'url' property is provided, which is the base URL of the executing module. This allows modules to locate resources relative to the

Re: Intent to implement and ship: same-site cookies

On 09/04/18 07:25 PM, Francois Marier wrote: > We intend to ship same-site cookies in Firefox 61. This has now been uplifted and will be shipping in Firefox 60. Status can be tracked on https://wiki.mozilla.org/Security/SameSiteCookies. Francois ___

Re: Intent to implement and ship: ping, rel, referrerPolicy, relList, hreflang, type and text properties on SVG elements

On 12/04/2018 00:00, da...@openweb.io wrote: On Tuesday, 10 April 2018 00:57:43 UTC-7, Gijs Kruitbosch wrote: On 10/04/2018 03:07, Cameron McCormack wrote: On Tue, Apr 10, 2018, at 11:58 AM, Jeff Gilbert wrote: Do we have a heuristic for when to /not/ include something from HTML in SVG? If

Re: Intent to implement and ship: ping, rel, referrerPolicy, relList, hreflang, type and text properties on SVG elements

On Tuesday, 10 April 2018 00:57:43 UTC-7, Gijs Kruitbosch wrote: > On 10/04/2018 03:07, Cameron McCormack wrote: > > On Tue, Apr 10, 2018, at 11:58 AM, Jeff Gilbert wrote: > >> Do we have a heuristic for when to /not/ include something from HTML in > >> SVG? > > > > If it doesn't make two

Re: Intent to implement and ship: same-site cookies

On Mon, Apr 9, 2018 at 11:56 PM, Anne van Kesteren wrote: > We keep > ​ ​ > trying to find ways to limit cookies transmitted over HTTP (and > limiting HTTP in general). Offering better cookies over HTTPS seems > like a good incentive for sites to migrate. > To me "better

Re: Intent to implement and ship: ping, rel, referrerPolicy, relList, hreflang, type and text properties on SVG elements

On 4/10/18 4:03 AM, Gijs Kruitbosch wrote: I looked at the patch briefly, and I'm a bit confused about the state of The DOM bit is exposed, but we don't actually send pings. Yes, this sucks in terms of detecting whether ping is supported... -Boris

Re: Intent to implement and ship: ping, rel, referrerPolicy, relList, hreflang, type and text properties on SVG elements

I like that our link handling is getting shared but would really love a fix for this bug in SVG rendering: https://bugzilla.mozilla.org/show_bug.cgi?id=1366494 Robert: do you have time to fix that one while you're in there? Thanks! --Jet On Tue, Apr 10, 2018 at 1:09 AM, Gijs Kruitbosch

Re: Intent to implement and ship: Blocking FTP subresources

On 09.04.2018 15:13, Tom Schuster wrote: > Summary: All FTP subresources in HTTPs pages (this also includes blob: > etc) will be blocked. Opening FTP links as toplevel documents is still > possible. > > Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1404744 > > Platform coverage: All >

Re: Intent to implement and ship: ping, rel, referrerPolicy, relList, hreflang, type and text properties on SVG elements

On 10/04/2018 09:03, Gijs Kruitbosch wrote: On 09/04/2018 22:11, longs...@gmail.com wrote: Summary: HTML anchor elements have ping, rel, referrerPolicy, relList, hreflang, type and text properties. SVG anchor elements should support these properties too according to the SVG 2 specification and

Re: Intent to implement and ship: ping, rel, referrerPolicy, relList, hreflang, type and text properties on SVG elements

On 09/04/2018 22:11, longs...@gmail.com wrote: Summary: HTML anchor elements have ping, rel, referrerPolicy, relList, hreflang, type and text properties. SVG anchor elements should support these properties too according to the SVG 2 specification and https://github.com/w3c/svgwg/issues/315.

Re: Intent to implement and ship: ping, rel, referrerPolicy, relList, hreflang, type and text properties on SVG elements

On 10/04/2018 03:07, Cameron McCormack wrote: On Tue, Apr 10, 2018, at 11:58 AM, Jeff Gilbert wrote: Do we have a heuristic for when to /not/ include something from HTML in SVG? If it doesn't make two features which already exist in both HTML and SVG more consistent, then I wouldn't include

Re: Intent to implement and ship: same-site cookies

On Tue, Apr 10, 2018 at 4:25 AM, Francois Marier wrote: > We intend to ship same-site cookies in Firefox 61. This new cookie > attribute allows sites to prevent cross-site requests from using those > cookies which provides a mechanism for web sites to protect themselves >

Re: Intent to implement and ship: ping, rel, referrerPolicy, relList, hreflang, type and text properties on SVG elements

On Tue, Apr 10, 2018 at 3:58 AM, Jeff Gilbert wrote: > Do we have a heuristic for when to /not/ include something from HTML in SVG? > > More or less, these additions to SVG just strike me as having solid > potential risk (for both spec-interaction and implementation bugs)

Re: Intent to implement and ship: same-site cookies

On Tue, Apr 10, 2018 at 4:25 AM, Francois Marier wrote: > Secure contexts: not restricted to secure contexts since cookies are > already available in non-secure contexts I'm not entirely convinced that is a good enough reason. We keep trying to find ways to limit cookies

Re: Intent to implement and ship: same-site cookies

On Tue, Apr 10, 2018 at 4:25 AM, Francois Marier wrote: > We intend to ship same-site cookies in Firefox 61. This new cookie > attribute allows sites to prevent cross-site requests from using those > cookies which provides a mechanism for web sites to protect themselves >

Re: Intent to implement and ship: same-site cookies

Yay! This is exciting, thank you! On Tue, Apr 10, 2018 at 4:30 AM Francois Marier wrote: > We intend to ship same-site cookies in Firefox 61. This new cookie > attribute allows sites to prevent cross-site requests from using those > cookies which provides a mechanism for

Intent to implement and ship: same-site cookies

We intend to ship same-site cookies in Firefox 61. This new cookie attribute allows sites to prevent cross-site requests from using those cookies which provides a mechanism for web sites to protect themselves against Cross-Site Request Forgery (CSRF) attacks. Specification (cookies):

Re: Intent to implement and ship: ping, rel, referrerPolicy, relList, hreflang, type and text properties on SVG elements

On Tue, Apr 10, 2018, at 11:58 AM, Jeff Gilbert wrote: > Do we have a heuristic for when to /not/ include something from HTML in SVG? If it doesn't make two features which already exist in both HTML and SVG more consistent, then I wouldn't include it. > More or less, these additions to SVG just

Re: Intent to implement and ship: ping, rel, referrerPolicy, relList, hreflang, type and text properties on SVG elements

Do we have a heuristic for when to /not/ include something from HTML in SVG? More or less, these additions to SVG just strike me as having solid potential risk (for both spec-interaction and implementation bugs) and negligible upside. Do we have people asking for this? Are there privacy concerns

<    1   2   3   4   5   6   7   >