The specifics of how this is going to work are still getting spec'd /
discussed in https://github.com/w3c/csswg-drafts/issues/6576, but this
allows DevTools to work fine and the feature to be complete enough for
Nightly experimentation (with the other in-flight patches).
Otherwise devtools crashes when trying to inspect pages that use them.
Differential Revision: https://phabricator.services.mozilla.com/D124656
When we had:
@layer A.B;
We were registering "A" and "B", not "A" and "A.B", which was the intention.
Fix is trivial.
Depends on D124620
Differential Revision: https://phabricator.services.mozilla.com/D124621
This makes layer order use a fixed set of bits per nesting level, to "reserve"
bits for children before they are registered.
See the comment in LayerOrder for the implementation limits it imposes, and
potential alternatives if these limits are not enough (but I think they should
be).
Enable the tests, as they mostly pass now (commit incoming to fix the remaining
ones).
Differential Revision: https://phabricator.services.mozilla.com/D124620
This works modulo the existing nested layer order bug. Will be covered
by WPT /css/css-cascade/layer-import.html once the feature is enabled (I
can probably enable it right away for those tests, but I'd rather fix
the obvious bugs first).
Differential Revision: https://phabricator.services.mozilla.com/D124538
This works modulo the existing nested layer order bug. Will be covered
by WPT /css/css-cascade/layer-import.html once the feature is enabled (I
can probably enable it right away for those tests, but I'd rather fix
the obvious bugs first).
Differential Revision: https://phabricator.services.mozilla.com/D124538
Same, I want to land this separately to see if it affects
micro-benchmarks. If so, we might want to pack the layer order
_somewhere_ (though in this case I'm not sure where, tbh).
With this, layer rules should have an effect on the page. There are
a few things missing before being able to enable them:
* Fix nested layer order in some cases (when parent layers are declared
out of order, see the previous commit mentioning this).
* Some kind of OM representation, perhaps.
* Tests of course, which are coming in bug 1728722 and bug 1727276.
But this should be enough to allow playing with them.
Depends on D124337
Differential Revision: https://phabricator.services.mozilla.com/D124338
I want to land this separately because we might want to get smarter with
the size of the Rule struct (maybe restricting layer order to a u8 per
scope and packing it with the source order, since 255 layers seem
plenty), but I'd rather do the obvious thing for now.
Depends on D124336
Differential Revision: https://phabricator.services.mozilla.com/D124337
This code is really hot, and we've had perf regressions in the past for
introducing function calls in the hot path.
After the previous patch, add_rule is recursive and thus it can't be
inlined, causing a function call for each CSS rule.
This reduces the overhead by making the function take a rule list
instead, causing a function call per rule _list_, which should be
unnoticeable in practice.
Depends on D124335
Differential Revision: https://phabricator.services.mozilla.com/D124336
For that, deal with children in add_rule recursively, to keep the
current layer name up-to-date in block layer rules.
This is not the final version of this code, as right now something like
this:
@layer A {
...
}
@layer B {
...
}
@layer A.A {
...
}
Would give A.A more priority over B, which is not correct. There are
tests for this incoming in wpt sync and such, but that can be tweaked
later.
Differential Revision: https://phabricator.services.mozilla.com/D124335
This shouldn't have any behavior change, but is necessary because for
cascade layers we are going to need to handle the child rules / sheets
ourselves, in order to handle nested layers properly.
Differential Revision: https://phabricator.services.mozilla.com/D124334
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
Not hooked anywhere yet, so this doesn't change behavior, but adds the
basic data model etc.
Adding parsing support requires some changes to cssparser to allow the
same at rule to be block and statement-like at the same time, so better
done separately.
Differential Revision: https://phabricator.services.mozilla.com/D124079
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
Also, more directly go from StyleImageRendering to wr::ImageRendering.
* image-rendering: smooth the non-deprecated version of
OptimizeQuality, which maps to SamplingFilter::LINEAR /
wr::ImageRendering::Auto (which uses gl::LINEAR).
* image-rendering: pixelated maps to wr::ImageRendering::Pixelated /
SamplingFilter::POINT which is the same crisp-edges does.
Note that this uncovers that we were mapping image-rendering:
crisp-edges to wr::ImageRendering::Pixelated.
I'm going to preserve behavior on this patch but we should consider
switching that to map to wr::ImageRendering::CrispEdges on a
follow-up (filed bug 1728831 for this).
Differential Revision: https://phabricator.services.mozilla.com/D124378
Also, more directly go from StyleImageRendering to wr::ImageRendering.
* image-rendering: smooth the non-deprecated version of
OptimizeQuality, which maps to SamplingFilter::LINEAR /
wr::ImageRendering::Auto (which uses gl::LINEAR).
* image-rendering: pixelated maps to wr::ImageRendering::Pixelated /
SamplingFilter::POINT which is the same crisp-edges does.
Note that this uncovers that we were mapping image-rendering:
crisp-edges to wr::ImageRendering::Pixelated.
I'm going to preserve behavior on this patch but we should consider
switching that to map to wr::ImageRendering::CrispEdges on a
follow-up (filed bug 1728831 for this).
Differential Revision: https://phabricator.services.mozilla.com/D124378
This is an oversight. I made selecteditem be -moz-html-cellhighlight,
but that's for inactive cells.
Use the inactive cell color everywhere (though android doesn't
differentiate). This matches other browsers and what was reviewed on
this bug.
MANUAL PUSH: The semi-transparent text-selection-disabled color caused
one test failure CLOSED TREE.
break-before/after: page|column seem harder because you need to deal
with nested breaks, I think, but this should be straight-forward.
Differential Revision: https://phabricator.services.mozilla.com/D121206
break-before/after: page|column seem harder because you need to deal
with nested breaks, I think, but this should be straight-forward.
Differential Revision: https://phabricator.services.mozilla.com/D121206
We probably want to do this when they do something different, but for
now behavior should be the same and it causes some subtests to fail
because `getComputedStyle(..).fontFamily` for system fonts seems to
return -apple-system, but `.style.fontFamily = "-apple-system"` returns
`system-ui`.
MANUAL PUSH: Orange fix on a CLOSED TREE
This was being used when we had special code for gecko profiler in the servo
codebase but we just removed the last one. This is safe to remove now. The
"enabled" feature in the gecko-profiler crate is being controlled by
gkrust-shared directly now.
Differential Revision: https://phabricator.services.mozilla.com/D120796
While the use of toml allows the flags to be separated, the split is
done via some shell shenanigans anyways, and servo's build.rs can
handle the same just fine.
Differential Revision: https://phabricator.services.mozilla.com/D121042
Emilio Cobos Álvarez
Jonathan Kew
Sandor Molnar
criss
Noemi Erli
Narcis Beleuzu
Dzmitry Malyshau
Matt Woodrow
Cosmin Sabou
Mats Palmgren
Sebastian Hengst
Barret Rennie
Ryan VanderMeulen
mbrubeck@limpet.net
Nazım Can Altınova
Mike Hommey