Re: Intent to implement: AVIF (AV1 Image Format) support

2020-01-16 Thread Martin Thomson 
This sounds good.  In the interests of transparency, it might be good to
get this (and AV1 even) added to our standards positions repo (
https://mozilla.github.io/standards-positions/).  I don't know if this
necessarily rises to "important" in the same way that AV1 does, but it
would be good to have a clear signal from us that other browsers can use in
their decision making.

On Thu, Jan 16, 2020 at 5:27 AM Jon Bauman  wrote:

> AVIF is an image format based on the AV1 video codec [1] from the Alliance
> for Open Media [2]. AV1 support shipped in release 55 [3] and is currently
> supported in Chrome, but not Safari. There is an open issue for AVIF
> support in Chrome [4].
>
> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=avif
>
> Standard: https://aomediacodec.github.io/av1-avif/
>
> Platform coverage: All
>
> Restricted to secure contexts: No. There's currently no mechanism to
> enforce this for image formats, but we can revisit this before enabling
> this by default. The same goes for CORS.
>
> Target Release: 76
>
> Preference behind which this will be implemented: image.avif.enabled,
> turned off by default.
>
> [1] https://en.wikipedia.org/wiki/AV1
> [2] https://aomedia.org/
> [3] https://bugzilla.mozilla.org/show_bug.cgi?id=av1
> [4] https://bugs.chromium.org/p/chromium/issues/detail?id=960620
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

CSS roadmap for 2020

2020-01-16 Thread Sebastian Zartner 
Hi everybody,

2020 is already about two weeks old now and I stumbled over the list of planned 
CSS features again at https://wiki.mozilla.org/CSS.

As the list is totally outdated, I was wondering what are the plans for CSS for 
this year? Is there some place where users can get involved in the 
prioritization? And is there somebody that could update the list accordingly to 
have some reference? I can help with removing all features that got implemented 
in 2019, at least.

Sebastian
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement: AVIF (AV1 Image Format) support

2020-01-16 Thread Tom Ritter 
We sandboxed av1 into its own process for security concerns.
Presumably this is using the same or a similar library; so do we have
plans for mitigating the same concern before rolling out to users?

-tom

On Wed, Jan 15, 2020 at 6:28 PM Jon Bauman  wrote:
>
> AVIF is an image format based on the AV1 video codec [1] from the Alliance
> for Open Media [2]. AV1 support shipped in release 55 [3] and is currently
> supported in Chrome, but not Safari. There is an open issue for AVIF
> support in Chrome [4].
>
> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=avif
>
> Standard: https://aomediacodec.github.io/av1-avif/
>
> Platform coverage: All
>
> Restricted to secure contexts: No. There's currently no mechanism to
> enforce this for image formats, but we can revisit this before enabling
> this by default. The same goes for CORS.
>
> Target Release: 76
>
> Preference behind which this will be implemented: image.avif.enabled,
> turned off by default.
>
> [1] https://en.wikipedia.org/wiki/AV1
> [2] https://aomedia.org/
> [3] https://bugzilla.mozilla.org/show_bug.cgi?id=av1
> [4] https://bugs.chromium.org/p/chromium/issues/detail?id=960620
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement: AVIF (AV1 Image Format) support

2020-01-16 Thread James Graham 

On 13/01/2020 21:48, Jon Bauman wrote:

AVIF is an image format based on the AV1 video codec [1] from the Alliance
for Open Media [2]. AV1 support shipped in release 55 [3] and is currently
supported in Chrome, but not Safari. There is an open issue for AVIF
support in Chrome [4].

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=avif

Standard: https://aomediacodec.github.io/av1-avif/

Platform coverage: All

Restricted to secure contexts: No. There's currently no mechanism to
enforce this for image formats, but we can revisit this before enabling
this by default. The same goes for CORS.

Target Release: 76

Preference behind which this will be implemented: image.avif.enabled,
turned off by default.


Is there some kind of cross-implementation testsuite for this format? Or 
how are we confident that we won't end up in a scenario where Chrome and 
Gecko have observable differences in their handling of AVIF?

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: native rendering of outline-style: auto

2020-01-16 Thread florian 
Very happy about this initiative. There's still a lot that is undefined about 
how outlines should work, but this should take us one step closer to a world 
where we can even attempt do define it.

—Florian
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: native rendering of outline-style: auto

2020-01-16 Thread Frederik Braun 
How much of this platform-dependent rendering is web observable?
If yes, I guess we'll need an escape hatch for Resist Fingerprinting Mode.

Emilio Cobos Álvarez  schrieb am Mi., 15. Jan. 2020,
19:27:

> Hi,
>
> In bug 1031664 I plan to enable the themed rendering of outline-style:
> auto.
>
> Standard: https://www.w3.org/TR/css-ui/#outline-style (sorry for the TR
> version, but I have problems to access the current draft without
> building it locally :/)
>
> Platform coverage: Linux, Mac, Windows
>
> Preference: layout.css.outline-style-auto.enabled
>
> DevTools bug: N/A (works fine with existing tools)
>
> Status in other browsers is:
>
>   * EdgeHTML: Doesn't parse the value at all.
>   * Safari: Supports the value as intended, by using the platform theme.
>   * Chromium: Parses the value, and outputs a fixed-width outline in
> chromium with a slight radius (at least on Linux and Windows, not sure
> about Mac). It respects outline-color which is a bit weird.
>   * Epiphany: Uses 1px dotted outline instead, with some weird effects
> if you change outline-width. Also respects outline-color.
>
> Without this patch, our current behavior is that we just treat auto as
> solid, respecting width (unlike other browsers), and color (unlike
> Safari, but like Chrome).
>
> With this patch our behavior would match Safari's, effectively.
>
> web-platform-tests: This is pretty hard to test in WPT, as it is
> platform and browser-dependent behavior.
>
> Secure contexts: This is not restricted to secure contexts, like other
> CSS features, and features that other browsers ship in insecure contexts.
>
> Addendum:
>
> I want to use the auto value as the default for our form controls, so
> that I can fix bugs like [1] by omitting its rendering for themed form
> controls.
>
> That is not _theoretically_ blocked by this change, I guess, as we have
> the auto value in the computed style anyway, but it'd be nice to show
> the native outline even if the form control is not themed. Also falling
> back to solid for form controls may not be great (other focused things
> use dotted outlines).
>
> If we find any compat issues / developer or user complaints due to this
> (specially on Windows / Linux), we should probably reconsider and take
> an approach more similar to Chromium / Epi's and remove the
> widget-specific implementations. But I think it'd be nice to do what the
> feature was intended for, I think.
>
> That being said, given the (clearly sub-standard) compat situation, let
> me know if you think it's better to keep it turned this on only for
> Nightly / Beta for a release or two. We're early in the cycle but...
>
> If you find any rendering problems with them or pages looking worse
> because of them, please file a bug blocking bug 1031664 and needinfo me
> or such.
>
> Thank you,
>
>   -- Emilio
>
> [1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1311444
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: native rendering of outline-style: auto

2020-01-16 Thread Emilio Cobos Álvarez 

On 1/16/20 8:35 AM, Frederik Braun wrote:

How much of this platform-dependent rendering is web observable?
If yes, I guess we'll need an escape hatch for Resist Fingerprinting Mode.


This doesn't feel particularly worse than our platform-dependent form 
controls. Height of  is different in different platforms for 
example, and you can query it trivially from script to make a guess.


I _think_ you could observe outline overflow areas from JS without much 
trouble.


I'm not aware of any RFP mitigations for form controls and such, though 
if there are some, or plans to add some then I'm happy to hook 
outline-style: auto into them or what not.


 -- Emilio



Emilio Cobos Álvarez mailto:emi...@mozilla.com>> 
schrieb am Mi., 15. Jan. 2020, 19:27:


Hi,

In bug 1031664 I plan to enable the themed rendering of
outline-style: auto.

Standard: https://www.w3.org/TR/css-ui/#outline-style
 (sorry for the TR
version, but I have problems to access the current draft without
building it locally :/)

Platform coverage: Linux, Mac, Windows

Preference: layout.css.outline-style-auto.enabled

DevTools bug: N/A (works fine with existing tools)

Status in other browsers is:

   * EdgeHTML: Doesn't parse the value at all.
   * Safari: Supports the value as intended, by using the platform
theme.
   * Chromium: Parses the value, and outputs a fixed-width outline in
chromium with a slight radius (at least on Linux and Windows, not sure
about Mac). It respects outline-color which is a bit weird.
   * Epiphany: Uses 1px dotted outline instead, with some weird effects
if you change outline-width. Also respects outline-color.

Without this patch, our current behavior is that we just treat auto as
solid, respecting width (unlike other browsers), and color (unlike
Safari, but like Chrome).

With this patch our behavior would match Safari's, effectively.

web-platform-tests: This is pretty hard to test in WPT, as it is
platform and browser-dependent behavior.

Secure contexts: This is not restricted to secure contexts, like other
CSS features, and features that other browsers ship in insecure
contexts.

Addendum:

I want to use the auto value as the default for our form controls, so
that I can fix bugs like [1] by omitting its rendering for themed form
controls.

That is not _theoretically_ blocked by this change, I guess, as we have
the auto value in the computed style anyway, but it'd be nice to show
the native outline even if the form control is not themed. Also falling
back to solid for form controls may not be great (other focused things
use dotted outlines).

If we find any compat issues / developer or user complaints due to this
(specially on Windows / Linux), we should probably reconsider and take
an approach more similar to Chromium / Epi's and remove the
widget-specific implementations. But I think it'd be nice to do what
the
feature was intended for, I think.

That being said, given the (clearly sub-standard) compat situation, let
me know if you think it's better to keep it turned this on only for
Nightly / Beta for a release or two. We're early in the cycle but...

If you find any rendering problems with them or pages looking worse
because of them, please file a bug blocking bug 1031664 and needinfo me
or such.

Thank you,

   -- Emilio

[1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1311444

___
dev-platform mailing list
dev-platform@lists.mozilla.org 
https://lists.mozilla.org/listinfo/dev-platform



___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement: AVIF (AV1 Image Format) support

2020-01-16 Thread Jon Bauman 
This will use the same library for decoding. The tentative plan is to use a
similar approach and do the decoding itself in a remote process (RDD), but
this will be the first image format (as opposed to audio/video) to use the
media decoding stack, so plans are still somewhat fluid.

On Wed, Jan 15, 2020 at 1:05 PM Tom Ritter  wrote:

> We sandboxed av1 into its own process for security concerns.
> Presumably this is using the same or a similar library; so do we have
> plans for mitigating the same concern before rolling out to users?
>
> -tom
>
> On Wed, Jan 15, 2020 at 6:28 PM Jon Bauman  wrote:
> >
> > AVIF is an image format based on the AV1 video codec [1] from the
> Alliance
> > for Open Media [2]. AV1 support shipped in release 55 [3] and is
> currently
> > supported in Chrome, but not Safari. There is an open issue for AVIF
> > support in Chrome [4].
> >
> > Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=avif
> >
> > Standard: https://aomediacodec.github.io/av1-avif/
> >
> > Platform coverage: All
> >
> > Restricted to secure contexts: No. There's currently no mechanism to
> > enforce this for image formats, but we can revisit this before enabling
> > this by default. The same goes for CORS.
> >
> > Target Release: 76
> >
> > Preference behind which this will be implemented: image.avif.enabled,
> > turned off by default.
> >
> > [1] https://en.wikipedia.org/wiki/AV1
> > [2] https://aomedia.org/
> > [3] https://bugzilla.mozilla.org/show_bug.cgi?id=av1
> > [4] https://bugs.chromium.org/p/chromium/issues/detail?id=960620
> > ___
> > dev-platform mailing list
> > dev-platform@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform