Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[selectors] Add :modal-dialog pseudo-class #6965

Closed
tabatkins opened this issue Jan 19, 2022 · 76 comments
Closed

[selectors] Add :modal-dialog pseudo-class #6965

tabatkins opened this issue Jan 19, 2022 · 76 comments

Comments

@tabatkins
Copy link
Member

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

@bfgeek
Copy link

bfgeek commented Jan 19, 2022

@mfreed7

@bfgeek
Copy link

bfgeek commented Jan 19, 2022

@josepharhar

@mfreed7
Copy link
Contributor

mfreed7 commented Jan 19, 2022

I'm strongly in favor of exposing a pseudo class for things in the top layer. So let's not call it :modal-dialog, let's call it :top-layer, and have it apply to modal <dialog>, full screen elements, and (in the future), anything else that is located in the top layer such as popup elements.

@tabatkins
Copy link
Member Author

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.

@vmpstr
Copy link
Member

vmpstr commented Jan 19, 2022

"being in the top layer" is something that should be doable from CSS.

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?

@tabatkins
Copy link
Member Author

Yeah, it's been in the cards for a long time.

@mfreed7
Copy link
Contributor

mfreed7 commented Jan 20, 2022

@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 :top-layer pseudo. It would be independent from "how" an element gets to the top layer, right?

@vmpstr
Copy link
Member

vmpstr commented Jan 20, 2022

Having said that, I don't see why there can't be a :top-layer pseudo

I think the hard part is something like

div { top-layer: yes }
div:top-layer { top-layer: no }

@mfreed7
Copy link
Contributor

mfreed7 commented Jan 20, 2022

Having said that, I don't see why there can't be a :top-layer pseudo

I think the hard part is something like

div { top-layer: yes }
div:top-layer { top-layer: no }

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.

@vmpstr
Copy link
Member

vmpstr commented Jan 20, 2022

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

@SebastianZ
Copy link
Contributor

For reference, there's a discussion around selectors that depend on layout in #5979.

Sebastian

@mfreed7
Copy link
Contributor

mfreed7 commented Jan 20, 2022

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

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 position:top-layer property), what would happen in this case? Would computedStyle still say position:top-layer? Worse, how would one re-request top layer access in this case? By removing the property and re-adding it? The issue is that CSS can’t really be modified by the UA. But if top layer access was provided by something like <div toplayer>, then the UA could just remove the attribute when needed.

@vmpstr
Copy link
Member

vmpstr commented Jan 20, 2022

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 :top-layer selector is likely to cement the fact that we can't add things to top layer with CSS, so it's important to understand whether or not CSS will ever be able to add things to top layer :)

@tabatkins
Copy link
Member Author

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 body and abspos or fixposing them. The point of the top layer is just convenience - because we reparent the element's box, it avoids things like scrollable ancestor clips automatically so you can put the element where it's convenient rather than always making it a body child.

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 video fullscreen button to mess up the entire page unless the author specifically handled exitting fullscreen; similarly with modals. If the UA provides, the UA should take away as well, for good user experience. But browsers don't have the ability to automatically dismiss home-brewed dialogs that are just abspos divs living at the end of body, because that's done entirely by the page author and it's their responsibility to control it and dismiss it.


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.

@mfreed7
Copy link
Contributor

mfreed7 commented Jan 21, 2022

So there's something somewhat magical about the top layer. It provides a guaranteed-on-top paint order, regardless of max(z-index) on the page. And as such, it gets some special attention from the UA to make sure it's being managed for the user. For example, both fullscreen and <dialog> have explicit provisions for the UA taking action to close the fullscreen/dialog for the user. (For fullscreen here, and dialog here.) In either of those cases, that works because they're both controlled via JS. However, if you provide access to the top layer via a CSS property, similar concerns will exist: the UA will need the power to remove those elements from the top layer in some cases, even if a position:top-layer CSS rule still matches the element. And when that happens, how do things work? See the questions here.

@Loirooriol
Copy link
Contributor

I'm not sure the UA would "need the power to remove those elements from the top layer".
If an author adds a position: fixed element as a direct child of the root, with a very high z-index, then it kind of behaves like in the top layer, and is painted on top of other contents. The UA offers no way to remove that element, and it's fine.

@chrishtr
Copy link
Contributor

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'm not sure the UA would "need the power to remove those elements from the top layer".

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.

If an author adds a position: fixed element as a direct child of the root, with a very high z-index, then it kind of behaves like in the top layer, and is painted on top of other contents. The UA offers no way to remove that element, and it's fine.

Yes, but that's not the top layer. That's the "developer layer".

@tabatkins
Copy link
Member Author

So there's something somewhat magical about the top layer. It provides a guaranteed-on-top paint order, regardless of max(z-index) on the page.

I mean, that's just the definition of it, sure. Nothing about that implies that it can't be used by author-level CSS.

However, if you provide access to the top layer via a CSS property, similar concerns will exist: the UA will need the power to remove those elements from the top layer in some cases

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 body and giving them a high z-index. The UA doesn't need the ability to remove those elements - what's different here?

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.

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 dialog-equivalents, for example.

@ByteEater-pl
Copy link

Would any value of contain prevent this behaviour? Or does it for the non-CSS styling currently applied to dialog elements by browsers? Is a new containment type needed? In general a prevention mechanism would be desirable, especially if you're using third party components and want to make sure they cannot interfere with anything outside the space you assign them.

@chrishtr
Copy link
Contributor

However, if you provide access to the top layer via a CSS property, similar concerns will exist: the UA will need the power to remove those elements from the top layer in some cases

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 body and giving them a high z-index. The UA doesn't need the ability to remove those elements - what's different here?

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.

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.

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 dialog-equivalents, for example.

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.

@mfreed7
Copy link
Contributor

mfreed7 commented Jan 25, 2022

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.

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.

@mfreed7
Copy link
Contributor

mfreed7 commented Jan 25, 2022

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.

@chrishtr
Copy link
Contributor

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.

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?

@tabatkins
Copy link
Member Author

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?

All of these questions/issues apply exactly equally to developers putting things "on top" today, by making them a final child of body with a high z-index. They'll be below the UA-provided "top layer" stuff, yeah. Why are these cases not problematic already?

@mfreed7
Copy link
Contributor

mfreed7 commented Jan 26, 2022

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?

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.

All of these questions/issues apply exactly equally to developers putting things "on top" today, by making them a final child of body with a high z-index. They'll be below the UA-provided "top layer" stuff, yeah. Why are these cases not problematic already?

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.

@fantasai fantasai added the selectors-4 Current Work label Jan 26, 2022
@smfr
Copy link
Contributor

smfr commented Jan 28, 2022

"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.

@ByteEater-pl
Copy link

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?

@smfr
Copy link
Contributor

smfr commented Jan 28, 2022

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.

@lkj4
Copy link

lkj4 commented May 25, 2022

So, currently I can't position <dialog /> properly, e.g. putting it at the bottom center of the screen, crucial on huge mobile phones and close to where the thumb is.

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?

@emilio
Copy link
Collaborator

emilio commented May 25, 2022

It wasn't clear from the resolution that :modal should also apply to fullscreen elements, but the spec includes them, what gives? I think WebKit's implementation limits them to modal dialogs.

@emilio
Copy link
Collaborator

emilio commented May 25, 2022

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>

@lkj4
Copy link

lkj4 commented May 25, 2022

:modal should also apply to fullscreen elements,

wdym? can you share some examples?

@emilio
Copy link
Collaborator

emilio commented May 25, 2022

https://drafts.csswg.org/selectors/#modal-state says:

For example, the dialog element is :modal when opened with the showModal() API. Similarly, a :fullscreen element is also :modal when opened with the requestFullscreen() API, since this prevents interaction with the rest of the page.

Which seems to hint that :modal should always match when :fullscreen matches. But as per above that's not necessarily true.

@emilio
Copy link
Collaborator

emilio commented May 25, 2022

I guess it would make sense for fullscreen to match :modal iff it makes the document modal.

@chrishtr
Copy link
Contributor

The spec text should not include fullscreen, that was not part of the resolution. :modal only applies when the element is in a truly modal state, which fullscreen is not.

@mfreed7
Copy link
Contributor

mfreed7 commented May 25, 2022

The spec text should not include fullscreen, that was not part of the resolution. :modal only applies when the element is in a truly modal state, which fullscreen is not.

+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:

a UI state that shows certain sub-parts of a UI, intentionally makes inert the rest of the UI while showing the sub-part, and requires an intentional action from the user to dismiss it. The element when shown via showModal meets this definition; so does an alert or confirm box.

Per that definition, fullscreen doesn't meet the definition - it does not "intentionally make inert the rest of the UI".

@nt1m
Copy link
Member

nt1m commented May 25, 2022

a UI state that shows certain sub-parts of a UI, intentionally makes inert the rest of the UI while showing the sub-part, and requires an intentional action from the user to dismiss it. The element when shown via showModal meets this definition; so does an alert or confirm box.

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.

@mfreed7
Copy link
Contributor

mfreed7 commented May 25, 2022

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

Yes, I agree Chromium makes the page inert but is this in the fullscreen spec somewhere? I definitely could have missed it, but I don't think it talks about making the page inert.

I'd agree that if this behavior is (or becomes) per-spec, then :modal should likely apply for fullscreen elements.

@chrishtr
Copy link
Contributor

I filed issue #7311 for whether fullscreen should be modal. In the meantime let's remove fulllscreen from the :modal spec.

@chrishtr
Copy link
Contributor

Reopening until the spec edit is made.

moz-v2v-gh pushed a commit to mozilla/gecko-dev that referenced this issue May 31, 2022
…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
aosmond pushed a commit to aosmond/gecko that referenced this issue Jun 3, 2022
…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
Loirooriol pushed a commit to Loirooriol/servo that referenced this issue Aug 15, 2023
…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
Loirooriol pushed a commit to Loirooriol/servo that referenced this issue Aug 15, 2023
…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
github-merge-queue bot pushed a commit to servo/servo that referenced this issue Aug 15, 2023
* 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>
github-merge-queue bot pushed a commit to servo/servo that referenced this issue Aug 15, 2023
* 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>
mrobinson pushed a commit to servo/servo that referenced this issue Aug 16, 2023
…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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests