The @page rule may contain both 'page-orientation' and 'size' properties. The
'size' property can contain an orientation component which was being
represented as 'PageOrientation' prior to this patch. This patch changes that
to 'PageSizeOrientation' so that 'PageOrientation' can be used for
'page-orientation' in a subsequent patch.
Differential Revision: https://phabricator.services.mozilla.com/D160790
It was made a bitfield so that we could include style. But then style
containment was removed and the bitfield keeps causing us to do wrong
check (since INLINE_SIZE intersects SIZE).
So just make it an enum. This causes a progression and a test that
failed now times out (which is a pre-existing issue, just like the
pseudo-elements test that times out).
Differential Revision: https://phabricator.services.mozilla.com/D160371
- For now, implementation always returns the fallback value, i.e. small viewport lengths.
- Enabled via existing pref `layout.css.container-queries.enabled`.
Differential Revision: https://phabricator.services.mozilla.com/D158054
Not yet hooked up to any rendering functionality.
The intention is for both the @font-palette-values at-rule and the font-palette property
to be behind the same pref being introduced here.
Differential Revision: https://phabricator.services.mozilla.com/D157953
Gijs for front-end bits, layout for the new CSS properties and the
removal of nsDeckFrame / nsStackLayout, Jamie and Morgan for the a11y
changes.
As discussed in the bug, the main tricky part here is handling a11y
correctly. For <deck>, that's trivial (just use `visibility: hidden` to
hide the panels visually, while removing the unselected panels from the
a11y tree).
For <tabpanels> however we need to do something special. We do want to
hide stuff visually, but we want to preserve the contents in the a11y
tree.
For that, the easiest fix is introducing a new privileged CSS property
(-moz-subtree-hidden-only-visually), which takes care of not painting
the frame, but marks stuff offscreen in the accessibility tree. This is
not intended to be a property used widely.
Other than that, the changes are relatively straight-forward, though
some of the accessible/mac changes I could get a sanity-check on.
Differential Revision: https://phabricator.services.mozilla.com/D157875
While looking at moving the flag around I realized that the only reason
we have FontMetricsProvider and co is because we didn't have access to
the per-document font-prefs cache. That's trivial to fix tho, so do
that and simplify the setup for font queries even more.
Differential Revision: https://phabricator.services.mozilla.com/D157589
I think it's fair to honor it, just like we honor system color keywords.
By definition if we're forcing colors currentColor can only be forced or
a system color.
Differential Revision: https://phabricator.services.mozilla.com/D157675
I haven't spotted any UI regression from this, and this should generally
make the XUL -> modern flex transition easier, and simplify some
of the relevant code.
This does fix a few layout issues with emulated flexbox.
For the most part, this shouldn't change behavior without that. This
changes behavior if you have mixed inline/non-inline content in the same
XUL box (before they'd get a single item, now you'd get the flexbox /
grid behavior of one item per inline run), and multiple inline-elements
(which would become their own flex items). But I pushed a patch with
some asserts and they didn't fire on our browser mochitests, so I think
we're good.
The UA rule refactoring (removing the inherit from xul anon blocks)
shouldn't matter in practice, since we only have one item (so
box-ordinal is irrelevant) and they have overflow: visible (so
text-overflow and overflow-clip-box shouldn't have an effect).
Differential Revision: https://phabricator.services.mozilla.com/D156375
Adds trait ZeroNoPercent to check for values that are 0 (such as 0px) but not 0%
Updated test css/css-transforms/animation/translate-interpolation.html and removed unnecessary formatting changes
Differential Revision: https://phabricator.services.mozilla.com/D154930
* Implement support for `drop-shadow`
* Clean up remnant from early attempts
* Fix misleading comments on GenericSimpleShadow
If Servo-specific `style` changes will need to be upstreamed anyway, I might as well fix a thing that had thrown me off!
* Revert "Fix misleading comments on GenericSimpleShadow"
This reverts commit cdc810b826ac082041adc212c24649ee3b86ca0a.
* Clean up an import
* Update test expectations
* Fix missing expectation on Layout 2013
Fix some tests to:
* Not assume `double` precision.
* Account for recent working group resolution with regards to NaN: https://github.com/w3c/csswg-drafts/issues/7067#issuecomment-1111211295
Not sure I caught all, but normalizing to 0 was already our existing
behavior. This feature needs more work before it can be enabled more
generally, so make it nightly-only, for now.
Also, it's unclear per spec what the serialization for infinity*1s or so
should be. Right now we serialize to <very-big-number>s, which seems
reasonable, but some tests (but not others!) expect different behavior.
I left those untouched for now.
Differential Revision: https://phabricator.services.mozilla.com/D154883
We now have test coverage, so let's do this.
The remaining failures are just about infinity/nan, which is a
completely different feature.
Differential Revision: https://phabricator.services.mozilla.com/D154831
We have unshipped these since forever, no point in keeping the pref
around. Move the relevant tests to chrome ref/mochitests.
Differential Revision: https://phabricator.services.mozilla.com/D154152
This matches what Linux and macOS do, and that allows the fix for bug 1782623
to work on Windows for unstyled selects.
This also simplifies the CSS (though it adds a new system color which is a bit
more annoying). I filed https://github.com/w3c/csswg-drafts/issues/7561 to
propose adding a more generic way to do this in the future (not just for
Firefox).
Differential Revision: https://phabricator.services.mozilla.com/D153549
To be honest, I'm a bit baffled that bug 1773795 caused a performance
regression, but I think it's because the standins codepath is not really
cached, so system colors that are "spoofed" always go through the
massive switch, which could potentially be expensive.
To fix, this, rejigger a bit the caches so that we key on both
color-scheme and use-standins. Also, while at it, make the set of colors
we spoof a single bitflag check, rather than relying on the compiler to
do something potentially smart with it.
I had to shuffle the order of colors around so that the expression to
initialize the bitfield is constexpr (doesn't go over 1 << 64), but
other than that this patch should be relatively straight-forward.
Differential Revision: https://phabricator.services.mozilla.com/D150100
