Pseudo-classes with a forgiving selector list argument are allowed to follow a pseudo-element, but must treat any selector that is not of the same type as invalid. It doesn't make any sense, but that's the behavior of other tainted browsers.
- Block slot elements from being matched by ::slotted
- Ensure ::slotted() is serialized as a pseudo-element
- Add pref to control whether the pseudo-class is enabled
What happens here if aListHead is an empty selector list:
(1) next selector group is parsed and continues to the next iteration if it's empty or invalid
(2) if we're a forgiving selector list and aListHead is empty, replace it with the selector group that we've just parsed
(3) step 1 ignores invalid/empty, so we assert that step 2 should never have an empty selector list
This modifies selector list parsing to accommodate being "forgiving". Aliases for the :is selector's former names were also included. Note that the older and prefixed variant `-moz-any` remains unforgiving.
I could have done this through a CSSLoader to allow all CSS unit quirks but
I wasn't planning to start passing around document and element references
everywhere, so instead just did it manually by accepting numbers/floats in
addition to pixel and percent.
This attempts to get the first non-whitespace token, which if exists, continues with previous behavior of parsing the margin string. Otherwise, if the specified margin string is empty or consists only of whitespace characters, is interpreted as zero length.
IntersectionObserver is the only consumer of the `ParseMarginString` method, as far as I can tell, so this should not affect anything else.
Note: For some reason, Firefox and Chrome treat the unitless zero length as invalid, while with this change, we do not change existing behavior in that regard and continue to accept that value.
This removes the `grid` prefix from the gap-related properties of grid since they are now part of the box alignment specification. Former grid-gap* properties were aliased to the unprefixed properties to maintain compatibility.
The previously multi-column layout only `column-gap` property has been modified to apply to the Grid layout (and Flexbox in a following commit), moving the `mColumnGap` member variable from `nsStyleColumn` to `nsStylePosition`.
Notes:
* Bug 1398537 - support for percent values in column-gap for multi-column layout landed as part of Issue #1230. However, it was incomplete because it did not update `nsRuleNode` to allow transformation of percentage values for `column-gap`. This was consequently fixed as part of this commit.
* Bug 1456166 - this might not apply because we don't have that devtools test in UXP
* `nsRuleNode`, `nsCSSParser`, `Declaration`, and other related classes were merged into Stylo. These should be taken into consideration when porting patches from Mozilla.
Partially based on https://bugzilla.mozilla.org/show_bug.cgi?id=1398482
This functionality was already added to Gecko for UA stylesheets allow the "dom.details_element.enabled" preference to work. I changed the condition to allow bool preferences to be used in chrome stylesheets as well.
I got very anxious about making sure I included VARIANT_OPACITY in all the places VARIANT_NUMBER was included to make sure it couldn't possibly break unexpectedly, and that led to me accidentally breaking a mechanism that prevented percentages from serializing as numbers in other parts of the code. It was a total accident, and these additions were unnecessary. Basically, the situation is that there was one part of the code where it determines what's allowed for the flex statement (and possibly other statements) by checking whether it got stored as a "number", and basically only disallows percentages if it attempted to store/serialize them as percentages.
However, it only got to that part of the code because I accidentally allowed VARIANT_OPACITY as a valid way for certain tokens to parse where it wasn't necessary. If it tries to parse it that way under very specific circumstances... percentages will be marked valid and fed through the system as numbers rather than being rejected and not serialized at all, because the check to disallow percentages there relied on them being stored as percentages.
It's a really weird thing to have a problem with in a lot of ways, because if percentages aren't allowed in a field, you would think people wouldn't try to use them there, much less depend on the broken behavior that results from them not parsing as a related value.
Even though percentages are already treated as floats internally by the style system for computation purposes, you have to go out of your way to stop them from being read back out as percentages. What I do here amounts to storing the percentage token in the "wrong" container, the one normally used for floats. This allows a value that was read in as a percentage to be read back out as something else, which is normally prevented by the design of the style system.
This stub is added because websites insist on considering this
very hardware-dependent and O.S.-variable low-level font-control
as a "critical feature" which it isn't as there is 0 guarantee
that font variation settings are supported or honored by any
operating system used by the client.
On top this is a WD status feature that sites shouldn't be using, and
the feature itself is strongly discouraged for use in favor of standard
CSS font manipulation keywords like `font-weight`.
FranklinDM
Martok
roytam1
Moonchild
Jeremy Andrews
Matt A. Tobin
wolfbeast
yami
wolfbeast
janekptacijarabaci