This doesn't change behavior by default but allows authors to remove the padding
previously enforced to align with focus ring padding, if they wish to.
Extra padding was created for a prospective -moz-focus-inner ring.
We now just size that ring the same as the content frame, inflated by its CSS
padding.
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.
The removal of this preference was botched, all other surrounding plumbing changes appear to be working okay. The ability to use prefs to control this stylesheet might be useful in the future, so perhaps this is one of those "if it ain't broke, don't fix it" bugs where leaving well enough alone in the first place would have been the best choice.
This PR passes all current tests for this feature, and implements the "prefers-color-scheme" media query as an enumerated keyword that is controlled by an integer preference.
Currently, the possible options are 0 to see a website's fallback code and essentially behave like this isn't implemented (our current behavior), 1 to express a preference for a light theme (the default for spec reasons), and 2 to express a preference for a dark theme. Over time, this list may expand to include other preferences like a preference for a sepia theme or something, and this leaves us prepared for that future.
ScrollbarStyles contains values of overflow, (over)scroll-behavior, etc.
The only one which is marginally related to scroll _bars_ is overflow, which can
be used to hide scrollbar (by making an element not scrollable) or enforce the
scrollbar to display.
It makes more sense to be called ScrollStyles as it's mainly concerning behavior
of scrolling, not scrollbars. Also, with the addition of scrollbar width
properties, the current name can be confusing.
While we do fail a couple of tests, the other mainstream browsers also fail them and I think our implementation of tab-size is good enough to be unprefixed at this point. Having this patch also makes testing easier.
Currently -moz-tab-size only accepts <number> values, and both Chrome and Firefox currently support <length> values and have for some time now. So with this you would be able to support sizes in px or em, for instance. This was implemented in Firefox 53 and was trivial to backport.
Mozilla's original implementation of this failed a couple of tests, but this seems to solve all the problems. Basically, the caret-color wasn't able to be set differently based on whether a link was visited, and the auto value implementation was incomplete. The only test we fail now is the one where you have grey text on a grey background and the caret is supposed to be visible, but I think that may have been removed from the spec. Even if it wasn't, no other browser supports it anyway.
This CSS property allows input carets (that blinking input cursor you see in text fields), to be given a custom color. This was implemented in Firefox 53, and it was such a minor feature that no one ever missed it, but I don't see any harm in implementing this.
https://bugzilla.mozilla.org/show_bug.cgi?id=1063162
