This allows to clean-up the previous patches by using a single ThinVec
(which stores length / capacity along with the allocation).
Differential Revision: https://phabricator.services.mozilla.com/D175029
This allows to clean-up the previous patches by using a single ThinVec
(which stores length / capacity along with the allocation).
Differential Revision: https://phabricator.services.mozilla.com/D175029
Starts to add part of the basic functionality for popover. Including
[1] :open & :closed CSS pseudo class
[2] showPopover(), hidePopover() and togglePopover() interfaces. Much of the
functionality is still to-do.
[3] PopoverData interface
Differential Revision: https://phabricator.services.mozilla.com/D171719
Added WebIDL interfaces as per spec, added some necessary changes to support maplike and setlike structures to be accessed from C++.
Added `::highlight(foo)` pseudo element to CSS engine.
Implemented Highlight as new kind of `Selection` using `HighlightType::eHighlight`. This implies Selections being added/removed during runtime (one `Selection` object per highlight identifier), therefore a dynamic container for highlight `Selection` objects was added to `nsFrameSelection`. Also, the painting code queries the highlight style for highlight Selections.
Implementation is currently hidden behind a pref `dom.customHighlightAPI.enabled`.
Differential Revision: https://phabricator.services.mozilla.com/D164203
Added WebIDL interfaces as per spec, added some necessary changes to support maplike and setlike structures to be accessed from C++.
Added `::highlight(foo)` pseudo element to CSS engine.
Implemented Highlight as new kind of `Selection` using `HighlightType::eHighlight`. This implies Selections being added/removed during runtime (one `Selection` object per highlight identifier), therefore a dynamic container for highlight `Selection` objects was added to `nsFrameSelection`. Also, the painting code queries the highlight style for highlight Selections.
Implementation is currently hidden behind a pref `dom.customHighlightAPI.enabled`.
Differential Revision: https://phabricator.services.mozilla.com/D164203
Added WebIDL interfaces as per spec, added some necessary changes to support maplike and setlike structures to be accessed from C++.
Added `::highlight(foo)` pseudo element to CSS engine.
Implemented Highlight as new kind of `Selection` using `HighlightType::eHighlight`. This implies Selections being added/removed during runtime (one `Selection` object per highlight identifier), therefore a dynamic container for highlight `Selection` objects was added to `nsFrameSelection`. Also, the painting code queries the highlight style for highlight Selections.
Implementation is currently hidden behind a pref `dom.customHighlightAPI.enabled`.
Differential Revision: https://phabricator.services.mozilla.com/D164203
Added WebIDL interfaces as per spec, added some necessary changes to support maplike and setlike structures to be accessed from C++.
Added `::highlight(foo)` pseudo element to CSS engine.
Implemented Highlight as new kind of `Selection` using `HighlightType::eHighlight`. This implies Selections being added/removed during runtime (one `Selection` object per highlight identifier), therefore a dynamic container for highlight `Selection` objects was added to `nsFrameSelection`. Also, the painting code queries the highlight style for highlight Selections.
Implementation is currently hidden behind a pref `dom.customHighlightAPI.enabled`.
Differential Revision: https://phabricator.services.mozilla.com/D164203
This allows us to propagate flags from the container query styles all the
way to the computed style of the element.
The flag for viewport units in container queries has to be different
because it requires rematching, see comments.
Depends on D159851
Differential Revision: https://phabricator.services.mozilla.com/D159852
Parsing is behind a config value `layout.css.has-selectors.enabled`. This
change does not support p:has(> a) combinators, but will handle them
gracefully, just not matching on them.
Differential Revision: https://phabricator.services.mozilla.com/D149515
Add a dom/base/rust crate called just "dom" where we can share these.
Most of the changes are automatic:
s/mozilla::EventStates/mozilla::dom::ElementState/
s/EventStates/ElementState/
s/NS_EVENT_STATE_/ElementState::/
s/NS_DOCUMENT_STATE_/DocumentState::/
And so on. This requires a new cbindgen version to avoid ugly casts for
large shifts.
Differential Revision: https://phabricator.services.mozilla.com/D148537
They are just convenience for :root[lwthemetextcolor="light"] (and dark,
respectively), but they generally shouldn't be used for dark mode
theming. In the past it was the only way to do it but now we have
prefers-color-scheme.
While at it, change lwthemetextcolor to be "lwtheme-brighttext" for
consistency with similar code we have for popups etc, and move it to
_setDarkModeAttributes.
While at it, remove layout.css.moz-lwtheme.content.enabled (which is
false always, we unshipped these from content successfully).
Differential Revision: https://phabricator.services.mozilla.com/D141593
Behind a pref for now. Given these selectors do nothing on non-chrome
documents (they just don't match) it seems worth trying.
A cursory search seems to indicate they're not used for UA detection or
something like that (or at least I haven't found such an usage).
Differential Revision: https://phabricator.services.mozilla.com/D130736
Behind a pref for now. Given these selectors do nothing on non-chrome
documents (they just don't match) it seems worth trying.
A cursory search seems to indicate they're not used for UA detection or
something like that (or at least I haven't found such an usage).
Differential Revision: https://phabricator.services.mozilla.com/D130736
Use the same document state mechanism we have for :moz-locale-dir. Also,
simplify the setup of the later to be the same as :dir(), allowing the
matching code to be less repetitive.
This should fix some flakiness in chrome mochitests, but we have no existing
tests for these pseudo-classes more generally and since they're just
chrome-only I'm not super-excited about adding more.
Differential Revision: https://phabricator.services.mozilla.com/D130735
This I noticed while working on the following patches. Shouldn't have
any behavior change: the behavior does in fact match the element state
flag semantics correctly if we do this. We did split the dir flags into
two element bits a while ago.
:not(:dir()) still behaves correctly of course, and we have tests for that.
Differential Revision: https://phabricator.services.mozilla.com/D130734
See the discussion here: https://twitter.com/Rich_Harris/status/1433153204678799365
This should make attribute selectors roughly as fast as class selectors.
I think it's worth trying and see if perf bots complain on
micro-benchmarks and stylebench and such.
I made attributes more specific than local names, but less specific than
classes, which I think makes sense. When doing something like
foo[data-bar], filtering by data-bar seems likely to yield less elements
than filtering by foo.
While at it, remove the bloom filter pref since we shipped it in
bug 1704551 for 87 and we haven't heard complaints.
Differential Revision: https://phabricator.services.mozilla.com/D124383
See the discussion here: https://twitter.com/Rich_Harris/status/1433153204678799365
This should make attribute selectors roughly as fast as class selectors.
I think it's worth trying and see if perf bots complain on
micro-benchmarks and stylebench and such.
I made attributes more specific than local names, but less specific than
classes, which I think makes sense. When doing something like
foo[data-bar], filtering by data-bar seems likely to yield less elements
than filtering by foo.
While at it, remove the bloom filter pref since we shipped it in
bug 1704551 for 87 and we haven't heard complaints.
Differential Revision: https://phabricator.services.mozilla.com/D124383
Safari does this. This reduces the runtime in the example linked from
comment 0 quite a lot (40ms on a local opt build, from ~130ms on a
release nightly build).
I added a pref because there's a slight chance of performance
regressions on pages that do not use attribute selectors, as we're now
doing more unconditional work per element (adding the attributes to the
bloom filter). But the trade-off should be worth it, I think.
Differential Revision: https://phabricator.services.mozilla.com/D111689
And alias :-moz-ui-valid and :-moz-ui-invalid to them.
There are CSSWG resolutions for these for quite a while, and spec for
user-invalid.
Differential Revision: https://phabricator.services.mozilla.com/D105966
No other browser supports anything like this and we don't even have
internal users. Only uses of this I've found on the wild were just
resetting the box shadow internal styling we added in bug 582277 (and
since removed in bug 600151).
Differential Revision: https://phabricator.services.mozilla.com/D105955
This shipped in 85, we can remove the feature flag now. Keep
:-moz-focusring as an alias to :focus-visible at parse time.
Differential Revision: https://phabricator.services.mozilla.com/D103752
This shipped in 85, we can remove the feature flag now. Keep
:-moz-focusring as an alias to :focus-visible at parse time.
Differential Revision: https://phabricator.services.mozilla.com/D103752
