- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 29 May 2019 16:40:19 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `possible future <custom-ident> value 'sepia'`. <details><summary>The full IRC log of that discussion</summary> <dael> Topic: possible future <custom-ident> value 'sepia'<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/3853<br> <dael> AmeliaBR: Brought up fairly early on<br> <dael> AmeliaBR: If we're talking about other color schemes a likely example is sepia<br> <dael> AmeliaBR: afaik every browser with a reading mode has a sepia color scheme with a creamy beige bg and dark gray text<br> <dael> AmeliaBR: Color scheme is popular based on readability studies<br> <dael> AmeliaBR: Also used on some websites as their own style, like Financial Times<br> <dael> AmeliaBR: One thing missing is we don't have any UA or OSs with sepia scheme form elements and widgets<br> <dael> florian: Not sure, but I suspect these exist in ebook readers<br> <dael> dauwhe: Really common in ebook, but I don't think many have form controls<br> <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?<br> <dael> AmeliaBR: I think same in that they override most styles to apply reader mode color scheme<br> <dbaron> It's not clear to me why this should be distinguished from 'light'.<br> <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<br> <dbaron> I don't know how Firefox reader mode works.<br> <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<br> <dbaron> This sounds like making up use cases.<br> <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.<br> <Rossen_> q?<br> <dael> AmeliaBR: On your website using color scheme property being able to say these styles work with light or sepia, whichever user prefers<br> <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.<br> <dael> TabAtkins: Those being specializes systems can do overrides on their own. DOn't need arbitrary webages to sepia<br> <dael> florian: If sepia form controls are a thing FT might want to opt in<br> <tantek> colorizing form controls is the easiest thing to customize about form controls<br> <dael> florian: AmeliaBR you've been saying this controls form contorls and refault colors. Does it actually do that?<br> <dauwhe> q+<br> <tantek> confused by that assertion about sepia form controls<br> <dael> TabAtkins: Supposed to<br> <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.<br> <dael> florian: Thanks<br> <jensimmons> q+<br> <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.<br> <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.<br> <Rossen_> ack dbaron<br> <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.<br> <dael> AmeliaBR: Form control maybe light makes sense to use in both. but it's knowing difference between light and sepia<br> <dael> dbaron: You could have a light with sepia-ish settings<br> <dael> TabAtkins: Or a black on white and lighter and both trigger from white<br> <dael> AmeliaBR: How would an author respond?<br> <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<br> <tantek> images, thus background images, decorative images etc.<br> <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.<br> <AmeliaBR> tantek, I don't think that happens. THis is about typography colors.<br> <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.<br> <dael> AmeliaBR: Good argument. Add color scheme in the media query but consider it light in color scheme?<br> <dael> TabAtkins: Yes. Light and dark are super categories. As we ID useful others they're sub categories we add to the MQ only<br> <Rossen_> q?<br> <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<br> <dael> AmeliaBR: Maybe try and find some time at F2F to think that it might look like<br> <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?<br> <dael> AmeliaBR: Having prefers color scheme for sepia is the biggest advantage. Sepia form elements aren't a high priority for me.<br> <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.<br> <dauwhe> ack dauwh<br> <Rossen_> ack jensimmons<br> <dael> jensimmons: Mostly have questions, but I can ask at F2F<br> <florian> q+<br> <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.<br> <dauwhe> https://github.com/readium/readium-css/blob/develop/css/src/modules/ReadiumCSS-sepia_mode.css<br> <dael> Rossen_: florian can we postpone to F2F?<br> <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.<br> <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<br> <tantek> iOS has grayscale, red/green filter (Protanopia), green/red filter (Deuteranopia), blue/yellow filter (Tritanopia), and "color tint"<br> <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.<br> <tantek> in the "Color Filters" setting inside "Display Accomodations" inside "Accessibility" inside "General" in "Settings"<br> <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<br> <dbaron> FWIW, browser default color backgrounds used to be gray rather than white, but basically all sites set a white background, so browsers changed...<br> <dael> Rossen_: Current issue as proposed I'm hearing pushback.<br> <dael> TabAtkins: There were just more details. I'll write up in issue and we'll discuss at F2F<br> <dael> Rossen_: I'll change label to F2F agenda<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-497015252 using your GitHub account
Received on Wednesday, 29 May 2019 16:40:23 UTC