[css-color-adjust-1] possible future <custom-ident> value 'sepia'

[BillGoldstein]

Suggestion:

In section 'Opting Into a Preferred Color Scheme: the color-scheme property'https://drafts.csswg.org/css-color-adjust-1/#color-scheme-prop,
suggest a possible future 'sepia' value for color-scheme .

Reasoning: It is a popular color scheme supported in many Reader Modes.

[AmeliaBR]

Agreed. Although it's not really a standard UI color scheme, we've got multiple implementations of it in CSS user agents for document styling. Standardizing the name & a couple details of what it means would allow those user agents to start experimenting with exposing it outside reader mode.

[fantasai]

Options here:

• Add it to the spec as a legal value with a description
• Don't add it to the spec, but use it in an example of handling unknown names from the future
• Don't mention it

[AmeliaBR]

My vote is for adding it directly as a valid value.

In addition to the reasons I stated previously, having a third value will force us to think carefully about how color schemes work when there are more than two options. E.g., should users be able to rank color schemes preferences in their browser options? (sepia > light > dark) How should that impact media queries & color scheme selections? If sepia UI (e.g. form elements) are available, should an author be able to force their use when the user preference is for light?

[css-meeting-bot]

The CSS Working Group just discussed possible future <custom-ident> value 'sepia'.

The full IRC log of that discussion

<dael> Topic: possible future <custom-ident> value 'sepia'
<dael> github: https://github.com//issues/3853
<dael> AmeliaBR: Brought up fairly early on
<dael> AmeliaBR: If we're talking about other color schemes a likely example is sepia
<dael> AmeliaBR: afaik every browser with a reading mode has a sepia color scheme with a creamy beige bg and dark gray text
<dael> AmeliaBR: Color scheme is popular based on readability studies
<dael> AmeliaBR: Also used on some websites as their own style, like Financial Times
<dael> AmeliaBR: One thing missing is we don't have any UA or OSs with sepia scheme form elements and widgets
<dael> florian: Not sure, but I suspect these exist in ebook readers
<dael> dauwhe: Really common in ebook, but I don't think many have form controls
<dael> myles: Reader mode in safari is picky about styles it lets through to reader mode. Do others work the same or do they dump the styles into reader mode?
<dael> AmeliaBR: I think same in that they override most styles to apply reader mode color scheme
<dbaron> It's not clear to me why this should be distinguished from 'light'.
<dael> AmeliaBR: We're talking about creating an option so on the main page a website could opt into those defaults so if user prefers them it can be on top. Wouldn't change whichs styles get into reader mode
<dbaron> I don't know how Firefox reader mode works.
<dael> myles: I'm trying to understand difference between a regular page like FT with a speia scheme compared to reader mode where browser supplies most of the styles. Neither use case needs this
<dbaron> This sounds like making up use cases.
<dael> AmeliaBR: Use case is responding to user preference. Being able to have a named color scheme that you could ask prefers sepia from prefers light. They're different in terms of reader experiences.
<Rossen_> q?
<dael> AmeliaBR: On your website using color scheme property being able to say these styles work with light or sepia, whichever user prefers
<dael> TabAtkins: myles point is arbitrary webpages where users can want to view light or dark. Arbitrary pages is sepia seems a lot smaller. reader mode replaces everything already. I haven't seen reader systems that do substanital css styling.
<dael> TabAtkins: Those being specializes systems can do overrides on their own. DOn't need arbitrary webages to sepia
<dael> florian: If sepia form controls are a thing FT might want to opt in
<tantek> colorizing form controls is the easiest thing to customize about form controls
<dael> florian: AmeliaBR you've been saying this controls form contorls and refault colors. Does it actually do that?
<dauwhe> q+
<tantek> confused by that assertion about sepia form controls
<dael> TabAtkins: Supposed to
<dael> AmeliaBR: florian's question, yes. If you set a color scheme on the root element then default background and text color should match that scheme.
<dael> florian: Thanks
<jensimmons> q+
<dael> dbaron: I still don't see why this is different from light. These schemes in reader mode are generally light colored. I don't see reason why not same as light.
<dael> AmeliaBR: I brought up reader as an example where this sceheme is popular. readers and ebooks offer sepia distinct from light so it means readers find these things different.
<Rossen_> ack dbaron
<dael> AmeliaBR: As a reader if I had a preference on a website to use sepia I would use that. Given it's popular in other reading environments i"m not the only.
<dael> AmeliaBR: Form control maybe light makes sense to use in both. but it's knowing difference between light and sepia
<dael> dbaron: You could have a light with sepia-ish settings
<dael> TabAtkins: Or a black on white and lighter and both trigger from white
<dael> AmeliaBR: How would an author respond?
<tantek> one possible difference between "light reader" and "sepia reader" is treatment of color images - I'd expect the latter to sepia-ize images, but not the former
<tantek> images, thus background images, decorative images etc.
<dael> TabAtkins: MQ can offer finer grained. If you want to address sepia tones when can provide that so a page can opt into that.
<AmeliaBR> tantek, I don't think that happens. THis is about typography colors.
<dael> TabAtkins: Agree with dbaron now, it's a good point, need an argument why color sheme property needs more than those two. It's generally light or generally dark. Page doesn't know if it's high contrast light or sepia light.
<dael> AmeliaBR: Good argument. Add color scheme in the media query but consider it light in color scheme?
<dael> TabAtkins: Yes. Light and dark are super categories. As we ID useful others they're sub categories we add to the MQ only
<Rossen_> q?
<dael> AmeliaBR: It's a practical solution that addresses use cases. Rethinking how property and MQ relate is required. Need to start thinking what the subsets mean for the MQ. What does it mean to prefer sepia but if it's not available light is better than dark. Ranking might come in
<dael> AmeliaBR: Maybe try and find some time at F2F to think that it might look like
<dbaron> I'm still not convinced about the need to add this to the media query, at least as a keyword for the existing one. Maybe media queries against characteristics of system colors?
<dael> AmeliaBR: Having prefers color scheme for sepia is the biggest advantage. Sepia form elements aren't a high priority for me.
<dael> dauwhe: This is a problem ebook has facer to balance user preference with content authors desire. epubs do a bunch of hacks. Even though these sound difficult I'm happy we're trying to talk about them.
<dauwhe> ack dauwh
<Rossen_> ack jensimmons
<dael> jensimmons: Mostly have questions, but I can ask at F2F
<florian> q+
<dael> jensimmons: We'll figure out the right balance between not overengineering and giving needed power. Open questions on how user of webpage spec what they want and will browsers provide those controls. Will designers design for many color systems? I'll ask these at F2F.
<dauwhe> https://github.com/readium/readium-css/blob/develop/css/src/modules/ReadiumCSS-sepia_mode.css
<dael> Rossen_: florian can we postpone to F2F?
<dael> florian: I thought F2F was MQ. My question is when we set property on root and it opts you into the correct color. If you say dark you get dark but when that means different colors you often have different foreground and background. But then you have image with background it looks bad in sepia. If you say light you might not be fine with any light, you'd look bad with sepia.
<dael> TabAtkins: I think that's exactly the deal we'll go with. Need to craft language. If you need white them spec white, if you're fine with anything light then use color scheme and you're good to good. Right now you have no way of knowing what type of light. It could be white, off white...problem exists today. You should set an explicit color if you need one
<tantek> iOS has grayscale, red/green filter (Protanopia), green/red filter (Deuteranopia), blue/yellow filter (Tritanopia), and "color tint"
<jensimmons> Web designers are not going to let go of control to the extent that ya'll are imaging they will.... things to debate about this over dinner & such next week.
<tantek> in the "Color Filters" setting inside "Display Accomodations" inside "Accessibility" inside "General" in "Settings"
<dael> AmeliaBR: Getting into last issue, if people test in current browsers light mode has a white background and people aren't planning for future. Need to warn people what is and isn't guar in color scheme
<dbaron> FWIW, browser default color backgrounds used to be gray rather than white, but basically all sites set a white background, so browsers changed...
<dael> Rossen_: Current issue as proposed I'm hearing pushback.
<dael> TabAtkins: There were just more details. I'll write up in issue and we'll discuss at F2F
<dael> Rossen_: I'll change label to F2F agenda

[AmeliaBR]

For the F2F, I think this is best as a breakout/workshop session, so we can work through some of the complications we just discussed on the call.

[tabatkins]

Summarizing from David's point in the minutes:

We don't necessarily need the 'color-scheme' property and (prefers-color-scheme) MQs to be in perfect alignment. In particular, we can define that "color-scheme: light" (or dark) just means that the UA's colors will generally be dark-fg-light-bg. That categorization matches the UA default, a high-contrast black-on-white, or even sepia (which is sepia-fg-white-bg).

This would mean that pages generically opt themselves into some kind of light (or dark) color scheme, without knowing the details beyond the aforementioned broad strokes about fg/bg lightness. Then the MQ can provide more detailed information for authors to specifically respond to if they'd like; (prefers-color-scheme: sepia) makes a lot of sense to add and respond to.

We'll have to put a little bit of thought into the MQ categories then, since presumably "light" and "dark" would still be supercategories there, so if we're carving out "sepia" we might want to also carve out some other common light schemes (like high-contrast white-on-black)

---

I like this quite a bit, as it handles lots of variation reasonably well. For example, the Nook app on Android has four different "light" themes (black on white, sepia on cream, black on pale brown, and black on light gray), two "dark" themes (white on black, light gray on dark gray), and one that's kinda light but a little weird (dark red on light red, presumably to help reduce blue light during evening reading)

[AmeliaBR]

sepia (which is sepia-fg-white-bg).

I'm not sure what colour you think "sepia" is, but the sepia colour scheme we're talking about is dark gray or dark brown foreground on cream/peach/beige background. The background color is the defining feature.

Firefox reader mode sepia:

Their other options are dark-gray-on-white and white-on-dark-gray:

MS Edge reader mode sepia:

Their other options include black-on-white, white-on-black, and black-on-gray:

So three of four are light modes, with the background lighter than the text color: one high contrast, one sepia, and one low contrast monochrome.

[tabatkins]

There are a lot of sepia-ish schemes. "sepia" is a dark brown tho, so white-bg-sepia-fg also qualifies; in particular, it's what happens when you run a sepia(100%) filter on the white-bg-black-fg default. ^_^

[tantek]

Would this page/post be considered "sepia"?

https://tantek.com/log/2002/12.html#L20021216

If I could I would use prefers-color-scheme: sepia for that page.

(Originally published at: https://tantek.com/2019/156/t4/)

[css-meeting-bot]

The CSS Working Group just discussed future <custom-ident> value sepia, and agreed to the following:

• RESOLVED: No change

The full IRC log of that discussion

<fantasai> Topic: future <custom-ident> value sepia
<astearns> github: https://github.com//issues/3853
<fantasai> AmeliaBR: Discussing idea of having sepia color scheme
<fantasai> AmeliaBR: to reflect reader mode options
<fantasai> AmeliaBR: discussed whether it's just a different type of light scheme
<fantasai> AmeliaBR: We have two different use cases
<fantasai> AmeliaBR: We have prefers-color-scheme MQ
<fantasai> AmeliaBR: which author use to set their own colors
<fantasai> AmeliaBR: And we have color-scheme which is about requesting or indicating which sets of UA color schemes you can work with without breaking
<fantasai> AmeliaBR: These use cases are different
<fantasai> AmeliaBR: Suggestion from Tab was for color-scheme property we could keep generic light/dark and maybe other
<fantasai> AmeliaBR: for prefers-color-scheme could have more nuanced options, so within 'light' might distinguish bright white vs sepia
<fantasai> AmeliaBR: Author could figure out which scheme user prefers the most
<fantasai> AmeliaBR: If we have nested hierarchical preferences, how does that look like?
<fantasai> florian: From MQ mechanics, no problem with multiple values matching atthe same time. Jus tneed to says so
<fantasai> florian: whether we want to do that is a separate question
<fantasai> AmeliaBR: So if we define nested categories, then MQ can handle it
<fantasai> AmeliaBR: Question is do we want a comprehensive set of queries light/dark/other?
<fantasai> TabAtkins: What would other be?
<fantasai> AmeliaBR: Brightly colored
<jensimmons> q+
<fantasai> AmeliaBR: Like blue-on-yellow
<astearns> ack AmeliaBR
<Zakim> AmeliaBR, you wanted to wrap up with some proposals
<fantasai> TabAtkins: I don't think that's realistic anywah
<fantasai> TabAtkins: Every scheme we've seen in practice can be described as light or dark
<fantasai> TabAtkins: I've seen maybe a few middling schemes, like light red on dark red
<fantasai> TabAtkins: but otherwise seen stark colors, low-contrast grays, and sepia
<fantasai> AmeliaBR: Also talked about color-scheme: any;
<fantasai> AmeliaBR: decided any was problematic
<fantasai> AmeliaBR: what about adding other
<fantasai> TabAtkins: Not quite as opposed, but don't think we need it yet
<jensimmons> q?
<fantasai> TabAtkins: If we have a definitive third category, then willing to reconsider
<fantasai> AmeliaBR: User would pick specific scheme, e.g. dark red on light red
<fantasai> AmeliaBR: But author has to say "this website can work with light scheme, dark scheme, or other scheme"
<fantasai> una: I think something as general as other is too generic
<fantasai> una: maybe call it contrast
<TabAtkins> s/willing to reconsider/happy to reconsider, and leaning toward that strategy for it/
<fantasai> una: like idea of sepia, but depends on so many things like ambient light
<fantasai> una: I like thought of considering that and giving authors more power
<astearns> ack jensimmons
<fantasai> jensimmons: I feel pretty strongly that the controls that we want to provide for authors
<fantasai> jensimmons: needs to match what browser makers are going to do in revealing user-facing controls
<fantasai> jensimmons: Right now we're responding to light mode dark mode toggles
<fantasai> jensimmons: It's in the news and popular media right now, switching entire OS to dark
<fantasai> jensimmons: or browser to dark
<fantasai> jensimmons: What I don't see is any browse rmaker stepping forward
<fantasai> jensimmons: to provide more complex controls for users
<fantasai> jensimmons: to opt into sepia or chocolate-fudge-brownie-cake or whatever
<fantasai> jensimmons: if we provide these controls to authors, they don't go anywhere
<fantasai> jensimmons: there's no demand for them, not hooked up to anything
<fantasai> AmeliaBR: non-browser UAs offer controls for more variants
<florian> q+
<fantasai> jensimmons: Or FF reader mode
<una> q+
<fantasai> jensimmons: But as author I can't style within reader mode anyway
<fantasai> jensimmons: there's nothing for me as an author to do
<fantasai> jensimmons: I have no access to that as an author
<fantasai> jensimmons: having a sepia mode in reader mode is not relevant to me as an author
<hober> i (again) completely agree with jensimmons
<fantasai> jensimmons: if Firefox wanted to hook that up to something else then we could consider
<fantasai> TabAtkins: If sepia mode shows images, might want to alter images
<fantasai> fantasai: Reader mode can apply sepia filter
<fantasai> jensimmons: Also want us to separate ideas that we personally have about how we want to surf the Web
<fantasai> jensimmons: from the reality of what browsers will actually implement wrt controls for users
<fantasai> jensimmons: Right now I don't think sepia reader mode will be hooked up to images like yo udescribe
<fantasai> jensimmons: This is one case where I really want browsers to say "we want this in CSS"
<fantasai> hober: We have a sepia mode in our ereader, and I don't want a sepia mode here.
<una> q-
<fantasai> TabAtkins: Do these books have CSS in them?
<fantasai> hober: of course they do
<fantasai> hober: Even if ? solves the problem for itself, I don't want to do it here
<fantasai> florian: EPUB is HTML + CSS
<fantasai> jensimmons: As person making a website, you can't control how reader mode presents content on any level
<tantek> q?
<tantek> ack florian
<fantasai> florian: Broadly yes, but for ebook readers, the style applies, the CSS that you apply in your book applies, and there is a sepia mode
<fantasai> jensimmons: Are there any ebook readers that want us to expose this to authors
<fantasai> dauwhe: I can also ask Readium about it
<fantasai> hober: As for a *positive request* from an implementer.
<fantasai> hober: I'm not saying never ship it
<fantasai> hober: if someone ships an OS-level control for it, we can do that
<astearns> s/As for/Absent/
<fantasai> hober: but I'm not seeing that
<fantasai> TabAtkins: I'm fine with that
<tantek> q+ to note that you'd likely need requests from authors of existing sepia styled web pages in order to motivate browser implementers to consider it
<tantek> e.g. https://github.com//issues/3853#issuecomment-499244493
<fantasai> TabAtkins: largely because behavior of "not sepia" and "not supported value" are identical
<AmeliaBR> q+ to reiterate Rossen's comment about users wanting different modes for content vs UI
<fantasai> TabAtkins: More general idea, what if any is the necessary correlation between color-scheme property and prefers-color-scheme
<tantek> but I don't know how much demand for this there is / would be? so I'm ok with or without it
<fantasai> TabAtkins: I think we can have them diverge in value space and meaning a bit
<fantasai> TabAtkins: Light vs dark we should keep
<fantasai> TabAtkins: prefers-color-scheme can deliver more detail as we wish it, sepia being a likely candidate
<fantasai> TabAtkins: When we have an existence proof of an implementation then we can add it later
<fantasai> TabAtkins: maybe put a note in the spec that this could happen
<fantasai> florian: I think I agree with Tab that MQ and prop are separate
<fantasai> florian: if we were to add sepia mode this is how we would do it, but absent demand from implementers let's not do ityet
<astearns> ack tantek
<Zakim> tantek, you wanted to note that you'd likely need requests from authors of existing sepia styled web pages in order to motivate browser implementers to consider it
<fantasai> tantek: I think similar to some of the previous questions, we should gauge it also by what are web author spublishing today
<fantasai> tantek: I've seen some sepia style pages, would be easy to opt in
<aja> issue was mostly to stop thinking of (supports-)color-scheme as binary dark/light, since it's spec'ed to support other values
<fantasai> tantek: but haven't seen a lot of them, so dunno how much demand there is
<fantasai> tantek: demand would have to be demonstrated to consder adding such a mode
<fantasai> TabAtkins: Note that none of this is "please add a sepia mode", it's just "if you have a sepia mode, ths is how to handle it"
<aja> what Tab said
<fantasai> tantek: To assess that plausibility in the future, we can look at what web authors are publishing to see if that would motivate browsers
<fantasai> TabAtkins: I don't care, it's not relevant to me
<fantasai> TabAtkins: I didn't say "please implement a new color scheme, browsers" Just establish how we will handle this in the future.
<fantasai> https://github.com//issues/3853#issuecomment-494472950
<fantasai> tantek: which of the three options are we going with?
<fantasai> Options here:
<fantasai> Add it to the spec as a legal value with a description
<fantasai> Don't add it to the spec, but use it in an example of handling unknown names from the future
<fantasai> Don't mention it
<fantasai> TabAtkins: I want a note in the spec so I remember in the future
<fantasai> fantasai: Add a comment in the source code
<fantasai> myles_: Audience of the spec isn't just ppl in this room
<jensimmons> q?
<fantasai> AmeliaBR: There's a note already mentioning possibility of future values
<astearns> ack AmeliaBR
<Zakim> AmeliaBR, you wanted to reiterate Rossen's comment about users wanting different modes for content vs UI
<fantasai> AmeliaBR: Wanted to respond to no demand from UAs
<fantasai> AmeliaBR: Nobody exposing these other modes
<fantasai> AmeliaBR: Want to go back to Rossen's comment about nested hierarchies
<fantasai> AmeliaBR: There's the OS color scheme, app UI scheme, and content color scheme
<fantasai> AmeliaBR: There is no demand for sepia in the outer levels
<fantasai> AmeliaBR: There is demand for color scheme selectors that focus only on content
<tantek> I suppose if there was a sepia color scheme I could change the photo on my site to use an old-timey outfit / hat.
<fantasai> AmeliaBR: It still comes down to we need UAs who are offering those color schemes to make that connection with these brand new CSS mechanisms
<fantasai> AmeliaBR: But just because it hasn't happened yet in the 6 months that we've discussed this, doesn't mean it won't happen next year
<jensimmons> q+
<fantasai> AmeliaBR: WE do have in the spec trying to be forward-focused with idea that there might be additional color schemes
<fantasai> AmeliaBR: so proposal is to clearly state that the color scheme keywords and prefers-color-scheme are not going to be 1:1
<fantasai> AmeliaBR: color-scheme property will focus on general classes of color scheme
<fantasai> AmeliaBR: and prefers-color-scheme exposes those classes but may in the future expose more specific subsets
<fantasai> AmeliaBR: to distinguish e.g. sepia mode vs bright white mode
<fantasai> florian: I don't disagree with what you're saying
<jensimmons> q+
<fantasai> florian: but it's overly prescriptive for what the WG might do in the future
<fantasai> TabAtkins: I'm done with this topic, we got the feedback we needed
<astearns> ack jensimmons
<fantasai> jensimmons: It's a good idea to think about future-forward and make sure we don't engineer ourselves into a corner
<fantasai> jensimmons: I also feel strongly that I don't want to put into any spec any values that don't exist yet
<fantasai> jensimmons: because it will really clutter up the discussion we have to have with designers
<fantasai> jensimmons: to explain all this dark mode light mode stuff
<fantasai> jensimmons: We already have to do a lot of education
<AmeliaBR> If the decision of the group is that we won't do this with user agent requests, we should have an note in the editor's draft spec requesting user agent feedback.
<fantasai> jensimmons: we don't need it to be excessively complicated or overwhelming
<AmeliaBR> s/with user/without user/
<tantek> more color modes = more job security for visual web designers! bring it!
<fantasai> jensimmons: I don't want to overengineer anything
<fantasai> jensimmons: keep ourselves from blocking into a corner, but don't try to anticipate a future that doesn't exist yet
<fantasai> RESOLVED: No change
<aja> tks for the (more serious than i'd even imagined) consideration

[lilles]

Closing based on resolution: #3853 (comment)