- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 12 Jun 2024 09:34:28 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed ``[css-color-adjust] Allow authors do define custom `color-scheme` values.``. <details><summary>The full IRC log of that discussion</summary> <TabAtkins> https://github.com/w3c/csswg-drafts/issues/9660#issuecomment-1945335637<br> <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<br> <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.<br> <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<br> <ChrisL> q+ to ask how light-dark works when a custom scheme is in effect<br> <jarhar> TabAtkins: anything you dont override ?? add more, that gets taken from the base scheme.<br> <alisonmaher> q+ to ask how this interacts with forced colors mode<br> <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<br> <jarhar> possibility of flash of unstyled content<br> <jarhar> TabAtkins: that is the proposal. any thoughts?<br> <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.<br> <Zakim> ChrisL, you wanted to ask how light-dark works when a custom scheme is in effect<br> <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<br> <jarhar> TabAtkins: im not sure i understand<br> <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<br> <jarhar> TabAtkins: it will be a known keyword that will respond appropriately<br> <jarhar> ChrisL: ok then how do you determine if its light or dark?<br> <jarhar> TabAtkins: ah right because it has simple syntax of two values<br> <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<br> <jarhar> ChrisL: so we need to do some work on light dark once we have this<br> <jarhar> TabAtkins: yes<br> <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 ??<br> <jarhar> TabAtkins: i expect we shouldnt change that, if authors want to return an alternate scheme thats interesting<br> <kizu> q+<br> <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<br> <jarhar> alisonmaher: sounds good<br> <lea> q?<br> <lea> q+<br> <Zakim> alisonmaher, you wanted to ask how this interacts with forced colors mode<br> <Zakim> fantasai, you wanted to ask about interaction with UI such as scrollbars and form controls<br> <jarhar> fantasai: hows this expected to interact with ui pieces such as scrollbars and form controls<br> <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<br> <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<br> <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<br> <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<br> <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<br> <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<br> <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 ???<br> <lea> q?<br> <jarhar> kizu: i also need to think about the html meta color scheme, can you define more than two there if you want to ?<br> <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<br> <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<br> <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<br> <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.<br> <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<br> <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<br> <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<br> <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<br> <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<br> <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<br> <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?<br> <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<br> <jarhar> fantasai: so what is the benefit of this over variables?<br> <jarhar> fantasai: so your intention i snot to define the custom color scheme but to influence the ui elements?<br> <jarhar> TabAtkins: yeah beause thats what you can do today<br> <jarhar> fantasai: ok that wasnt clear but thats what youre doing?<br> <jarhar> TabAtkins: thats very clear in the op, smaller version in comment<br> <jarhar> fantasai: ok so now the question is can - is it possible to do that cross all platforms?<br> <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<br> <emilio> q+<br> <florian> q?<br> <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<br> <jarhar> fantasai: so youre expecting that this will chagne the way scrollbars etc change in some platforms but not others?<br> <jarhar> TabAtkins: to the extent that itis today<br> <florian> qq+<br> <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<br> <jarhar> fantasai: so most people override ? except for form controls ? except for html stylesheet<br> <jarhar> TabAtkins: i think we do use them for borders on inputs etc backgrounds on various things<br> <Zakim> florian, you wanted to react to lea<br> <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<br> <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<br> <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<br> <kizu> q+<br> <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<br> <kizu> https://github.com/w3c/csswg-drafts/issues/5900<br> <jarhar> kizu: i just wanted to mention that - i pasted it into irc<br> <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<br> <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<br> <jarhar> ^ kizu not tab<br> <jarhar> TabAtkins: thats just a usability issue not security issue<br> <fantasai> s/TabAtkins: issue/kizu: issue/<br> <jarhar> lea: less power to custom styling than native form controls which actually use the system accent color<br> <jarhar> fantasai: any other comments on this proposal? tab what are you looking for<br> <florian> s/but you dont know how/but authors dont necessarily know how, right?<br> <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<br> <jarhar> fantasai: i need to check with webkit people<br> <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<br> <TabAtkins> https://github.com/w3c/csswg-drafts/issues/9660#issuecomment-1834713634<br> <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<br> <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<br> <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<br> <jarhar> fantasai: so why are we building this into the browser is the question you need to answer<br> <jarhar> TabAtkins: ill come back in abit with a more detailed one. so it sounds like no large objections just use cases?<br> <lea> q?<br> <jarhar> fantasai: if this can all be done with variables then theres no use for this<br> <lea> q+ to reply to fantasai<br> <jarhar> TabAtkins: theres more to this that makes it more compelling<br> <TabAtkins> +1 to lea's point<br> <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<br> <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<br> <ydaniv> +1<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9660#issuecomment-2162555011 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 12 June 2024 09:34:29 UTC