Re: Intent to Prototype: text-decoration-skip-ink

[Daniel Holbert]

On Wednesday, August 7, 2019 at 12:18:16 PM UTC-7, Tom Schuster wrote:
> Very cool, I have been looking forward to this. I hope we can enable
> this for links by default at some point, like Chrome.

That's the plan!

The new property here, "text-decoration-skip-ink", has the unusual distinction 
of being a CSS feature where the property's *default value* ("auto") is the 
value that triggers the new behavior.

So once we pref on support for the property, then the default behavior for all 
text-decorations will change -- though sites can request the old behavior by 
specifying "text-decoration-skip-ink: none" (which turns on the 
"legacy"/current behavior).
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to Prototype: text-decoration-skip-ink

[Tom Schuster]

Very cool, I have been looking forward to this. I hope we can enable
this for links by default at some point, like Chrome.

On Wed, Aug 7, 2019 at 12:14 AM Charlie Marlow  wrote:
>
> Summary: text-decoration-skip-ink is a CSS feature that makes underlines and 
> overlines skip around the text, instead of painting behind it. There is a 
> picture of this effect on the standards link.
>
> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1411922 
> 
>
> Standard: 
> https://drafts.csswg.org/css-text-decor-4/#text-decoration-skip-ink-property 
> 
>
> Platform coverage: This will be available on all platforms using Gecko.
>
> Preference: It will be preffed off by default under 
> layout.css.text-decoration-skip-ink.enabled
>
> DevTools bug: This is a minor, cosmetic visual feature with no clear 
> opportunity for DevTools integration.
>
> Other browsers: It works in both Chrome and Safari.
>
> Web-platform-tests: Initial reftests will be landed with the first patch, 
> they are here: https://phabricator.services.mozilla.com/D40707 
> 
>
> Secure contexts: No, it is not restricted to secure contexts in other 
> browsers, so for compatibility we don’t restrict it either.
>
>
> Charlie Marlow
> ___
> 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: Removing --enable-shared-js [Was: Rust and --enable-shared-js]

[Henri Sivonen]

On Tue, May 28, 2019 at 3:16 AM Mike Hommey  wrote:
>
> On Tue, May 21, 2019 at 10:32:20PM -0400, Boris Zbarsky wrote:
> > On 5/21/19 9:55 PM, Mike Hommey wrote:
> > > Considering this has apparently been broken for so long, I guess nobody
> > > will object to me removing the option for Gecko builds?
> >
> > It's probably fine, yeah...
>
> Now removed on autoland via bug 1554056.

Thanks.

It appears that building jsrust_shared is still conditional on
ENABLE_WASM_CRANELIFT. How optional is ENABLE_WASM_CRANELIFT in
practice these days? Is it genuinely optional for Firefox? Is it
genuinely optional for standalone SpiderMonkey? If it is, are we OK
with building without ENABLE_WASM_CRANELIFT having other non-Cranelift
effects on SpiderMonkey performance (e.g. turning off SIMD for some
operations) or on whether a particular string conversion is available
in jsapi.h?

I'm trying to understand the implication of Cranelift being optional
for other Rust code in SpiderMonkey. I'd like to add Rust-backed
SIMD-accelerated Latin1ness checking and UTF-8 validity checking to
SpiderMonkey and Rust-backed conversion from JSString to UTF-8 in
jsapi.h, and my understanding from All Hands was that adding these
things would be OK, since SpiderMonkey already depends on Rust.

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

Re: Static prefs are now defined in a YAML file

[Nicholas Nethercote]

On Thu, 18 Jul 2019 at 14:20, Nicholas Nethercote 
wrote:

> Greetings,
>
> I just landed the patches in bug 1564724. As a result, static prefs are no
> longer defined in modules/libpref/init/StaticPrefList.h. They are now
> defined in modules/libpref/init/StaticPrefList.yaml, from which a
> StaticPrefList.h file is generated. The format is explained in a comment at
> the top of StaticPrefList.yaml.
> [...]
> The change will also allow some larger benefits in the immediate future.
> - Rust access to static prefs can become easier (bug 1563555
> ).
>

This has now landed. If you want to access a mirrored static pref from Rust
code, do the following.
- Add a `rust: true` field to the definition in StaticPrefList.yaml.
- Use the `pref!` macro from the `static_prefs` crate, e.g. `let
foo_bar_baz = static_prefs::pref!("foo.bar-baz");`

You can see real-world examples in Stylo.

In other libpref news, docs are now available here
.
Note particularly the "Guidelines" section, which discusses how we have too
many prefs (several thousand!) and has some ideas about which kinds of
prefs might be removable (hint, hint).

Finally, we have a long-running project to convert all VarCache prefs to
static prefs. See here

for a description of the benefits. Once all VarCache prefs have been
converted, we'll be able to do some nice clean-ups within libpref. There
are still roughly 200 prefs that need converting, and most conversions are
straightforward. Any help would be welcome. Instructions are here
. We don't want
any duplication of effort, so please use the tracking bug
 to see what others
are doing and communicate what you are doing. I am happy to review any
patches. Thanks.

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