These are gated by the same layout.css.font-tech.enabled pref as the
closely-related `tech()` function for the @font-face src descriptor;
once the spec questions are settled, we should enable them all together.
Differential Revision: https://phabricator.services.mozilla.com/D155359
These are gated by the same layout.css.font-tech.enabled pref as the
closely-related `tech()` function for the @font-face src descriptor;
once the spec questions are settled, we should enable them all together.
Differential Revision: https://phabricator.services.mozilla.com/D155359
There are a couple of current issues/discussions that may lead to a change in the set of supported keywords, so we may want to hold back a little on actually shipping this.
- In https://github.com/w3c/IFT/pull/113, the WebFonts WG proposes several new incremental-* keywords (and maybe implies dropping the currently-defined incremental?)
- In https://github.com/w3c/csswg-drafts/issues/7633, I just proposed renaming the feature-* keywords to features-* (plural) for better readability; I'd like to see a decision on that before we ship this to release.
Differential Revision: https://phabricator.services.mozilla.com/D155458
Now that the style system has keywords for this, we don't need to define them in gfx
but can just use the enum directly. (No functional change, just code simplification.)
Depends on D154237
Differential Revision: https://phabricator.services.mozilla.com/D154238
This aligns with CSS Fonts 4 (rather than Fonts 3) and with behavior in other browsers;
I don't expect any significant breakage, given that specifying multiple format strings
was never supported in other engines AFAIK, and never served any useful purpose.
Depends on D154234
Differential Revision: https://phabricator.services.mozilla.com/D154235
Now that the style system has keywords for this, we don't need to define them in gfx
but can just use the enum directly. (No functional change, just code simplification.)
Depends on D154237
Differential Revision: https://phabricator.services.mozilla.com/D154238
This aligns with CSS Fonts 4 (rather than Fonts 3) and with behavior in other browsers;
I don't expect any significant breakage, given that specifying multiple format strings
was never supported in other engines AFAIK, and never served any useful purpose.
Depends on D154234
Differential Revision: https://phabricator.services.mozilla.com/D154235
Now that the style system has keywords for this, we don't need to define them in gfx
but can just use the enum directly. (No functional change, just code simplification.)
Differential Revision: https://phabricator.services.mozilla.com/D154238
This aligns with CSS Fonts 4 (rather than Fonts 3) and with behavior in other browsers;
I don't expect any significant breakage, given that specifying multiple format strings
was never supported in other engines AFAIK, and never served any useful purpose.
Differential Revision: https://phabricator.services.mozilla.com/D154235
Now that cbindgen and rust support const generics, it seems more simple.
This centralizes all the relevant font constants etc in rust and avoids
conversions when going from rust to C++ and vice versa.
Differential Revision: https://phabricator.services.mozilla.com/D148847
Now that cbindgen and rust support const generics, it seems more simple.
This centralizes all the relevant font constants etc in rust and avoids
conversions when going from rust to C++ and vice versa.
Differential Revision: https://phabricator.services.mozilla.com/D148847
It's much nicer.
One nice thing about this is that the new code is subject to the existing
threadedness checking, which identified that several of these should be atomic
because they're accessed off the main thread.
Differential Revision: https://phabricator.services.mozilla.com/D40792
It's much nicer.
One nice thing about this is that the new code is subject to the existing
threadedness checking, which identified that several of these should be atomic
because they're accessed off the main thread.
Differential Revision: https://phabricator.services.mozilla.com/D40792
This doesn't change the way C++ code uses static prefs. But it does slightly
change how Rust code uses static prefs, specifically the name generated by
bindgen is slightly different.
The commit also improves some comments.
Differential Revision: https://phabricator.services.mozilla.com/D35764
This doesn't clean up as much as a whole, but it's a step in the right
direction. In particular, it allows us to start using simple bindings for:
* Filters
* Shapes and images, almost. Need to:
* Get rid of the complex -moz- gradient parsing (let
layout.css.simple-moz-gradient.enabled get to release).
* Counters, almost. Need to:
* Share the Attr representation with Gecko, by not using Option<>.
* Just another variant should be enough (ContentItem::{Attr,Prefixedattr},
maybe).
Which in turn allows us to remove a whole lot of bindings in followups to this.
The setup changes a bit. This also removes the double pointer I complained about
while reviewing the shared UA sheet patches. The old setup is:
```
SpecifiedUrl
* CssUrl
* Arc<CssUrlData>
* String
* UrlExtraData
* UrlValueSource
* Arc<CssUrlData>
* load id
* resolved uri
* CORS mode.
* ...
```
The new one removes the double reference to the url data via URLValue, and looks
like:
```
SpecifiedUrl
* CssUrl
* Arc<CssUrlData>
* String
* UrlExtraData
* CorsMode
* LoadData
* load id
* resolved URI
```
The LoadData is the only mutable bit that C++ can change, and is not used from
Rust. Ideally, in the future, we could just use rust-url to resolve the URL
after parsing or something, and make it all immutable. Maybe.
I've verified that this approach still works with the UA sheet patches (via the
LoadDataSource::Lazy).
The reordering of mWillChange is to avoid nsStyleDisplay from going over the
size limit. We want to split it up anyway in bug 1552587, but mBinding gains a
tag member, which means that we were having a bit of extra padding.
One thing I want to explore is to see if we can abuse rustc's non-zero
optimizations to predict the layout from C++, but that's something to explore at
some other point in time and with a lot of care and help from Michael (who sits
next to me and works on rustc ;)).
Differential Revision: https://phabricator.services.mozilla.com/D31742
This doesn't clean up as much as a whole, but it's a step in the right
direction. In particular, it allows us to start using simple bindings for:
* Filters
* Shapes and images, almost. Need to:
* Get rid of the complex -moz- gradient parsing (let
layout.css.simple-moz-gradient.enabled get to release).
* Counters, almost. Need to:
* Share the Attr representation with Gecko, by not using Option<>.
* Just another variant should be enough (ContentItem::{Attr,Prefixedattr},
maybe).
Which in turn allows us to remove a whole lot of bindings in followups to this.
The setup changes a bit. This also removes the double pointer I complained about
while reviewing the shared UA sheet patches. The old setup is:
```
SpecifiedUrl
* CssUrl
* Arc<CssUrlData>
* String
* UrlExtraData
* UrlValueSource
* Arc<CssUrlData>
* load id
* resolved uri
* CORS mode.
* ...
```
The new one removes the double reference to the url data via URLValue, and looks
like:
```
SpecifiedUrl
* CssUrl
* Arc<CssUrlData>
* String
* UrlExtraData
* CorsMode
* LoadData
* load id
* resolved URI
```
The LoadData is the only mutable bit that C++ can change, and is not used from
Rust. Ideally, in the future, we could just use rust-url to resolve the URL
after parsing or something, and make it all immutable. Maybe.
I've verified that this approach still works with the UA sheet patches (via the
LoadDataSource::Lazy).
The reordering of mWillChange is to avoid nsStyleDisplay from going over the
size limit. We want to split it up anyway in bug 1552587, but mBinding gains a
tag member, which means that we were having a bit of extra padding.
One thing I want to explore is to see if we can abuse rustc's non-zero
optimizations to predict the layout from C++, but that's something to explore at
some other point in time and with a lot of care and help from Michael (who sits
next to me and works on rustc ;)).
Differential Revision: https://phabricator.services.mozilla.com/D31742
