[css-color-adjust] Allow authors to define custom color-scheme values.
#9660
Comments
|
To keep it structured I am thinking of a new at-rule, that lists the possible values. @color-scheme ancestry, arc, arc-grey;Not sure if you’d also be able to use this as a block, which could accept globals (two birds, one stone) |
|
The alternative to this is registering them with a JS API? Also should we require a colour scheme be tied to a base light or dark. If an input is set as arc-grey how does it know how to render? |
|
GitHub is a good example where color schemes are tied to a light or dark base. |
Would be nice indeed. Simliar to
I think custom light and dark themes should be separate versions. Looking at VS Code as an example they offer “Solarized Light” and “Solarized Dark”, which are separate things. The registered custom color schemes should also be observable via the Web Preferences API, so that the choice can be set and persisted via JS. |
They would be distinct custom colour schemes but without tying them to either light or dark how does the browser decide how to style native UI using them? Could we allow a color-scheme to provide it's own system color pallete? Like we currently have for light and dark colour schemes? Might not solve the issue if native UI aren't actually using those colours under the hood though? |
|
@lukewarlow I don't think themes are tied to base light / dark. When I think about this issue I always think about Kindle which has light, dark, sepia, and green themes. In particular the green theme doesn't seem to be either a "light" or "dark" base. Testing out their web app, they have a light theme for their UI chrome, but it would work equally well with dark UI chrome. That's a scenario where I'd probably have configurable color schemes on the What i mean: <body data-theme="dark">
<nav><!-- toolbar UI here --></nav>
<article data-theme="green">Article text here</article>
</body> |
|
Hm, we should be clearer on the exact use-case here. The only effect of color-scheme is to change the system color keywords; if you're changing all of the colors to your own chosen set of colors, you can just use your own color custom properties instead. But it does seem like there are two reasonable arguments to make here:
Especially if #2 comes to pass, this does seem pretty useful. Design-wise, hm, we'll need to make sure that it's compatible with us adding more system color keywords in the future. I propose we require you to specify a "base" color-scheme (one of the already-defined ones; no particular need to do a full inheritance chain here), and then you can override any or all of the color keywords; any you don't override get taken from the base. So, like: This would override the "main" colors (text and background) used by everything (page background, inputs, etc), but take any remaining colors from the standard |
|
What do you mean by system colors? |
|
Ok, thanks, I think I understand the |
You can use your custom @color-scheme --solarized-dark {
…
}
html {
color-scheme: --solarized-dark light dark;
}
a {
color: schemed-value(
--solarized-dark yellow,
light red,
dark lime
);`
} |
|
It's rather nitpicky but I don't think color-scheme actually requires a dashed ident. |
|
Right, the property doesn't, to allow for future CSS-defined color schemes. Custom color schemes should absolutely be dashed-idents, precisely to avoid ever clashing with a CSS-defined future one. (Otherwise we'll almost certainly never be able to add a new one, because |
|
Ahh yeah like how it works for stuff like the only keyword that was added. Yeah right that makes sense. |
|
Restricting to dashed idents can be simpler, but it could also be like |
|
@counter-style's ability to do overriding is a special case that we generally don't want to repeat. Counter styles work that way because the set of predefined ones is somewhat large, potentially growing, and fairly arbitrary (so which ones are CSS-defined vs user-defined isn't very obvious); also very important, we didn't want to overly privilege some languages over others by allowing some to be written without dashes (the predefined ones) and other requiring dashes (the author-defined ones). None of these apply in this case (or in most cases) - we have a pretty small, fairly stable set of predefined things, and we don't have any particular cultural-sensitivity reasons to avoid privileging those predefined ones over author-defined ones. |
|
I would favor dashed idents, over a |
|
So something like this? @color-scheme --ancestry, --arc, --arc-grey;
:root {
--foo: schemed-value(
--ancestry yellow,
--arc red,
--arc-grey lime
)
}This way I can define all my colors in one selector, instead of 3 ( You can make it a block if you want to change the system colors and/or provide a scheme for native ui: @color-scheme --ancestry {
base-scheme: dark;
CanvasColor: #002b36;
CanvasText: #93a1a1;
AccentColor: #6c71c4;
} |
|
I cannot tell what your first example is trying to do. Can you elaborate on the actual behavior you expect? |
|
Basically, this: @color-scheme --ancestry, --arc, --arc-grey;
:root {
--color-link: schemed-value(
--ancestry yellow,
--arc red,
--arc-grey lime
)
}
a { color: var(--color-link) }would be equivalent to this: :root.ancestry {
--color-link: yellow;
}
:root.arc {
--color-link: red;
}
:root.arc-grey {
--color-link: lime;
}
a { color: var(--color-link) }Not sure if this is what Bramus had in mind lol. |
|
For the same reason that you'd want to override system colours for custom themes would you not also want to be able to do this for the built in light and dark? Might people just use a custom colour scheme even if they only have 1 dark theme specifically so they can more easily style native UI? |
Originally I thought of only defining custom @color-scheme --ancestry, --arc, --arc-grey;
:root {
--color-link: schemed-value(
--ancestry yellow,
--arc red,
--arc-grey lime
)
}
a { color: var(--color-link) }(Ideally your example should also include This feels like a good approach to pull some one-offs, but that is to be discussed in #7561. What Luke and Tab are suggesting2 3, is to use a I hadn’t originally considered this, but this also makes sense, as it makes things a lot easier. With only these system colors, you can already change the entire site’s appearance. I don’t think these should exclude each other. Combined, I see authors use it like this: /* Define --solarized-dark custom color-scheme, based on dark */
@color-scheme --solarized-dark {
base-scheme: dark;
CanvasColor: …;
…
}
/* This page supports all of these color-scheme values */
html {
color-scheme: --solarized-dark light dark;
}
/* Light Mode colors */
:root {
--link-color: blue;
}
/* Dark Mode colors */
@media (prefers-color-scheme: dark) {
:root {
--link-color: pink;
}
}
/* Custom --solarized-dark colors */
@media (prefers-color-scheme: --solarized-dark) {
:root {
--link-color: yellow;
}
}
/* Ideal usage: use the custom prop that already responds to the chosen color-scheme */
a {
color: var(--link-color);
}
/* Use schemed-value() for one-offs, i.e. for values that are not stored in a custom property that respond to color-scheme */
a.special {
text-decoration-color: schemed-value(--solarized-dark red, light pink, dark lime);
}Footnotes |
Yeah I completely agree. The |
Oh, they were never intended to. A color scheme is a color scheme, if we have What I still don't actually understand, tho, is what your original example is intending to do. I don't see anything activating a color scheme, nor any definition of what those three custom color schemes are. Are they intended to be literally meaningless outside of their ability to trigger I might be missing something obvious about how you're intending that first example to behave, tho. |
Activation:
No. I like what you proposed here, in which an author can define a new color scheme and set the system colors. The minimum required descriptors are only the /* Bare minimum custom color scheme */
@color-scheme --custom-minimum {
base-scheme: dark;
}
/* Fully fledged custom color scheme */
@color-scheme --solarized-dark {
base-scheme: dark;
AccentColor: …;
AccentColorText: …;
ActiveText: …;
ButtonBorder: …;
ButtonFace: …;
ButtonText: …;
Canvas: …;
CanvasText: …;
Field: …;
FieldText: …;
GrayText: …;
Highlight: …;
HighlightText: …;
LinkText: …;
Mark: …;
MarkText: …;
VisitedText: …;
}I see where my reply could be misinterpreted as the first code snippet echos what I initially had in mind … but that initial thought has evolved as this thread grew. The second example in that comment has the full picture, and incorporates your proposal (as also detailed in the code snippet in this comment) … I think we’re thinking the same on this? |
|
Okay, then yeah, we're on the same page. ^_^ |
|
@bramus but |
|
@matthewp Providing a single value to the The used colour scheme will be the singular value. Only when the element supports multiple is there some decision to be made on which one to use (based on user preference). |
|
@lukewarlow is this a new behavior being proposed? I don't see this happening currently, see for ex. https://codepen.io/matthewp/pen/RwvveQd |
|
The reason for your example appearing to not work is because of how color works. It's default value is CanvasText on html but then it inherits. So changing canvas text within the context of the section doesn't change how the CSS value is computed. If you add "color: CanvasText; background-color: Canvas;" to your example you'll see it works. |
|
@lukewarlow Thanks again. I have very rarely seen the system colors used in CSS. I'm guessing probably because they cannot be changed. It seems like this new feature might cause people to use them more (or, maybe it's more correct to say, allow them to be used as defaults). I could see that, even for light and dark schemes, you would define a custom |
|
Summarizing the issue, the current proposal is to allow authors to register custom color schemes through an at-rule. It requires a name (which is a Inside the definition, all System Colors can then be specified. When one is omitted, the one from the @color-scheme --solarized-dark {
base-scheme: dark;
AccentColor: …;
AccentColorText: …;
…
}Custom color schemes can then be used as a value in the html {
color-scheme: --solarized-dark;
}The Web Preferences API would allow switching to a custom theme through a preference if multiple are defined. That would also enable the use of a custom color scheme in The addition of custom color schemes opens up the door to |
|
If we were to allow custom color scheme names, I would restrict to dashed idents only so the non-dashed namespace remains available to the UA. (Mentioning this because custom idents cover both dashed and non-dashed) Though in general, I am doubtful of the utility of this feature with CSS variables existing. |
|
Just for the record, I once proposed something related: custom color palettes optionally reusing existing color keywords. #5730 |
Good clarification. That is the intention indeed: dashed-idents only. |
The major benefit of this is when it can be persisted in the Web Preferences API. If there are multiple schemes, but you have to wait for JS to query localStorage/etc to find out which scheme the user actually wants, you can have the unfortunate flash-of-wrongly-styled-content. |
|
The CSS Working Group just discussed The full IRC log of that discussion<TabAtkins> https://github.com//issues/9660#issuecomment-1945335637<jarhar> TabAtkins: bramus had a proposal for allooiwng authors to write their own color schemes. theres a reason to want a parrticular set of colors. after back and forth we came to a particular shape to proposal at this comment. the core use cases are a. built in stuff uses system colors all over the plate. if you wanted all them to be sconsistent with <jarhar> your set of colors you have to override builtins until we add more controls. if you missed any ? the second use case is the web prefere3nces api proposal lets you persist certain site preferences and persists across page loads. if that happens then you could save the color scheme for a site and then make it apply the next time you visist the siste. <jarhar> the proposal is a new color scheme at rule you give a name and a color scheme and then you can override any of the system colors for that color scheme <ChrisL> q+ to ask how light-dark works when a custom scheme is in effect <jarhar> TabAtkins: anything you dont override ?? add more, that gets taken from the base scheme. <alisonmaher> q+ to ask how this interacts with forced colors mode <jarhar> TabAtkins: this dash ident is usable in the colro scheme, that will switch all the system colros for light and dark and it will let you respond to it - schemed color something like that. if we are in light or in dark or --solarized used this third color, if and when the web preferences api that could be persisted over there without having the <jarhar> possibility of flash of unstyled content <jarhar> TabAtkins: that is the proposal. any thoughts? <ChrisL> This function computes to the computed value of the first color, if the used color scheme is light or unknown, or to the computed value of the second color, if the used color scheme is dark. <Zakim> ChrisL, you wanted to ask how light-dark works when a custom scheme is in effect <jarhar> ChrisL: i have a question about this. we accept that means the light dark thing will evaluate to light because it matches light or unkonw. unless its marked as dark we treat it as light. i just wanted to make sure were ok with that <jarhar> TabAtkins: im not sure i understand <jarhar> ChrisL: in color 5 we have light-dark and it says that if it matches light or is uknown wthen you get light, otherwise you get dark. custom color schemes will come out as light <jarhar> TabAtkins: it will be a known keyword that will respond appropriately <jarhar> ChrisL: ok then how do you determine if its light or dark? <jarhar> TabAtkins: ah right because it has simple syntax of two values <jarhar> TabAtkins: at the moment the only two builtin ones are light dark so it should act like whatever its base scheme is. if youre building a sheme based on dark then i tshould respond with dark. we should also have a new syntax with more schemes <jarhar> ChrisL: so we need to do some work on light dark once we have this <jarhar> TabAtkins: yes <jarhar> alisonmaher: i have a question on how this will interact with forced colors. today it overrides light and dark themes, but it looks like authors might specify their own. so i wonder if we will still have forced colors oerride other schemes or ?? <jarhar> TabAtkins: i expect we shouldnt change that, if authors want to return an alternate scheme thats interesting <kizu> q+ <jarhar> TabAtkins: by default i think we should just be - default color schemes are jus tlike like and dark, forced colors will override everything becuase user preference should override author preference <jarhar> alisonmaher: sounds good <lea> q? <lea> q+ <Zakim> alisonmaher, you wanted to ask how this interacts with forced colors mode <Zakim> fantasai, you wanted to ask about interaction with UI such as scrollbars and form controls <jarhar> fantasai: hows this expected to interact with ui pieces such as scrollbars and form controls <jarhar> TabAtkins: to the extent that they draw from system colors they will use what you specify. if they are painted with unknown colors it wont be affected by those <jarhar> TabAtkins: if you wantt hem to be more controlable we should be - that should be based onsystem colors or add more system colors. we cant give all the colors and things change over time <jarhar> TabAtkins: i iimagine that to the extent that we dont have control over them, they should act in the base scheme like light or dark but that should get better as we go along do piecemeal <jarhar> kizu: i wanted to ask about color scheme its not a media query you cant change it from author styles themselves. ??? decided to to html, it will stil match the color scheme that was defined outside the document. there is a way with custom properties and light dark to detect light or dark color because you can assign light dark to a custom proeprty <jarhar> and then in a query check this value, but it will only work for light and dark function. so we will need either a container query which reflects the propsoed colors sheme or have some other conditional way of checking what is the color because we cant change the first color scheme because its a media query <jarhar> TabAtkins: that should be handled by web preferences api. if you use the js api, we can expose that to to the document because its document level, no circularity involved <jarhar> TabAtkins: we were designing light dark we knew we wanted to address mroe schemes in the future but we only have two, so for that the work we did on light dark for allowing morecolor schemes ??? <lea> q? <jarhar> kizu: i also need to think about the html meta color scheme, can you define more than two there if you want to ? <jarhar> TabAtkins: yeah but color scheme meta should be defined by css parsing, we should accept the same set of values that color scheme does. to the extent that might need tweaking to keep up with css behavior we can make sure that is happening. it is either well defined now or close to work consistently with css <jarhar> lea: so first i think its important use case to define something for color schemes. i dont think we should do it adhoc, theres alot fo existing work with design systems that is realted and we only get one chance to do it right. also i think that so if we want to go the route of redefining system colors we should have a systematic attempt to define <jarhar> ??? color scheme otherwise it is too little too late. using light and dark to ??? ancestry seems very weird. its a workaround but ideally we need a conditional which makes that clear <jarhar> TabAtkins: design token stuff, the general case of wanting to do mroe complex things of wanting to set up sets of colors it soutside the scope of this because you can already do this with variables, if you want to do more useful stuff that ultimatesly lives in the same space as variables, you can already do it. <jarhar> TabAtkins: what you cant do is custom usage of builtin colors and you want to override and do it in a fairly safe way because as we add new colros int he browser ui it should still look reasonable. if a newly added form control is added it should be ok <jarhar> TabAtkins: thats why this uses the systme color approach instead of appropriately designed tokens, ??? undoable at the moment. regarding needing a large set of system colors, i agree but that doesn't stop us from doing it with colors right now. ??? so taht you build on a predefined color scheme ?? gradually extend this in the future, still get <jarhar> moderately ok things, exspecially if close to a dark or light scheme. if youre in the middle we need another predefined scheme but thats the best we can do at the moment <jarhar> TabAtkins: we only have light and dark predefined things, you can do things in the middle, neither is great, if we define midtone stuff so theres an idea of predefined colors if you didnt define them, were working with the tools we got <jarhar> lea: i like this, but when it comes to light dark but what im saying is picking colors is orthogonal to light or dark, seems orthoganal. maybe this could fit into other use cases for positionals we are discussing tomrorow <jarhar> TabAtkins: we thought about scheme color but did light dark because its common case and not ideal for other schemes but not the end of the world, stand by our conclusion from design process, its awk but we can put other schemes besides light or dark in there <jarhar> fantasai: id liek to go back to the use cases for this. so generaly what it does is it changes a bunch of variables you coudl use in your design to a new set of different things and thats it? <jarhar> fantasai: right it changes system colors which are color variables. if your design is using system colrs then it changes. if your design is using other things then nothing changes <jarhar> fantasai: so what is the benefit of this over variables? <jarhar> fantasai: so your intention i snot to define the custom color scheme but to influence the ui elements? <jarhar> TabAtkins: yeah beause thats what you can do today <jarhar> fantasai: ok that wasnt clear but thats what youre doing? <jarhar> TabAtkins: thats very clear in the op, smaller version in comment <jarhar> fantasai: ok so now the question is can - is it possible to do that cross all platforms? <jarhar> TabAtkins: yeah? the system colors are all under browser control, but whether the yswstem colros are used in a set of ui controls is a different matter <emilio> q+ <florian> q? <jarhar> TabAtkins: this isnt setting anything on how browsers use system colors but they do tend to use their system colors to a large extent. theyre still pretty decently used across things. if not then theyre probably not controllable at all like glossy buttons from previous macos versions <jarhar> fantasai: so youre expecting that this will chagne the way scrollbars etc change in some platforms but not others? <jarhar> TabAtkins: to the extent that itis today <florian> qq+ <jarhar> TabAtkins: if there are thing sthat are uncontrollable then yes but there are a bunch of proeprties set and colros set with system colors, if you have knowledge of how colors are set you can manually override that but if you add new ones then they cant be styles and we should make that case safer <jarhar> fantasai: so most people override ? except for form controls ? except for html stylesheet <jarhar> TabAtkins: i think we do use them for borders on inputs etc backgrounds on various things <Zakim> florian, you wanted to react to lea <jarhar> florian: so you dont so much mean influence the native rendering of form controls, rather their css version which you could as you said override by redefining the proeprties but you dkont know how theyre built but theorietically its doable in css but you dont know how <jarhar> TabAtkins: this is allowed - browsers to do more specialized rendering based ont heir colors in a similar way to accent-color. its lightly specified but that still gives you theming capability that is a meaningful input to hbow pages work <jarhar> emilio: in that topic, for example we do have some non exposed to web content system colors for things like ? options in active windows or select and button having different backgrounds. seems like this proposal allows you to address them with standard styles for form controls almost feels like not very useful <kizu> q+ <jarhar> TabAtkins: as we decide there are gaps in system colors that will be useful to expose for authors we should and will expand that, generally the system color set more useful <kizu> https://github.com//issues/5900 <jarhar> kizu: i just wanted to mention that - i pasted it into irc <jarhar> kizu: issue about giving access to accent color we have inconsistency where we have the accentcolor variable or keyword which doesnt match wich accent-color when you set it and maybe we want to approach for this as well, you can define accent color but can be overridden by accent-color property <jarhar> TabAtkins: the accent color exposure issue is about exposing the - not about the ability to contorl the accent color - when you set it you cant access it back any way, stored but then you dont have a way to get it, lea made this issue <jarhar> ^ kizu not tab <jarhar> TabAtkins: thats just a usability issue not security issue <fantasai> s/TabAtkins: issue/kizu: issue/ <jarhar> lea: less power to custom styling than native form controls which actually use the system accent color <jarhar> fantasai: any other comments on this proposal? tab what are you looking for <florian> s/but you dont know how/but authors dont necessarily know how, right? <jarhar> TabAtkins: if theres n oobjections then id like to include this as part of color adjust 2. i dont believe we have any impelemntor support yet so we can iterate on this for a while but i just wanted to get the ball rolling if it sounds ok with people <jarhar> fantasai: i need to check with webkit people <jarhar> fantasai: it would be helpful if it said instead of changing the system color keywords that it is to influence the styling of all sorts of stuff that is the main use case youre thinking of <TabAtkins> https://github.com//issues/9660#issuecomment-1834713634 <jarhar> TabAtkins: heres the post where i ? about the use cases, the original post is about heres a set of variables, but you can already use variables <jarhar> TabAtkins: we had a couple useful techincal questions which have obvious answers but could be written down in a proposal so they dont get asked again <jarhar> fantasai: how about you create an explainer with the proposal and the description you have of the use case is that it only changes the system colors keywords then its just a pile of variables which is not a huge benefit <jarhar> fantasai: so why are we building this into the browser is the question you need to answer <jarhar> TabAtkins: ill come back in abit with a more detailed one. so it sounds like no large objections just use cases? <lea> q? <jarhar> fantasai: if this can all be done with variables then theres no use for this <lea> q+ to reply to fantasai <jarhar> TabAtkins: theres more to this that makes it more compelling <TabAtkins> +1 to lea's point <jarhar> lea: before we switch topics, as a general principle authors can do it with variables i dont thin kthats a principle we should be following because theres a difference between native syntax and author thing, its a contract that both ends in a codebase need to be aeawrae of to foloow. lets say youre integrating a component in a page which has its <jarhar> own variables, and the compoentns has different variables and authors have to glue the two. when you have native conventions about this thing then you dont have to glue them together. im saying as a general principle it doesnt mean that if authors can do it by convention then we dont have to do it in the syntax <ydaniv> +1 |
|
Happy to see Tab covered this one, as I wasn’t able to attend the F2F this morning (things here got hectic pretty quickly …). To reply to some specific things from the discussion:
/ping @svgeesus, @LeaVerou, @fantasai, @emilio, and @kizu who all joined the discussion this morning. |
LeaVerou
changed the title
color-scheme values.color-scheme values.
In #7561 we resolved on adding
light-dark()so that authors can easily use a color based on whether thelightordarkcolor scheme is being used. Authors are generally in favor of this addition but some of the feedback I got is asking why is this limited to light and dark only?Reason for this, is that this is the current reality we live in: the possible values for
color-schemetoday are onlylightordark(ornormal).<custom-ident>s are allowed as values but these are ignored, as per spec:(Hereby a thank you to the person who suggested to put that in; very future friendly!)
Looking at #7561,
light-dark()isn’t the end goal of that feature. The end goal is something likeschemed-value(): allow authors to get a value based on a passed incolor-scheme– anycolor-scheme.To unblock that issue forward, a first step would be to allow authors to define custom
color-schemevalues. These defined values could then then be used in sidecolor-schemeand theprefers-color-schemeMedia Feature.Classic use-cases are coding color schemes, or application theming such as Slack or VS Code offer:
The text was updated successfully, but these errors were encountered: