- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 01 Apr 2020 23:36:44 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-color-adjust-1] Cascade within forced-colors MQ`. <details><summary>The full IRC log of that discussion</summary> <dael> Topic: [css-color-adjust-1] Cascade within forced-colors MQ<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/4178<br> <dael> Rossen_: Is fantasai on?<br> <dael> Rossen_: I'll introduce.<br> <dael> Rossen_: Brought up by some framework devs when starting to adopt new forced colors MQ and forced colors adjust properties<br> <dael> Rossen_: Feedback is in contrast to previous impl in IE and Edge when used high-contrast and high-contrast-adjust the MQ and the way properties inside MQ evaluate is sign different<br> <dael> Rossen_: Boils down to it's currently...ergonomocs are such that if you decide to adjust a single color properties inside a forced color MQ you have to take over entire styling of elements<br> <dael> astearns: Because the forced color wins of MQ declaration?<br> <dael> Rossen_: NO. Current way to do it is you have to set foced color adjust to none inside the selector in the MQ. Once selected yoru lemeents, set it to none. Means you're taking the entire element and its subtree from forced color being applied<br> <dael> astearns: Why need to say none?<br> <dael> Rossen_: To change border color for ex<br> <dael> astearns: B/c forced color will otherwise override?<br> <dael> Rossen_: Correct.<br> <dael> Rossen_: We have a MQ that detects forced color adjust. Just like in example. When forced colors evaluates active inside MQ you do whatever you want. In this case select disabled = true elements. Wants to set the color of those to gray<br> <dael> Rossen_: To do this today you have to set forced-color adjust to none. Otherwise color would be window color<br> <dael> Rossen_: Making sense?<br> <dael> astearns: Yes<br> <dael> Rossen_: Previous to that high contrast impl we had we allowed individual prop to apply to individual elements. Color for that one property would override.<br> <heycam> q+<br> <dael> Rossen_: That's the proposal of this change when it started. Since there was discussion between AmeliaBR emilio and fantasai.<br> <dael> Rossen_: fantasai prop which I want to understand better is to do it other way around. Spec properties except ones you want to adjust. So forced colors except in this case border-stroke<br> <dael> Rossen_: Some support to this, but not seeing it recorded<br> <astearns> ack dbaron<br> <dael> astearns: Not sure anyone is agreeing with fantasai prop except something like it need to happen<br> <chrishtr> q+<br> <dael> dbaron: Was going to say I think a way to frame this is what we want is more granular way to override forced colors. A property that's everything or nothing isn't granular enough. Peopl care about properties or maybe declarations. Maybe makes sense to re-title issue?<br> <dael> dbaron: I think there's a 3rd option, complex, but have it in value of prop rather than sep prop. In hindsight when we have a property that modifies how another works we end up regretting. I think this is like box sizing in that way. But that's a lot of syntaxes to modify. Not sure if there's a more elegent way to do it.<br> <astearns> ack heycam<br> <dael> heycam: I wanted to agree with emilio initial comment finding it confusing if we change depending on what properties are inside. In favor of some opption that makes it more explicit be that fantasai prop or something like dbaron<br> <TabAtkins> q+<br> <dael> heycam: Question on MQ itself. Does it respond to value of [missed]> Forced color property determines if MQ matches?<br> <dael> chrishtr: I believe prop is not MQ but another property or value that overrides instead.<br> <TabAtkins> So a possible "adjust the value" option is to finally jump into using new ! options. Like `!override-forced-color`, so that *if* this declaration wins the cascade, it's allowed to override a forced color.<br> <dael> astearns: It's an alternative we're discussing but so far no one on thread has liked prop to having MQ allow override<br> <dael> heycam: Question is what determines if the MQ matches. Is it the property that enables forced color adjusting on a subtree?<br> <dael> Rossen_: Request is to enable single properties on selected items to take precedence over forced color<br> <astearns> q?<br> <dael> Rossen_: Target BG color which is set to canvas. If you select a given element within forced color acive MQ we would have allowd bg color to take precedence over forced color.<br> <TabAtkins> Then we switch forced-colors mode to, rather than using the cascade and UA-!important rules, instead just use magic to win the cascade automatically, *unless* the cascade-winning declaration has the appropriate ! on it.<br> <dael> Rossen_: Now to do it you have to first set foced-color-adust to none and take over everything by your self<br> <dael> heycam: Property to turn it to none would that make MQ not match?<br> <dael> Rossen_: NOt really. Mode of browser is still active<br> <dael> heycam: MQ is the overall mode, not individual sub trees where you set htat property<br> <dael> Rossen_: Yeah<br> <dael> heycam: Cool.<br> <TabAtkins> (And because we're using magic, this allows us to handle multiple such override modes in the future, if we introduce them, by internally handling conflicts, rather than trying to rely on the cascade to resolve them.)<br> <dael> astearns: Anything else heycam ?<br> <astearns> ack chrishtr<br> <dael> heycam: No<br> <dael> chrishtr: When you enforce colors mode I think there is no defined spec for what UA does. Right?<br> <dael> Rossen_: Not correct. Spec defining this is css-color-adjustment<br> <dael> chrishtr: Spells out exact stylesheets applied?<br> <astearns> https://www.w3.org/TR/css-color-adjust-1/#forced<br> <Rossen_> https://drafts.csswg.org/css-color-adjust-1/#forced-color-adjust-prop<br> <dael> Rossen_: We have the exact stylsheet? Asking if we define UA stylesheet?<br> <dael> Rossen_: No, we define colors are reverted to system colors. System colors are defined in Colors module<br> <dael> chrishtr: Different than heuristic darkening of page<br> <dael> Rossen_: Yes<br> <dbaron> https://drafts.csswg.org/css-color-adjust-1/#forced-colors-properties is somewhat well-defined, I think<br> <dael> chrishtr: Any override is predictable to dev<br> <dael> Rossen_: Yep<br> <dael> chrishtr: Got it, thank you<br> <astearns> ack TabAtkins<br> <dael> TabAtkins: I wrote stuff in IRC.<br> <dael> TabAtkins: Revisiting dbaron about building funcitonality into property value space. We do have a spot to do that in syntax with guar compat. Using stuff after ! which we only use for one thing. Syntax spec allows for more<br> <dael> TabAtkins: Possible way to address particular properties overriding forced color and to simplify is first switch forced color to magically win cascade regardless of author. THen allow author spec after a ! they override forced color. Say it's explicitly meant even if forced. If it wins cascade it doesn't get overwritten<br> <dael> TabAtkins: Same as figuring out how to insert a new keyword but allows completely consistant regardless of value space. Auto-extensible to future things. As well having forced colors apply magically gives more flexibility if we have to add more things like this<br> <florian> q?<br> <florian> q+<br> <dael> TabAtkins: THen can have resolution rules based on whatever arbitratry requirements we need. Without having to worry about cascade we let ! and author cascade determine<br> <dael> Rossen_: Question. Your prop is !override after property?<br> <dael> TabAtkins: Yeah<br> <dael> Rossen_: Like it. Pretty cool<br> <dael> TabAtkins: ! value space is allowed multi value so you can do !important override so we're not limiting authors<br> <dael> astearns: Talking about a generic ! override or !over-forced-colors<br> <dael> TabAtkins: More specific one<br> <dael> florian: On one hand what TabAtkins desc makes snese for this and has future extensibility. Does feel a lot like additional cascade origins. Not long ago had prop from miriam about having control over these things. I wonder if we shouldn't try harder to figure out that story. Various levels of cascade origin feels like what we're doing here. Worth exploring before being sure that's not it<br> <Rossen_> ack florian<br> <dael> TabAtkins: DOn't believe it's similar. While UA provided forced colors live on a high cascade, cascade-origins doesn't allow selective override unless we allow opt into even higher cascade. I like my proposal b/c doesn't have author cascade finnagle. They have existing rules and if they happen to be rules that should apply even in case of forced colors you add an indicator vs having a different cascade that auto-wins over another cascade that auto-wins<br> <dael> TabAtkins: You have one instance auto-winning all the time in that case and that may not be what you want<br> <dael> miriam: Agree with TabAtkins. Feels different use case. I'd be willing to dig in further to see if overlap but offhand seems not same problem<br> <Rossen_> q?<br> <dael> astearns: Other opinions?<br> <Rossen_> ack dbaron<br> <dael> dbaron: Reference to custom cascade brought an interesting question. If an author has rules they want to override forced colors and other rules that would normally override them what happens? Do we want that to be possible? Maybe one arg is if author says this overrides forced color it overrides all the other rules.<br> <dael> dbaron: Maybe want authors to do that. SOme of these have confusing outcomes. Might think someone wants it, but may be 1 person wants and 99 are confused. Makes me think maybe more like custom-cascade origins. Maybe this is a little more like cascade. Worth thinking about what we want to allow and what's too confusing<br> <dael> florian: I think we can do 3 things. One is you set super override and always wins. Another is super override doesn't win if you've overwritten it with the normal cascade. Asking for trouble b/c people won't test with forced colors<br> <dael> dbaron: 3 is horrible<br> <dael> TabAtkins: Writing down 1, 2, and 3 would be good<br> <dbaron> 1. color: blue ! override always beats color: red, even if red would normally win the cascade<br> <dael> florian: If you have blue in yoru normal cascade which wins then red !white with specificifity that doesn't win it's still blue. THe red lost alreay. That's 1<br> <dbaron> 2. color blue ! override and color: red cascade normally, and if red wins in the cascade, then there's no longer an override and the blue just gets ignored<br> <dael> florian: 2 is ! override makes red more important than forced color and more important than blue. Implicitly important<br> <dael> florian: 3 which is bad is if !override-red lioses to blue in normal and over blue and system in forced.<br> <dael> TabAtkins: Agree. 1st is per declaration. 2nd is mega-important. 3rd is bad<br> <dael> dbaron: I think first is mega important<br> <dael> TabAtkins: Do we want to take this with the two good options to the issue? Or decide now?<br> <dael> astearns: Rossen_?<br> <dbaron> Issue discussion, I thnik -- there's a ton of stuff to sort out here.<br> <dael> Rossen_: It's easy to discount option 3. Exploring 2 is interesting but i'm hesitant on mega-important.<br> <TabAtkins> I mean, !mega-important is just Custom Cascade Origins<br> <dbaron> This 1/2/3 thing is a discussion within a discussion.<br> <dael> Rossen_: If we can agree on 1 vs 2 that's a path forward to experiment and see how it works<br> <dael> dbaron: Feel like 1 vs 2 is a discussion in a discussion and there's large points to sort out. Better in the issue<br> <dael> astearns: Can resolve that we'll solve this issue in the value space<br> <dael> TabAtkins: As opposed to properties, yeah<br> <dael> dbaron: When I said value space I wouldn't have counted TabAtkins proposal as there, but I like TabAtkins proposal<br> <dael> Rossen_: I like it as well<br> <heycam> if there are many properties to override to adapt to the forced color mode I wonder if it will be onerous to write an !override on every property declaration<br> <dael> astearns: Let's take it back to the issue for now since we have alternatives and people like emilio and fremy with strong opinions. THen we can hopefully resolve soon.<br> <TabAtkins> (Given a time machine, I'd have proposed adding `!border-box` to the sizing properties, rather than box-sizing. ^_^)<br> <dael> astearns: Any last words?<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4178#issuecomment-607541234 using your GitHub account
Received on Wednesday, 1 April 2020 23:36:47 UTC