Re: Intent to ship: CSS 'display:block ruby'

[Mats Palmgren]

On 8/14/19 9:51 PM, David Burns wrote:

Are there any web platform tests for this ...

Yes, it seems I missed to include this item in my original email:

Tests: WPT and other tests were added.


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

Re: Intent to ship: CSS 'display:block ruby'

[David Burns]

Are there any web platform tests for this or will they be added as part of
this work?

David

On Wed, 14 Aug 2019 at 17:38, Mats Palmgren  wrote:

> Summary:
> Add support for 'display:block ruby' which creates a block box
> with a ruby box inside it.
>
> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1557825
>
> Standard: https://drafts.csswg.org/css-display/#the-display-properties
>
> Platform coverage: All
>
> Estimated or target release: v70
>
> Preference: None
>
> DevTools: The new value has been added to the auto-completion menu
> for the 'display' property
>
> Other browsers: Other UAs don't support this yet, AFAIK.
>
>
> /Mats
> ___
> 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: multi-keyword values on the CSS 'display' property

[Boris Zbarsky]

On 8/14/19 12:37 PM, Mats Palmgren wrote:

This first patch set adds support for the new syntax
only, but no new box types (I'll add those separately in a bit).


In general, it seems like we should think about how to integrate this 
stuff into layout in a better way than anonymous boxes everywhere.  In 
particular, we may want to consider changing nsIFrame such that we have 
it point to a "how I look to my parent" class and a "how I manage my 
kids or paint myself" class and be able to mix and match those.  That's 
out of scope for this intent, but if we plan to start adding various 
implementations of multiple keywords for display this seems like it 
would be the way to go about it...



Other browsers: Other UAs don't support this yet, AFAIK.


Do they plan to?

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

Intent to ship: CSS 'display:block ruby'

[Mats Palmgren]

Summary:
Add support for 'display:block ruby' which creates a block box
with a ruby box inside it.

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

Standard: https://drafts.csswg.org/css-display/#the-display-properties

Platform coverage: All

Estimated or target release: v70

Preference: None

DevTools: The new value has been added to the auto-completion menu
for the 'display' property

Other browsers: Other UAs don't support this yet, AFAIK.


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

Intent to ship: CSS 'display:inline list-item' and 'display:inline flow-root list-item'

[Mats Palmgren]

Summary:
Add support for 'display:inline list-item', which creates an inline box
with a ::marker box inside it, and 'display:inline flow-root list-item',
which creates an inline-block with a ::marker (inside or outside).

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

Standard: https://drafts.csswg.org/css-display/#list-items

Platform coverage: All

Estimated or target release: v70

Preference: None

DevTools: The new values have been added to the auto-completion menu
for the 'display' property.

Tests: WPT and other tests were added.

Other browsers: Other UAs don't support this yet, AFAIK.


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

Intent to ship: multi-keyword values on the CSS 'display' property

[Mats Palmgren]

Summary:
Add support for multi-keyword values on the CSS 'display' property.
The spec splits this property into three parts: an outside part,
an inside part, and a list-item part so the author can specify them
separately.  This first patch set adds support for the new syntax
only, but no new box types (I'll add those separately in a bit).
So, this bug just adds a bunch of synonyms for exist values we
already support, so we can now write "block flow list-item" or
"block list-item" etc instead of just "list-item".  Keywords can
be given in arbitrary order, so there are now a lot of valid
permutations for the same computed value.  The values are
serialized to their shortest form as usual though.

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

Standard: https://drafts.csswg.org/css-display/#the-display-properties

Platform coverage: All

Estimated or target release: v70

Preference: None

DevTools: No change

Tests: WPT and other tests were added.

Other browsers: Other UAs don't support this yet, AFAIK.


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

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

[Dão Gottwald]

Are we going to remove support for this pref in a subsequent release?

Am Mo., 12. Aug. 2019 um 10:05 Uhr schrieb Johann Hofmann <
jhofm...@mozilla.com>:

> In desktop Firefox 70, we intend to remove Extended Validation (EV)
> indicators from the identity block (the left hand side of the URL bar which
> is used to display security / privacy information). We will add additional
> EV information to the identity panel instead, effectively reducing the
> exposure of EV information to users while keeping it easily accessible.
>
> Before:
>
>
> After:
>
>
> The effectiveness of EV has been called into question numerous times over
> the last few years, there are serious doubts whether users notice the
> absence of positive security indicators and proof of concepts have been 
> pitting
> EV against domains  for
> phishing.
>
> More recently, it has been shown  that EV
> certificates with colliding entity names can be generated by choosing a
> different jurisdiction. 18 months have passed since then and no changes
> that address this problem have been identified.
>
> The Chrome team recently removed EV indicators from the URL bar in Canary
> and announced their intent to ship this change in Chrome 77
> .
> Safari is also no longer showing the EV entity name instead of the domain
> name in their URL bar, distinguishing EV only by the green color. Edge is
> also no longer showing the EV entity name in their URL bar.
>
>
>
> On our side a pref for this
> (security.identityblock.show_extended_validation) was added in bug 1572389
>  (thanks :evilpie
> for working on it!). We're planning to flip this pref to false in bug
> 1572936 .
>
> Please let us know if you have any questions or concerns,
>
> Wayne & Johann
> ___
> firefox-dev mailing list
> firefox-...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Removing --enable-shared-js [Was: Rust and --enable-shared-js]

[Henri Sivonen]

On Tue, Aug 13, 2019 at 2:18 PM Lars Hansen  wrote:
> Cranelift should be genuinely optional until further notice; to my 
> knownledge, no near-term product work in Firefox or SpiderMonkey depends on 
> Cranelift.  Cranelift is present in Nightly but (so far as I can tell) not in 
> Release. It can be disabled in the JS shell by configuring with 
> --disable-cranelift, and I just tested that this works.  To the extent there 
> is other Rust code in SpiderMonkey it should not, so far as I know, depend on 
> the presence of Cranelift.  It also seems to me that we should be able to use 
> Rust in SpiderMonkey independently of whether Cranelift is there, so if that 
> does not work it ought to be fixed.

Thanks. That makes sense to me.

The present state (now that
https://bugzilla.mozilla.org/show_bug.cgi?id=1572364 has landed) is
that when built as part of libxul, SpiderMonkey can use Rust code
(jsrust_shared gets built) regardless of whether Cranelift is enabled.
However, when SpiderMonkey is built outside libxul, SpiderMonkey can
use Rust code (jsrust_shared gets built) only if Cranelift is enabled.
I've filed https://bugzilla.mozilla.org/show_bug.cgi?id=1573098 to
change that.

(The actual addition of non-Cranelift Rust code of interest to
jsrust_shared hasn't landed yet.)

-- 
Henri Sivonen
hsivo...@mozilla.com
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform