[css-ui] Add a way for authors to indicate that they want dark-mode form controls etc #3299
Comments
|
Have you considered just re-using the Alternate Style Sheets mechanism from HTML per http://www.idpf.org/epub/altss-tags/#app-night-version-style-set-tags ? |
|
@fantasai that proposal will suffer from the problem that the style resolution happens after the document is already displayed. |
|
I think dark mode will need a different default UA stylesheet. For instance, the default document color could be transparent or black and default text color white. |
I've thought a little bit about what would be required for a I'm not sure that just one browser alone could implement a 'dark-mode.css' stylesheet that would be helpful for CSS authors to develop on top of if it wasn't necessarily catching every default style that another browser's user-agent stylesheet was setting. If anybody is interested in making some kind of |
|
Note that WebKit solves some of the complexity of dark and light mode colors by having special handling of CSS named colors. The named color can resolve to different values, depending on what mode you are in — like So our |
|
Is this something that can be put in a spec? Does CSS use named colors for default styles? For the magic leap use case, we'd also like to have the color of the root element to be transparent by default instead of white (or black in dark mode) |
|
Any reason not to support this in response headers as well? |
Could you elaborate what the use case of these headers would be? |
|
You have a few meta tags that should/must be served in the first packet of the response body, like |
|
Sorry, the "few meta tags" point is that the more meta tags of those kinds (the "put it as early as possible" kind) pile up, the harder it gets to have them as early as required. Headers are shorter in nature and are received earlier than any response body (not trailing headers, obviously). |
|
Hmm, the proposed feature seems backwards to me. A site shouldn't decide what theme the user should see. The preferred theme is entirely a user preference and the site should accommodate whatever theme the user has chosen, not the other way around. |
|
@MatsPalmgren this isn't about the site deciding the theme. |
|
@rcabanier That's not how I understand this feature. So, if I'm using dark theme and a web page says |
|
It will render the content in a light theme. It won't switch the whole browser. |
|
Right, and I think that's an abomination. We shouldn't add new features to the User Agent that enables authors to disrespect the user's preferences any further. I see this proposal as the anti-thesis of the good intent that prefers-color-scheme represents. I think that's the feature we should encourage authors to use. So that they present a dark-styled page to users with a dark mode and a light-styled page to users with light theme. |
|
I don't see how this "disrespects" the user's preferences. The whole point of css is that pages are allowed to style their own content. Are you saying that there should be a way for a user provided stylesheet to override the tag? (ie an user that never wants to see a light or dark themed page) The prefers-color-scheme feature suffers from the flash of white alongside not being able to style UA provided UI. This meta tag solves those significant issues. |
|
I'd note that, when the system theme is dark, we get a bunch of complaints from users (see, e.g., the recent activity in bug 70315) complaining that Web pages are broken when dark defaults are applied. Given this, I think I'd be happy with a mode that indicates that a page is capable of rendering correctly with either light or dark themes. This would allow UAs capable of doing so to, if they wish, when the system theme is dark and a page does not have this indicator, render the "system" controls as colors as a light theme instead of the dark one. Given that, today, pages all work with light themes, it seems like it would be a step backward to allow pages to do the opposite, and force dark controls/colors when the user has a light system theme. I think that's a bad idea for two reasons:
UAs might have problems implementing this if the system's theming mechanism doesn't have a clear way to switch between "equivalent" light and dark themes. I think this is true of GTK (based on familiarity with the theme switching UI and with the underlying APIs), and I think also older versions of Windows (though not Windows 10, I think), based on experience with the Windows 10 UI, and with the UI and API on substantially older versions. (I'm not sure where the change was, though!) (I'd note that GTK used to have a way for an app to force a dark system theme to be light, but not the reverse, and that mechanism was recently removed.) |
|
@dbaron I think the following tag is an indicator that a page is capable of rendering with dark and light: I don't quite understand what you mean by:
First you say that there should be an indicator but then you ask for behavior if there is no indicator. Maybe you can rephrase?
Why is that? If a UA supports this tag and CSS property, it can do transformations for pages that specify |
|
I'm proposing that the only indicator ( What I'm suggesting is that I don't want to create a set of Web pages that don't work correctly if the system controls are light, because I'd rather not make the problem of pages that don't work in certain situations worse than it already is. I prefer this both because I'd like to be able to honor the user preference for what controls are as much as possible (both since honoring the user's preference is good and since doing so makes those controls more recognizable to the user) and because some implementations (on some platforms) may be unable to produce an appropriate light and dark theme at will. |
|
I think you're proposing that a page must always render correctly in
We (as in Magic Leap) have a big problem with people wanting their pages to be dark because it looks a lot better in an immersive environment. We have transformations but it results in many broken pages and it would be great if authors could tell us not to do those transformations. I think this proposal would be a great help. |
Yes. (Though then there's the question of what dark mode means: just system controls like buttons, text inputs, and scrollbars as exists in a few browsers today when the user has a dark system theme, or an entire swap of default colors as some have suggested above.)
Is this sentence missing a negation somewhere? |
No :-) |
|
The CSS Working Group just discussed The full IRC log of that discussion<astearns> topic: dark mode<astearns> github: https://github.com//issues/3299 <heycam> ScribeNick: heycam <heycam> futhark: Chrome is soon shipping dark mode for the UI of the browser itself <heycam> ... respecting the dark mode setting of the OS <heycam> ... but we also want to render the pages dark <heycam> ... so the MQs 5 hsa prefers-color-scheme <heycam> ... letting the authors follow the setting the user has <heycam> ... but in order to render the content dark for all pages from day 1 <heycam> ... we're looking at a UA intervention that automatically darkens the web pages <heycam> ... but giving the author the possibility to opt out of that <heycam> ... and we have looked at a <meta> element that Apple has already implemented <heycam> ... what it does is that you can specify which color schemes the page can respond to using MQs <heycam> ... and apply a UA style sheet which renders form controls dark, having a lighter foreground color, using a black canvas backgrdop <heycam> ... this is basically what safari does <heycam> ... the proposal here is that we do this with a <meta> element <heycam> emilio: also the CSS property? <heycam> futhark: the CSS property I haven't mentioned yet <heycam> ... there's the posisbility for the page saying that parts of the page are styled itself, but also the possibility to do automatic darkening of other parts of the page <heycam> ... we get this request for various Google products <heycam> ... where they want to handle some UI parts themselves in dark <heycam> ... but automatically darken some content <fremy> q+ <heycam> smfr: we have to distinguish between auto darkening, which is clobbering what the author's done <heycam> ... and this thing, which allows the author to tell us they've thought aobut dark mode <heycam> ... for us this is jus chanign form controls, selection, ... <florian> q+ <heycam> ... an auto darkifying thing is maybe orthogonal to this <heycam> futhark: what we've been thinking about is that the <meta> element at the same time it says it wants the dark UA style, it would also opt out of the auto darkening <heycam> ... because it knows how to render dark pages <heycam> futhark: when the author has a <meta> saying it knows how to render this page in a dark color scheme, please opt out of auto darkening <heycam> ... one of the reasons we've been thinking about <meta> is that we don't want any flash of white background <heycam> ... so having it available early <xfq> ack db <AmeliaBR> q+ <emilio> q+ <heycam> dbaron: I agree with a bunch of what Simon said <heycam> ... there's a long standing problem we've had which is that when we use native form controls and certain things like that, if the user has a dark theme, those don't work with some pages <heycam> ... e.g. text input is a common one. if the text input has a dark background with a light text color, and the author overrides only one of bg/fg, it's broken <heycam> ... as a result we've done work to prevent dark native themes to get through to web content <heycam> ... some recent Gtk changes broke this <heycam> ... so I think there are a few separate problems here <heycam> ... one is the fact that because of these dark theme options in macOS, Windows 10, etc., more users have dark themes <heycam> ... and in a lot of web contne tthat doesn't work, even if they want it to work <heycam> ... but we can't just go apply it to web content unless we know it will work with that <heycam> futhark: that's why we want to rely on the meta element to have the page tell us it's ok <heycam> dbaron: I think a meta that says "I the page author have thought about this and I know that my page will work with a dark theme" is a good thing <heycam> ... I think UAs could use it for different things <heycam> ... one could use it to say "the user has a dark theme, so I will let dark theme data theme, and use the user's preferred form controls for this page" <heycam> ... or the UA could say "for pages that haven't done this, do auto darkening" <heycam> ... and a meta that says "I suppor tdark theme" serves both of those purposes but not completely <heycam> ... if the user wants the entire thing to be dark, working with dark form controls doesn't imply that their whole UI is dark <heycam> ... so they still might want the auto darkening in that case <heycam> ... another thing in here I don't like. it also allows authors to say that their page doesn't work with light pages <heycam> ... and I'd rather not create this problem <heycam> futhark: the only keyword? <heycam> dbaron: you can say supported schemes "dark", and skip light <heycam> ... in the spirit of trying to do more of what the user wants, where right now users want to see things in dark mode, I'm hesitant to give authors an option to say this page doesn't work in light mode <heycam> ... for users who want that <heycam> futhark: there's also the "only" keyword that Safari implements <heycam> ... don't you have to say "dark only"? <heycam> smfr: [nods] <heycam> futhark: if you have a light theme and say "dark only" in the meta tag, you get the authored dark page <heycam> dholbert: and widgets are dark? <heycam> smfr: primarily widgets <xfq> ack fr <heycam> fremy: I am very curious about how you're going to enforce dark themes on pages that aren't prepared <heycam> ... I'm skeptical people will like that <heycam> ... you'll end up with images that look wrong etc. <heycam> ... for a11y purposes it's a fair tradeoff <heycam> ... but I am very unsure that people going to bing.com that doesn't support dark theme now the links aren't visible <gregwhitworth> q? <heycam> futhark: auto darkening is not something we'd like to spec <fantasai> +1 to fremy <heycam> fremy: otoh, replying to david, I don't see why you'd want dark only <heycam> ... in VS Code, a web app, it has dark menus <heycam> ... it makes sense for them to say "dark only" <heycam> ... they want to control all their app UI <heycam> ... if you're talking about wikipedia, they should probably not say "dark only", but I don't think they will do that <heycam> ... maybe for a powerpoint thing, if the author has thought about it, why prevent it? <heycam> dbaron: one of my worries about this stuff is that not all browsers will be able to do all of these things <heycam> ... if we want web pages to be able to say "dark only", the browsers need a native set of light and dark controls <heycam> ... which on some platforms is not realistic <heycam> fremy: you can always have a normal styled fallback for form controls <xfq> ack fl <heycam> florian: that's the difference between I prefer dark and I support dark only <fantasai> slides from the earlier high-contrast discussion: https://lists.w3.org/Archives/Public/www-archive/2019Feb/att-0000/CSSWG_F2F_High_Contrast.pdf <heycam> ... if you don't have dark controls, and your OS doesn't have them -- that's different from saying "if you show light controls I will be broken" <heycam> ... we shouldn't have that <heycam> ... why create that category? <heycam> ... there are some that would look better with dark controls <heycam> fremy: VS Code only has dark controls <fantasai> high constrast explainer https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/master/HighContrast/explainer.md <heycam> ... why do they custom style everything? because they can't get dark controls <heycam> ... I think what you're saying exists today <heycam> ... but the web page custom styles every single thing <heycam> florian: if the OS doesn't support dark controls? <heycam> fremy: you fall back, just like when you put borders on form controls <bdc> q+ <heycam> florian: so VS Code will still need to hand code their dark controls, since they can't handle that some OSes will fall back <heycam> fremy: today the light controls have this fallback today <gregwhitworth> q? <heycam> ... if you have a button border-radius:3px, you get the fallback rendering <heycam> ... and you can do this same fallback for the dark one <fantasai> high contrast explainer archived: <fantasai> https://lists.w3.org/Archives/Public/www-archive/2019Feb/0001.html <heycam> dbaron: I think there is a tradeoff here. some sites that want to own things so much they will replace the native controls <heycam> ... there's a tradeoff betwene that and having sites where the controls are more recognizable as such to users <heycam> ... and the users recognize the thing over there is an input field <heycam> ... that's a tradeoff <heycam> ... there's an advantage to contrls that look native <heycam> ... esp for less experienced users <heycam> ... if we offer more ability to change what the controls look like, we will pull some designers away from replacing everything <heycam> ... but we will also push some users into things that are less recognizable for them <heycam> ... there's no one answer is more correct 100% <heycam> florian: afaict, the property here, whether it has a bunch of properties or auto vs i-support-dark, does the same thing at the meta tag? just at a subtree granularity <heycam> ... whether or not you suppor tdark theme depends on the style sheet, so it belongs in the style sheet rather than meta tag <heycam> ... I know I will not get full agreement on that <heycam> gregwhitworth: for end user experience reasons <heycam> florian: but it could become wrong when you update the style sheet and forget to update the meta <heycam> gregwhitworth: bad author <heycam> florian: if you have a page that claims to support dark mode, the author sheet does support dark mode, but user sheet doesn't -- how to tell the page? <xfq> ack Am <heycam> futhark: the property wins <heycam> AmeliaBR: I'm a bit uncomfortable doing style theming in the meta tag because you might have all sorts of flexible themings based on user prefs based on your own thing <heycam> ... but as long as the style property overrides the meta tag, that's ok <heycam> ... but then I'm not sure why the meta tag is necessary <heycam> ... if the style sheet sdon't load, I'm assuming the browser can apply whichever one <heycam> futhark: if you parse the meta tag, you can apply the black canvas pretty early <heycam> fremy: it's about flashing <heycam> AmeliaBR: is there any reason to do the flashing? if the style sheets haven't loaded can't you have a default bg that is according to the default theme? <heycam> smfr: every wikipedia page will flash <heycam> AmeliaBR: ok that's the point of the meta tag, for the default backdrop before style sheets load <heycam> fantasai: use bgcolor on body? :) <heycam> ... I totally agree this is not something that belongs in the HTML layer if possible <heycam> ... if you want to put it there, we have bgcolor <heycam> ... the best thing there is you can solve that for any background color <heycam> AmeliaBR: not necessarily because what if the style sheet has a MQ switch based on user preference <heycam> fantasai: then it will override, but that's better <heycam> AmeliaBR: you can indicate which themes you support <heycam> fremy: bgcolor can only supply black, not "which theme the author supports" <heycam> fantasai: you're only doing this for white or black -- is this a big problem? <heycam> TabAtkins: if I'm looking at dark screens in bed, I don't want a big flash of white <heycam> AmeliaBR: why would wikipedia put a meta tag saying "dark only"? <heycam> florian: they won't hae the tag, so you know it's a light site, but you can still show dark until it shows up <heycam> [wikipedia just as an example here] <heycam> AmeliaBR: my other point, repeating some of fremy, if there's any discussion about auto applying styles without author opt in, that should be discussed in the context of accessibile color schemes, high contrast mode, think of it that way <heycam> ... when you're overriding author styles it's an a11y feature <heycam> ... but that's separate from trying to match user preferences <heycam> ... for matching user prefs, I like the idea of making it easier for authors to say this site supports a dark theme, draw default styles for select boxes, if you have one, or saying my styles work well whether you use light or dark whichever the user prefers <heycam> ... there are sites that are dark that require custom styling for form controls now, so I like the easy way to opt in to native dark mode styles <fantasai> +1 <heycam> ... we kind of have multiple themes now in browsers <heycam> ... the "legacy" widget themes, if you much around with styles <heycam> ... then we have the modern native look buttons in light or dark theme <heycam> ... I don't know how is the way the prop is currently specced going to interact with that? <heycam> ... when you revert to the legacy styles <heycam> futhark: I don't have an answer for that <heycam> AmeliaBR: if you use this prop are you saying "use the native UI look no matter what other styles I put on the element?" <heycam> smfr: still has these fallbcak interactions <heycam> AmeliaBR: so if I wanted styles that say use native dark mode, but if you don't support these new props, and if I want a custom styled dark inputs, you'll need @supports or something? <heycam> ... will @supports just look at syntax, don't say you support dark mode unless you have one to use <heycam> ... but that would break an author request of dark or light <heycam> ... so the keywords need to be recognized even if they don't have matching themes <heycam> ... can sites detect "do you have a native dark theme"? <heycam> emilio: that's a fair request <heycam> ... an author to see if the browser suppotrs a native dark theme or not <astearns> ack emilio <heycam> ... it feels to me that the auto darkening has a lot of potential to backfire <xfq> ack bdc <heycam> bdc: I think there are 2 different issues <fantasai> +1 to emilio <heycam> ... one is that it makes a lot of sense for a page to fit into its environment <heycam> ... the other use case, which I disagree with, is fremy's example of "I'd prefer a dark theme for my app so I will just use theme by requesting dark controls" <heycam> ... it's a design shortcut <heycam> ... it's a differnet purpose IMO <heycam> ... VS Code is not designing that because they don't have access to a dark mode <heycam> ... they just design it that way <heycam> ... to me it's a different use case <heycam> ... to want to re-use a set of controls that are nicer to the designer's eye is different from fitting to the environment <florian> +1 <heycam> fremy: the #1 request we got for controls in Edge is sites wanted dark scrollbars <heycam> ... we don't want to customize the scrollbar, we just want a dark one <heycam> ... when they do customize it, we get perf issues, etc. <fantasai> I would like to point out that Adobe Creative Suite uses dark mode for its UI, but the expectation is that content being edited is black-on-white, so it's not that you always want to match content to the OS "theme". <tantek> +1 same we get requests for dark scrollbars primarily <fantasai> Sometimes. not always <heycam> ... that's the point of this prop, this area of the page is dark, it's a choice we made, but we want to play nice with native controls <heycam> ... for better UX for users <heycam> ... also, let's say you have a blog engine, you want to support dark theme <heycam> ... so you say the page supports light and dark <heycam> ... an embedded component from another origin, it only supportslight <heycam> ... you need to have a way to say this part of my webpage does not support dark theme, even though my site overall does <heycam> ... this is the point of the property <heycam> ... incorporating components from different sites, you might not want to give up your overall site dark theme <heycam> ... the "dark only" value might not be useful ... <heycam> ... I have seen sites that just want a dark scrollbar <heycam> ... and you need "light only" anyway <heycam> AmeliaBR: anothe rexample, you're concerned it's not respecting user prefs <heycam> ... for somethings I like a dark theme, but if I'm reading a lot, I can't read a lot of white text on black bg <heycam> ... so I'm going to have different prefs for different sites <heycam> ... maybe browsers will one day allow me to set prefs on a per site basis <heycam> ... but lots of sites have a way for the user to opt in to a theme <heycam> ... so maybe when they're doing "light only" or "dark only", they're reflecting the user's preference in the site <heycam> bdc: the way I would summarize is that letting the browser know that you are dark theme compatible is nice, a good citizen in this environment <heycam> ... doing the opposite is being hostile to the env <heycam> ... whatever you choose, I'm going to have dark, because I like it <heycam> fremy: but you could have a theme inside the app <heycam> AmeliaBR: we can encourage authors to make their sites theme flexible <heycam> ... just like responsive sites <heycam> ... but I don't think a dark only is any more hostile than saying background-color:black, etc. <heycam> ... it's just one way for the author to opt in to a color scheme without setting everything themselves <heycam> ... and making it a bit more native and familiar <heycam> bdc: I see that, but it really depends on how many things in the UI that change <heycam> ... e.g. at some point I think Edge had a title bar that matched the site header color <heycam> ... here you're forcing UI changes because use as an author prefer black <heycam> ... it might be pushy <heycam> Rossen: we used to have a mode that when you pin a site to the taskbar or start menu and you want to use it exclusivle in an app mode <heycam> ... we would do small things to match the page <heycam> ... that was the behavior we did <heycam> bdc: this kind of thing can have an impact on the UI as a whole <heycam> ... who knows what the OS will do in the future <heycam> ... so it could affect more things <heycam> AmeliaBR: good point but it sounds like it's outside the scope of CSS <heycam> ... anything the browser/OS is doing to extract styles from the page and applying outside the page ... <heycam> bdc: these properties and meta tags would do that no? <heycam> florian: just within the page <heycam> AmeliaBR: the only thing outside we can style with CSS is styling the dark/light bg of the canvas <heycam> bdc: the chrome of the browser could/should change based on that <heycam> gregwhitworth: the way I would see this working in Edge, user turns on dark mode, Edge would flip into dark mode, devtools would too <heycam> ... if you have the meta tag, it would flip to dark controls too, if not, it wouldn't <AmeliaBR> s/outside we can/outside what we can already/ <heycam> ... is there an issue with that? <heycam> bdc: not with that <heycam> ... but in the future making the assumption that if the site opts in that other UI is now dark, then I do <heycam> dholbert: alerts could be dark <heycam> gregwhitworth: they're not controlled by you now anyway <heycam> AmeliaBR: that's an issue on the browser team to decide whether to respond author or OS choices ... <astearns> q? <heycam> Rossen: the one thing to keep in mind is that at least in Windows, probably on macOS, we have three levels of where color schemes can apply <heycam> ... there's the shell, which is only controlled by the user <heycam> ... usually it doesn't propagate anywhere beside the shell <heycam> ... then there are apps. apps are going to depending on the UI framework they use, they may be either forced or opt in to a particular color theme <heycam> ... regardless of it it's dark or whatever <heycam> ... then there's the content of these apps <heycam> ... even besides browsers. many other apps that have content that could benefit from theming <heycam> ... and there, it's the choice of the app on whether to propagate that information to the content <heycam> ... a quick survey of 1st party apps that ship with Windows or macOS, even there is some inconsistency <heycam> ... e.g. in Windows the shell is always dark, doesn't mean 1st party apps will always be dark <heycam> ... at the same time, in Edge, there's a user choice to change the UI to be dark mode only <heycam> ... changing the UI of the browser alone doesn't fit with anything else if the shell is light <heycam> ... for these cases, to say that because I'm switching my app to be dark, I want everyhing else inside to be dark <heycam> ... Mail doesn't usually force content to be dark by default <heycam> ... looking at macOS Mail, it seems this is only done for text only messages <heycam> ... propagating this down to the site and alowing the site to say "yes I'm fine if you are going to change your UI, regardless where the change came from, I'm going to match it a bit better" <heycam> ... so I think the overall approach of this proposal doesn't seem crazy, it's just that how do we get to the point where the actual handshake between content and the app layer becomes as transparent/easy as possible <heycam> ... most platforms today have these 3 tiers of color scheme propagation that, whether or not in this group agree, is irrelevant <heycam> futhark: one of the things I wanted to figure out is if a meta tag is the right way to do this <heycam> ... the standardization of a meta tag typically doens't happen in CSS <heycam> Rossen: what are you optimizing for here? style sheet download, so that before you navigate you want the right theme applied without flashing? <heycam> ... if you're going from page to page on wikipedia, and let's say wikipedia had a dark mode, you don't each navigation flash to white <heycam> ... if we're ok with flashing, then meta tag or property or alternative style sheet would work <heycam> smfr: we're not ok with flashing <heycam> ... asked one of our engineers about the meta tag proposal <heycam> ... there are clients other than browsers, like mail client, it's useful for them to be able to parse the first part of the message without a css parser <heycam> ... I think that's the primary reason <heycam> florian: I'm personally not enthusastic about the meta tag, but I understand why you need it <heycam> ... and as long as you have the property, that's fine <tantek> q? <heycam> bdc: the only change you're contemplating is form controls, canvas <heycam> futhark: foreground color, background color <heycam> s/canvas/root viewport color/ <tantek> I'm curious if a <style> element would solve the flash or not <heycam> florian: would this change the bg color of the selection? <heycam> smfr: yes <heycam> florian: that's meant to be affected by a normal property on a selector <heycam> smfr: currently the selection color uses a system provided color <heycam> ... but this will be overridden <heycam> ... there's also spelling dots <heycam> ... and the scrollbar color, even though we have a property for that now <heycam> ... links too <heycam> jensimmons: does it also include the colors in the UA sheet? <heycam> hober: in practice we didn't have to, since it used named colors <heycam> smfr: in KHTML there was a system color called "text" <heycam> ... that value persisted to the present day <heycam> ... now we're using that in the UA sheet <heycam> ... that becomes white when you use dark mode <heycam> emilio: we should talk about, because all UAs probably use system colors for this <heycam> ... doesn't make sense to deprecate things that everyone is using them... <heycam> dbaron: on system colors, I had a bunch of proposals <heycam> ... the current set is very Windows specific <heycam> ... you generally think there is a fg and bg pair <heycam> ... ButtonText / ButtonFace, HighlightText / Highlight <heycam> ... in that set, from the Windows API, seeing how the Windows UI used those, there were some non obvious pairs <heycam> ... there was a set of 4 colors, call them ABCD <heycam> ... it was confusing <heycam> ... in 2001..2003, I had a proposal for fixing this by adding another name for the other combinations <heycam> ... rather than assuming this control always uses the fg color from this control and the bg color from that control <heycam> ... and Gecko implements a bunch of these behinds prefixes <heycam> ... additional system colors so we can do sane things on non-Windows <heycam> ... Dialog and Field <astearns> ack dbaron <heycam> ... I would support working un-deprecating system colors given how much they're used, I had some proposals to fix them <heycam> dbaron: I think it's possible that it might make sense to have 2 different flags rather than 1 <heycam> ... it might be that the aspect of what to do with native controls is different from what to do with default colors <heycam> ... so you may wish to say that my page supports either light or dark native controls, but I still want to leave the default colors light by default <heycam> ... not fully thought through <Rossen> q? <heycam> florian: I think that makes sense. think of an existing dark today site, but was written dark with the assumption the UA sheet is light <heycam> ... and might rely on some thing sfrom there <heycam> ... even if they want to opt into dark controls <heycam> emilio: but if you have no meta tag <heycam> florian: you add the meta tag to use the dark controls <heycam> emilio: hopefully you then check the page! <fantasai> bgcolor=dark <fantasai> :p <heycam> ... presumably if you request dark theme, look at your page, notice that it has light text that looks broken ... <heycam> florian: so don't ask for it and hack controls the old way? <dbaron> https://dbaron.org/css/test/sec1802 has some examples of how the system colors work -- part of the mess is that there are both single-border and double-border styles for raised buttons, which is why there are so many colors for the edges of buttons <heycam> emilio: on one hand, I agree more configurability is nice. otoh, exploding the amount of combinations of themes and bits that you can tweak is also going to be a mess <heycam> florian: the #1 statement before was dark form controls <heycam> ... not a dark UA style sheet <heycam> ... why are we coupling the two? <heycam> AmeliaBR: is the disclosure on details a form control or just a style sheet thing? so many things <heycam> florian: fremy earlier stated if you try auto darkening you will get problem <heycam> ... to me a dark UA sheet is a primitive form of that <heycam> fremy: but if it's opt in they can fix it <heycam> ... if they don't want to fix it that's up to them <heycam> Rossen: not having the foreground color matching form controls would be strange <heycam> ... let alone backgrounds <heycam> AmeliaBR: I suspect in most cases the author is going ot override most of the things tha twould be applied on non form controls, like on sites now <heycam> ... but it seems nice to have the option to have a quick one liner <heycam> ... just write this web site in a light or dark whatever the user wants <heycam> ... or write this section in a generic dark style because it's a chunk of text and we won't fuss on it too much <heycam> florian: if the meta tag switches the UA sheet, does the property too? how do you switch the UA from light to dark on a subtree level? <heycam> ... if oyu have a meta dark, and this subtree light only, how do you apply things from the UA sheet in that subtree? <heycam> Rossen: that's what we do for high contrast <heycam> florian: you have selectors that depend on the value of a prop? <heycam> fremy: the colors chnage <heycam> florian: change the UA sheet? <heycam> fremy: we don't have a UA sheet for dark theme <heycam> ... we switch a couple of colors <heycam> AmeliaBR: but this would allow to opt in not just form controls, but also dark and the page will be light text on dark background, which is essentially the dark UA sheet <heycam> ... right now we just have appearance <heycam> ... whether browser styles apply to that element <heycam> ... but it's only for isolated replaced elements, not paras <heycam> florian: if the only differnece between light and dark UA sheets, and all differences are system colors, that's doable <heycam> ... if there is any difference, then you can't do that in a subtree <dbaron> The other fun question is whether the system color keywords are computed values. <heycam> astearns: I'm not hearing any objections <heycam> ... some research into what the meta tag would actually do <heycam> ... we need more details written down <heycam> tantek: other question this raises is that there is a hole in the CSS rendering model about initial / transitional paints <heycam> ... and we're not addressing it <heycam> ... and the jump to a specific solution like meta tag is a way of ducking that problem <heycam> ... I believe this group owns this problem <heycam> ... not saying we're addressing it today, but we should admit it's a problem <heycam> smfr: there are consumers of HTML/CSS like mail clients without the same navigational behavior as browsers <heycam> ... when browsers paint during page load is in some cases a differentiator between browsers <heycam> ... we try to paint not too late or early <heycam> ... not sure specifying that is productively <heycam> astearns: not specifying first paint, but specifying some control over what happens in that first paint to avoid flashes <heycam> ... seems like a good thing to work on <heycam> fremy: first paint can happen before CSS <heycam> tantek: I sense a hole <heycam> ... I won't diagree with smfr that browsers are motivated at doing a good job at, just that it's a hole that authors have asked for control of it, but we haven't provided for <heycam> ... we can do a better job too, but those two are not in conflict <heycam> astearns: can you raise an issue on that? <heycam> ... for the meta tag, seems like we should do some more work and come back with a more concrete proposal <fremy> scribenick: fremy |
|
I have drafted proposals for a CSS property[1] and a meta tag[2] here: [1] https://lilles.github.io/specs/supported-color-schemes.html |
|
Couldn't the flash of white issue be more simply solved by just using the theme of the previously visited site? The way I see it, flashing is only a problem when it needlessly happens between two dark sites. Also, wouldn't it make more sense to use add attributes to |
|
To add attributes to |
|
Well, it does apply only to the stylesheet: without a stylesheet that contains dark styling, the whole point is moot. |
|
@aaxx - no, it applies to the page, it may change the default background and text color, for example, without any CSS. If you define it on a stylesheet, you will have to define it on all of the stylesheet references, right? I mean, on every |
|
I think what this meta tag does gets pretty clear at the example of WebKit's user-agent stylesheet (do a full text search for "dark"). To illustrate, here's one such CSS rule (using the input,
input:matches([type="password"], [type="search"]) {
-webkit-appearance: textfield;
#if defined(HAVE_OS_DARK_MODE_SUPPORT) && HAVE_OS_DARK_MODE_SUPPORT
color: text;
background-color: -apple-system-control-background;
#else
background-color: white;
#endif
[…]
}So if combined with |
|
@tomayac - I would think it allows a page to opt into, not out of the user agent applied transformation. I mean, by default, the web did not intend dark mode controls. So this should remain the default for backward compatibility. If the user indicates it supports dark mode, then it opts into this transformation. Anyway, @aaaxx - since a media query for dark mode is also planned, you could use it at the (Note - this is pseudo-code, I do not remember if this is the exact syntax) |
|
@phistuck I have clarified my comment:
|
|
@tomayac - oh, to opt out of light mode transformation (since dark is opt-in by default), right? |
|
@phistuck Both actually the way I read it:
|
|
@tomayac - well, that does not make a lot of sense... "I support dark mode colors, so do not transform the page to have dark mode colors". Right? |
|
@tomayac - I see now. I re-read. Well, "only" is a bad keyword for this functionality. I would prefer "no-transformation" or something. :( I am not sure what is the use case for this keyword. |
|
I've tried to summarize this proposal in an article. Feedback/comments/corrections welcome. |
|
Since the META tag belongs in HTML, I've filed whatwg/html#4504 separately. |
|
Since the |
Yes. |
As described here, not implemented in Firefox but it is in Safari and Chrome: w3c/csswg-drafts#3299
Proposal
Authors should be able to style their content taking into account the users's preferred system-level color scheme (e.g. for dark mode on macOS Mojave, or Microsoft's high-contrast mode). This would allow, for example, a page to express the fact that it has a "dark mode", which would be displayed to users whose system preference is to use a dark-mode interface. Authors would use this new property in conjunction with the prefers-color-scheme media query.
Some UAs may also wish to apply automatic presentational transformations to web content (auto-darkening, or conversion into a high-contrast mode). The functionality described below allows a page to opt out of this UA-applied transformation.
Meta tag
We think adding a new meta tag is necessary so that UAs know early in parsing which color scheme is to be used, since this may impact the default appearance of the view containing the web content, and we wish to avoid flashes caused by delayed switches between color schemes.
The meta tag syntax is:
<meta name="supported-color-schemes" content="[light? || dark? || <ident>?]* || only?">"" (empty string) (the default)—the UA may choose to transform the content to match the user's preference.
light dark—the UA will choose the light or dark theme to match the user's preference. If the user's preference does not match something in the list, the UA is allowed to apply transformations to the content (e.g. apply high-contrast).only—synonym forlight only; the UA will only ever render the content in the light color scheme, and never apply transformations[1].light dark only—the UA will choose the first of the listed schemes that it supports taking user preference into account, and never apply transformations[1].Custom scheme, like
hi-contrast only—if the UA doesn't supporthi-contrastit's allowed to fall back to its default renderinglight, and will never apply transformations.Note:
<ident>is present for compatibility; some UAs may support color schemes in addition to light and dark, and the including of unrecognized schemes should not break parsing.must not be “only”
Note: Maybe the meta tag should be specified outside of CSS.
[1] UAs are allowed to apply minimal transformations, for example making the root background transparent, but not change the overall appearance of the content.
CSS Property
supported-color-schemes: [light? || dark? || <ident>?]* || only?Inherited: yes
Initial value: light
The CSS property has the same behavior as the meta tag, and allows authors to style sub-sections of content with a different color theme.
How the color scheme affects rendering
The UA may take the chosen color scheme into account when rendering the default page background, form controls, the default selection color, and other UA-controlled UI like misspelling underlines.
Interaction with the media query
The media query always matches the user preference. Authors should avoid styling content for the dark mode if they don't claim to support it in the meta tag.
Issue: Maybe in “non-only” mode the media query should reflect the scheme the UA is converting to?
The text was updated successfully, but these errors were encountered: