Not the prettiest, but it will work, and LengthPercentage will be 12 bytes which
is pretty good (we could do better if wanted I guess):
* Au(i32) length;
* f32 percentage;
* AllowedNumericType(u8) clamping_mode;
* bool has_percentage;
* bool was_calc;
This will allow me to start moving C++ stuff to use this representation.
Differential Revision: https://phabricator.services.mozilla.com/D16929
The only reason it was on style_traits is so that they could use it from some
other crates, but Servo eventually ends up getting the value from an integer, so
may as well pass it around and do that in the end of the process anyway.
Differential Revision: https://phabricator.services.mozilla.com/D16557
Based on https://bugzilla.mozilla.org/show_bug.cgi?id=1348519#c6 and
https://github.com/w3c/csswg-drafts/issues/3201:
Currently grid-template-rows/columns interpolate “per computed value”, which
means that if the number of tracks differs, or any track changes to/from a
particular keyword value to any other value, or if a line name is added/removed
at any position, the entire track listing is interpolated as “discrete”.
But we "agree" with two more granular options:
1. Check interpolation type per track, rather than for the entire list, before
falling back to discrete. I.e. a length-percentage track can animate between
two values while an adjacent auto track flips discretely to min-content.
2. Allow discrete interpolation of line name changes independently of track
sizes.
Besides, for the repeat() function, it's complicated to support interpolation
between different repeat types (i.e. auto-fill, auto-fit) and different repeat
counts, so we always fall-back to discrete if the first parameter of repeat()
is different.
Differential Revision: https://phabricator.services.mozilla.com/D16129
This restores the previous behavior of using calc().
Note that background-position / object-position, which test this, weren't
hitting the assertion because they use another codepath.
I didn't add more extensive tests for this because it's well tested for those
two properties, and because this is legacy anyway, see the comment in the test.
I did add the assertion to the codepath those two properties hit.
Differential Revision: https://phabricator.services.mozilla.com/D16176
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
Replace LengthOrPercentage with NonNegativeLengthOrPercentage on
ShapeRadius, Circle, Ellipse. And derive ToAnimatedValue for ShapeSource and
its related types, so we clamp its interpolated results into non-negative
values. (i.e. The radius of circle()/ellipse() and the border-radius of
inset().)
Note: We may get negative values when using a negative easing function, so the
clamp is necessary to avoid the incorrect result or any undefined behavior.
Differential Revision: https://phabricator.services.mozilla.com/D14654
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
Support unprefixed min-content and max-content and treat the prefixed
version as aliases for
1. width, min-width, max-width if inline-axis is horizontal, and
2. height, min-height, max-height if inline-axis is vertical, and
3. inline-size, min-inline-size, max-inline-size, and
4. flex-basis.
Besides, update the test cases to use unprefixed max-content and
min-content.
Differential Revision: https://phabricator.services.mozilla.com/D7536
ExtremumLength is the keyword type for css sizing properties, so we
could use cbindgen.
In Gecko, we use nsStyleCoord to store the sizing properties, and use
integer values to check the enum values, so I keep the macros in nsStyleConsts.
Even though we need to convert the enum type into integer, we still have
benefits to reduce the complexity of converting Rust into C++, and leave
the simplified mappings in C++ for better readability.
Differential Revision: https://phabricator.services.mozilla.com/D7535
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
Previously we'd omit it since it was merely an explicit way of requesting the
default behavior. But the spec has changed such that it's not necessarily
equivalent to the default anymore:
https://drafts.csswg.org/css-align/#overflow-values
(Technically the behaviors are probably still equivalent in our implementation,
pending bug 1451380, but we don't have to publicize that via our
serialization.)
Differential Revision: https://phabricator.services.mozilla.com/D14599
I'm pretty sure the FIXME I left in the outline-style code is a bug,
but I want to clean this up further and I didn't want to fix it without adding
a test.
Differential Revision: https://phabricator.services.mozilla.com/D12859
This is all the style-system work needed for this.
This implements the concept of legacy shorthands, teaches tests to understand
it, and adds a few more tests for these properties in particular.
The WPT even caught a few WebKit / Blink bugs:
https://bugs.chromium.org/p/chromium/issues/detail?id=906336https://bugs.webkit.org/show_bug.cgi?id=191803
This doesn't change the layout behavior for page-break-before: always, since
it'd stop breaking in multicol and such. Similarly, break-before / break-after:
column and page still behave the same, I'll file followups for those given
comment 22.
Differential Revision: https://phabricator.services.mozilla.com/D12211
There's a few subtle behavior changes here, which I'll try to break down in the
commit message.
The biggest one is the EditableDescendantCount stuff going away. This
was added in bug 1181130, to prevent clicking on the non-editable div from
selecting the editable div inside. This is problematic for multiple reasons:
* First, I don't think non-editable regions of an editable element should
be user-select: all.
* Second, it just doesn't work in Shadow DOM (the editable descendant count is
not kept up-to-date when not in the uncomposed doc), so nested
contenteditables behave differently inside vs. outside a Shadow Tree.
* Third, I think it's user hostile to just entirely disable selection if you
have a contenteditable descendant as a child of a user-select: all thing.
WebKit behaves like this patch in the following test-case (though not Blink):
https://crisal.io/tmp/user-select-all-contenteditable-descendant.html
Edge doesn't seem to support user-select: all at all (no pun intended).
But we don't allow to select anything at all which looks wrong.
* Fourth, it's not tested at all (which explains how we broke it in Shadow DOM
and not even notice...).
In any case I've verified that this doesn't regress the editor from that bug. If
this regresses anything we can fix it as outlined in the first bullet point
above, which should also make us more compatible with other UAs in that
test-case.
The other change is `all` not overriding everything else. So, something like:
<div style="-webkit-user-select: all">All <div style="-webkit-user-select: none">None</div></div>
Totally ignores the -webkit-user-select: none declaration in Firefox before this
change. This doesn't match any other UA nor the spec, and this patch aligns us
with WebKit / Blink.
This in turn makes us not need -moz-text anymore, whose only purpose was to
avoid this.
This also fixes a variety of bugs uncovered by the previous changes, like the
SetIgnoreUserModify(false) call in editor being completely useless, since
presShell->SetCaretEnabled ended in nsCaret::SetVisible, which overrode it.
This in turn uncovered even more bugs, from bugs in the caret painting code,
like not checking -moz-user-modify on the right frame if you're the last frame
of a line, to even funnier bits where before this patch you show the caret but
can't write at all...
In any case, the new setup I came up with is that when you're editing (the
selection is focused on an editable node) moving the caret forces it to end up
in an editable node, thus jumping over non-editable ones.
This has the nice effect of not completely disabling selection of
-moz-user-select: all elements that have editable descendants (which was a very
ad-hoc hack for bug 1181130, and somewhat broken per the above), and also
not needing the -moz-user-select: all for non-editable bits in contenteditable.css
at all.
This also fixes issues with br-skipping like not being able to insert content in
the following test-case:
<div contenteditable="true"><span contenteditable="false">xyz </span><br>editable</div>
If you start moving to the left from the second line, for example.
I think this yields way better behavior in all the relevant test-cases from bug
1181130 / bug 1109968 / bug 1132768, shouldn't cause any regression, and the
complexity is significantly reduced in some places.
There's still some other broken bits that this patch doesn't fix, but I'll file
follow-ups for those.
Differential Revision: https://phabricator.services.mozilla.com/D12687
Although the methods of Matrix3D in animated_properties.mako.rs could be
simplified by mako, it's a little bit hard to read because they are far
from the usage and definition. Therefore, we move them to the definition of
computed::Matrix3D and expand the mako.
Differential Revision: https://phabricator.services.mozilla.com/D11961
We manually implement ComputeSquaredDistance for Translate, Rotate, and
Scale because we have to handle mismatch cases, and actually we don't
need to implement it for specified types.
Differential Revision: https://phabricator.services.mozilla.com/D11935
Basically, most of the animation code of transform don't need mako, so
we could move them into values/animated/transform.rs.
However, we still use mako to generate some code to make the methods of
Matrix3D simpler, so I still leave them in animated_properties.mako.rs.
Differential Revision: https://phabricator.services.mozilla.com/D11934
This way we always serialize in the shortest form, and take less space.
This is useful because when serializing uncomputed values we'd like to compare
to the initial value to avoid serializing parts of a shorthand, but with the
existing implementation we would generate always a second keyword, which means
that we'll never match it.
This also matches Chrome and WebKit, incidentally, so I'm pretty confident the
behavior change when serializing specified style is web-compatible.
Differential Revision: https://phabricator.services.mozilla.com/D11941
Rotate accepts rotate axis and angle in any order
(i.e. <number>{3} <angle> or <angle> <number>{3}), so we rewrite the
parser.
Differential Revision: https://phabricator.services.mozilla.com/D11417
It's only used in contenteditable.css, and same usage in comm-central. That
sheet is loaded as a ua sheet so let's restrict it to that. No relevant
external usage either. This value was introduced in bug 1181130.
Differential Revision: https://phabricator.services.mozilla.com/D11584
It's an attempt of an alias to `all`, except it doesn't get handled in all
places.
Seems unused both in comm-central and mozilla-central, and all external usage I
could find is followed by -webkit-user-select: all.
Differential Revision: https://phabricator.services.mozilla.com/D11582
This is the first step to unprefix user-select.
This has no behavior change, it's just a nicer way to do the same thing which
allows us to unship individual values more easily using parse(condition).
Differential Revision: https://phabricator.services.mozilla.com/D11580
