We clamp earlier (parse time rather than computed value time), but that's the
only behavior change, which I think doesn't really matter.
Differential Revision: https://phabricator.services.mozilla.com/D35198
--HG--
extra : moz-landing-system : lando
This needs https://github.com/eqrion/cbindgen/pull/362, but I expect it to be
uncontroversial. I'll add a patch to this bug when it's merged to update it.
cbindgen historically didn't include these, but it turns out to be pretty useful
to generate constants for the style crate (since the binding crate is
`servo/ports/geckolib`).
An alternative is to get a completely different cbindgen-generated header for
these, but that seems a bit wasteful. This generates the constants with the
Style prefix (so we'll get `StyleMAX_GRID_LINE` for example), which is very
ugly. But we probably want to eventually stop using the Style prefix and use a
namespace instead, plus it's trivial to do `auto kMaxLine = StyleMAX_GRID_LINE`,
for example, so it's probably not a huge deal.
Another alternative would be to use associated consts, which _are_ generated by
cbindgen. Something like:
```
struct GridConstants([u8; 0]);
impl GridConstants {
const MAX_GRID_LINE: i32 = 10000;
}
```
Which would yield something like:
```
static const int32 StyleGridConstants_MAX_GRID_LINE = 10000;
```
I'm not sure if you find it preferrable, but I'm also happy to change it in a
follow-up to use this.
We need to fix a few manual C++ function signature definitions to match the C++
declaration.
Differential Revision: https://phabricator.services.mozilla.com/D35197
--HG--
extra : moz-landing-system : lando
Option<> is not FFI-safe, so if we want to use the same representation
everywhere we need to get rid of it. This also makes it take the same amount of
memory as the C++ representation, and it's not very complex, I'd think.
Differential Revision: https://phabricator.services.mozilla.com/D35195
--HG--
extra : moz-landing-system : lando
We clamp earlier (parse time rather than computed value time), but that's the
only behavior change, which I think doesn't really matter.
Differential Revision: https://phabricator.services.mozilla.com/D35198
--HG--
extra : moz-landing-system : lando
This needs https://github.com/eqrion/cbindgen/pull/362, but I expect it to be
uncontroversial. I'll add a patch to this bug when it's merged to update it.
cbindgen historically didn't include these, but it turns out to be pretty useful
to generate constants for the style crate (since the binding crate is
`servo/ports/geckolib`).
An alternative is to get a completely different cbindgen-generated header for
these, but that seems a bit wasteful. This generates the constants with the
Style prefix (so we'll get `StyleMAX_GRID_LINE` for example), which is very
ugly. But we probably want to eventually stop using the Style prefix and use a
namespace instead, plus it's trivial to do `auto kMaxLine = StyleMAX_GRID_LINE`,
for example, so it's probably not a huge deal.
Another alternative would be to use associated consts, which _are_ generated by
cbindgen. Something like:
```
struct GridConstants([u8; 0]);
impl GridConstants {
const MAX_GRID_LINE: i32 = 10000;
}
```
Which would yield something like:
```
static const int32 StyleGridConstants_MAX_GRID_LINE = 10000;
```
I'm not sure if you find it preferrable, but I'm also happy to change it in a
follow-up to use this.
We need to fix a few manual C++ function signature definitions to match the C++
declaration.
Differential Revision: https://phabricator.services.mozilla.com/D35197
--HG--
extra : moz-landing-system : lando
Option<> is not FFI-safe, so if we want to use the same representation
everywhere we need to get rid of it. This also makes it take the same amount of
memory as the C++ representation, and it's not very complex, I'd think.
Differential Revision: https://phabricator.services.mozilla.com/D35195
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : rebase_source : 13cf215aeb713e188103ef0cd04d094aa150853e
Correctly handle clamping to 1 behavior of grayscale(),
invert(), opacity() and sepia().
Differential Revision: https://phabricator.services.mozilla.com/D35509
--HG--
extra : moz-landing-system : lando
This patch invalidates the style for `::selection`, which will restore the behavior before the regression.
However, it's still not quite correct, because repaint is not triggered. Given that `::selection` requires some major change to implement https://github.com/w3c/csswg-drafts/issues/2474, we can address this problem later.
Differential Revision: https://phabricator.services.mozilla.com/D35305
--HG--
extra : moz-landing-system : lando
This patch produces the following serialization:
```
input | computed value
------------------------------
1. "auto" "auto"
2. "auto auto" "auto"
3. "15px auto" "15px"
4. "15px" "15px"
```
i.e. If the second value is 'auto', then it's omitted from our serialization,
because it's implied.
Besides, we update the wpt to address this spec issue:
https://github.com/w3c/csswg-drafts/issues/2574
Differential Revision: https://phabricator.services.mozilla.com/D35510
--HG--
extra : moz-landing-system : lando
In particular:
* trait objects without an explicit `dyn` are deprecated
* `...` range patterns are deprecated
I think these shouldn't really warn by default and should be clippy / opt-in
lints, but anyway, doesn't hurt.
Differential Revision: https://phabricator.services.mozilla.com/D35135
--HG--
extra : moz-landing-system : lando
The style system already atomizes all CustomIdent values, which means that we're
just wasting memory and CPU by doing string copies all over the place.
This patch fixes it. This also simplifies further changes to use as much of the
rust data structures as possible.
I had to switch from nsTHashtable to mozilla::HashTable because the former
doesn't handle well non-default-constructible structs (like NamedLine, which
now has a StyleAtom, which is not default-constructible).
Differential Revision: https://phabricator.services.mozilla.com/D35119
--HG--
extra : moz-landing-system : lando
Right now we do a lot of useless string copying. In order to avoid transcoding
to utf-16 during layout, make sure to use nsCString at a few related places.
I may revisit this since we're storing other line names as atoms in some places.
So it may be better to just use atoms everywhere.
But that'd be a different patch either way.
Depends on D35116
Differential Revision: https://phabricator.services.mozilla.com/D35117
--HG--
extra : moz-landing-system : lando
Should not serialize default shape-outside circle() function radius.
The ToCss impl of Circle and Ellipse turn out to be identical in specified and computed value, thus move them to generics.
Differential Revision: https://phabricator.services.mozilla.com/D35183
--HG--
extra : moz-landing-system : lando
Should not serialize default shape-outside circle() function radius.
The ToCss impl of Circle and Ellipse turn out to be identical in specified and computed value, thus move them to generics.
Differential Revision: https://phabricator.services.mozilla.com/D35183
--HG--
extra : moz-landing-system : lando
I want to enable in Nightly to evaluate (in the medium term) shipping it without
the part forwarding, once the cascade order and importance issues are fixed, and
that we pass all the tests that don't involve forwarding.
That is, I want to monitor whether having ::part() causes compat issues or not.
Depends on D32648
Differential Revision: https://phabricator.services.mozilla.com/D32649
--HG--
extra : moz-landing-system : lando
This should make all the pieces come together.
Note that we don't need to look at the snapshot for ::part() for now (other than
when selector-matching normally) because I decided to just restyle the element
for now when the part attribute changes.
::part() can't affect descendants anyway (as long as we don't do the forwarding
stuff), and eager pseudo-elements are handled during the normal element restyle,
so it seems to me that adding all the complexity that we have for classes to
part may not be worth it at least yet.
Depends on D32647
Differential Revision: https://phabricator.services.mozilla.com/D32648
--HG--
extra : moz-landing-system : lando
I still haven't implemented each_part(), so this will do nothing yet.
The cascade order stuff is fishy, I know, and I'll fix in a followup if it's
fine with you. I moved the sorting of the rules to rule_collector, since it
seemed to me it was better that way that duplicating the code, and those
SelectorMap functions only have a single caller anyway.
Depends on D32646
Differential Revision: https://phabricator.services.mozilla.com/D32647
--HG--
extra : moz-landing-system : lando
Unlike for :host() or ::slotted(), or regular rules, we don't need a whole
SelectorMap<>, so gotta make the code a bit more generic.
Depends on D32645
Differential Revision: https://phabricator.services.mozilla.com/D32646
--HG--
extra : moz-landing-system : lando
Andreea Pavel
Charlie Marlow
Emilio Cobos Álvarez
Cameron McCormack
Mihai Alexandru Michis
Connor Brewster
Nicholas Nethercote
Alastor Wu
Dorel Luca
violet
Boris Chiou
Noemi Erli