We are always able to produce an x height, but depending on whether the
glyph exists, we sometimes can't produce a zero glyph width.
Differential Revision: https://phabricator.services.mozilla.com/D23424
It's not very easy to understand on its current state, and it causes subtle bugs
like bug 1533654.
It could be simpler if we centralized where the interactions between properties
are handled. This patch does this.
This patch also changes how MathML script sizes are tracked when scriptlevel
changes and they have relative fonts in between.
With this patch, any explicitly specified font-size is treated the same (being a
scriptlevel boundary), regardless of whether it's either an absolute size, a
relative size, or a wide keyword.
Relative lengths always resolve relative to the constrained size, which allows
us to avoid the double font-size computation, and not give up on sanity with
keyword font-sizes.
I think given no other browser supports scriptlevel it seems like the right
trade-off.
Differential Revision: https://phabricator.services.mozilla.com/D23070
The only fishy bit is the animation stuff. In particular, there are two places
where we just mint the revert behavior:
* When serializing web-animations keyframes (the custom properties stuff in
declaration_block.rs). That codepath is already not sound and I wanted to
get rid of it in bug 1501530, but what do I know.
* When getting an animation value from a property declaration. At that point
we no longer have the CSS rules that apply to the element to compute the
right revert value handy. It'd also use the wrong style anyway, I think,
given the way StyleBuilder::for_animation works.
We _could_ probably get them out of somewhere, but it seems like a whole lot
of code reinventing the wheel which is probably not useful, and that Blink
and WebKit just cannot implement either since they don't have a rule tree,
so it just doesn't seem worth the churn.
The custom properties code looks a bit different in order to minimize hash
lookups in the common case. FWIW, `revert` for custom properties doesn't seem
very useful either, but oh well.
Differential Revision: https://phabricator.services.mozilla.com/D21877
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
We really only have two sets of prefs, one for chrome-like documents
(stuff in chrome docshells + chrome-origin images), and one for the rest.
Differential Revision: https://phabricator.services.mozilla.com/D20946
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
The euclid size is not really used for anything. Also rename it to Size2D to
avoid cbindgen conflicts with values::length::Size.
Differential Revision: https://phabricator.services.mozilla.com/D20959
I want to do this so that I can get rid of Either<>. The reasons for getting rid
of either are multiple:
* It doesn't generate as nice C++ code using cbindgen.
* It isn't that nice to use either from Rust.
* cbindgen has bugs with zero-sized types.
I started using this for ColorOrAuto and a few others, for now.
Differential Revision: https://phabricator.services.mozilla.com/D19844
-moz-tab-size, border-image-outset and border-image-slice.
This is not a particularly interesting patch, just removes some code. We can
remove way more code when a few related properties are also ported.
Differential Revision: https://phabricator.services.mozilla.com/D19825
Really sorry for the size of the patch :(
Only intentional behavior change is in the uses of HasLengthAndPercentage(),
where it's easier to do the right thing. The checks that used to check for
(IsCalcUnit() && CalcHasPercentage()) are wrong since bug 957915.
Differential Revision: https://phabricator.services.mozilla.com/D19553
This patch:
* Makes LengthPercentageOrAuto generic, and removes a bunch of code fo
LengthPercentageOrNone, which was used only for servo and now can use the
normal MaxLength (with a cfg() guard for the ExtremumLength variant).
* Shrinks MaxLength / MozLength's repr(C) reperesentation by reducing enum
nesting. The shrinking is in preparation for using them from C++ too, though
that'd be a different bug.
* Moves NonNegative usage to the proper places so that stuff for them can be
derived.
I did this on top of bug 1523071 to prove both that it could be possible and
that stuff wasn't too messy. It got a bit messy, but just because of a bug I
had fixed in bindgen long time ago already, so this updates bindgen's patch
version to grab a fix instead of ugly workarounds :)
Differential Revision: https://phabricator.services.mozilla.com/D17762
Also for the intersection observer root margin, since it was easier to fix it
up and clean it up than not doing it.
This is the first big step to get rid of nscoord. It duplicates a bit of logic
in nsLayoutUtils since for now max/min-width/height are still represented with
nsStyleCoord, but I think I prefer to land this incrementally.
I didn't add helpers for the physical accessors of the style rect sides that
nsStyleSides has (top/bottom/left/right) since I think we generally should
encourage the logical versions, but let me know if you want me to do that.
Differential Revision: https://phabricator.services.mozilla.com/D17739
