On 1/14/19 7:23 PM, Boris Zbarsky wrote:
> On 1/14/19 12:58 PM, Mats Palmgren wrote:
>> Do other browser engines implement this? No,
>> https://wpt.fyi/results/css/css-logical/logical-box-padding.html
>
> Do they plan to? That is, is the spec reflecting some sort of general
> consensus?
They'r
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}
I
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
Estimated
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
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.
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 rig
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 mult
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, 201
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
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
_
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 'i
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. I
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 11:2
(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
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:
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 unfortuna
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 test
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
https://lists.mozilla.org/listinfo/dev-platform
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
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
are/wer
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, bu
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 unprefi
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 f
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.
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 https://github.com/w3c/csswg-drafts/iss
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
will
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 enabled
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 cove
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.
>
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 t
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:
> https://developer.mozilla.org/en-US/do
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 P
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 come
(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.
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, 2
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 é
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" issues
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: https://bugzilla.mo
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:
https://drafts.csswg.org/c
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] https://www.joel
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
HTMLMar
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 developm
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 exp
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 allow
>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. Th
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 it
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 f
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
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 sen
> 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 happe
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 not se
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
happen to know whether we already do that, or have a bug on adding it
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
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
> new
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: https://bugz
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 https://bugzilla.mozilla.org/show_bug.cgi?id=cookierestric
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 th
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"...
> >
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 implem
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, Jan-
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 I
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 them
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 ho
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 usef
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 A
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, t
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
>
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 st
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 N
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 un
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 HTMLMediaEl
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 w
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.
This
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 quickly.
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
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 sp
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 poli
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
Summary: Allow setting the decoding attribute on img elements to hint at
synchronous/asynchronous decoding of image data. We currently decode images
asynchronously which can cause flickering in some circumstances (e.g. if
the src is changed), while other browsers default to synchronous decoding
(wh
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
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
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
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: https://bugzilla.mozilla.org/show_bug.cgi?id=1365
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
m
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
___
de
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
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 featur
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 cookies" means the __Sec
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
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
wrote
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
> Targe
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
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.
B
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 i
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
> against Cross-Site Reque
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) and
> negligible upside.
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 transmitted over HTTP (an
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
> against Cross-Site Reque
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 web sites to protect the
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):
https://tools
101 - 200 of 748 matches
Mail list logo