[selectors] Add :modal-dialog pseudo-class #6965
Comments
|
I'm strongly in favor of exposing a pseudo class for things in the top layer. So let's not call it |
|
That's not possible in general, since "being in the top layer" is something that should be doable from CSS. But we could certainly generalize it to anything built-in that forces itself (or at least defaults) into the top layer. |
Just to confirm, that is currently not possible in CSS right? But you're saying that in the future we may be able to put something in the top layer via CSS? |
|
Yeah, it's been in the cards for a long time. |
|
@tabatkins are there any artifacts you can point to for that idea (CSS-based top layer access)? I'm working on a proposal for exactly that, but CSS seems like a hard way to do it. I'm looking at an HTML attribute. But I'd love to see what's already been thought through. Having said that, I don't see why there can't be a |
I think the hard part is something like |
Precisely. You can't control access to the top layer via CSS, for this and other reasons, but I don't see why you can't select based on it. |
|
Isn't it just the fact that you can have one but not both? That is, you either control access via CSS but can't select, or you can select but then you can't control access via CSS. I don't know what "other reasons" are though, so the choice of whether to allow selection or access is probably decided by something else |
|
For reference, there's a discussion around selectors that depend on layout in #5979. Sebastian |
The basic issue is that the UA controls the top layer, and can “kick out” elements. E.g. both full screen elements and modal dialogs get forcibly removed from the top layer when you hit ESC. If access to the top layer were provided by CSS (say via a |
|
I appreciate the difficulty in getting things into top layer with CSS. I'm just trying to reconcile this with @tabatkins reply that "top layer with CSS is probably coming". Adding a |
|
There's been several issues discussing it, but the most relevant one is #4645. There's nothing inherently magical about the top layer. You can achieve identical effects today via the common strategy of putting elements as final direct children of So removing things from the top layer similarly isn't a property of "being in the top layer", but rather "being a UA-provided feature, and thus not necessarily something the page author knows about". We don't want the So, yes, we can't have a selector that means "element is in the top layer" and a property that puts elements in the top layer. But we definitely want the latter, because it's a useful convenience primitive that has no reason not to be exposed to authors. And we don't actually need the former; what we need is a pseudo-class for detecting when a host-language specific element is in a host-language specific state that, as a side-effect, puts it in the top layer, because that's a useful semantic detail of the element's current state; that's completely doable. When a dialog is modal, when a video is fullscreened, etc. are all potentially foldable into here if we think it's useful. |
|
So there's something somewhat magical about the top layer. It provides a guaranteed-on-top paint order, regardless of |
|
I'm not sure the UA would "need the power to remove those elements from the top layer". |
|
I don't think it's ok to have CSS put something in the top layer. The top layer is a stacking context that is managed by the UA, and enables it to implement features such as fullscreen and dialog reliably on behalf of the user and developer. If the developer were able to put things into the top layer that the UA did not understand, the UA would lose its ability to reliably implement the features it does have for the top layer, because it wouldn't be sure that the fullscreen or dialog was on top of other content.
I think it does. I don't think the top layer should be considered just a developer convenience. The developer already has convenience via the other stacking contexts.
Yes, but that's not the top layer. That's the "developer layer". |
I mean, that's just the definition of it, sure. Nothing about that implies that it can't be used by author-level CSS.
Why? I don't see why this is required - top-layer is just a somewhat more reliable/convenient version of what authors can already do today, by putting their "top-layer" elements as final children of
Yes, having the UA features always sit further on top (the "UA top layer", I suppose) is fine and reasonable. But none of this requires us to deny authors the ability to reliably put things in a top layer with the same convenient ancestor-escaping capability; authors should be able to make their own |
|
Would any value of |
The reason why is the need for the UA-manipulated stuff to be on top. I don't have an objection to considering exposing another top layer to developers that is below the UA one, if there is a strong use case, so long as it doesn't get in the way of the UA one.
Ok. I think we're on the same page then: agreed that it's likely useful to developers to have their own top layer, and that the UA top layer should win. |
By arranging it this way, aren't there going to be odd situations? What happens if a fullscreen element or modal dialog puts something into the "developer top layer". It'll be below the fullscreen/dialog and never visible. For example, what if you want a tooltip on top of a modal dialog? That would be impossible, or would require special case logic to do something entirely different if your dialog was modal. On the other hand, if the one top layer was managed by the UA, it could allow nested top layer elements like this, with more specific rules. For example, it's ok to show a tooltip on top of a popup on top of a fullscreen element, but if the user hits ESC, the entire stack of three elements gets removed from the top layer. |
BTW, this already has some funny corner cases, just between fullscreen and modal dialog. For example, at least in Chromium, you can open a fullscreen element and then a dialog, which displays "properly" in this order. However, hitting ESC removes the fullscreen element but leaves the dialog. Perhaps they both should close. Or we should at least think about what should happen here. |
Browser-provided features like fullscreen, modal or popup should use the UA top layer. A potential developer top layer would always be below it. That suffices right? |
All of these questions/issues apply exactly equally to developers putting things "on top" today, by making them a final child of |
Well, fullscreen and modal dialog yes. But "popup" I'd expect to use this new thing, whatever it is. And I also don't think it suffices - again, if you have either fullscreen or modal dialog and want that to put something into the developer top layer, it won't work. It'll be underneath the fullscreen/modal. I.e. no way to put a tooltip on top of a modal dialog.
Well, yes and no. Today, if you have a fullscreen or modal dialog, you have to know that, and put your tooltip as the last child of the fullscreen or dialog element rather than the body, in order for it to show up on top. So it's a problem today. But I'd hate to make it worse by ushering in a whole new capability that was rife with the same problems. I would hope we could make this easier for developers by just having one top layer which behaves rationally. And in most normal situations, things "just work". In the corner case (e.g. user hits ESC), the UA has the power to pull things back out, but developers don't have to worry about that at all. Maybe I'm overthinking this. But some use cases sound common. A tooltip on a dialog sounds familiar. A pop-up volume slider on a fullscreen video sounds familiar. I'd just prefer to have a solution that covers these use cases and doesn't make them harder than they are today. |
|
"top-layer" was designed to allow the UA to guarantee that it could always put things on top of page content. If we allow CSS to control whether things go into the top layer, then we're re-opening the "layering things on top" arms race that we had before "top-layer" existed. I support not allowing CSS to put things in the top layer. |
|
Your comment is unclear to me, @smfr. Guarantee to whom? Could you elaborate on scenarios in which authors' wishes may conflict in this regard with someone else's (presumably not the user's) and yet the UA should grant the latter? |
|
Video fullscreen, and modal dialogs are two cases where I think it would be weird if page content could pop elements above the video, or above the dialog. Sure, the page can spawn another modal dialog, but that has some UA-level guarantees like the Escape key dismisses it. |
|
So, currently I can't position But you are drafting the spec to make this possible. When can we expect to have the spec finalized and implemented by all major browsers? |
|
It wasn't clear from the resolution that |
|
And in Gecko fullscreen isn't "modal", you can interact with the page behind if you want, see: <!doctype html>
<style>
#fullscreen {
background-color: rgba(0, 255, 0, .5);
}
#fullscreen::backdrop {
background-color: transparent;
}
#fullscreen, #fullscreen::backdrop {
pointer-events: none;
}
</style>
<p>Here's some text</p>
<div id="fullscreen"></div>
<button>Go fullscreen</button>
<script>
document.querySelector("button").addEventListener("click", function(e) {
document.getElementById("fullscreen").requestFullscreen();
});
</script> |
wdym? can you share some examples? |
|
https://drafts.csswg.org/selectors/#modal-state says:
Which seems to hint that |
|
I guess it would make sense for fullscreen to match |
|
The spec text should not include fullscreen, that was not part of the resolution. |
+1. As we discussed at the meeting, we need a crisp definition of "Modal". The resolution refers (see the notes) to @chrishtr's comment above, which defines it this way:
Per that definition, fullscreen doesn't meet the definition - it does not "intentionally make inert the rest of the UI". |
It does make inert the rest of the UI in Chromium fwiw: https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/css/resolver/style_adjuster.cc;l=712-724;drc=164a13142f64c249d85e219cf745c371fc51b701 I don't have a particular preference on whether this should be the case, though I guess it does make sense. |
Yes, I agree Chromium makes the page I'd agree that if this behavior is (or becomes) per-spec, then |
|
I filed issue #7311 for whether fullscreen should be modal. In the meantime let's remove fulllscreen from the |
|
Reopening until the spec edit is made. |
…to fullscreen too behind a pref. r=edgar For now, don't turn it on by default yet, because I want to wait for more discussion in w3c/csswg-drafts#6965 and so on. But I think the code is simple enough to land this. Differential Revision: https://phabricator.services.mozilla.com/D147295
…to fullscreen too behind a pref. r=edgar For now, don't turn it on by default yet, because I want to wait for more discussion in w3c/csswg-drafts#6965 and so on. But I think the code is simple enough to land this. Differential Revision: https://phabricator.services.mozilla.com/D147295
…screen too behind a pref For now, don't turn it on by default yet, because I want to wait for more discussion in w3c/csswg-drafts#6965 and so on. But I think the code is simple enough to land this. Differential Revision: https://phabricator.services.mozilla.com/D147295
…screen too behind a pref For now, don't turn it on by default yet, because I want to wait for more discussion in w3c/csswg-drafts#6965 and so on. But I think the code is simple enough to land this. Differential Revision: https://phabricator.services.mozilla.com/D147295
* style: Simplify selector flag setting now that flag setting is atomic These bits are write-only, actually, and we don't even need to read them. Differential Revision: https://phabricator.services.mozilla.com/D141888 * Further changes required by Servo * style: Support media queries for dynamic-range and video-dynamic-range This is a stub that only matches "standard" for all platforms. Differential Revision: https://phabricator.services.mozilla.com/D141053 * style: Remove :-moz-lwtheme-{brighttext,darktext} 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 * style: layout.css.moz-locale-dir.content.enabled We successfully removed these from content in bug 1740230 (Firefox 96). Differential Revision: https://phabricator.services.mozilla.com/D141727 * style: Really honor background-color: transparent in HCM even for form controls I forgot we were doing this "revert-or-initial" shenanigans (which is needed for stuff like link colors to be honored), so we need to early-return. Use a more explicit test rather than a reftest for this. Differential Revision: https://phabricator.services.mozilla.com/D142063 * style: Ignore unchanged property for scroll-linked effect detector I think this is cleaner. Differential Revision: https://phabricator.services.mozilla.com/D141737 * style: Allow to derive Parse/ToCss/SpecifiedValueInfo on bitflags We keep getting this pattern of properties that have a set of joint and disjoint flags, and copy-pasting or writing the same parsing and serialization code in slightly different ways. container-type is one such type, and I think we should have a single way of dealing with this, thus implement deriving for various traits for bitflags, with an attribute that says which flags are single vs mixed. See docs and properties I ported. The remaining ones I left TODOs with, they are a bit trickier but can be ported with some care. Differential Revision: https://phabricator.services.mozilla.com/D142418 * Further changes required by Servo * style: Implement parsing / serialization for container{,-type,-name} CSS properties Two noteworthy details that may seem random otherwise: * Moving values around in nsStyleDisplay is needed so that the struct remains under the size limit that we have to avoid jumping allocator buckets. * All the test expectation churn is because tests depend on `container-type: size` parsing to run, and now they run. Tests for the relevant bits I implemented are passing, with the only exception of some `container-name-computed.html` failures which are w3c/csswg-drafts#7181. Safari agrees with us there. Other notes when looking at the spec and seeing how it matches the implementation: * `container` syntax doesn't match spec, but matches tests and sanity: w3c/csswg-drafts#7180 * `container-type` syntax doesn't _quite_ match spec, but matches tests and I think it's a spec bug since the definition for the missing keyword is gone: w3c/csswg-drafts#7179 Differential Revision: https://phabricator.services.mozilla.com/D142419 * style: Remove assert that doesn't hold for text-decorations because of presentation hints MANUAL PUSH: Orange fix CLOSED TREE * style: Migrate `<th>` `text-align` behaviour from presentation hint to UA CSS Differential Revision: https://phabricator.services.mozilla.com/D142494 * style: Deduplicate TokenList values faster Remember whether we have already de-duplicated them once and avoid doing that again. This is an alternative approach that doesn't add overhead to attribute setting in the general case. Differential Revision: https://phabricator.services.mozilla.com/D142813 * style: Inherit used color-scheme from embedder <browser> elements This allows popups and sidebars to use the chrome preferred color-scheme. This moves the responsibility of setting the content-preferred color scheme to the appropriate browsers to the front-end (via tabs.css). We still return the PreferredColorSchemeForContent() when there's no pres context (e.g., for display:none in-process iframes). We could potentially move a bunch of the pres-context data to the document instead, but that should be acceptable IMO as for general web content there's no behavior change in any case. Differential Revision: https://phabricator.services.mozilla.com/D142578 * Further changes required by Servo * style: Add basic @container rule parsing and boilerplate For now parse a MediaFeatureCondition. That needs being made more specific, but that is probably worth its own patch. Differential Revision: https://phabricator.services.mozilla.com/D143192 * Further changes required by Servo * style: Tweak cascade priority to split writing-mode and font properties This makes the worst case for cascade performance slightly more expensive (4 rather than three declaration walks), but my hope is that it will make the average case faster, since the best case is now just two walks instead of three, and writing mode properties are somewhat rare. This needs a test, but needs to wait until the writing-mode dependent viewport units land (will wait to land with a test). Differential Revision: https://phabricator.services.mozilla.com/D143261 * style: Implement new {small,large,dynamic} viewport units Differential Revision: https://phabricator.services.mozilla.com/D143252 * Further changes required by Servo * style: Implement new *vi and *vb units Differential Revision: https://phabricator.services.mozilla.com/D143253 * style: Implement prefers-contrast: custom and let prefers-contrast ride the trains Differential Revision: https://phabricator.services.mozilla.com/D143198 * style: Join servo style threads during shutdown I was unable to change the BLOOM_KEY field to no longer be leaked, as the TLS is also accessed on the main thread, which is not exited before the leak checker shuts down. Differential Revision: https://phabricator.services.mozilla.com/D143529 * Further changes required by Servo * style: Fix visited handling after bug 1763750 Before bug 1763750, we unconditionally called compute_writing_mode, which got the writing mode from the cascade mode for visited styles. However after that bug we only do that if we apply any writing-mode-related property. We could just call compute_writing_mode unconditionally, but instead it seems better to skip all that work for visited cascade and reuse the mechanism introduced in that bug to only apply the visited-dependent longhands. We assert that all visited-dependent longhands are "late" longhands, so as to also avoid applying the font group and such. Differential Revision: https://phabricator.services.mozilla.com/D143490 * style: Clean-up viewport unit resolution a bit I should've caught this when reviewing the new viewport units but alas :-) Differential Revision: https://phabricator.services.mozilla.com/D143856 * style: Implement `contain: inline-size` Differential Revision: https://phabricator.services.mozilla.com/D143501 * style: Simplify media query evaluation code a bit This patch: * Removes generic <ident> support for media features. These were used for some privileged media features but are no longer used. * Simplifies media feature getters by shifting the responsibility of dealing with RangeOrOperator to the caller. This makes it easier to implement container-query / mediaqueries-4 syntax, and also cleans up the code a bunch. There should be no change in behavior. Differential Revision: https://phabricator.services.mozilla.com/D144051 * Further changes required by Servo * style: Move transitions and animations to nsStyleUIReset This mostly just moves code around, to minimize potential behavior changes. There are some cleanups that we should try to do long term (this "have an array with n different counts" is pretty weird). But for now this should unblock people. The destination struct (nsStyleUIReset) was chosen mainly because it's small and non-inherited, and it doesn't seem like a worse place than nsStyleDisplay. Differential Revision: https://phabricator.services.mozilla.com/D144183 * Further changes required by Servo * style: Make media feature evaluation take a computed::Context This has no behavior change right now, but will simplify sharing code with container queries. Container queries will have container information in the computed::Context (this is necessary anyways for container-based units), so this avoids having to have different code for media and container queries. Differential Revision: https://phabricator.services.mozilla.com/D144152 * Further changes required by Servo * style: Add scroll() to animation-timeline for style system scroll() is defined in the spec proposal, and there is a temporary spec: https://drafts.csswg.org/scroll-animations-1/rewrite#scroll-notation. The spec is still under development, so we don't drop the orignal scroll-timeline at rule. Instead, we add a new scroll() notation to animation-timeline, and support both syntax for now. Differential Revision: https://phabricator.services.mozilla.com/D143417 * style: Tweak contain bitflag definition order to avoid static constructors This has no behavior change otherwise. The STRICT definition depended on SIZE, which was defined later. That's fine in Rust, but in C++ it causes the initialization to be dynamic because it doesn't have the definition of SIZE yet (ugh). This is the fix for the regression, though the following patch turns on constexpr support in cbindgen, which would've caught this at build-time, and guarantees that we don't have extra static constructors. Differential Revision: https://phabricator.services.mozilla.com/D144316 * style: Move some of the media query code to a more generic queries module No behavior change, just moving and renaming files. The code in the "queries" module will be shared between @media and @container. @media has some other code that container queries doesn't need like MediaList / MediaType / etc. That remains in the media_queries module. Differential Revision: https://phabricator.services.mozilla.com/D144435 * Further changes required by Servo * style: cleanup animation-name Make the representation the same between Gecko and Servo code. This will enable further clean-ups in the future. Make serialization be correct, serializing as identifier unless it's an invalid one (in which case we serialize as a string). This changes our stringification behavior in the specified style, but now it will match the computed style and be more correct over-all. Differential Revision: https://phabricator.services.mozilla.com/D144473 * Further changes required by Servo * style: Add support for parsing container-query-specific features There are some mediaqueries-5 features that we still don't support and explain the remaining failures in at-container-{parsing,serialization}. Differential Revision: https://phabricator.services.mozilla.com/D144446 * Further changes required by Servo * style: Introduce Optional<T> to represent optional values in the style system cross-fade() was kinda doing this in its own way with PercentOrNone, but since now we have more use-cases for this we should probably make this a slightly more general solution. I added some convenience APIs, but they're unused as of this patch so let me know if you want them gone. Differential Revision: https://phabricator.services.mozilla.com/D144831 * style: Fix insertRule with layer statements before imports We need to do a bit more nuanced check because @layer statements might go before imports. Differential Revision: https://phabricator.services.mozilla.com/D144996 * style: Factor out parsing the query feature name No behavior change. Differential Revision: https://phabricator.services.mozilla.com/D145229 * style: Refactor media feature expression representation in preparation to support multi-range syntax No behavior change. Depends on D145229 Differential Revision: https://phabricator.services.mozilla.com/D145230 * style: Implement media feature expression multi-range syntax Differential Revision: https://phabricator.services.mozilla.com/D145231 * style: Remove proton places tooltip code There's nobody working on it, and tooltips should hopefully be nice enough after recent changes (bug 1765423). Having it enabled causes artifacts like bug 1767815 comment 3. We can always rescue this from hg history if needed. Differential Revision: https://phabricator.services.mozilla.com/D145621 * style: Simplify selector flags setup even more In my investigation for bug 1766439, I am digging into why selector matching regressed. It doesn't help that the selector-matching code is instantiated a gazillion times (so there's a ton of copies of the relevant functions). This was needed in the past because we had different ways of setting the selector flags on elements, but I unified that recently and now we only need to either set them or not. That is the kind of thing that MatchingContext is really good for, so pass that instead on MatchingContext creation. Differential Revision: https://phabricator.services.mozilla.com/D145428 * Further changes required by Servo * style: Track @container condition id in style rules Much like we track layer rules. Consolidate that "containing rule state we pass down while building the cascade data" in a single struct that we can easily restore. For now, do nothing with it. I want to land this patch separately because it touches the Rule struct and CascadeData rebuilds, which both are performance sensitive. Its layout shouldn't change because I also changed LayerId to be a u16 (this shouldn't matter in practice, since LayerOrder is already a u16). Differential Revision: https://phabricator.services.mozilla.com/D145243 * Further changes required by Servo * style: Fix layer statement rules with multiple layer names MANUAL PUSH: Trivial orange fix CLOSED TREE. * style: Implement piecewise linear function Differential Revision: https://phabricator.services.mozilla.com/D145256 * style: Convert specified value tests to compile-time tests These were written at a time where std::mem::size_of wasn't a `const fn` in Rust. Now that it is, we can make these tests live in the style crate, and the build not to compile if they fail. Differential Revision: https://phabricator.services.mozilla.com/D146103 * Further changes required by Servo * style: Move size of tests to compile-time tests in the style crate Same reasoning as the previous commit. Differential Revision: https://phabricator.services.mozilla.com/D146104 * Further changes required by Servo * style: Lint and 32-bit build fix. MANUAL PUSH: Bustage fix CLOSED TREE * style: Implement 'update' media feature Differential Revision: https://phabricator.services.mozilla.com/D146338 * style: Clean up unused -moz-window-shadow values After bug 1768278 and bug 1767815 there's no more uses of the cliprounded value in the tree (also it causes artifacts on HiDPI screens so we probably don't want new usages). The "sheet" value is unused, and the other values other than "default" and "none" are only derived from "default", so they don't need to be exposed in the style system. Differential Revision: https://phabricator.services.mozilla.com/D145821 * style: More container queries plumbing Provide container information in computed::Context and use it to resolve the container queries. This still fails a lot of tests because we are not ensuring that layout is up-to-date when we style the container descendants, but that's expected. Differential Revision: https://phabricator.services.mozilla.com/D146478 * Further changes required by Servo * style: Ensure options in listbox selects are not stacking contexts by default We could have a different property or something but this seems reasonable as well probably. Differential Revision: https://phabricator.services.mozilla.com/D146994 * style: Implement overflow-clip-margin: <length> Differential Revision: https://phabricator.services.mozilla.com/D146432 * style: Change order of container shorthand Since the initial value of container-type is an open issue [1], I'm leaving that as-is for now. [1] w3c/csswg-drafts#7202 Differential Revision: https://phabricator.services.mozilla.com/D147338 * style: Make modal dialog code more generic, and make it apply to fullscreen too behind a pref For now, don't turn it on by default yet, because I want to wait for more discussion in w3c/csswg-drafts#6965 and so on. But I think the code is simple enough to land this. Differential Revision: https://phabricator.services.mozilla.com/D147295 * style: Cache computed styles objects display: none subtrees This reuses our existing undisplayed style generation, but in a per-document rather than per-nsComputedDOMStyle object, which means that we can avoid re-resolving styles of elements in display: none subtrees much more often. This brings the test-case in the bug to par with other browsers or better, and is much simpler than the initial approach I tried back in the day. Differential Revision: https://phabricator.services.mozilla.com/D147547 * Further changes required by Servo * style: Parse scroll-snap-stop style and propagate it to APZ side Depends on D146147 Differential Revision: https://phabricator.services.mozilla.com/D145850 * style: Update color-mix() syntax to match the current spec Test expectation updates for this in the latest patch of the bug. Differential Revision: https://phabricator.services.mozilla.com/D147002 * Further changes required by Servo * style: Make the color interpolation code more generic It's really piece-wise premultiplied interpolation, with a special-case for hue, so centralize the implementation. Differential Revision: https://phabricator.services.mozilla.com/D147003 * style: Implement more color-mix() color-spaces We had code to convert between these and the latest draft supports them so... Differential Revision: https://phabricator.services.mozilla.com/D147004 * style: Fix color-mix() percentage normalization Differential Revision: https://phabricator.services.mozilla.com/D147005 * style: Fix hue adjustment to match the spec The value to sum is tau, not pi. This was caught by some tests, see https://drafts.csswg.org/css-color/#shorter Differential Revision: https://phabricator.services.mozilla.com/D147006 * style: Do hue interpolations in degrees rather than radians. r=barret This gives us a bit more precision. Differential Revision: https://phabricator.services.mozilla.com/D147007 * style: Improve Percentage -> LengthPercentage conversion This doesn't change behavior because we only use them for images that have no clamping. Depends on D147008 Differential Revision: https://phabricator.services.mozilla.com/D147511 * style: Remove some dead vibrancy code Drive-by cleanup. Differential Revision: https://phabricator.services.mozilla.com/D147698 * style: Fix warnings about whitelist/blocklist functions being deprecated in bindgen 0.59 Differential Revision: https://phabricator.services.mozilla.com/D147695 * style: Update style to arrayvec 0.7 Differential Revision: https://phabricator.services.mozilla.com/D147476 * style: Update style to uluru 3.0 Differential Revision: https://phabricator.services.mozilla.com/D147477 * style: Remove -moz-scrollbar-thumb-proportional It unconditionally matches on all platforms, so it's not returning any useful information. Depends on D147689 Differential Revision: https://phabricator.services.mozilla.com/D147690 * style: Use ColorMix for interpolated colors in the computed style rather than ComplexColorRatios This among other things preserves the right color-space when interpolating currentColor. Differential Revision: https://phabricator.services.mozilla.com/D147512 * Further changes required by Servo * style: Add an input-region-margin to widgets, and implement it on Linux Recompute the input region when resizing the widget and so on, and use it to check for rollups. Depends on D148211 Differential Revision: https://phabricator.services.mozilla.com/D148222 * Avoid complaints from ./mach test-tidy * Update test expectations --------- Co-authored-by: Emilio Cobos Álvarez <emilio@crisal.io> Co-authored-by: Brad Werth <bwerth@mozilla.com> Co-authored-by: David Shin <dshin@mozilla.com> Co-authored-by: Hiroyuki Ikezoe <hikezoe.birchill@mozilla.com> Co-authored-by: Nika Layzell <nika@thelayzells.com> Co-authored-by: Boris Chiou <boris.chiou@gmail.com> Co-authored-by: Autumn on Tape <autumn@cyfox.net> Co-authored-by: Mike Hommey <mh+mozilla@glandium.org>
* style: Simplify selector flag setting now that flag setting is atomic These bits are write-only, actually, and we don't even need to read them. Differential Revision: https://phabricator.services.mozilla.com/D141888 * Further changes required by Servo * style: Support media queries for dynamic-range and video-dynamic-range This is a stub that only matches "standard" for all platforms. Differential Revision: https://phabricator.services.mozilla.com/D141053 * style: Remove :-moz-lwtheme-{brighttext,darktext} 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 * style: layout.css.moz-locale-dir.content.enabled We successfully removed these from content in bug 1740230 (Firefox 96). Differential Revision: https://phabricator.services.mozilla.com/D141727 * style: Really honor background-color: transparent in HCM even for form controls I forgot we were doing this "revert-or-initial" shenanigans (which is needed for stuff like link colors to be honored), so we need to early-return. Use a more explicit test rather than a reftest for this. Differential Revision: https://phabricator.services.mozilla.com/D142063 * style: Ignore unchanged property for scroll-linked effect detector I think this is cleaner. Differential Revision: https://phabricator.services.mozilla.com/D141737 * style: Allow to derive Parse/ToCss/SpecifiedValueInfo on bitflags We keep getting this pattern of properties that have a set of joint and disjoint flags, and copy-pasting or writing the same parsing and serialization code in slightly different ways. container-type is one such type, and I think we should have a single way of dealing with this, thus implement deriving for various traits for bitflags, with an attribute that says which flags are single vs mixed. See docs and properties I ported. The remaining ones I left TODOs with, they are a bit trickier but can be ported with some care. Differential Revision: https://phabricator.services.mozilla.com/D142418 * Further changes required by Servo * style: Implement parsing / serialization for container{,-type,-name} CSS properties Two noteworthy details that may seem random otherwise: * Moving values around in nsStyleDisplay is needed so that the struct remains under the size limit that we have to avoid jumping allocator buckets. * All the test expectation churn is because tests depend on `container-type: size` parsing to run, and now they run. Tests for the relevant bits I implemented are passing, with the only exception of some `container-name-computed.html` failures which are w3c/csswg-drafts#7181. Safari agrees with us there. Other notes when looking at the spec and seeing how it matches the implementation: * `container` syntax doesn't match spec, but matches tests and sanity: w3c/csswg-drafts#7180 * `container-type` syntax doesn't _quite_ match spec, but matches tests and I think it's a spec bug since the definition for the missing keyword is gone: w3c/csswg-drafts#7179 Differential Revision: https://phabricator.services.mozilla.com/D142419 * style: Remove assert that doesn't hold for text-decorations because of presentation hints MANUAL PUSH: Orange fix CLOSED TREE * style: Migrate `<th>` `text-align` behaviour from presentation hint to UA CSS Differential Revision: https://phabricator.services.mozilla.com/D142494 * style: Deduplicate TokenList values faster Remember whether we have already de-duplicated them once and avoid doing that again. This is an alternative approach that doesn't add overhead to attribute setting in the general case. Differential Revision: https://phabricator.services.mozilla.com/D142813 * style: Inherit used color-scheme from embedder <browser> elements This allows popups and sidebars to use the chrome preferred color-scheme. This moves the responsibility of setting the content-preferred color scheme to the appropriate browsers to the front-end (via tabs.css). We still return the PreferredColorSchemeForContent() when there's no pres context (e.g., for display:none in-process iframes). We could potentially move a bunch of the pres-context data to the document instead, but that should be acceptable IMO as for general web content there's no behavior change in any case. Differential Revision: https://phabricator.services.mozilla.com/D142578 * Further changes required by Servo * style: Add basic @container rule parsing and boilerplate For now parse a MediaFeatureCondition. That needs being made more specific, but that is probably worth its own patch. Differential Revision: https://phabricator.services.mozilla.com/D143192 * Further changes required by Servo * style: Tweak cascade priority to split writing-mode and font properties This makes the worst case for cascade performance slightly more expensive (4 rather than three declaration walks), but my hope is that it will make the average case faster, since the best case is now just two walks instead of three, and writing mode properties are somewhat rare. This needs a test, but needs to wait until the writing-mode dependent viewport units land (will wait to land with a test). Differential Revision: https://phabricator.services.mozilla.com/D143261 * style: Implement new {small,large,dynamic} viewport units Differential Revision: https://phabricator.services.mozilla.com/D143252 * Further changes required by Servo * style: Implement new *vi and *vb units Differential Revision: https://phabricator.services.mozilla.com/D143253 * style: Implement prefers-contrast: custom and let prefers-contrast ride the trains Differential Revision: https://phabricator.services.mozilla.com/D143198 * style: Join servo style threads during shutdown I was unable to change the BLOOM_KEY field to no longer be leaked, as the TLS is also accessed on the main thread, which is not exited before the leak checker shuts down. Differential Revision: https://phabricator.services.mozilla.com/D143529 * Further changes required by Servo * style: Fix visited handling after bug 1763750 Before bug 1763750, we unconditionally called compute_writing_mode, which got the writing mode from the cascade mode for visited styles. However after that bug we only do that if we apply any writing-mode-related property. We could just call compute_writing_mode unconditionally, but instead it seems better to skip all that work for visited cascade and reuse the mechanism introduced in that bug to only apply the visited-dependent longhands. We assert that all visited-dependent longhands are "late" longhands, so as to also avoid applying the font group and such. Differential Revision: https://phabricator.services.mozilla.com/D143490 * style: Clean-up viewport unit resolution a bit I should've caught this when reviewing the new viewport units but alas :-) Differential Revision: https://phabricator.services.mozilla.com/D143856 * style: Implement `contain: inline-size` Differential Revision: https://phabricator.services.mozilla.com/D143501 * style: Simplify media query evaluation code a bit This patch: * Removes generic <ident> support for media features. These were used for some privileged media features but are no longer used. * Simplifies media feature getters by shifting the responsibility of dealing with RangeOrOperator to the caller. This makes it easier to implement container-query / mediaqueries-4 syntax, and also cleans up the code a bunch. There should be no change in behavior. Differential Revision: https://phabricator.services.mozilla.com/D144051 * Further changes required by Servo * style: Move transitions and animations to nsStyleUIReset This mostly just moves code around, to minimize potential behavior changes. There are some cleanups that we should try to do long term (this "have an array with n different counts" is pretty weird). But for now this should unblock people. The destination struct (nsStyleUIReset) was chosen mainly because it's small and non-inherited, and it doesn't seem like a worse place than nsStyleDisplay. Differential Revision: https://phabricator.services.mozilla.com/D144183 * Further changes required by Servo * style: Make media feature evaluation take a computed::Context This has no behavior change right now, but will simplify sharing code with container queries. Container queries will have container information in the computed::Context (this is necessary anyways for container-based units), so this avoids having to have different code for media and container queries. Differential Revision: https://phabricator.services.mozilla.com/D144152 * Further changes required by Servo * style: Add scroll() to animation-timeline for style system scroll() is defined in the spec proposal, and there is a temporary spec: https://drafts.csswg.org/scroll-animations-1/rewrite#scroll-notation. The spec is still under development, so we don't drop the orignal scroll-timeline at rule. Instead, we add a new scroll() notation to animation-timeline, and support both syntax for now. Differential Revision: https://phabricator.services.mozilla.com/D143417 * style: Tweak contain bitflag definition order to avoid static constructors This has no behavior change otherwise. The STRICT definition depended on SIZE, which was defined later. That's fine in Rust, but in C++ it causes the initialization to be dynamic because it doesn't have the definition of SIZE yet (ugh). This is the fix for the regression, though the following patch turns on constexpr support in cbindgen, which would've caught this at build-time, and guarantees that we don't have extra static constructors. Differential Revision: https://phabricator.services.mozilla.com/D144316 * style: Move some of the media query code to a more generic queries module No behavior change, just moving and renaming files. The code in the "queries" module will be shared between @media and @container. @media has some other code that container queries doesn't need like MediaList / MediaType / etc. That remains in the media_queries module. Differential Revision: https://phabricator.services.mozilla.com/D144435 * Further changes required by Servo * style: cleanup animation-name Make the representation the same between Gecko and Servo code. This will enable further clean-ups in the future. Make serialization be correct, serializing as identifier unless it's an invalid one (in which case we serialize as a string). This changes our stringification behavior in the specified style, but now it will match the computed style and be more correct over-all. Differential Revision: https://phabricator.services.mozilla.com/D144473 * Further changes required by Servo * style: Add support for parsing container-query-specific features There are some mediaqueries-5 features that we still don't support and explain the remaining failures in at-container-{parsing,serialization}. Differential Revision: https://phabricator.services.mozilla.com/D144446 * Further changes required by Servo * style: Introduce Optional<T> to represent optional values in the style system cross-fade() was kinda doing this in its own way with PercentOrNone, but since now we have more use-cases for this we should probably make this a slightly more general solution. I added some convenience APIs, but they're unused as of this patch so let me know if you want them gone. Differential Revision: https://phabricator.services.mozilla.com/D144831 * style: Fix insertRule with layer statements before imports We need to do a bit more nuanced check because @layer statements might go before imports. Differential Revision: https://phabricator.services.mozilla.com/D144996 * style: Factor out parsing the query feature name No behavior change. Differential Revision: https://phabricator.services.mozilla.com/D145229 * style: Refactor media feature expression representation in preparation to support multi-range syntax No behavior change. Depends on D145229 Differential Revision: https://phabricator.services.mozilla.com/D145230 * style: Implement media feature expression multi-range syntax Differential Revision: https://phabricator.services.mozilla.com/D145231 * style: Remove proton places tooltip code There's nobody working on it, and tooltips should hopefully be nice enough after recent changes (bug 1765423). Having it enabled causes artifacts like bug 1767815 comment 3. We can always rescue this from hg history if needed. Differential Revision: https://phabricator.services.mozilla.com/D145621 * style: Simplify selector flags setup even more In my investigation for bug 1766439, I am digging into why selector matching regressed. It doesn't help that the selector-matching code is instantiated a gazillion times (so there's a ton of copies of the relevant functions). This was needed in the past because we had different ways of setting the selector flags on elements, but I unified that recently and now we only need to either set them or not. That is the kind of thing that MatchingContext is really good for, so pass that instead on MatchingContext creation. Differential Revision: https://phabricator.services.mozilla.com/D145428 * Further changes required by Servo * style: Track @container condition id in style rules Much like we track layer rules. Consolidate that "containing rule state we pass down while building the cascade data" in a single struct that we can easily restore. For now, do nothing with it. I want to land this patch separately because it touches the Rule struct and CascadeData rebuilds, which both are performance sensitive. Its layout shouldn't change because I also changed LayerId to be a u16 (this shouldn't matter in practice, since LayerOrder is already a u16). Differential Revision: https://phabricator.services.mozilla.com/D145243 * Further changes required by Servo * style: Fix layer statement rules with multiple layer names MANUAL PUSH: Trivial orange fix CLOSED TREE. * style: Implement piecewise linear function Differential Revision: https://phabricator.services.mozilla.com/D145256 * style: Convert specified value tests to compile-time tests These were written at a time where std::mem::size_of wasn't a `const fn` in Rust. Now that it is, we can make these tests live in the style crate, and the build not to compile if they fail. Differential Revision: https://phabricator.services.mozilla.com/D146103 * Further changes required by Servo * style: Move size of tests to compile-time tests in the style crate Same reasoning as the previous commit. Differential Revision: https://phabricator.services.mozilla.com/D146104 * Further changes required by Servo * style: Lint and 32-bit build fix. MANUAL PUSH: Bustage fix CLOSED TREE * style: Implement 'update' media feature Differential Revision: https://phabricator.services.mozilla.com/D146338 * style: Clean up unused -moz-window-shadow values After bug 1768278 and bug 1767815 there's no more uses of the cliprounded value in the tree (also it causes artifacts on HiDPI screens so we probably don't want new usages). The "sheet" value is unused, and the other values other than "default" and "none" are only derived from "default", so they don't need to be exposed in the style system. Differential Revision: https://phabricator.services.mozilla.com/D145821 * style: More container queries plumbing Provide container information in computed::Context and use it to resolve the container queries. This still fails a lot of tests because we are not ensuring that layout is up-to-date when we style the container descendants, but that's expected. Differential Revision: https://phabricator.services.mozilla.com/D146478 * Further changes required by Servo * style: Ensure options in listbox selects are not stacking contexts by default We could have a different property or something but this seems reasonable as well probably. Differential Revision: https://phabricator.services.mozilla.com/D146994 * style: Implement overflow-clip-margin: <length> Differential Revision: https://phabricator.services.mozilla.com/D146432 * style: Change order of container shorthand Since the initial value of container-type is an open issue [1], I'm leaving that as-is for now. [1] w3c/csswg-drafts#7202 Differential Revision: https://phabricator.services.mozilla.com/D147338 * style: Make modal dialog code more generic, and make it apply to fullscreen too behind a pref For now, don't turn it on by default yet, because I want to wait for more discussion in w3c/csswg-drafts#6965 and so on. But I think the code is simple enough to land this. Differential Revision: https://phabricator.services.mozilla.com/D147295 * style: Cache computed styles objects display: none subtrees This reuses our existing undisplayed style generation, but in a per-document rather than per-nsComputedDOMStyle object, which means that we can avoid re-resolving styles of elements in display: none subtrees much more often. This brings the test-case in the bug to par with other browsers or better, and is much simpler than the initial approach I tried back in the day. Differential Revision: https://phabricator.services.mozilla.com/D147547 * Further changes required by Servo * style: Parse scroll-snap-stop style and propagate it to APZ side Depends on D146147 Differential Revision: https://phabricator.services.mozilla.com/D145850 * style: Update color-mix() syntax to match the current spec Test expectation updates for this in the latest patch of the bug. Differential Revision: https://phabricator.services.mozilla.com/D147002 * Further changes required by Servo * style: Make the color interpolation code more generic It's really piece-wise premultiplied interpolation, with a special-case for hue, so centralize the implementation. Differential Revision: https://phabricator.services.mozilla.com/D147003 * style: Implement more color-mix() color-spaces We had code to convert between these and the latest draft supports them so... Differential Revision: https://phabricator.services.mozilla.com/D147004 * style: Fix color-mix() percentage normalization Differential Revision: https://phabricator.services.mozilla.com/D147005 * style: Fix hue adjustment to match the spec The value to sum is tau, not pi. This was caught by some tests, see https://drafts.csswg.org/css-color/#shorter Differential Revision: https://phabricator.services.mozilla.com/D147006 * style: Do hue interpolations in degrees rather than radians. r=barret This gives us a bit more precision. Differential Revision: https://phabricator.services.mozilla.com/D147007 * style: Improve Percentage -> LengthPercentage conversion This doesn't change behavior because we only use them for images that have no clamping. Depends on D147008 Differential Revision: https://phabricator.services.mozilla.com/D147511 * style: Remove some dead vibrancy code Drive-by cleanup. Differential Revision: https://phabricator.services.mozilla.com/D147698 * style: Fix warnings about whitelist/blocklist functions being deprecated in bindgen 0.59 Differential Revision: https://phabricator.services.mozilla.com/D147695 * style: Update style to arrayvec 0.7 Differential Revision: https://phabricator.services.mozilla.com/D147476 * style: Update style to uluru 3.0 Differential Revision: https://phabricator.services.mozilla.com/D147477 * style: Remove -moz-scrollbar-thumb-proportional It unconditionally matches on all platforms, so it's not returning any useful information. Depends on D147689 Differential Revision: https://phabricator.services.mozilla.com/D147690 * style: Use ColorMix for interpolated colors in the computed style rather than ComplexColorRatios This among other things preserves the right color-space when interpolating currentColor. Differential Revision: https://phabricator.services.mozilla.com/D147512 * Further changes required by Servo * style: Add an input-region-margin to widgets, and implement it on Linux Recompute the input region when resizing the widget and so on, and use it to check for rollups. Depends on D148211 Differential Revision: https://phabricator.services.mozilla.com/D148222 * Avoid complaints from ./mach test-tidy * Update test expectations --------- Co-authored-by: Emilio Cobos Álvarez <emilio@crisal.io> Co-authored-by: Brad Werth <bwerth@mozilla.com> Co-authored-by: David Shin <dshin@mozilla.com> Co-authored-by: Hiroyuki Ikezoe <hikezoe.birchill@mozilla.com> Co-authored-by: Nika Layzell <nika@thelayzells.com> Co-authored-by: Boris Chiou <boris.chiou@gmail.com> Co-authored-by: Autumn on Tape <autumn@cyfox.net> Co-authored-by: Mike Hommey <mh+mozilla@glandium.org>
…screen too behind a pref For now, don't turn it on by default yet, because I want to wait for more discussion in w3c/csswg-drafts#6965 and so on. But I think the code is simple enough to land this. Differential Revision: https://phabricator.services.mozilla.com/D147295
HTML defines that the
<dialog>element has an "is modal" flag, and uses that as a styling hook. We just discussed adding some more properties to modal dialogs in the UA stylesheet, which would need to do the same.This should just be handled as a real pseudo-class, rather than an abstract "pretend these styles were applied as if from the UA stylesheet".
@emilio @bfgeek @smfr
The text was updated successfully, but these errors were encountered: