As it turns out we need this to avoid losing precision both during painting and
during serialization.
This patch also changes to serialize `context-value` if it's the computed value.
I could keep the previous behavior, but it makes no sense to serialize the
initial value. We're the only ones to support this value anyway, and I couldn't
find a definition or spec for this.
Also update tests and expectations for:
* New unexpected passes.
* Always serializing the unit in getComputedStyle.
* Calc and interpolation support.
Chrome also always serializes the unit in getComputedStyle, so I'm pretty sure
this is compatible with them. Chrome is inconsistent and keeps numbers in
specified style, but that's inconsistent with itself and with other quirky
lengths, so I updated the tests instead.
Differential Revision: https://phabricator.services.mozilla.com/D21819
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
Use it to be consistent in InsetRect serialization and storage between Servo and
Gecko.
Differential Revision: https://phabricator.services.mozilla.com/D21493
--HG--
extra : moz-landing-system : lando
Otherwise the Trait for clamping negative animation value isn't generated thus
negative animating results are exposed in computed values.
Depends on D21152
Differential Revision: https://phabricator.services.mozilla.com/D21153
--HG--
extra : moz-landing-system : lando
The euclid size is not really used for anything. Also rename it to Size2D to
avoid cbindgen conflicts with values::length::Size.
Depends on D20958
Differential Revision: https://phabricator.services.mozilla.com/D20959
--HG--
extra : moz-landing-system : lando
So we can let KeyframeEffect::ContainsAnimatedScale check individual
transforms, which is used by ActiveLayerTracker.
Depends on D19631
Differential Revision: https://phabricator.services.mozilla.com/D19525
--HG--
extra : moz-landing-system : lando
Converted the #define variable NS_STYLE_FLEX_DIRECTION to an enum class in nsStyleConsts.h and made changes in other files that access it
Differential Revision: https://phabricator.services.mozilla.com/D20291
--HG--
extra : moz-landing-system : lando
I want to do this so that I can get rid of Either<>. The reasons for getting rid
of either is 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
It's a global object, it doesn't have to be stored in nsFont. Pass it from the
caller like the user font set and co.
Depends on D20141
Differential Revision: https://phabricator.services.mozilla.com/D20142
This is more consistent with what the Rust bits of the style system do, and
removes a pointer from ComputedStyle which is always nice.
This also aligns the Rust bits with the C++ bits re. not treating xul pseudos as
anonymous boxes. See the comment in nsTreeStyleCache.cpp regarding those.
Can't wait for XUL trees to die.
Depends on D19001
Differential Revision: https://phabricator.services.mozilla.com/D19002
--HG--
extra : moz-landing-system : lando
It's a global object, it doesn't have to be stored in nsFont. Pass it from the
caller like the user font set and co.
Depends on D20141
Differential Revision: https://phabricator.services.mozilla.com/D20142
--HG--
extra : moz-landing-system : lando
The reason why we use RelaxedAtomBoolis that
ScrollSnapUtils::GetSnapPointForDestination() is called both from the main and
the compositor threads, and the function will have a branch depending on the
pref value.
Differential Revision: https://phabricator.services.mozilla.com/D20101
--HG--
extra : moz-landing-system : lando
We already avoid putting styles in the shared style cache for an element that
has animations[1] but if we are doing the initial style of two siblings where
the _second_ has animations applied, there is nothing to stop us from trying to
share with the first (un-animated) element. This patch adds a check to prevent
sharing in that case since sharing style between animated elements is unsound
for the reasons described in [1].
A number of tests including:
testing/web-platform/tests/web-animations/animation-model/animation-types/visibility.html
will fail without this fix once we remove the style flush from
KeyframeEffect::SetKeyframes later in this patch series.
[1] https://searchfox.org/mozilla-central/rev/6e3cc153566f5f288ae768a2172385b8436d61dd/servo/components/style/sharing/mod.rs#597
Differential Revision: https://phabricator.services.mozilla.com/D18913
--HG--
extra : moz-landing-system : lando
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
But enable it in all tests because a lot of them rely on using it in the
style="" attribute for example, or in inline stylesheets, which will no longer
parse this (even in chrome documents), and we don't want to rewrite all the XUL
and XBL tests.
Differential Revision: https://phabricator.services.mozilla.com/D18027
--HG--
extra : moz-landing-system : lando
These days for the types we share computed value representation we don't really
need any special code.
Differential Revision: https://phabricator.services.mozilla.com/D17763
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
This patch implements -moz-gtk-csd-hide-titlebar-by-default media query
to check if the system titlebar should be disabled by default on Linux systems
(it's already disabled on Window/Mac).
It also removes explicit definition of browser.tabs.drawInTitlebar preference on Linux.
When browser.tabs.drawInTitlebar is missing the -moz-gtk-csd-hide-titlebar-by-default
is used to obtain the titlebar state. When browser.tabs.drawInTitlebar is set
in about:config or by Customize menu, the user peference is used instead of the default.
It also fixes a -moz-gtk-csd-available media query,
it was always true regardless the actual system setting.
Differential Revision: https://phabricator.services.mozilla.com/D16036
--HG--
extra : moz-landing-system : lando
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.
Depends on D16339
Differential Revision: https://phabricator.services.mozilla.com/D16129
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
Instead of per-document. This also allows to reuse this thread-pool if needed
for other stuff, like parallel CSS parsing (#22478), and to share more code with
Gecko, which is always nice.
This cherry-picks https://github.com/servo/servo/pull/22487, with a few minor
fixes to the build that are landing as part of the sync associated to this bug,
and an lsan exception tweak to point to the right module since it's moving.
It was enabled by default in bug 1041833 (for desktops) and
bug 1087562 (for Fennect).
Depends on D15706
Differential Revision: https://phabricator.services.mozilla.com/D15707
--HG--
extra : moz-landing-system : lando
Summary: Really sorry for the size of the patch. It's mostly automatic
s/nsIDocument/Document/ but I had to fix up in a bunch of places manually to
add the right namespacing and such.
Overall it's not a very interesting patch I think.
nsDocument.cpp turns into Document.cpp, nsIDocument.h into Document.h and
nsIDocumentInlines.h into DocumentInlines.h.
I also changed a bunch of nsCOMPtr usage to RefPtr, but not all of it.
While fixing up some of the bits I also removed some unneeded OwnerDoc() null
checks and such, but I didn't do anything riskier than that.
This brings us alignas support and also associated constants for bitfield enums.
Differential Revision: https://phabricator.services.mozilla.com/D15334
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
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.
Depends on D7536
Differential Revision: https://phabricator.services.mozilla.com/D14320
--HG--
extra : moz-landing-system : lando
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.
Depends on D7535
Differential Revision: https://phabricator.services.mozilla.com/D7536
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
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.
Depends on D14672
Differential Revision: https://phabricator.services.mozilla.com/D14673
--HG--
extra : moz-landing-system : lando
I'm about to introduce another use of it and I don't want to repeat the same
copy-pasta again.
Differential Revision: https://phabricator.services.mozilla.com/D14672
--HG--
extra : moz-landing-system : lando
Since it allows to animate display, which is not good.
This is a regression from:
https://hg.mozilla.org/mozilla-central/rev/6884ba750aa3
Actually I wonder if the logic shouldn't be the other way around, i.e., a
shorthand is animatable if all the longhands are, not if just one.
In any case this rolls back to the previous behavior, should we do that, it
should be another bug.
Differential Revision: https://phabricator.services.mozilla.com/D14632
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
We could keep using ParsedCaseSensitivity::CaseSensitive as a temporary stand-in
for "case-sensitive or maybe not depending on what HTML says" until we check the
attribute list, but it seems better to make that explicit.
Differential Revision: https://phabricator.services.mozilla.com/D14093
--HG--
extra : moz-landing-system : lando
This allows to experiment with other hash maps easily rather than
depending on what hashglobe::fake::HashMap dereferences to.
In particular I wrote it while trying to get a build working with hashbrown.
Differential Revision: https://phabricator.services.mozilla.com/D14098
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
Put a hard cap on the value length instead of counting substitutions, because it
works best, see the comment.
Differential Revision: https://phabricator.services.mozilla.com/D13352
--HG--
extra : moz-landing-system : lando
Changes for nsIDOMWindowUtils.getOMTAValue is in the next commit with come test
cases.
Differential Revision: https://phabricator.services.mozilla.com/D13001
--HG--
extra : moz-landing-system : lando
Changes for nsIDOMWindowUtils.getOMTAValue is in the next commit with come test
cases.
Differential Revision: https://phabricator.services.mozilla.com/D13001
--HG--
extra : moz-landing-system : lando
display: -moz-box is no longer exposed to content so this is not necessary.
See bug 1407701 for context.
Differential Revision: https://phabricator.services.mozilla.com/D12961
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
Without this change an assertion checking IsInStyleRefresh() in
EffectCompositor::PostRestyleForAnimation will be hit when we call
FindAnimationsForCompositor from RestyleManager::DoProcessPendingRestyles
that will be introduced in a subsequent commit in this series.
I wrote a crash test which causes an assertion in KeyframeEffect::CanThrottle()
without the subsequent commit, but we need more work in display item stuff to
make the assertion won't happen (bug 1508466).
Depends on D12367
Differential Revision: https://phabricator.services.mozilla.com/D12368
--HG--
extra : moz-landing-system : lando
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.
Depends on D11935
Differential Revision: https://phabricator.services.mozilla.com/D11961
--HG--
extra : moz-landing-system : lando
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.
Depends on D11934
Differential Revision: https://phabricator.services.mozilla.com/D11935
--HG--
extra : moz-landing-system : lando
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.
Depends on D11933
Differential Revision: https://phabricator.services.mozilla.com/D11934
--HG--
rename : servo/components/style/properties/helpers/animated_properties.mako.rs => servo/components/style/values/animated/transform.rs
extra : moz-landing-system : lando
I'm trying to put all the mako code together, so we could move transform
code into a different file.
Differential Revision: https://phabricator.services.mozilla.com/D11933
--HG--
extra : moz-landing-system : lando
Converted NS_STYLE_BORDER_STYLE_* consts to enum class. Updated corresponding values to enum class. reduced BCCornerInfo struct values to fit StyleBorderStyle values inside struct. Added defaults to switches that do not fully cover all instances of StyleBorderStyle.