-
Notifications
You must be signed in to change notification settings - Fork 715
[css-color-adjust-1] accent-color in Forced Colors Mode #5987
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
Comments
If adjust is set to none, I don't think accent color should be reset. But, more generally, it probably isn't necessary to do anything with this property btw because, in forced colors mode, browsers can just decide not to use the accent color in their firm control design, right ? |
@FremyCompany yeah, honoring |
The CSS Working Group just discussed
The full IRC log of that discussion<dael> Topic: [css-color-adjust-1] accent-color in Forced Colors Mode<dael> github: https://github.com//issues/5987 <dael> alisonmaher: This is around adding accent-color to prop adjusted in forced color mode. Similar to scrollbar where force to auto. Question is what should happen w/ forced color adjust. Rest of control isn't adjustable. fremy makes sense, though. Should be honored but up to UA how to apply. <dael> alisonmaher: Does that sound good or are there other options to look at? <dael> fantasai: If it's none we shouldn't force colors. Main q is do we force it to auto or do we allow it to be a color <fantasai> s/color/system color/ <dael> astearns: Other opinions? <dael> fantasai: I lean toward force to auto. Author doesn't know what system color will be and since trying to make page match colors user is comfortable with pushing to auto makes more sense <tantek> regrets+ <dael> astearns: fremy comment seems to imply if adjustment is set to none other colors are reset? <Rossen_> q? <dael> fremy: Not the case. If adjust is none we should not touch property. But maybe we don't need to do anything. UA isn't forced to do anything with it. Saying it does not really matter. We can switch to auto, but easier to impl that we do nothing <dael> fantasai: Could add a note UA could do that <dael> fremy: Yeah <dael> fantasai: Prop would be add a note what UA can ignore accent color in forced colors mode where it wouldn't otherwise <dael> astearns: Add to the list but then say not really? <nicole> what would happen with say a black and white display on an ereader <dael> fantasai: Property value would stay at what set at. UA if and how it uses an accent color...well...we do define if ther is an accent color you have to change. So I think force to auto. This is used value time operation <dael> fantasai: We do require if you have something desc as an accent color then the property does change it <dael> astearns: fremy you okay force to auto? <fantasai> nicole, that e-reader wouldn't have an accent-color, so accent-color would not have any effect <dael> fremy: Yeah. Doesn't matter sinc can't observe as a user. Whatever is easier <dael> astearns: Prop: Add accent color to list of properties adjusted and have it adjusted to auto <dael> alisonmaher: Sounds right <dael> astearns: Obj? <dael> RESOLVED: Add accent-color to list of properties adjusted and have it adjusted to auto |
It seems like we should probably add
accent-color
to the list of properties that are adjusted in Forced Colors Mode.Forcing this to
auto
seems like the obvious choice, similar toscrollbar-color
. However, what should happen ifforced-color-adjust
is set tonone
oraccent-color
is set to a system color? Should we ignore those and forceaccent-color
toauto
no matter what, or should we honor the adjust rules to allow author customization?The text was updated successfully, but these errors were encountered: