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
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
-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
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
It does not represent `<length> | <percentage>`, but `<length-percentage>`, so
`LengthOrPercentage` is not the right name.
This patch is totally autogenerated using:
rg 'LengthOrPercentage' servo | cut -d : -f 1 | sort | uniq > files
for file in $(cat files); do sed -i "s#LengthOrPercentage#LengthPercentage#g" $file; done
Differential Revision: https://phabricator.services.mozilla.com/D15812
This is a first step to share LengthOrPercentage representation between Rust and
Gecko.
We need to preserve whether the value came from a calc() expression, for now at
least, since we do different things depending on whether we're calc or not right
now. See https://github.com/w3c/csswg-drafts/issues/3482 and dependent bugs for
example.
That means that the gecko conversion code needs to handle calc() in a bit of an
awkward way until I change it to not be needed (patches for that incoming in the
next few weeks I hope).
I need to add a hack to exclude other things from the PartialEq implementation
because the new conversion code is less lossy than the old one, and we relied on
the lousiness in AnimationValue comparison (in order to start transitions and
such, in [1] for example).
I expect to remove that manual PartialEq implementation as soon as I'm done with
the conversion.
The less lossy conversion does fix a few serialization bugs for animation values
though, like not loosing 0% values in calc() when interpolating lengths and
percentages, see the two modified tests:
* property-types.js
* test_animation_properties.html
Differential Revision: https://phabricator.services.mozilla.com/D15793
We should let block-size/min-block-size/max-block-size accept keywords as the
initial value, just like width in vertical writing mode or height in horizontal
writing mode.
Differential Revision: https://phabricator.services.mozilla.com/D14320
This ended up not being so small of a patch as I'd have thought, since it
propagated a bit. But most of it is mechanical. Interesting part is
NonNegativeNumberOrPercentage and the actual uses of the NonNegative stuff and
during parsing.
This looks like it'd fix a few correctness issues during interpolation for all
the types except for BorderRadius and co (which handled it manually).
I should write tests for those in a different patch.
Differential Revision: https://phabricator.services.mozilla.com/D14673
Basically, we rewrite the type of generics::transform::Translate and its
ToCss to match the spec. Besides, we always serialize Translate by servo,
so we could drop a lot of duplicated code.
Differential Revision: https://phabricator.services.mozilla.com/D11206
With this change, all of Chrome, Edge, Firefox, and Safari serialize
background-size by omitting the second "auto" if the value is "auto
auto". Other keywords are still repeated.
Differential Revision: https://phabricator.services.mozilla.com/D10446
Most of types just derive it using proc_macro directly. Some of value
types need manual impl.
In my current plan, this new trait will be used in bug 1434130 to expose
values as well.
Bug: 1455576
Reviewed-by: emilio
MozReview-Commit-ID: LI7fy45VkRw
