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
It's always true, so remove it.
Add another pref to allow -webkit-line-clamp to work on all blocks
rather than just legacy -webkit-boxes, which seems something we should
try to look into, eventually.
Depends on D155181
Differential Revision: https://phabricator.services.mozilla.com/D155182
This is a hack, sorta, similar to Chromium's:
https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/layout/layout_object.cc;l=356;drc=312b74e385e6aba98ab31fd911238c0dc16b396c
except at computed-value rather than used-value time, because it's both
simpler to reason about and prevents lying in the computed style.
This fixes the relevant test-case, and matches closer what Chromium does,
by not creating anonymous flex items for all elements inside the
line-clamp context.
The behavior change is covered by the test changes. I had to also fix a
couple pre-existing bugs that were caught by tests, now that the
line-clamped block is the -webkit-box-styled element rather than an anonymous
flex item (and thus now had padding).
Depends on D155180
Differential Revision: https://phabricator.services.mozilla.com/D155181
In the past, mathvariant was cancelling the effect of legacy
fontstyle/fontweight attributes by resetting the font-style/font-weight
properties. These legacy attributes have been removed in bug 1783841,
so remove this hack from Stylo and add corresponding WPT test.
Differential Revision: https://phabricator.services.mozilla.com/D156174
The math-depth implementation is refined to take into account the
ScriptPercentScaleDown and ScriptScriptPercentScaleDown constants (if the
parent's first valid font has a MATH table) in order to calculate the
scale factor between math-deth 0 and 1, and between 0 and 2 respectively.
Behavior is unchanged if the legacy scriptsizemultiplier attribute is
specified or if no MATH table is available.
The preference layout.css.math-depth.enabled remains disabled in nightly
until the remaining bit (support for font-size: math) is implemented in
bug 1667090.
Differential Revision: https://phabricator.services.mozilla.com/D91604
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
These are gated by the same layout.css.font-tech.enabled pref as the
closely-related `tech()` function for the @font-face src descriptor;
once the spec questions are settled, we should enable them all together.
Differential Revision: https://phabricator.services.mozilla.com/D155359
These are gated by the same layout.css.font-tech.enabled pref as the
closely-related `tech()` function for the @font-face src descriptor;
once the spec questions are settled, we should enable them all together.
Differential Revision: https://phabricator.services.mozilla.com/D155359
There are a couple of current issues/discussions that may lead to a change in the set of supported keywords, so we may want to hold back a little on actually shipping this.
- In https://github.com/w3c/IFT/pull/113, the WebFonts WG proposes several new incremental-* keywords (and maybe implies dropping the currently-defined incremental?)
- In https://github.com/w3c/csswg-drafts/issues/7633, I just proposed renaming the feature-* keywords to features-* (plural) for better readability; I'd like to see a decision on that before we ship this to release.
Differential Revision: https://phabricator.services.mozilla.com/D155458
This patch will use the width/height attributes from <source> to override
width/height/aspect-ratio CSS property values of <img> elements.
So basically, we need to introduce an extra nsMappedAttribtue member in
HTMLSourceElement (and it only stores width and height attributes).
And then we use it as an extra declarations (which are generated by
Gecko_GetExtraContentStyleDeclarations()) so we can override the
declarations created from presentation attributes of <img>.
Besides, we need to make sure <img> elements get restyled in the
following cases:
1. width/height attributes is changed in <source> elements
2. <source> is inserted as a <picture>'s child
3. <source> is removed from the child list of <picture>
4. <img> is inserted as a <picture>'s child
5. <img> is removed from the child list of <picture>
We make the responsive source synchronously get updated in the previous patch,
so now we can just restyle the image when updating its responsive source.
Note: We fix the reflection of percentages for width/height attributes in
the next patch.
Differential Revision: https://phabricator.services.mozilla.com/D152586
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
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
This makes it easier to get parity between legacy and regular flex
without having to either have tons of arbitrary attribute selectors in
the xul sheet, nor adding attribute lookup hacks to the html flexbox
layout.
Also, reimplement the remaining supported flex attribute-values (0 and 1)
purely in terms of CSS rules in xul.css (regardless of whether
emulate-moz-box-with-flex is enabled).
In practice these are pretty uncommon and the style attribute does the
trick in every case I've tried.
Add a debug-only assertion to ensure we preserve behavior for now.
Add a new test with another behavior difference between flexbox
emulation and old xul layout because the old reftest now passes. Use
replaced elements, which in modern flex are treated differently.
Differential Revision: https://phabricator.services.mozilla.com/D154394
This makes it easier to get parity between legacy and regular flex
without having to either have tons of arbitrary attribute selectors in
the xul sheet, nor adding attribute lookup hacks to the html flexbox
layout.
Also, reimplement the remaining supported flex attribute-values (0 and 1)
purely in terms of CSS rules in xul.css (regardless of whether
emulate-moz-box-with-flex is enabled).
In practice these are pretty uncommon and the style attribute does the
trick in every case I've tried.
Add a debug-only assertion to ensure we preserve behavior for now.
Add a new test with another behavior difference between flexbox
emulation and old xul layout because the old reftest now passes. Use
replaced elements, which in modern flex are treated differently.
Differential Revision: https://phabricator.services.mozilla.com/D154394
Now that the style system has keywords for this, we don't need to define them in gfx
but can just use the enum directly. (No functional change, just code simplification.)
Depends on D154237
Differential Revision: https://phabricator.services.mozilla.com/D154238
This aligns with CSS Fonts 4 (rather than Fonts 3) and with behavior in other browsers;
I don't expect any significant breakage, given that specifying multiple format strings
was never supported in other engines AFAIK, and never served any useful purpose.
Depends on D154234
Differential Revision: https://phabricator.services.mozilla.com/D154235
Now that the style system has keywords for this, we don't need to define them in gfx
but can just use the enum directly. (No functional change, just code simplification.)
Depends on D154237
Differential Revision: https://phabricator.services.mozilla.com/D154238
This aligns with CSS Fonts 4 (rather than Fonts 3) and with behavior in other browsers;
I don't expect any significant breakage, given that specifying multiple format strings
was never supported in other engines AFAIK, and never served any useful purpose.
Depends on D154234
Differential Revision: https://phabricator.services.mozilla.com/D154235
Now that the style system has keywords for this, we don't need to define them in gfx
but can just use the enum directly. (No functional change, just code simplification.)
Differential Revision: https://phabricator.services.mozilla.com/D154238
This aligns with CSS Fonts 4 (rather than Fonts 3) and with behavior in other browsers;
I don't expect any significant breakage, given that specifying multiple format strings
was never supported in other engines AFAIK, and never served any useful purpose.
Differential Revision: https://phabricator.services.mozilla.com/D154235
