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