There are a few canvas2d-related dependencies that haven't updated, but they
only use euclid internally so that's not blocking landing the rest of the
changes.
Given the size of this patch, I think it's useful to get this landed as-is.
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
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
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 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
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
It looks like bug 1547939 will stick, given how fast the other regressions came
in for bug 1337655.
We haven't seen any regression from this, and it seems unlikely that we'd want
this code back.
This blocks further improvements to the style system. Simplifying this code
allows me to remove all the conversion code for gradients.
Let me know if you think it's premature and I'm happy to wait, but I really want
to see this code gone :)
Differential Revision: https://phabricator.services.mozilla.com/D33820
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 will save us some time from figuring out what's the best thing to do in
bug 1552587, so that other patches I have in flight (mainly bug 1552708) can
land, since we cannot add a single byte to nsStyleDisplay right now otherwise.
The code removed here is well isolated and not that complicated, so it seems to
me that should be easy to bring back should we have an emergency (and I commit
to doing that while preserving the nsStyleDisplay size limit if we need to :)).
Differential Revision: https://phabricator.services.mozilla.com/D32026
This avoids the expensive conversion, and cleans up a bunch.
Further cleanup is possible, just not done yet to avoid growing the patch even
more.
Differential Revision: https://phabricator.services.mozilla.com/D30748
This enables destructors for tagged unions in cbindgen, implemented in:
* https://github.com/eqrion/cbindgen/pull/333
Which allow us to properly generate a destructor for the cbindgen-generated
StyleBasicShape (which now contains an OwnedSlice).
For now, we still use the glue code to go from Box<BasicShape> to
UniquePtr<BasicShape>. But that will change in the future when we generate even
more stuff and remove all the glue.
I could add support for copy-constructor generation to cbindgen for tagged
enums, but I'm not sure if it'll end up being needed, and copy-constructing
unions in C++ is always very tricky.
Differential Revision: https://phabricator.services.mozilla.com/D29769
The previous commit removed the dependence on the discriminant value, so we
don't need to keep discriminants different from text-align anymore.
Differential Revision: https://phabricator.services.mozilla.com/D29361
They're only used in forms.css, and only for some anonymous content, which are
not content-accessible in the first place.
The only place where this could be exposed is calling
getComputedStyle(input, "::placeholder"), so I think this should be pretty safe,
but I've added a pref just in case.
While at it, also derive the Parse implementation. Less code is better.
Differential Revision: https://phabricator.services.mozilla.com/D25118
I feel a bit weird for using LenghtPercentageOrAuto to implement LengthOrAuto,
but I don't think much other code will use it so it seemed a bit better to me.
Differential Revision: https://phabricator.services.mozilla.com/D21863
This also adopts the resolution from [1] while at it, making letter-spacing
compute to a length, serializing 0 to normal rather than keeping normal in the
computed value, which matches every other engine.
This removes the SMIL tests for percentages from letter-spacing since
letter-spacing does in fact not support percentages, so they were passing just
by chance.
[1]: https://github.com/w3c/csswg-drafts/issues/1484
Differential Revision: https://phabricator.services.mozilla.com/D21850
This may or may not be part of the plan to get rid of nsCSSValue ;)
Option is not usable via FFI, and they should not be needed (we should be
following the shortest serialization principle instead). These patches also do
that, which matches the other transform properties. I think that slight change
is fine, if we can make it work, and consistent with other properties.
Alternative is adding more TransformOperation variants or such, which I rather
not do.
Differential Revision: https://phabricator.services.mozilla.com/D21862
Instead of storing them as LengthPercentage | Number, always store as
LengthPercentage, and use the unitless length quirk to parse numbers instead.
Further cleanups to use the rust representation can happen as a followup, which
will also get rid of the boolean argument (since we can poke at the rust length
itself). That's why I didn't bother to convert it to an enum class yet.
Differential Revision: https://phabricator.services.mozilla.com/D21804
