- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Fri, 15 Sep 2023 14:01:24 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed ``[css-anchor-position-1] Define interaction with the cascade in `@try` ``, and agreed to the following:
* `RESOLVED: !important must win and the issue of putting @try properties in their place in the cascade will be investigated`
<details><summary>The full IRC log of that discussion</summary>
<emeyer> TabAtkins: When you are doing fallback positions, you’re overwriting various properties<br>
<emeyer> …The question is, what does it mean to do that?<br>
<emeyer> …Right now, it means you’re overwriting values, which means it’s higher than specificity, because when you’re doing layout, the cascade has already been resolved<br>
<xiaochengh> q+<br>
<emeyer> …You might not always want to do that, but implementation seems hard<br>
<emeyer> xiaochengh: Right now, fallback is completely post-cascade<br>
<emeyer> …If we want to make it part of cascade, it’s very to specify in that way<br>
<emeyer> …It’s sort of like the container query situation, where part of the stlye depends on layout<br>
<emeyer> …For at least level 1, we want to avcoid this problem and make it a post-cascade effect<br>
<emilio> Just realized I filed this as https://github.com/w3c/csswg-drafts/issues/9229<br>
<iank_> q+<br>
<astearns> ack xiaochengh<br>
<emeyer> …There’s a related issue that fallbacks override all the !important style, which is counterintuitive to authors<br>
<emeyer> …If we want to stop that, it’s actually implementable<br>
<emeyer> …I propose we keep it so it doesn’t participate in the cascade but does not override !important<br>
<emeyer> TabAtkins: Does this mean we keep around a notion of whether a styles was important or not past the end of the cascade resolution?<br>
<emeyer> xiaochengh: Currently we don’t allow too many properties in fallbacks<br>
<emeyer> …So we can add a flag whether a value is important or not<br>
<astearns> ack iank_<br>
<emeyer> TabAtkins: So it would still be an addition, but a much easier one, got it<br>
<emeyer> iank_: It’s somewhat different to the container query case<br>
<emeyer> …Here we’re messing around with the style of the thing we’re targeting<br>
<dbaron> （I have vague memories of this approach being taken for compositor animations in some engine, though I don't remember which engine!)<br>
<dbaron> (and compositor animations have the similar characteristic that they're for a limited set of properties)<br>
<emeyer> …If the !important case can be done, but for simplicity’s sake people don’t think it’s important, mild preference to keep things simple<br>
<astearns> ack fantasai<br>
<jensimmons> q+<br>
<emeyer> fantasai: My take is that it’s not okay to have stuff that some lower level of the cascade can insert but can’t be written by !important<br>
<emeyer> …We fixed it for animations and should not create the problem here<br>
<astearns> +1 to not overriding !important. It would be an attractive nuisance for CSS crimes<br>
<TabAtkins> +1 to what fantasai's saying wrt bad to make something not overrideable<br>
<emeyer> …The more styles we allow into @try blocks, the bigger this problem will become<br>
<emeyer> …You end up with a problem where somebody who’s set up these styles end up with it slotted into the wrong part of the cascade<br>
<TabAtkins> and we use UA !important for some invariants, bad to defeat that<br>
<emeyer> …At a minimum, we need to fix this for !important<br>
<emeyer> …But we also need to have things interact with the cascade at the level they entered it<br>
<astearns> ack jensimmons<br>
<emeyer> (scribe missed)<br>
<TabAtkins> TabAtkins: The fallback doesn't really have an associated style rule, does it?<br>
<emeyer> jensimmons: I feel like it would be confusing for authors to have a certain hole in the ground where if they step in it, everything they do there overrides everything else<br>
<TabAtkins> fantasai: The rule that applies the 'position-fallback' prop.<br>
<astearns> +1 to jensimmons<br>
<emeyer> …Why would we do that? The cascade is so core to CSS<br>
<fantasai> [note to Dael, that comment from me is in response to Tab above, goes higher]<br>
<emeyer> …I get that there’s a problem with implementing, which is a sign that we need to keep going and figure this out<br>
<fantasai> +1 to jensimmons<br>
<emeyer> fantasai: I don’t know if my proposal is the best idea<br>
<kizu> q+<br>
<emeyer> …I agree with Jen that we should figure this out<br>
<jensimmons> Yes, I didn't say, but I believe that just having !important have effect, but not everything else is a problem.<br>
<emeyer> xiaochengh: We still have another problem of having to run layout to decide which fallback to use<br>
<emeyer> …Without seeing a solution for that, I don’t see how we b ring fallbacks to the cascade<br>
<emeyer> TabAtkins: I believe it would work as what you described for !important, just more complicated<br>
<emeyer> …When a fallback is chosen, we’d record the necessary cascade information and do the same for all overwritable properties, and then compare them<br>
<emilio> q+<br>
<emeyer> …This is a more complicated version of what you describe for !important<br>
<emeyer> …Instead of a boolean for !important, we’d store more complicated information<br>
<astearns> ack dbaron<br>
<Zakim> dbaron, you wanted to react to jensimmons<br>
<emeyer> dbaron: An alternate of describing what Tab just said is that you can think of it as turning every property that can be overridden by the try blocks into a shorthand<br>
<TabAtkins> oooh yeah that works<br>
<TabAtkins> weird but it woudl be internal<br>
<emeyer> …that sets a bunch of booleans you than check to see if overriding is okay<br>
<astearns> ack kizu<br>
<emeyer> …This turned out to be awful when we did it for directionality, and it’s a lot of overhead, but it’s a way of thinking about it<br>
<emeyer> kizu: +1 to Jen; from an author perspective, it can be hard to tell where styles come from<br>
<emeyer> …This would be another case where the author doesn’t know where the styles come from<br>
<emeyer> …If it’s hard for implementation to lay out things in a way that’s not outside the scope of the current rule, we should at least be able to override with !important<br>
<TabAtkins> (when we're done with the q, i have a proposed resolution)<br>
<emeyer> …Ideally, this is a case where we’d want to consider other cases like area positioning<br>
<emeyer> …In my experiments with trying to use variables in @try rules, we have to repeat a lot of things<br>
<astearns> custom property use in @try is a *good* consideration<br>
<emeyer> …Maybe the proposals of Miriam with functions could help<br>
<emeyer> …I don’t know if the fallbacks with the current anchor positioning is something okay<br>
<emeyer> …As an author, I’d be kind of okay with fallback later rather than right now<br>
<emeyer> …Fallbacks are not that well formed and it would b e nice to consider area fallbacks as well<br>
<emeyer> emilio: Excluding insets from fallbacks seems okay<br>
<emeyer> …Changing position is not all that bad, because you can read the used value<br>
<iank_> q+<br>
<emeyer> …If you’re going to change order etc., it becomes really confusing<br>
<astearns> ack emilio<br>
<astearns> ack iank_<br>
<emilio> emilio: revert might make it harder<br>
<emeyer> iank_: Reply to emilio: we may file an issue to revisit border-padding speficially<br>
<emeyer> s/speficially/specifically/<br>
<fantasai> border padding issue -> https://github.com/w3c/csswg-drafts/issues/9195<br>
<emilio> emilio: haven't fully grasped dbaron's proposal but I think you might need to keep track of declarations that would otherwise be ignored<br>
<emeyer> TabAtkins: I propose we resolve that !important properties will win over @try blocks and investigate the feasibility of doing proper cascade checking<br>
<emilio> q+<br>
<emeyer> astearns: Concerns?<br>
<emilio> q- later<br>
<emeyer> astearns: Proposed resolution is that !important must win and the issue of putting @try properties in their place in the cascade will be investigated<br>
<emeyer> RESOLVED: !important must win and the issue of putting @try properties in their place in the cascade will be investigated<br>
<emeyer> emilio: I assume the use cases for non-positioning properties in @try are mostly around being able to, if you have an arrow and it’s flipped, the arrow will point the other way<br>
<dbaron> fyi, emilio, I was proposing to handle it similar to the way we handled logical properties when things were only ltr vs. rtl, which didn't extend properly to adding vertical text because it created too many possibilities. Essentially 'top' would become a shorthand for 'top' and 'top-source', and 'position-fallback' (??) would also set 'top-source' but to the other possible value, and then the ...<br>
<emeyer> …I’m not proposing anything like that, but for the record, in Gecko, we do expose position events<br>
<dbaron> emilio, ... computed value of 'top-source' would determine whether the try block could apply 'top'<br>
<emeyer> …Whenever a fallback happens, we would schedule an event so the fallback could be tweaked by CSS<br>
<emeyer> …That’s used for things like making sure arrows point the right direction<br>
<emeyer> iank_: I think we need a container query like thing that lets you style the insides based on the position that was selected<br>
<emeyer> …You might have to add a wrapper and get the desired decorative elements<br>
<emeyer> …We could investigate also adding an event as well<br>
<emeyer> TabAtkins: I think there’s a lot of discussion to be had here about the exact mechanics<br>
<emeyer> …I think we can get something productive out in the future<br>
<emilio> dbaron, ah, interesting... I think my concern is orthogonal. Does `@try {}` allow `revert` / `revert-layer` or so? If so you might need to end up recording arbitrarily many specified values<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9149#issuecomment-1721333819 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 15 September 2023 14:01:26 UTC