12:58:10 RRSAgent has joined #css 12:58:10 logging to https://www.w3.org/2019/06/05-css-irc 12:58:12 RRSAgent, make logs public 12:58:12 Zakim has joined #css 12:58:14 Meeting: Cascading Style Sheets (CSS) Working Group Teleconference 12:58:14 Date: 05 June 2019 13:00:40 tiger has joined #css 13:08:57 projector_ has joined #css 13:11:31 una has joined #css 13:11:50 (waiting on Florian and Elika to start the text brouhaha) 13:12:55 (now waiting on the espresso makers to return) 13:16:00 dauwhe_ has joined #css 13:17:15 present+ 13:17:57 Present+ 13:18:16 Zakim, remind us in 9 hours to go home 13:18:16 ok, dbaron 13:18:42 rachelandrew has joined #css 13:18:44 present+ 13:18:45 present+ 13:18:46 present+ 13:18:48 myles_ has joined #css 13:18:48 present+ 13:18:49 present+ 13:18:55 present+ myles 13:18:56 present+ 13:19:02 jensimmons has joined #css 13:19:02 present+ 13:19:02 present+ 13:19:06 present+ 13:19:15 fremy has joined #css 13:19:16 present+ 13:19:20 stantonm has joined #css 13:19:25 present+ 13:19:29 present+ 13:19:31 present+ 13:19:37 present+ 13:19:40 AmeliaBR has joined #css 13:19:40 present+ 13:19:50 present+ 13:19:50 present+ 13:19:52 present+ 13:19:57 scribeNick: una 13:20:10 ScribeNick: una 13:20:20 bkardell_ has joined #css 13:20:21 Topic: space expansion 13:20:30 https://specs.rivoal.net/css-space-expansion/ 13:20:34 present+ 13:20:59 Rossen_ has joined #css 13:21:04 present+ 13:21:25 florian: So there are a number of languages (human langs, i.e. Japanese) where there are no spaces between the words when you break them normally 13:21:44 ... and usually in Japanese for example, in childrens books (or for language learners) they do display spaces between words 13:21:56 ... they have space seperated chunks of sentences 13:22:13 ... sometimes they switch to a mode where they only break the line between words 13:22:25 ... the primary use for this is textbooks and storybooks for young children but also books for language learners 13:22:34 ... and its also something people with dyslexia appreciate 13:23:04 ... and so the ability to style a text to have word seperation with spaces or not is a stylistic choice where the dominant style is to not do this, but sometimes you want it 13:23:21 ... there is an increasing push to do this, and the govt is pushing for all textbooks to be available in electronic format 13:23:49 ... next week there is an exhbibition in Japan where several companies are going to announce ebook solutions where there is not a public standard for this 13:24:15 ... it turns out that very little is actually missing, so after discussing this w/the Japanese publishers and fantasai, we came up with a solution 13:24:48 chris has joined #css 13:24:49 ... that allows for unicode and have a CSS prop that turns these nito spaces so you do your markup w/normal Japanese text except you include your text w/space properties 13:25:01 present+ 13:25:05 myles_: but that doesn't include the case where you want to include line spaces 13:25:12 s/myles_ /hober/ 13:25:23 florian: word-break would re-introduce this, the line-breaking is already handles but space-insertion is not 13:25:38 ... the spec I'm introducing lets you expand these spaces 13:26:21 chris: so if youre copying and pasting (i.e. with plaintext) youre not going to see any visual difference 13:26:40 florian: so I wasn't seeing that in the presentation-preserving sense, but when people author things 13:27:19 ... if you use the unicode character rather than the HTML tag, you could do a similar thing 13:27:23 q+ 13:27:32 q+ 13:27:37 myles_: if you round trip it, you can't do that- how would the other env know? 13:27:44 s/myles_/hober/ 13:28:02 fantasai: all of these presentations are valid presentations, it just depends on the user context as to what they want. it will wrap and look like normal text otherwise 13:28:33 ... when you copy text out of an HTML doc it operates under loose rules of line-breaking and theres still no problem with the text 13:28:43 s/can't do that/don't get the word-break: keep-all behavior/ 13:28:43 ... it's a similar concept to this 13:29:12 florian: just to finish this up: the property is designed to be inheritable 13:29:31 ... if you want to selectively turn on some word breaks and not others, you can put classes on your wbr's and turn it off here and there 13:29:44 ... and then in the spec I have a few examples 13:30:04 AmeliaBR: how does this interact w/justification and word spacing? 13:30:10 florian: it's kind of like a text transform 13:30:22 AmeliaBR: so justification/wordspacing would be applied after? 13:30:24 florian: yes 13:30:53 florian: I started w/a Japanese usecase for this. we're using wbr, something that is valid if not common in Thai. 13:31:08 q? 13:31:12 fantasai: cases where this could be useful: Etheopic typesetting 13:31:30 q+ 13:31:34 ... this property could be able to switch between the two. Also Korean where you want to collapse line spaces 13:31:40 ... we should design the prop with that in mind 13:31:50 chris: this sounds like you have an open ended list of substitution chars 13:31:59 fantasai: substitution is propably a seperate property 13:32:20 florian: based on the Etheopic/Korean use case, it's prob not a space-expansion property, but a space-substituion prop 13:32:31 ... so theres a bit of bikeshedding to figure out what we want this to expand to 13:32:41 q? 13:32:41 chris: space substitution sounds like the content gets changed 13:32:45 q+ 13:32:56 koji: I have two pieces of feedback: 13:33:13 ... 1 is for the usecase this is done by a font feature 13:34:09 ... 2 the other one is about the content is okay with keyed content, and combining this idea with keyboard, but a11y includes non-keyed content. Keyboard is not enough 13:34:36 fantasai: if you want to 100% control breaks with the wbr element, you can set the entire element w/whitespace:nowrap 13:34:48 koji: I disagree 13:35:24 q? 13:35:24 florian: thats a bug, whitespace applies to inlines, and something that should wrap inside of it and doesnt wrap should be fixed 13:35:28 ack koji 13:35:46 ?: we definitely did have compat bugs and fixed them 13:35:53 s/?/emilio/ 13:35:58 florian: there are definitely bugs left in that area, but the bugs are getting fewer 13:36:00 q+ 13:36:25 koji: what about the other part? I think substitution can be better done by font features 13:36:45 florian: this does not interact with other props done by CSS text, these are regular spaces substituted in. All the text works 13:36:55 ?: strong argument this should be done by every font 13:36:58 florian: yes 13:36:59 jensimmons has joined #css 13:37:08 s/?/myles_/ 13:37:14 koji: 0 width has justification 13:37:18 fantasai: no 13:37:29 ack astearns 13:37:38 astearns: you mentioned that there are proprietary ebook solutions proposed for this, do you know what they are? 13:37:48 florian: I dont know what they are, I just know they will be announced 13:38:04 ... I dont know how they work, I just know its a topic that is bubbling in the market 13:38:24 astearns: we should prob get their input on how they want their ecosystems to express this thing 13:38:39 florian: I havent talked to the software vendors, but i've talked to the publishers 13:38:47 ... they dont want to get vendor-locked 13:38:54 ... thats why Japanese publishers are pushing for this 13:39:05 ack AmeliaBR 13:39:06 ... they dont want to do something that turns away from the open platform of the web 13:39:11 AmeliaBR: I have 2 questions: 13:39:26 ... 1. Is it feasible to get acceptable results from this in an auto way (i..e hyphenation dictionary) 13:39:39 ... end users might want to change display but that only works if the text has these complex word breaking inserted 13:40:08 florian: yes and no - some kind of natural lang processing could insert this. probably in regular publishing tha tis meant to do this, there is some degree of regular publishing and some manual 13:40:16 ... language analysis is not 100% reliable 13:40:26 ... if its done automatically you'd get some mistakes, some degree being right 13:40:55 ... in the textbook concept, since there are diff degrees of strictness, for content that is intentionally prepped for this, they'd probably use a bunch of manual application 13:41:11 AmeliaBR: so then my q is - is it reasonabel to treat this like hyphenation in the browswer? 13:41:18 fantasai: I think you'd have to do gramatical analysis 13:41:26 ... I dont think we'd want to build that into the browser 13:41:42 AmeliaBR: My second q - you said it behaves like a text transform. Why does it need to be a seperate prop? 13:42:10 florian: I'm leaning toward it not being a part of text transofrm for 2 reasons - text transform happens after whitespace collapsing, I think this should happen before 13:42:22 ... another reason is from an author point of view this should be seperate 13:42:33 ... the inner mechanism can use some of the same machinery 13:42:36 q? 13:42:40 ... thats issue 3 in the spec 13:42:53 fantasai: cascading seperately is really he reason it should be a seperate property 13:43:16 ?: this reminds me of something completely different 13:43:29 ... sometimes when people have text of poetry, they seperate the lines with slashes 13:43:38 s/?/dauwhe/ 13:43:39 s/?/dauwhe/ 13:43:40 ... and go back and forth with great annoyance to line breaks and slashes 13:43:50 ack dauwhe 13:43:59 fantasai: I'd like to deal with that using the
tag 13:44:05 florian: in that case it's kind of similar 13:44:24 fantasai: this one is doing a transformation on the result of the br 13:44:34 florian: it's considered sort of equivilant to a whitespace 13:44:51 q? 13:45:03 ack myles_ 13:45:11 myles_: so I think this is a pretty interesting feature, and don't know much about it but I have q's.. 13:45:46 ... there are text facilities for getting words and characters between some text, I wonder if the same facilities could be extended to iterate over clauses and rather than having content inject a bunch of 0 width and wbr chars, 13:45:55 ... for the same reason justification is done by the browser 13:46:08 florian: I think this would fall short. unlike hyphenation, it's not just dict based 13:46:35 ... it's harder to do - this kind of software exists in Japanese, but it's not all there and it sounds expensive and hard 13:46:49 ... you'll probably also want to add classes to your wbrs 13:47:04 ... to seperate different words and the automated approach wouldn't be subtle enough to do this 13:47:16 myles_: that's still better than having people spray a bunch of chars inside their content 13:47:26 fantasai: that might be good enough for general web browsing, but not for publishing 13:47:50 myles_: I think hyphenation is great model for this 13:48:13 ... I think its worth investigating rather than defining this is the one true way 13:48:43 myles has joined #css 13:48:54 fantasai: we need to do this quickly enough before the japanese publishing industry is forced to switch to properietary solutions 13:49:14 florian: I don't think this model is incompatible with the automated mode in the future 13:49:26 q? 13:49:58 AmeliaBR: we can have an automatic model, and this is what do you do with those breaking opportunities 13:50:11 q? 13:50:12 ... do you auto insert word break opportunities when there is a good browser solution 13:50:29 myles_: the next thing is, there are 2 mechanisms for describing where the spaces go -- why? 13:50:35 florian: I would describe it as 1.5 instead of 2 13:50:39 s/do you/a separate property could say whether you/ 13:51:28 florian: when we've tried to characterize what wbr is, the fact that it applies to 0-width space would make it auto apply to wbrs 13:51:35 ... I want to be able to put classes on these wbrs 13:52:01 q+ 13:52:06 ... i think just doing it w/wbrs and ignoring 0-width spaces would solve the problem-ish but its not unimaginable to say an IME would insert whitespaces between words 13:52:36 myles_: I was just about to say i like wbr bc when you copy and paste they get stripped 13:52:42 florian: but those aren't garbage characters 13:53:19 myles_: under which situation would someone want to change the value of the css here - why not bake it in, why is it configurable 13:53:40 florian: regular content ppl read is not spaces out but ppl w/dyslexia will want that to be spaced out 13:53:55 ... you can add a browser extension to have this space out characters 13:54:14 ... if youre reusing the same content for various grades (school grades) you can space it based on grades 13:54:28 fantasai: the japanese industry can standardize levels of spacing 13:54:39 AmeliaBR: it can become a part of the e-reader styling 13:55:21 fantasai: a lot of ebook readers arent going to do a lot of NLP, and the point is we want to provide visibility in the platform so people can build on top of it 13:55:42 q+ 13:56:29 fantasai: I dont think its necessary for epub readers to transform the text, it can be a css prop they can turn on and off 13:56:36 koji: I agree with Myles and we should try to make this a feature of the readers not the platform 13:56:57 fantasai: suppose you have a website w/stories for children to read, they can use their own UI 13:57:00 rachelandrew_ has joined #css 13:57:18 ack hober 13:57:58 hober: overall this sounds great, but one of the rsponses to the q of doing this automatically is that it might be hard to implement, and everyone uses ICU these days - there is a patch for line break 13:58:09 ... in principle this kind of thing could be done with ICU in shorter term 13:58:20 s/line break/myanmar line breaks/ 13:58:34 ... i'd like to tune-in to ICU case by case to make this happen automatically in the shorter-term 13:58:57 AmeliaBR: we should think of the model as automatic when designing the props even if manual gets implemented first 13:59:06 florian: sounds reasonable. the model should at least be compat w/that 13:59:19 q? 13:59:23 fantasai: they should say which one they want to find 13:59:37 ?: we've done analysis on word breaking, its not sufficient. ICU is not enough 13:59:44 s/?/stantonm/ 13:59:53 q? 13:59:56 stantonm: you get about 80% of the way there 14:00:32 fantasai: I think one fo the things you have is with hypehnation, you get a word, and at what point do you decide at the 0-width space that you dont want any breaks 14:00:37 q? 14:00:48 ack Zakim 14:00:50 Karen has joined #css 14:00:54 ack stantonm 14:01:05 stantonm: I was also going to agree that the way to add spaces automatically without the markup - we do that w/kindle and don't see authors do a lot of extra work on their content 14:01:15 ... but allowing the flexibility to do this would be a nice touch 14:01:32 florian: i see more optimism about the feasability of manual insertion than what I heard in Japan 14:01:59 ... what I'd like to do at this point is take this as a standalone ED or more likely as a standalone section and go through them over the next couple of months 14:02:24 ... if some browsers find this interesting and imp gets sponsored in others, we could make reasonable rapid progress in this 14:02:33 ... does this look liek something we should impl into text lvl 4? 14:02:52 AmeliaBR: are you willing to accept this should be 2 props - 1 defining the transformation and 1 defining whether it should be manual or automatic? 14:03:06 florian: I agree it should be manual and automatic whether that should be a flag 14:03:16 fantasai: I think a seperate prop for auto makes sense 14:03:24 ... its quite a different usecase 14:03:33 florian: fair enough 14:03:57 ... we could put this into text level 4 and automtic text level insertion into level 4 as well 14:04:15 fantasai: I think we need some kind of outline for the second prop but we can take a resolution to this one 14:04:24 ... i dont want to define a prop w/undefined set of vals in the spec 14:04:41 Rossen_: We can do that -- for the 0-width space we can add this one now - any objections? 14:05:04 Rossen_: Resolved, and a seperate resolution is to define the auto vs. manual one and once its ready lets bring it on the call and decide on it 14:06:02 projector has joined #css 14:06:15 RESOLVED: Add zero-width-space-expansion to text4 14:06:33 Rossen has joined #css 14:06:47 RESOLVED: Add manual vs automatic space expansion property (name TBD) to text 4 14:07:03 shans has joined #css 14:07:33 sylvaing has joined #css 14:08:34 leaverou has joined #css 14:08:56 [some name bikeshedding; agreement that we don't want to bake the character name zero-width-space into the property name] 14:08:57 Rossen_: Let's move onto the next topic: issue 3927 14:09:03 We should rename the property in a way that isn't tied into specific character names 14:09:04 plinss_ has joined #css 14:09:11 one possible future use case is switching between space / ethiopic word-space 14:09:16 (which is a visible character) 14:09:21 so take that into consideration 14:09:29 Topic: hyphens:auto should not hyphenate Capitalized words 14:09:29 florian has joined #css 14:09:38 github: https://github.com/w3c/csswg-drafts/issues/3927 14:10:02 florian: so the issue being raised is that in some langs, when words are capitalized you should hyphenate and in some they should not 14:10:08 ... we should bake this into the spec 14:10:27 ... i'd like to close this as wontfix or rejected bc we already say this is dict based within the logic of the lang-based resource 14:10:39 q+ 14:11:15 fantasai: I would go a little farther and say that we should only put a note and not change normative requirements and talk about proper nouns 14:11:31 ... it can suggest i.e. in English you may want to supress hyphenation words that are proper nouns and mixed case 14:11:49 ... I would like to leave the heuristics up to the user agent and not bake anything into the spec 14:12:00 ack dauwhe 14:12:24 dave: in english should capital letters be hyphenated? maybe... I wouldn't want anythign baked into the spec that says what should happen 14:12:29 s/dave/dauwhe/ 14:12:49 AmeliaBR: the rec is more to add a suggested note to add in your hyphenation dictionaries you should consider this 14:12:54 ... at least one browser has agreed 14:13:00 ... not sure this is a normative requirement 14:13:18 Rossen_: so proposed resolution for this is to add a note and no normative change 14:13:42 RESOLVED: Add A note to the spec and close with no normative change 14:13:51 tiger_ has joined #css 14:14:17 florian: myles, a while back you raised 3566 - should we reopen? 14:16:04 Topic: Does vertical writing mode of an HTML body element cause an orthogonal flow? 14:16:13 github: https://github.com/w3c/csswg-drafts/issues/3066 14:16:36 fantasai: This deals w/the fact that we have writing mode propogation from writing mode to HTML tha tis not very consistently implemented 14:17:17 ... it seems to me that we should propogate it to the HTML elem and consequently not have an orthogonal flow bc its on the the entire doc, not the root element 14:17:31 jensimmons has joined #css 14:17:34 Rossen_: so this is only the case when writing mode is specified ont he body only 14:18:00 fantasai: whether you specify one on the body or not, we're basically ignoring it 14:18:17 Rossen_: you end up w/double scrollbars sometimes on the wrong sides 14:18:20 fantasai: Edge doesn't do that 14:18:26 ... my proposal would be to do what Edge did 14:18:44 myles_ has joined #css 14:19:13 ... theres a few things that need to be fixed, but the proposed resolution is to go w/that Edge did which is that the body writing mode is propogat4ed to both the root element and the writing block 14:19:28 AmeliaBR: so it would be treated the same as if you set it on the HTML 14:19:31 Rossen_: as an overwrite 14:19:53 emilio: there is a viewport implementation, but the root element style is different 14:20:08 Rossen_: wish we had a time machine to go back and have fixed this when it was originally done 14:20:16 fantasai: there are margin-collapsing bugs 14:20:28 ... we resolved to propogate things before but there are some side effects 14:20:48 koji: in chrome, we used to track the propogate and we resolved not to propogate and removed the code 14:20:59 fantasai: really? i remember it wasn't possible 14:21:08 florian: IIRC direction does not propogate 14:21:09 s/possible/possible due to compat/ 14:22:05 emilio: we should use a computed value propogation ? 14:22:24 emuller has joined #css 14:22:39 dbaron: the way the spec describes this propogation, it is not affecting the computed styles 14:22:53 koji: only the principle writing mode is affected but no style propogation 14:23:08 dbaron: if i read what the spec says literally - it is saying tha ti fyou set writing mode on body to vertical LR 14:23:31 ... you have an initail containing block fo rvertical LR containing a block for the body element which is seperate 14:23:52 florian: either dont do any propogation at all or have all of those things use the same writing mode 14:24:17 koji: propogation leads to conflicts 14:24:44 dbaron: the hardest part of style is changing the computed styles, if you want to fix this propogation you want to make the propgat4ed val also apply to the block for the elem 14:25:06 ... without messing with styles at all, making it apply to both the block and the styles for the html 14:25:18 florian: we added propogation bc it felt necessary and i dont think we can remove it 14:25:29 fantasai: my recollection was compat requirements for ebooks, which is why we have it 14:25:41 emilio: batch propogates writing mode props 14:25:56 ... direction, writing mode, etc. 14:26:12 fantasai: i think we're propogating the full set, doing part of it will get weirdly inconsistent 14:26:24 ... writing mode, direction, text orientation are the set of props that determine the direction mapping 14:26:37 ... i think text-orientation won't have any effect on the intitial containing block anyway 14:26:57 s/you have an initail containing block fo rvertical LR containing a block for the body element which is seperate/you have an initial containing block that's vertical-lr containing a block for the html element that's horizontal containing a block for the body that's vertical-lr/ 14:27:13 q? 14:27:32 Rossen_: so are we leaning towards that resolution that defined the propogation without affecting computed styles? 14:27:53 ... so the style subsytem doesn't have to be complex, but the experience makes sense and it avoids orthogonal flow changes when they're not needed 14:28:09 emilio: it'll be weird if you have a pseudo element but i guess thats not very common 14:28:49 iank_: I'm a big concerned about the perf implications 14:29:34 Rossen_: let's evaluate the perf once you have a patch that actually does it 14:29:46 s/a pseudo-element/a pseudo-element in the root element 14:30:14 ... in terms of behavior the proposed resolution is to add from body to the root element, the propogration & logic 14:30:35 ? : is this for any root element? 14:30:40 Rossen_: I remember we didn't do this for SVG 14:30:45 s/?/heycam/ 14:31:07 AmeliaBR: is there a reason not to do it for SVG? 14:31:13 Rossen_: we didn't have body element in SVG 14:31:30 AmeliaBR: the propogation doesn't apply but the fact that the root element defines a principle writing mode for the document should apply to SVG 14:31:37 Rossen_ & fantasai: sure 14:32:17 iank_: what happens to props like border-block-end? 14:32:34 fantasai: for propogating the user values, theyre resolved before writing implementation 14:33:04 iank_: I'm concerned about low-end device perf 14:33:12 Rossen_: let's talk abotu it when we have a little more info 14:33:48 AmeliaBR: so is the resolution full propogation from the body to the root 14:34:21 Rossen_: progotat4e direction, writing mode, and text orientation from the body to the root without affecting computed styles 14:35:10 s/progotat4e/propogate/ 14:35:40 fantasai: the case of the document specifying vertical text orientation on the entire document and also being RTL is an unusual use case 14:35:49 Rossen_: the proposed resolution is the same minus text-orientation 14:36:13 fantasai: we could say propagated text orientation is optional 14:36:43 proposed resolution: propagate direction, and writing mode from the body to the root without affecting computed styles w/optional text-orientation 14:36:56 tantek has joined #css 14:36:59 RESOLVED: proposed resolution: Propagate direction, and writing mode from the body to the root without affecting computed styles w/optional text-orientation 14:37:17 present+ 14:37:24 fantasai: we'll need an implementation report and some bug fixes 14:37:32 Rossen_: is it vastly different than what was done before? 14:37:38 s/RESOLVED: proposed resolution:/RESOLVED:/ 14:37:39 fantasai: it needs an update 14:38:21 florian: we're a week worth of work away from making it a rec - bug fixing and updating the implementation report 14:38:44 github: topic 14:38:56 github: end topic 14:39:00 github: endtopic 14:39:17 topic: break 14:39:19 github-bot: endtopic 14:39:19 Rossen_, Sorry, I don't understand that command. Try 'help'. 14:39:25 github-bot: end topic 14:39:39 github-bot: help 14:39:39 Rossen_, The commands I understand are: 14:39:39 help - Send this message. 14:39:39 intro - Send a message describing what I do. 14:39:40 status - Send a message with current bot status. 14:39:40 bye - Leave the channel. (You can /invite me back.) 14:39:40 end topic - End the current topic without starting a new one. 14:39:41 reboot - Make me leave the server and exit. If properly configured, I will then update myself and return. 14:39:47 github-bot: end topic 14:49:03 myles has joined #css 14:53:48 s/to lunch/to dinner/ 14:59:17 jensimmons has joined #css 14:59:40 ScribeNick: emilio 15:00:45 Topic: (css-text) Add new CSS text-transform values for math 15:01:07 Github: https://github.com/w3c/csswg-drafts/issues/3745 15:02:11 fantasai: I really think this should be done with i18n experts 15:02:24 ... probably at tpac 15:02:33 Rossen: who added it to the agenda? 15:02:35 bkardell_: I did 15:02:43 Rossen: are we ready to discuss this? 15:02:49 Rossen_ has joined #css 15:03:10 bkardell_: there were very strong objections when I added it to the agenda but it seems that has been solved 15:03:21 bkardell_: I'd like to make some progress on that issue 15:03:32 astearns: what's the points you're talking about? 15:03:56 bkardell_: the philosophy of text-transforms and how it interacts with a11y 15:04:05 q+ 15:04:12 q+ 15:04:13 bkardell_: we have a new transform that prob. needs to do something different 15:04:27 ... the are at least two answers to the questions 15:04:43 florian: I think that's why we need other experts on the discussions 15:05:00 ... because whether text-transform affects the semantics is complicated 15:06:18 fantasai: I think text-transform, if we're stuck for compat with a11y for capitalization that's unfortunate, but we shouldn't introduce the same for math 15:06:31 https://github.com/w3c/csswg-drafts/issues/3745#issuecomment-478206009 15:07:02 florian: once we have the markup communicate the semantics, we probably want text-transform to affect some of the presentation but not a11y 15:07:53 bkardell_: my understanding is that we'd encourage putting it in the markup, but there's a bunch of legacy content which is what would make this necessary 15:08:32 AmeliaBR: I think florian's point is that you could have a presentation transform but the accessibility stuff should be in the markup 15:09:01 bkardell_: I'd like to get some kind of checkpoint on this 15:09:53 AmeliaBR: the question is: "for math-variant to be exposed and accessible, does it need to be exposed through text-transform transforming the text-content, or via an attribute that gets passed to the a11y tree, which _also_ gets a UA rule to make the presentation change' 15:10:23 fantasai: I think that's the right way to go, and gives you the ability to give more accurate info to a11y that doing unicode transformation 15:10:37 ... unicode transformation doesn't contain math semantics 15:11:18 ... that needs to be in the markup, if that information is in the content it should be given to a11y that way, rather than via text-transform 15:11:52 ... a11y doesn't say "Bold", it uses the fact that you're on 15:12:39 AmeliaBR: actually that's not true, a11y is trying to introduce roles for and similar, authors don't distinguish or 15:13:12 ... if there's an italic in a header it'd be called out depending on the verbosity level 15:13:24 Rossen: it calls out format stops 15:14:42 s/a11y/ARIA WG/ 15:15:05 bkardell_: there's a similarity here with html's kinda-weak semantics, a11y tools get mostly plain text with other hints, for math a11y my understanding is that some tools use the unicode information 15:15:33 Rossen: we don't support mathml in Edge 15:15:47 bkardell_: well, Edge does parse mathml as XML content 15:16:12 ... which is why mathml is a kinda weird place 15:17:08 Rossen: [describes how a11y works in Edge and how screen readers can poke at the DOM / render tree in non-Edge (Chromium / Firefox)] 15:17:37 Rossen: Edge doesn't allow third-party processes in its process 15:18:00 bkardell_: please fact-check me :) 15:18:20 myles_ has joined #css 15:18:29 fremy has joined #css 15:18:49 florian: I think this is a topic for TPAC, since different a11y experts have diverging oppinions 15:19:11 Rossen: are we going to make any progress? 15:19:14 q? 15:19:28 bkardell_: do we have some specific questions/ 15:19:29 *? 15:19:35 ack AmeliaBR 15:20:04 ack iank_ 15:20:04 AmeliaBR: I think my point was previously said, so to wrap up: We're saying that the specific proposal is to take it back to see if we can decouple the style and the markup a11y, and defer for TPAC? 15:20:08 bkardell_: yeah 15:20:09 ack iank_ 15:20:29 iank_: seems like the people objecting about text-transform is just about a11y, is that correct? 15:20:57 AmeliaBR: yeah, it's about whether it sees the characters for a11y before or after transform 15:21:32 florian: it's not just about a11y but more generally the semantics, like what would happen in reader mode and such? 15:22:37 iank_: another point is that mathml has a lot of legacy content, and mathml does this in a very magic way. We don't want to get in a situation where other math libraries cannot opt-in to this power 15:22:53 Rossen_: let's stop here for now 15:23:14 Topic: resolved value of line-height 15:23:23 github: https://github.com/w3c/csswg-drafts/issues/3749 15:23:32 github: https://github.com/w3c/csswg-drafts/issues/3749 15:23:58 AmeliaBR: what's the question to be resolved? 15:24:18 florian: this is about the resolved value of `line-height: normal` 15:24:34 koji: right now Blink behaves differently from Gecko / WebKit 15:24:48 koji: one of our contributors is willing to try to change Blink 15:24:56 koji: seems smoother for Blink to change, want to confirm that with WG 15:25:05 ScribeNick: fantasai 15:25:13 scribenick: heycam 15:25:18 emilio: Gecko and WebKit already have this behavior since CSS 2 15:25:34 ... CSS2 defines the used value of line-height as something based on the primary font of the element 15:25:50 ... I did try to switch Gecko to return normal, and it's probably not impossible, but it's a bunch of work 15:25:56 ... also mats disagreed with it 15:26:00 florian: what CSS 2 has to say is fuzzy 15:26:04 ... different editions 15:26:13 ... all browsers are interoperable about what line-height:normal does, to an approximation 15:26:22 ... that is different from what CSS 2.1 says 15:26:28 ... 2.1 claims normal is equivalent ot a number 15:26:31 ... that's not what everyone does 15:26:44 ... therefore it would make sense that for resolved value, you return the word "normal" 15:26:49 emilio: there is 15:26:50 florian: there isn't 15:26:55 ... there is only if the element is empty 15:27:04 dbaron: part of the problem is we had a long discussion at Tokyo F2F about line height 15:27:14 ... and there's nothing written down that reflects the results of that 15:27:19 ... in a readable format 15:27:24 ... some edits made to CSS 2 and reverted 15:27:39 ... there's no usable reference for the results of that discussion, therefore some people involved here inlc emilio and mats, who don't know what's discussed there 15:27:45 florian: I'm frustrated about these edits being reverted 15:27:55 ... I'll take those edits and put them into css-inline 15:28:11 ... skipping oer the detalis, the behavior of line-height:normal is not euivalnet to a number 15:28:35 emilio: you copmute a number at the start of the element (and the element itself), but once you get that number, which is what Gekco and WK return from gCS, it's the same as if you use that px value ... 15:28:36 dbaron: it's not 15:28:40 ... there are 2 ways it's different at least 15:28:52 koji: I think dbaron and florian are talking about how line-height:normal is laid out 15:28:59 ... emilio is talking about how line-height is computed 15:29:06 ... and that is interop between Gecko and WK 15:29:17 dbaron: what florian and I are saying is that there does not exist a number or a px value that is equivalent to normal 15:29:31 ... because depending on the text you have in the element, adn what font fallbcak occurs, you'll get different results 15:29:33 tantek has joined #css 15:29:34 koji: that's for layout 15:29:39 florian: the computed value is normal as a keyword 15:30:02 dbaron: I don't think the point you're making is relevant here, I think florian's argument is that we're looking at situations where the computed value is normal, from a style perspective 15:30:06 ... and we're asking what resolved value to report there 15:30:20 ... florian's point is that in most cases when we have a reoslved value, putting that resolved value back in the computed value is basically euqivalent 15:30:27 ... so there are cases where the computed value is a % and resolved value is px 15:30:44 ... but if you take the resolved value and put it back in computed value, you would get the same result (at least for that element, not necessarily for inheritance etc.) 15:31:11 ... florian's point is that in this case, there is not a single number that leads to that result, because what normal does around say font fallback, looking at metrics of possibly one possibly multiple fonts, is different from what any particulra number does 15:31:19 ... that's the stuff that is not well documented because the CSS 2.1 edits were reverted 15:31:27 florian: the right value to return from gCS would be normal 15:31:52 ... but if there's broad interop everywhere but Chrome, to return what that number would be if the element is empty, then that's unfortuate but not unfortunate enough to object to that 15:31:55 una has joined #css 15:32:15 emilio: I was going through the Gecko code, we have various bits of if line-height is normal, update the line 15:32:20 reverting the 2.1 edits (there were a bunch more) was the right thing to do because none of it was based in minuted discussions nor even test cases, and that kind of editing for a stable document like 2.1 is irresponsible 15:32:24 dbaron: there are a bunch of things in Gecko code based on line-height normal, a bunch are wrong 15:32:32 ... some were discussed at that previous meeting, 15:32:43 dbaron: a bunch of the conditions in the gecko code are in the wrong place 15:33:04 ... there's a bunch of design decisions important for interactions with other features, due to hte lack of interop, we probaly still have the freedom to make 15:33:37 emilio: after seeing our usage of line-height:normal in our layout engine, I agree that given normal is more special, the right thing to do would be to return normal 15:33:46 ... I can try again to change Gecko, and if I can't I can report back 15:33:49 florian: getting interop would be nice 15:33:57 q? 15:34:04 ... if the only way for that is to return a number, that's OK, otherwise let's try normal 15:34:06 from my recollection, line-height normal was a way used (by implementation) to capture the legacy Netscape behavior of inline line layout, as opposed to what Håkon & Bert wanted line-height to do 15:34:14 myles_: philosophically returning normal would be great 15:34:20 ... might break the web 15:34:27 florian: chrome has been returning normal for a long time, so maybe wouldn't? 15:34:34 ... maybe there is UA sniffing that would maek it break 15:34:47 emilio: given this conversation I can try to convince mats 15:34:53 florian: I will try to take the CSS 2.1 fixes and put them in Level 3 15:35:10 emilio: notes in the spec about how that not only affects resolved value, but other stuff, would be great 15:35:31 koji: dbaron's explanation I finally understand why we want normal, it makes sense 15:35:46 ... but I also want interop. is WK willing to change? 15:35:51 myles_: I don't think I would chane this before Gecko does 15:35:57 ... if Gecko succeeds we'd probably be willing to do it 15:37:28 dbaron: my memory of the discussions we had in Tokyo, I'm not 100% sure we all agreed that we want to stick to a behavior that normal cannot be mapped to a number 15:37:48 ... that number might depend on something in the first available font, it almost certianly would, but I'm not sure we agreed that we do not want hte behavior that you could'nt convert normal to an equivalent number based on available font metrics 15:37:54 ... that is using font metrics but not particular character availability 15:38:09 florian: how about we reopen that issue as necessary, based on the Tokyo text, which describes ~reality 15:38:12 ... and do that based on the text 15:38:27 myles_: are you suggesting you want to change hte behavior to make normal not magic? or numbers be more magic? 15:38:36 dbaron: change normal so that its magic is a bit different 15:38:43 ... e.g. how font fallback interacts with line rhythm 15:39:03 ... one piece there is that maybe it is better if the box that normal gives you is only a function of hte first available font, and not hte fallback fonts 15:39:14 ... then when you have multiple lines/elements, some of which trigger fallbcak, you don't get unstable line rhythm 15:39:22 ... I'm not sure we sorted that out fully 15:39:28 myles_: I have opinions on this but maybe that's a different topic 15:39:40 dbaron: the reason I'm bringing it up, is it relates to the conclusion that there does not exist an equivalent number 15:39:46 ... but that's a full day long discussion 15:39:52 florian: I agree there's room for discussion 15:40:00 ... I propose we first get back the text, and go from there 15:40:09 dbaron: sure 15:40:20 github-bot: end topic 15:40:29 ScribeNick: emilio 15:40:53 Topic: [css-lists] counter scopes should be based on box tree, not element tree 15:41:06 github: https://github.com/w3c/csswg-drafts/issues/674 15:41:31 tiger has joined #css 15:42:02 topic: end 15:54:40 Karen has joined #css 15:56:54 nigel has joined #css 16:09:58 bradk has joined #css 16:14:56 myles has joined #css 16:18:44 una has joined #css 16:24:01 myles_ has joined #css 16:39:46 liam has joined #css 16:40:30 bradk has joined #css 16:42:21 antonp has joined #css 16:42:47 Is everyone at lunch? 16:42:54 rachelandrew_ has joined #css 16:54:09 myles has joined #css 17:01:10 yeah 17:04:12 jensimmons has joined #css 17:07:44 we should start soon, but I'm overhearing at least two good side discussions, so I'm waiting a bit 17:09:11 Karen has joined #css 17:15:12 rachelandrew__ has joined #css 17:18:41 fremy has joined #css 17:19:00 ScribeNick: fantasai 17:19:02 Topic: Color Stuff 17:19:28 s/Color Stuff/Color modification functions/ 17:19:38 github: https://github.com/w3c/csswg-drafts/issues/3187 17:20:11 una: Chatting with TabAtkins and my team about color modification b/c very highly requested 17:20:16 una: Used a lot in preprocessors 17:20:18 Una's proposal: https://gist.github.com/una/edcfa0d3600e0b89b2ebf266bf549721 17:20:26 una: Very common pattern, so wanted to revisit as native CSS 17:20:33 una: Here's a proposal for a more simplified proposal 17:20:36 una: based on three functions 17:20:44 una: adjust-color(), mix-color(), and contrast-color() 17:21:00 una: color adjustment is basic modification via hcl values 17:21:14 una: first arg is color to adjust, then list of modification functions 17:21:28 una: mix-color mixes two colors 17:21:44 una: contrast-color, submit a bgcolor and then list of color values 17:22:02 una: that you would place as text and background, and picks the highest contrasted color 17:22:08 una: HCL would be default color space 17:22:12 una: can also have color space argument 17:22:20 una: lightness in LCH vs HSL 17:22:38 una: If using lightness in a color space in e.g. cmyk, then do transformation in LCH and then clipped to CMYK range 17:22:50 una: Wanted to make easy to use 17:22:58 chris: Like picking LCH by default because it ... gamut 17:23:24 chris: result will always be a color 17:23:30 chris: like that it's explicit about color space 17:23:39 chris: Does mix up in what color space doing calc and what you revert to 17:23:44 chris: Gave some comments on this 17:24:09 chris: slightly concerned that ppl will believe that lightness = bright ness and chroma = saturation 17:24:20 myles_ has joined #css 17:24:20 chris: Need to understand that ... 17:24:31 chris: Like that we have mixing colors, pretty convenient 17:24:42 chris: I do this often by putting colors on a gradient to find a color in between 17:24:47 chris: Unsure about ... 17:24:55 chris: Contrast color, I like that. Saw ppl asking for conrast things 17:25:08 chris: But often they're asking for ... 17:25:16 chris: Finding most contrasty color is nice 17:25:24 chris: .... 17:25:32 tantek has joined #css 17:25:39 chris: I do like the idea of having a thing called currentBackground that we can use elsewhere 17:25:52 chris: Lea points out that once you have opacity, you have ranges of contrasts 17:25:55 currentbgcolor 17:25:57 s/unsure about .../unsure about mixing by component/ 17:26:03 present+ 17:26:04 leaverou: What do you do about ranges that are overlapping? 17:26:12 una: Transparency issue is still unsolved by dev tools and a11y 17:26:16 una: so don't know how best to handle that 17:26:29 una: but still creating contrast checkers in devtools and other things, can re-use technology 17:26:32 una: pick best color 17:26:37 una: up to author to make sure it contrasts enough 17:26:43 leaverou: not deal breaker, many ways to specify 17:26:53 leaverou: just something that needs to be addressed 17:27:02 s/asking for .../asking for the ability to tweak their preferred color to meet minimum contrast requirements/ 17:27:03 una: background with rgba have a difficulty 17:27:12 Rossen_ has joined #css 17:27:13 leaverou: can also have semitransparent text, though 17:27:15 q+ 17:27:29 chris: I think it's an interesting proposal 17:27:38 chris: lots of details to tweak, but overall it's nice 17:27:42 q? 17:27:44 chris: also clamping needs to be defined 17:27:55 q+ 17:28:19 chris: ... 17:28:27 una: I think we could .. with filter now, brightness/saturation 17:28:31 una: I like unclamped 17:28:34 una: can use value of 1000 17:28:47 una: creates interesting effects in CSS that wouldn't otherwise be possible 17:28:55 chris: Clamping should be done at last possible moment 17:29:06 q? 17:29:07 leaverou: Let's discuss other proposal too so that we can compare. Might end up with blend of both 17:29:32 ack heycam 17:29:36 heycam: overall I like the idaea of color adjustment things 17:29:49 heycam: one comment about syntax for mix-color, for images we have the cross-fade function 17:29:59 heycam: so if we only want one axis of interpolation, should aign the syntax wth that 17:30:10 heycam: this kind of liear interpolation is something ppl want for other numeric tpes as well 17:30:15 heycam: e.g. interpolation of lenghts 17:30:26 heycam: so maybe generic way for different types, or separate thing for color 17:30:39 TabAtkins: We have outstanding rsolution for generic interpolate() function 17:30:45 TabAtkins: but mix-color can do more than simple interpolate 17:31:13 TabAtkins: mix-color can mix different aspects of the color, pay attention to opacity or not, so much more complicated than other tpes 17:31:25 AmeliaBR: For mix-color, heycam talking about cmparison with cross-fade 17:31:31 AmeliaBR: A comparison I think of is blend-modes 17:31:39 AmeliaBR: The efault mixture of two colors is equivalent ot normal blend more 17:31:51 AmeliaBR: to exten there's a % adjustment, that's adjusting opacity of the top blend layer 17:32:06 AmeliaBR: Instead of talking about blending two colors using certian channels, maybe mixing using different blend modes is a way to go 17:32:18 AmeliaBR: But general rule is re-use existing concepts in CSS as much as possible 17:32:23 una: really like idea of thinking as blend modes 17:32:29 una: agree that re-using concepts can be nice here 17:32:36 ack fremy 17:32:37 s/asking for .../asking for a 4.5:1 ratio to pass WCAG/ 17:32:44 fremy: I was wondering about the color-conrast function 17:32:58 fremy: mainly I'm trying to understand how to use in application 17:33:06 una: Used for a11y if you have reusable elements 17:33:08 una: or dark mode 17:33:20 una: if you switch from light pink bg to dark purple bg 17:33:24 una: need to ensure conrast 17:33:30 una: only have to specify colors one time 17:33:36 una: it'll update the color on top of the background 17:33:42 una: common thing from SASS that ppl love 17:34:02 TabAtkins: crude example here: text is black or white depending on bg in this color palette 17:34:37 leaverou: use case right there on github with labels, can give your labels custom bg colors, and GH picks text color to contrast sufficiently -- automatically do that with contrast-color() 17:34:50 fremy: Now I understand the use case, label use case is very clear 17:35:26 AmeliaBR: One thing about the way una describe diferent from conrast function previously 17:35:51 AmeliaBR: previous contrast function, you gave a fixed color and a 2nd color and then a desired contrast ratio 17:35:57 AmeliaBR: and it adjusted 2nd color to meet the contrast ratio 17:36:08 AmeliaBR: As I understand deciding the correct math for that wasn't satisfactory 17:36:21 AmeliaBR: Una's proposal the website author has to give a palette list 17:36:34 AmeliaBR: would just select best contrast from list instead of calculating adjustments 17:36:48 AmeliaBR: could default to black/white 17:37:01 chris: Advantage is end up with a color provided by author rather than random color 17:37:10 leaverou presents alternate proposal 17:37:18 https://github.com/w3c/csswg-drafts/issues/3187#issuecomment-499126198 17:37:19 https://github.com/w3c/csswg-drafts/issues/3187#issuecomment-499126198 17:37:37 leaverou: this is just about color adjustment 17:37:49 leaverou: problem with color-mod was it only worked in rgb 17:37:59 leaverou: Nowadays ppl use ? gamma monitors 17:38:09 s/? gamma/wide gamut/ 17:38:10 Abc has joined #css 17:38:21 leaverou: ppl use terrible hacks by putting things into different variables and stringing together and stuff 17:38:32 leaverou: They've used ? in PostCSS, implemented in custom scripts, etc. 17:38:39 leaverou: Really need to settle on something whether this or Una's proposal 17:38:47 leaverou: THis proposal is based on fact that we have a number of color functions 17:38:49 s/used ?/used color-mod()/ 17:38:55 leaverou: besides rgb() and hsl(), also have lab() and ? 17:39:03 +100 to we need color modification functions (of some syntax)!!! 17:39:05 leaverou: Every color adjustment can be described as djusting channels on one of those functions 17:39:16 leaverou: Instead of creating colors, augment by introducing a coor argument on each of them 17:39:27 leaverou: so either set coordinates specifically or use calc() 17:39:38 leaverou: could also use an underscore to say that this component stays the same 17:39:49 leaverou: so making lighter, use lch, multiply lightness by 1.2 would make it lighter 17:39:59 leaverou: benefit of this is that every color function gives us extra djusters for free 17:40:08 leaverou: Easy to understand b/c uses existing color functions 17:40:18 leaverou: Let's say you have cmyk() space, comes with its own adjusters 17:40:21 leaverou: also allows adjusting alpha 17:40:31 leaverou: re-uses existing syntax, the adjustment just uses calc() 17:40:37 leaverou: obivous what the math is 17:40:45 leaverou: Drawback is that it might give authors too much rope 17:40:52 leaverou: they might just use hsl because familiar 17:41:04 leaverou: Una's proposal uses lch(), which does the right thing by default 17:41:09 leaverou: but worries me, e.g. doesn't have alpha 17:41:14 leaverou: what more is it missing, that we need to add? 17:41:24 leaverou: if we add 10 different keywords, then gets too big 17:41:38 leaverou: the only benefit is very clear what the target color space is 17:41:44 leaverou: Obvious when you convert colors 17:41:46 leaverou: clear what's going on 17:41:50 leaverou: but it's also more complex 17:41:53 leaverou: clarity comes at a cost 17:42:13 chris: I like being explicit about the color space of computation and result 17:42:21 chris: converting from starting not hard 17:42:47 chris: _ is awkward, but might be familiar to ppl using SASS etc, where they construct the result bit by bit 17:42:51 chris: Also like using calc() 17:43:04 chris: You could do all sorts of interesting things with calc(), so that's astrength 17:43:13 chris: if we do get on to cmyk and 7-color printing, hexachrome 17:43:17 chris: we don't have to invent new things 17:43:26 chris: we just get them for free because it's whatever position it is in the synta already 17:43:31 chris: but... 17:43:39 chris: Una's proposal does 3 things and each function 17:43:48 chris: Your proposal does only one thing, doesn't do the other two 17:44:05 chris: The color functions become extremely complicated syntactically 17:44:13 chris: First thought was I didn't like this because looked complicated 17:44:22 chris: I would like to dive more into what serialization is 17:44:32 chris: in general need to understand what serialization is and what's stored in DOM 17:44:41 chris: Right now colors are stored as sRGB and that's it 17:44:54 chris: Everyone that's seen the color spec, yeah this is good, have LCH and ICC colors 17:45:06 chris: high dynamic range etc. solved problem, doing this the right way 17:45:13 chris: But interested in how browsers are going to add this 17:45:29 chris: So would like to hear comments from implementers 17:45:44 chris: Both of these also depend on existing color functions, so need implementers to comment on that too 17:45:50 leaverou: both of these would require implementation of LCH 17:46:03 AmeliaBR: Do any browsers have work on the way to implement more advanced color spaces? 17:46:24 TabAtkins: Don't have work on it, but also LCH is only matrix-math different from sRGB, so not hard, just need some engineering time 17:46:29 chris: All the matrix math is in the spec 17:46:38 chris: also don't have to implement it like that, can also use ICC or color sync 17:46:42 chris: does all that as well 17:47:13 AmeliaBR: Lea's syntax can be implemented in parallell, since still get adjustments on rgb and hcl, just that the best artistic results come from lab or lch 17:47:31 leaverou: If HSL adjuster is implemented first and then LCH later, then more likely that existing designers will use HSL even though it's not as good 17:47:39 fremy: well it works for them 17:47:46 chris: It works for them because it's the only tool they have 17:48:03 TabAtkins: If you have boht, there's no reason to use HSL, LCH is wayyyy better 17:48:20 TabAtkins: Only reason to include older worse ones is compatibility with existing color systems 17:48:31 TabAtkins: but want to make using the good function the easy pasth 17:48:37 q+ 17:48:38 TabAtkins: so ppl use it and get happy results 17:48:45 (to correct the notes, I just said that if designers end up using it, that means it worked for them, if the result isn't good enough, they can learn how to improve) 17:48:47 una: Problem with Lea's proposal is harder to understand what's going on 17:48:56 una: Harder to follow what's happening 17:49:11 una: Taking concepts of ?, transformation space, and output clipping 17:49:16 una: then build on that 17:49:24 leaverou: That's what I was wondering about as well 17:49:38 leaverou: ? lightness and hue cover a large percentage of cases. Unsure about individual color channels 17:49:45 leaverou: SASS has these, wondering if we can get usage stats 17:49:52 leaverou: See how many ppl need them and what use cases are 17:49:57 s/concepts of ?/concepts of color space transform + set clipping space 17:50:08 leaverou: most use cases I've come across are saturation and lighness 17:50:17 s / concepts of ?/concepts of color space transform + set clipping space / 17:50:31 ack myles_ 17:50:34 chris: Making a color "more green" is a bit straightforward in rgb, but going towards blue-gree... makes more sense to give a target color and go closer to that 17:51:09 chris: Myles, you're building on top of ColorSync, would be interested in what would be hard to do easy to do etc. 17:51:12 myles_: not prepared to answer that 17:51:38 leaverou: Issue with 2nd one beign underscores, could be some keyword or whatever. 17:51:56 leaverou: was an underscore only beause avoids conflicts within color function 17:52:10 astearns: Anyone from implementers with enough color experience? 17:52:19 AmeliaBR: Reminder that use cases for color modicifcation is increasing steadily 17:52:27 AmeliaBR: FIrst with custom properties 17:52:39 AmeliaBR: You can't do it in the preprocessor, has to be in the browser to work with dynamic colors 17:53:06 AmeliaBR: going into dark mode and using system colors, don't have concrete color to manipulate 17:53:15 AmeliaBR: need to do dynamically in the browser 17:53:26 una: contrast-color important for dark mode especially 17:53:36 una: these work hand in hand with changing technology being implemented in browsers now 17:53:40 heycam: One other syntax comment - 17:53:56 myles has joined #css 17:54:01 heycam: In 1st proposal, have adjust-color(), but we have a color-adjust property... 17:54:08 AmeliaBR: Could go back to color-mod() 17:54:21 TabAtkins: Also switch it to color-mix() 17:54:39 ?: And color-contrast() to match 17:54:56 astearns: Comment about Una's proposal requiring LCH ... 17:55:01 astearns: ... 17:55:03 s/?/heycam/ 17:55:23 astearns: Want to reserve the default for LCH, require a color space until LCH is around, then allow that to be dropped 17:55:28 TabAtkins: I object 17:55:35 TabAtkins: I don't think the LCH part is the engineering blocker 17:55:43 TabAtkins: They're both relatively easy thing that just need effrot 17:55:52 TabAtkins: getting it right the first time 17:56:05 TabAtkins: if someone wants to impelment adjust-color(), then doing LCH also isn't hard 17:56:15 dbaron: Implementing color modification functions seems significantly mroe work than implementing LCH 17:56:36 markus: ... Adjustment of image color 17:56:46 rachelandrew___ has joined #css 17:56:54 q+ 17:56:54 chris: Ther'es a longrunning FF bug about ICC and imgaes, maybe just for raster images? 17:56:59 Markus: ? is working on image color adjustment 17:57:12 TabAtkins: Handling profiles but not anything else... so outputting rgb as monitor color space? 17:57:32 chris: Can see the difference on my screen, Chrome really gives you the desaturation , Firefox ... 17:57:46 heycam: Since we don't color adjust CSS colors, which aspects of these proposals would not be possible ? 17:57:53 TabAtkins: none, just do the math 17:58:02 TabAtkins: If you have badly-adjusted colors mixed with other colors 17:58:12 TabAtkins: In a consistent color space, get better colors later 17:58:23 Markus: Nothing hard in the spec from my perspective 17:58:35 markus: Hard part is Firefox doing color management in the first place 17:58:36 s/mixed with other colors/mixed with other colors, you have a problem, but/ 17:58:51 markus: I don't know about parsing / serialization, but in terms of spec hard part is just finding the right syntax 17:59:07 AmeliaBR: Rendering resulting color is a separate, but result of these functions is going to be another oclor function using exisitng color function syntax 17:59:23 AmeliaBR: question of what do we do about Browsers trying to squish color functiosn into hex codes when requesting coptued style 17:59:30 AmeliaBR: but that's an issue with all advanced gamut 17:59:37 chris: It's even an issue with sRGB 17:59:42 s/gamut/gamut color functions/ 17:59:47 chris: If you go into wide gamut or high gamut, not enough storag 17:59:53 q? 17:59:56 s/storag/storage/ 18:00:03 ack myles 18:00:10 q+ 18:00:19 leaverou: Tab, you said that colors mixed being in same color space... do you mena can't mix colors from different spaces? 18:00:34 TabAtkins: When mixing colors from differnet spaces and no color managing 18:00:44 TabAtkins: Then colors that look like they match won't later once you fix 18:00:49 TabAtkins: but if define the mixing color space then it's OK 18:01:08 AmeliaBR: If you have an imge that uses a color properly calibrated red 18:01:17 AmeliaBR: andyou have an uncalibrated red in your CSS, then your color scheme will look bad 18:01:32 TabAtkins: Used to be that RGB 255,0,0 in an image could look dfferent from red in CSS 18:01:39 dbaron: depending on whether image had color profiel data 18:01:54 una: You can mix colors from different spaces, have to speicfy mixing color space 18:02:06 leaverou: Would be nice to have defaults so that you don't have to speficy if you don't want to 18:02:09 leaverou: e.g. default to LAB 18:02:13 leaverou: if they're not in the same space 18:02:27 TabAtkins: One aspect of mixing proposal is nice to mix a single channel 18:02:33 TabAtkins: NOt directly interpolation 18:02:39 chris: That is an advantage of Una's proposal 18:02:49 chris: You could have a profoto RGB color and an adobe RGB color and ???? 18:03:09 s/????/mix the lightness of them, which neither color space has/ 18:03:14 myles: In first propsoal, contrast-color is different from first two otpions 18:03:34 myles: contrast-coor might be unimplementable depending on composting and how far back you have to go back through to find the bg color 18:03:40 myles: and if you don't punch through, kinda useless 18:03:50 TabAtkins: I don't think punching layers is good, problematic for implementations 18:03:58 TabAtkins: have to be in a reasonable situation like bg color on your element 18:04:02 myles: but is it good enough? 18:04:11 una: could require the first argument to be a solid color 18:04:33 dbaron: what is the computed value if you do this contrast color thing? 18:04:42 una: result would be a color 18:04:54 dbaron: in terms of CSS computed value, how is contrast-color going to inherit? 18:05:05 chris: I think the computed value would be the winning color 18:05:12 TabAtkins: It's a good question, need to figure that out 18:05:31 q? 18:05:33 AmeliaBR: Question of how we dealt with currentColor -- it inherts as a keyword, and also wanted to switch the system colors to do that also 18:05:57 AmeliaBR: If we do that, then it would be awkward if the contrast selection is set at the body level but the actual element using that color has now the value of that varable or keyword ahs a different value 18:06:16 chris: If computed value is as specified ... 18:06:22 leaverou: Might not want a different alue on the child 18:06:37 dbaron: Part of my concern here is that except for this thing, it seems like the computed value can be computed to a color 18:06:45 s/Might not want a different alue on the child/even if it's a CSS variable, it could have a different value on the child/ 18:06:50 dbaron: but this is the one thing in all this color adjustment stuff thats "layout"-dependent thing 18:07:11 TabAtkins: I don't think so... but if one of the options s currentColor or currentbg or whatever, then it's an issue 18:07:18 q? 18:07:23 fantasai: Systme colors also vary by element 18:08:03 dbaron: when you're doing style computation, you know what hte coptued value of the color property is. So you can know what currentcolor is as a color 18:08:11 AmeliaBR: we choose to inherit it as a keyword rather than a color 18:08:19 dbaron: Same for system colors. You can do the lookup 18:08:28 TabAtkins: Then I don't understand why other color mods are different 18:08:35 dbaron: I think all of that can happen in computed value 18:09:08 https://github.com/jonathantneal/postcss-color-mod-function 18:09:09 dbaron: The question is, is this definition of "aht is the relevant bg to contrast with", what does it depend on and is it something that can be resolved at computed value time locally? 18:09:20 dbaron: Or do you need to do layout to find out? 18:09:32 TabAtkins: Just being able to contrast with element's own background woudl be enough 18:09:55 AmeliaBR: I think it's better to leave out idea of "current background" rather than having overly-simplistic definition 18:10:02 AmeliaBR++ 18:10:06 una: ... 18:10:13 una: You don't need it 18:10:25 emilio: You can use -webkit-text-fill-color 18:10:44 s/.../we can leave out current background for now/ 18:10:45 chris: If syntax is you put two colors in here, then new keyword 18:11:15 myles: I brought up contrast-color in order to differentiate from other functions 18:11:27 myles: picking between proposal A and B, contrast-color is distinct from either 18:11:33 myles: Ignoring it for the moment 18:11:38 s/need it/need it because you can put currentColor in that slot and specify the background behind currentColor/ 18:11:51 myles: Both of these proposals are saying here's some syntax, take the color, do some math in a coor space, and then put it back into a color space 18:11:56 myles: But do designers think in that terms? 18:12:02 myles: Amelia said about blend modes 18:12:15 q? 18:12:25 myles: Instead of describing as channels independently, maybe match ? maybe match better how designer would think about it 18:12:31 AmeliaBR: I don't think they're opposing concepts 18:12:41 AmeliaBR: I think Una's proposal had an adjust color and a mix color 18:12:50 AmeliaBR: I'm suggesting an adjust color using oneof these syntaxes 18:12:54 AmeliaBR: And a blend color 18:13:04 AmeliaBR: Adjust color is lighten or brighten or dullen 18:13:10 q+ 18:13:11 AmeliaBR: Mix is for ppl thining more of combinin two colors 18:13:20 AmeliaBR: You can interpret lighten / darken as combine with white/black 18:13:29 q? 18:13:35 AmeliaBR: but ... 18:13:41 leaverou: Wrt proposal A and B 18:13:49 leaverou: ? doesn't have mix color or contrast color 18:13:55 leaverou: so it's really about picking how to do the adjustments 18:14:02 leaverou: lighter / darker / more opaque / more translucent / etc 18:14:03 s/.../you can't make saturation brighter or duller that way/ 18:14:29 s/?/my proposal/ 18:14:33 TabAtkins: We have strong existence proof that ppl do think about this in terms of color adjusters, because every preprocess has a variant of channel adjusters 18:14:41 TabAtkins: might not be ideal, but super common 18:14:45 leaverou: Wrt blending modes 18:14:54 leaverou: My experience is that designers how blending modes work 18:14:55 +1 leaverou 18:15:01 leaverou: Every time I give a talk about them 18:15:10 s/designers how/designers don't know how/ 18:15:14 leaverou: ppl come up to me, I didn't understand how these work, just tried different ones to see the result 18:15:17 una: ... 18:15:23 una: You can also clikc around in devtools to see what works for you 18:15:33 una: A huge use case for color funcitons is to create palettes from a single source 18:15:40 una: so you'll still need color adjustment and not just mixing 18:15:52 mstange: Two existing ways to mix colors 18:15:55 mstange: gradients 18:15:57 mstange: and transitions 18:16:03 ack mstange 18:16:06 mstange: Is the ? color function equivalent to what those do? 18:16:10 mstange: or is that something we want? 18:16:15 TabAtkins: we should offer one 18:16:22 TabAtkins:both of those interpolate in premultipled sRGB space 18:16:24 TabAtkins: not idea space 18:16:30 TabAtkins: but good to provide that so can match 18:16:56 una: could remove arugments of whcih manipulations, and then mix those two colors evenly by default in sRGB 18:17:05 AmeliaBR: Agree that if we have a default it should match default for gradients and tansitions 18:17:07 s/My experience is that designers how blending modes work/My experience is that designers don't really understand how blending modes work, they just try things until they get the desired result/ 18:17:15 AmeliaBR: I would also like to define gradients and transitions to one day use other color spaces 18:17:29 AmeliaBR: e.g. color-interpolation from SVG whch nobody implements :( 18:17:36 AmeliaBR: want to say "mix in LCH" 18:17:42 chris: Had that in spec 10 yrs ago, had to take out 18:17:55 chris: Not that we contro lvia CSS, but antialiasing of forreground shape and bg shape, that also requires interpolation 18:17:58 chris: and that's again different 18:18:06 chris: but it's all linear interpolation and have to specify the color space 18:18:16 leaverou: Drawback to interpolation in LCH? 18:18:19 TabAtkins: Doesn't match 18:18:23 leaverou: but result is same or better? 18:18:25 TabAtkins: proably 18:18:52 markus: So if I'm shifting from red to green, do I go around the circle or through to gray 18:18:59 chris: L axis 18:19:05 chris: black is zeor 18:19:10 chris: 100 is reflective white 18:19:15 chris: on screen whatever native white is 18:19:24 chris: 50% is visually midway between black and white 18:19:31 chris: if you move 10% it is equal -looking steps 18:19:37 chris: then have A and B axis which are cones from your eyes 18:19:48 chris: ... oppostie collor through the L 18:19:53 s/zeor/zero/ 18:19:56 chris: ... 18:20:09 chris: LCH is the polar form of that, ou have a hue angle starting from A axis and going round 18:20:09 s/oppostie collor/opposite color/ 18:20:15 chris: you have chroma which is like saturation but better 18:20:18 chris: L axis is neutral axis 18:20:21 chris: that's perception 18:20:29 chris: moving by constant amount 18:20:45 AmeliaBR: to ansewr your question, you're converting a color to a vector of 3-4 numbers, and then doing simple interpolation of the numbers 18:20:51 chris: If you itnerpolate LAB you'll get a striaght line 18:21:04 chris: iF you interpolate in LCH you'll also sweep through hue angle, see the rainbow 18:21:16 chris: if you wnat to go through gray then you want LAB 18:21:16 q? 18:21:42 AmeliaBR: Can we make a resolution that we all agree color modificaiton functions are a good idea and have them? 18:21:50 q+ 18:22:02 chris: I would like us to do that, actually 18:22:17 chris: ppl think we don't care, but we do 18:22:27 TabAtkins: it's just that my previous proposal sucked 18:22:58 fantasai: my suggestion would be: if we have a clear idea of which proposal we want, we should decide now, but otherwise, we can put both in the spec for now 18:23:21 fantasai: then it's not just a giant issue, we can work on it, we can iterate, and people can see what we're working on 18:23:39 innovati has joined #css 18:23:42 chris: I like that idea, but i'd rather do it in css-color-mod-1 rather than css-color-5 18:24:03 myles_ has joined #css 18:24:05 fantasai: I think we should finish color-4 quickly, and then color-5 won't seem that far out 18:24:10 AmeliaBR: If color mod and LCH come togheter can be in the spec 18:24:17 AmeliaBR: we have two proposals right now 18:24:31 AmeliaBR: conrast function seem to all like thate xcept for current bg, so maybe resolve on that? 18:24:36 leaverou: and maybe mixing? 18:24:43 AmeliaBR: So maybe mix with color space option 18:24:58 astearns: LCH is not currently in color 4? 18:25:04 astearns: So could put this into color 4 18:25:35 s/So maybe/And I recognize that blending is nice but confusing, stick with/ 18:25:44 fantasai: I think we should put into color 5 and get color 4 into CR 18:25:55 chris: Implementer interest??? 18:25:57 q+ 18:26:05 ack fantasai 18:26:21 TabAtkins: We're done with the *spec*, we can put it into CR. Just can't go to REC because waiting for implementations. 18:26:45 fantasai: we don't want to conflict REC and CR. even if we don't have implementations, if we're done with the spec, it should go to CR 18:27:02 rachelandrew____ has joined #css 18:27:26 fantasai: and then this new stuff needs design work, so it should go in different level because we'll file issues, make big changes, etc. So new level or new module 18:27:28 s/conflict/conflate 18:27:43 q? 18:27:47 q+ 18:28:06 fantasai: I'd prefer color level 5, because it really is the same scope as colors in general 18:28:08 ack leaverou 18:28:26 leaverou: One issue with putting i neparate module, if we go with proposal B, it modifies the gramar of the functions 18:28:39 AmeliaBR: That's a good argument for color level 5 18:29:00 astearns: Chris, would you objet to css-color-5? 18:29:04 chris: No, and volunteer to edit 18:29:15 TabAtkins: I don't want to, but maybe Una? 18:29:18 una: sure 18:29:32 rad! 18:29:48 astearns: So put some subset of these proposals into css-color-5 with Chris and future Una as editors 18:29:59 s/i neparate/in a separate/ 18:30:01 RESOLVED: Put all the proposals into css-color-5, ChrisL and future Una as editors 18:30:09 myles_: Please please please no underscores 18:30:21 chris: Some languages are positional, others need to name them... 18:30:34 TabAtkins: We have lucky thing that function name gives single-letter name of channels 18:30:41 TabAtkins: can use that 18:30:44 leaverou: but what about alpha? 18:30:45 TabAtkins: a 18:30:47 TabAtkins: but LAB? 18:30:50 TabAtkins: other a! 18:30:58 ... 18:31:04 rbga(x, y, z, w) => rgb(calc(x + 20), 100, calc(z - 20)) 18:31:15 to name the arguments you want to use 18:31:21 astearns: let's resolve to put color-contrast in the spec 18:31:27 s/TabAtkins: but LAB?/leaverou: but LAB? It has a, plus alpha. 18:31:48 una: Going to rename color-conrast, color-mod, color-mix 18:32:00 RESOLVED: Rename to put 'color' first, adjust-color -> color-mod() 18:32:09 RESOLVED: Add color-contrast() without currentbg 18:32:24 TabAtkins: why not just .2? 18:32:33 fantasai: we should make sure we align it with the syntax for crossfade 18:32:41 fantasai: ... to the extent possible 18:32:50 RESOLVED: Add color-mix(), try to align with cross-fade() 18:33:05 astearns: So two remainign option for color adjust 18:33:12 astearns: could put both in the draft and add an issue that we only need one of htese 18:33:16 astearns: or show why we need both 18:33:19 astearns: or decide now on which to pursue 18:33:28 astearns: anyone have a strong opinion which way to go? 18:33:37 TabAtkins: I'm reasonably leaning towards Una's proposal because I helped work on it 18:33:48 And color-mix suggesting the name of mix() for the generic interpolation of numbers, etc. 18:33:49 fremy: My perspective is, Lea's proposal is very useful but believe storngly we can do that with custom functions 18:33:56 fremy: this is kind of math we cna do with it 18:34:10 leaverou: how does that work? 18:34:16 AmeliaBR: it's a Houdini proposal 18:34:28 astearns: I think that's true of all of these functions 18:34:35 s/cna/can/ 18:34:41 fremy: Arbitrary math it's not different from doing math in JS 18:34:58 fremy: but Una's proposal translates to designer vocabulary 18:35:11 fremy: I don't think there's value in creating a new function with special parsing etc. for math 18:35:19 fremy: I would prfer to do a custom function, re-use in your JS 18:35:33 chris: Are you arguing to remove calc() 18:35:34 fremy: what??? 18:35:42 astearns: This is not a useful discussion. 18:36:27 leaverou: they are equivalent modifications, just syntax is different 18:36:39 fremy: yes, but if I have to choose between them I prefer the one more scoped to what designers use 18:36:49 una: my proposal is more simplified than Lea's, her's has more power 18:36:58 una: You have to specify each channel even if blank 18:37:07 una: but first proposal is simplified version, do by channel, but using keywords 18:37:07 antonp has joined #css 18:37:30 fantasai: I suggest putting both in the spec, issue at top, request feedback 18:37:47 astearns: Useful to have both proposals in a spec where people can see them 18:37:55 fantasai: and also file issues, improve them, and compare the improved versions as well 18:37:59 astearns: arguments against? 18:38:11 AmeliaBR: It needs to be very cleary set out even if someone is jumping to heading in the document 18:38:22 AmeliaBR: so ppl following along can follow the options 18:38:32 Can also put the .annoying-warning there 18:38:33 basically to use the same example it's color-adjust(blue lightness(120%) chroma(.4)) vs lch(from blue, calc(120% * l) calc(.4 * c) h) 18:38:45 astearns: Also, I expect us to chose only one, but it might be that we end up with both 18:39:02 astearns: if we have good justification have both 18:39:07 una: also might be able to combine them 18:39:20 una: because same calculaitons, less explicitly laid out 18:39:34 ... 18:39:38 TabAtkins: lab vs alpha! 18:39:44 leaverou: write out 'alpha' 18:39:49 myles_: ? 18:39:59 +1 to putting both in color-5 18:40:02 astearns: My proposal is to put both proposals into css-color-5 with keywords instead of underscores 18:40:14 astearns: and start opening issues to discuss bits we want to modify 18:40:20 s/?/but one is clearly more powerful than the other, it uses calc & you can put anything in there. The other only does multiplications/ 18:40:43 RESOLVED: Put both color adjustment proposals into css-color-5, with keywords instead of css-color-5 18:40:44 fantasai: are there other things we know we should put in color-5? 18:41:08 RESOLVED: Add Lea Verou as editor of css-color-5 18:41:51 Una: we're going to make it happen! As long as you make it happen, implementers :) 18:41:57 Topic: corner-shape use cases 18:41:58 🎉 18:42:19 github: https://github.com/w3c/csswg-drafts/issues/3457 18:42:20 https://drafts.csswg.org/css-backgrounds-4/#corner-shaping 18:42:29
18:43:05 RESOLVED: Add Florian as editor of css-text-4 18:49:48 ScribeNick: fremy 18:50:28 una: corner-shape is something that google uses in the material design system 18:50:34 una: it works on ios and android 18:50:39 una: but not on the web 18:50:45 una: I tried to write this in houdini 18:51:00 una: but it's not super straightforward because you need a background, a mask, etc... 18:51:16 una: but since this feature is very common, I don't think the custom approach is very practical 18:51:17 q+ 18:51:40 una: so I'd like to revisit the spec to reintroduce the corner-shape 18:51:59 una: for instance, angled and rounds border are very important 18:52:09 jensimmons: can somebody summarize what we have done in the past? 18:52:13 leaverou: sure 18:52:17 https://drafts.csswg.org/css-backgrounds-4/#corner-shaping 18:52:23 leaverou: what we have right now (pasted linke) 18:52:48 leaverou: one of the reason this hasn't moved much is that it's trying to do too much and is scaring away implementers 18:53:07 leaverou: and it turns out everytime people ask me about this, people want angled corners 18:53:27 leaverou: so I think we could remove a lot of the complexity and keep most of the use cases 18:54:01 https://material.io/design/shape/about-shape.html#shape-customization-tool 18:54:06 una: (showing a couple of buttons, and some options like angle, distance, rounding...) 18:54:09 q+ 18:54:10 myles has joined #css 18:54:43 una: now we have to implement with custom shapes, but that would be better as part of css, because we could reuse colors and not have to define the masking 18:54:50 rachelandrew____: I concur a lot of people want this 18:54:55 rachelandrew____: and asked me for it 18:55:24 (we are talking about angled borders) 18:55:55 AmeliaBR: the border should follow the shape 18:55:59 q? 18:56:05 myles_: what is the specific proposal? 18:56:18 `corner-shape: round | angle` 18:56:37 una: what is in the draft minus scoop and notch, and rename angle and bevel 18:56:52 ack myles_ 18:56:53 myles_: so the proposal is to drop values? 18:56:58 una: and rename one 18:57:03 dbaron: two comments 18:57:41 dbaron: one is that one of the difficult thing about adding things to the webplatform is that we have to articulate how these new things have to work with all the other things in this area of the platform 18:58:00 dbaron: and it so happens that borders are one of the areas where we already have a lot of undefined corner cases 18:58:12 dbaron: maybe the spec is better now, but we are not very interoperable now 18:58:22 leaverou: didn't fantasai do a lot of work on this already? 18:58:42 fantasai: yes, the cases we would introduce here are similar to the things we had to define for rounded corners 18:58:56 fantasai: so globally I don't think this would be too undefined 18:59:03 q? 18:59:05 q+ 18:59:15 For rendering, this affects: drawing borders (dot/dash spacing, color or width changes at corners), clipping backgrounds, replaced content like images, and child content (if overflow is hidden), box shadow shape, hit testing. 18:59:25 dbaron: but even then, there are so many weird things about borders, and each of these weird features have their own code paths 18:59:42 dbaron: and even special codepaths for specific combinations 18:59:49 dbaron: and I'm concerned about it 18:59:51 ack dbaron 19:00:01 astearns: for instance shape-outside, etc 19:00:04 dbaron: and clip for instance 19:00:18 fantasai: I think this would be manageable 19:00:49 dbaron: an example I would want to mention is one time where we spent 30% of the time in rendering gmail in drawing border 19:01:27 dbaron: and that is because border has a lot of cases, and all of them have to be fast 19:01:43 myles: sure, but we are trying to drop values, so this is better now, right? 19:01:54 ack bkardell_ 19:01:56 dbaron: well there was also encouragement to implement, right? 19:02:08 myles: sure, encouragement received, but we could discuss the proposal 19:02:25 bkardell_: you mentioned that houdini was difficult to use? 19:02:45 bkardell_: could we have done anything better to make this easier, or is the problem just hard in general? 19:03:12 Example 1 in https://drafts.csswg.org/css-backgrounds-4/#the-border-color looks hard to do in reality... 19:03:28 bkardell_: (asking because this has been around for a very long time, and didn't get traction, so it might never happen) 19:03:45 una: I think the main reason I want to standardize is that this is very common 19:03:49 dbaron, that's not even what we're discussing, though 19:04:00 una: Houdini is for unique cases 19:04:00 That's a separate issue, dbaron! 19:04:19 una: houdini is great for custom things, but it's complex here, and this problem is common, so I think this should be a default provided feature 19:04:34 una: to get this right I have to mask the corners 19:04:42 una: having to define both a background, a border, a mask, so in the end it's very heavy on the usage side 19:05:00 una: in the end it works, but it's not great 19:05:16 I think it's not a separate issue, because we're talking about dropping two of the four values from a feature that was optimistically put in the spec without clear implementor interest 19:05:26 iank_: also, you can't easily incorporate the clipping effect of the border-radius in various other properties, painting is just part of the story 19:05:45 iank: also need to handle hit-testing 19:06:13 florian: note that the outline should follow corner-shape but no browser does 19:06:26 ack leaverou 19:06:26 s/does/does, except sometimes for auto/ 19:06:41 bkardell_: but border does, so people sometimes use borders for outlines because they are so powerful 19:07:59 leaverou: an interesting thing I was wondering is that maybe we could use border-radius to define the radius to have a nice fallback? 19:08:01 s/note that/the spec notes that/ 19:08:14 fantasai: yes, but it's a worse name, and we can already use @supports 19:08:28 leaverou: ah, true, then I guess we prefer to stick with the best name 19:08:39 astearns: anything else on this topic? 19:08:49 fantasai: we need a resolution to drop the two values 19:08:58 astearns: yes, and I think it's a good idea 19:09:09 s/we could use/we could use a new better name for/ 19:09:29 s/a nice fallback/fallback to sharp corners instead of to rounded corners/ 19:09:40 astearns: I however I want to point out that the border-radius took so long to implement that by the time it shipped people moved to other designs 19:09:56 una: border radius is everywhere today 19:09:59 astearns: so do we know that material design is not going to switch to another type of border by the time we ship? 19:10:04 Youri has joined #css 19:10:07 una: people still use border-radius a lot though 19:10:25 fantasai: also, there are a lot of other cases where we need special shapes and polygons 19:10:50 AmeliaBR: for instance parallelograms are useful, and difficult to make in css 19:11:07 clip-path solves the BSG use-case: https://css-tricks.com/notched-boxes/ 19:11:08 astearns: ok, let's move to the resolution, does anyone object to that? 19:11:31 RESOLVED: drop the less useful values, and rename as proposed in the issue 19:11:53 astearns: anything else on this topic? 19:12:03 una: no, thanks 19:12:40 (discussion about implementer interest) 19:13:25 iank_: that's a lot of work, and we didn't see enough use cases yet to change our prioritization, but we would be happy to adjust based on more data 19:13:38 Topic: definition of light and dark 19:13:41 github: https://github.com/w3c/csswg-drafts/issues/3983 19:13:44 projector_ has joined #css 19:14:10 ScribeNick: emilio 19:14:28 AmeliaBR: So I wrote this up after the last telcon 19:14:46 ... we were talking about sepia mode, and whether we needed a new keyword 19:14:48 Rossen_ has joined #css 19:15:05 ... it came up that sepia is usually a dark text on light background which match light 19:15:27 ... people assume that the default colors for light / dark mode are white / black 19:16:00 ... and if we want more flexibility of color schemes but still group them into light / dark / etc. then we need to have some sort of normative definition of what do they mean 19:16:19 ... i.e., how far can you adjust those while being light or dark 19:17:01 q+ 19:17:01 ... I put an example with yellow / bright blue on the issue, I'd be surprised if authors would expect a light theme to have those colors 19:17:22 ... if authors use system colors or such and only use the preferred media query then having the variety could be problematic 19:17:41 ... so I think we should define what's the scope of variation for these definition 19:18:06 ... I posted some suggestions using the contrast definition, because that's a very important factor 19:18:16 ... but we may want to limit saturation as well for example 19:18:40 q+ heycam 19:18:42 hober: disclaimer: I don't know about colors but I'm channeling feedback 19:19:04 ... it's probably fine to have light / dark being somewhat generic 19:19:16 ... I'm a little wary of including specific colors in that definition 19:19:38 ... for example in Mac there's a fairly specific algorithm 19:19:53 q+ 19:19:54 ... but yeah something that says "this needs to have enough contrast" sounds good 19:19:59 ack heycam 19:20:08 s/I don't know about colors// 19:20:33 heycam: I'm a bit skeptical about how much we need to worry about custom background and foreground colors set by the user and have sites be able to respond to all of those 19:20:51 ... seems pretty niche, and if browsers wanted to decide whether they're light or dark that seems fine 19:21:20 ... but probably this doesn't warrant spending a lot of time figuring out a precise authors 19:21:37 AmeliaBR: this is also about potential future changes of OS-provided colors 19:21:55 florian: seems like the OS vendor should be the one figuring that out 19:21:57 +1 to Florian 19:22:02 s/in Mac there's a fairly specific/macOS Mail has a complex/ 19:22:16 AmeliaBR: it's kind of awkward that this is the first issue we talk about this 19:22:18 q- 19:22:41 q+ 19:22:44 ... even something like sepia mode people seem to be clear that it's light, but for authors it doesn't seem so 19:22:53 fantasai: may be worth adding a note to that effect to the spec 19:22:55 q? 19:23:02 ack jensimmons 19:23:30 jensimmons: I'm unclear about what do you want us to write up, it's some kind of fence about where default background / colors can be? And if so why a fence and not a specific value? 19:23:49 ... But this is also about the WG teaching designers to do the right thing 19:24:08 ... and I don't think that that may be the right thing to reach them 19:24:24 myles_ has joined #css 19:24:25 ... I also don't particularly agree that they would assume black / white 19:24:40 ... I'd like to talk about it but it's probably not WG's business 19:25:24 AmeliaBR: my main focus is about UAs but also about whether we should have different color schemes for the media queries but not for the properties 19:25:39 ... I think we cannot resolve this issue without deciding how to group color schemes 19:25:51 q? 19:25:51 ... and are authors aware about it/ 19:26:06 ... because people are implementing different thing 19:26:23 fantasai: spec says dark / light, no black / white, so we could add a note 19:27:09 AmeliaBR: the issue is contrast, if the author assumes it's a black background for contrast requirements and the background ends up grey then there may not be enough contrast 19:27:35 q+ 19:28:01 ... so my proposal is to define the min luminance ratio so that we can guarantee that authors meet requirements which may be a legal obligation 19:28:19 jensimmons: ... 19:28:43 jensimmons: Authors are probably going to be picking both background and foreground colors 19:28:52 ack Rossen_ 19:29:14 bradk has joined #css 19:29:23 Rossen_: When I was going about how high-contrast is implemented on windows 19:29:24 jensimmons: we can add text to the spec to remind everyone that color contrast is important. In notes. 19:29:39 ... There are three different ways of color-scheme propagation 19:29:54 ... the os one (which doesn't propagate to the browser at least on windows) 19:30:22 ... so for example the shell started to ship dark mode but none of the apps were opted in 19:30:46 ... then there's the author of the application opting in to the UI of the application 19:31:11 ... then there's the propagation into the content. high-contrast propagates all the way forcibly 19:31:43 ... for color schemes, first there are not many colors to begin with, authors should be able to make pretty well educated guesses 19:32:12 q? 19:32:15 ... if the colors are what we need to expose, we already have this and decided to undeprecate the system colors 19:32:41 ... and they would have an effect however the browser manages to get them there 19:32:55 una has joined #css 19:32:58 ... you can also opt individual apps into force colors mode (e.g., only the browser) 19:33:09 ... none of this involves sepia btw 19:33:23 ... though it's a reasonable expectation on content 19:34:34 ... as we're going down this path it's best to have an easily detectable mechanism to figure out whether (1) I'm forced (2) what's the general preference (light / dark) (3) and a way to identify the individual colors so that you can programatically address them 19:34:50 ... so my question is, what's missing in the platform so that authors can make these decisions 19:35:16 AmeliaBR: for this specific issue we're just looking at the colors that came down to the content 19:35:40 ... so your question is "we got the system colors, why would we need to define them more or less" 19:35:52 q+ 19:35:55 ... one answer could be telling authors "just stick with system colors" 19:36:26 ... but if we acknowledge that system colors won't be enough, then you need a way to figure out the variance 19:36:41 Rossen_: wdym with system colors not being enough? 19:36:45 projector has joined #css 19:36:54 AmeliaBR: if you also have your own brand color or such 19:37:00 ... color mod functions may be enough? 19:37:15 Rossen has joined #css 19:37:34 ... but right now we've got a system where people designing for dark mode make assumptions of what system colors look like 19:37:46 shans has joined #css 19:37:51 ... so we need to either educate or limit dark mode to define what the range 19:38:05 Rossen_: the UA UI-color choice is not something we should be demanding 19:38:16 sylvaing has joined #css 19:38:28 ... currently all of the color schemes that are propagated down are based on this matching the ui 19:38:49 jensimmons: I think it's fine if we want to add notes and such in the spec 19:39:11 ... but this proposal is to pin point what light and dark mean and I don't think we want to do that 19:39:16 leaverou has joined #css 19:39:30 q? 19:39:33 ack jensimmons 19:39:34 ... we don't do that in a bunch of places and try to teach people how to use media queries 19:39:47 we do sometimes * 19:39:47 plinss_ has joined #css 19:40:24 ... I don't share the premise of authors making assumptions about system colors 19:40:30 bkardell_: indeed, it would be interesting to list all the places we reference WCAG* from CSS* specs 19:40:38 in terms of author guidance 19:41:43 ... it's not clear if we are entering an era where we have OSes have dark and light mode with a bunch of colors, or all the way to a heavily customized sites like in the old days 19:41:46 https://www.w3.org/TR/css-flexbox-1/#order-accessibility 19:42:06 ... I don't think we should define this without knowing where this is going 19:42:16 q? 19:42:21 florian has joined #css 19:42:21 q? 19:42:35 ... and I think people are caring more and more about contrast and such 19:42:41 hober: I agree with what jensimmons just said 19:43:11 bkardell_: I thought hober said said that the spec could mention should have specific contrast 19:43:34 jensimmons: well we could do add a somewhat vague note, but not finding a precise definition 19:44:09 ack dbaron 19:44:11 AmeliaBR: one way to solve this would be adding a warning to the spec to tell authors not to make assumptions about them 19:44:57 dbaron: I think one of the problems we've had in the past is that when the platform has too many degrees of freedom in it, developers aren't able to test what they're doing well enough 19:45:19 ... I spent a lot of time in the past dealing with GTK themes in the Firefox UI 19:45:51 ... so I had to write a debugging mode where I would customize the light / background color, and ensuring that setting front / back colors were matched 19:46:04 ... but they're extremely hard to test 19:46:26 ... I think light / dark would be ok, but if you expose too many degrees of freedom 19:46:56 ... then you break the users that have the weird settings 19:47:06 q+ 19:47:15 astearns: so you would oppose to add a note to the spec and would want something more normative? 19:47:37 dbaron: I'm fine with a note as long as it's something for which authors can reasonably test, which I think this is 19:48:20 AmeliaBR: so thinking about what that specific note should look like I think it should be focusing on the system colors (which includes using a color scheme and not specifying background / text colors) 19:48:40 ... in that case we should encourage authors to use them in a very dedicated set 19:48:57 ... that way if those pairs don't have enough contrast then it's the user choice 19:49:13 ... but if you mix the colors with your on colors then you're also responsible 19:49:21 Is there any existential evidence of *any* web designer or web site of authors using system colors in such pairs or very dedicated sets? 19:49:42 ... (puts some example about some win10 dialog not working in high contrast) 19:49:56 Many years ago I tried to do so and was one of the reasons why I gave up on System Colors 19:50:09 dbaron: I think that goes well beyond what we can reasonably ask authors to do 19:50:25 q? 19:50:28 q+ 19:50:39 ... if you want that kind of stuff we need to write tools for that because they're not going to get it right 19:50:41 q- 19:50:52 ... and I think we should ensure that light / dark mode should be coherent enough 19:50:55 ack tantek 19:51:41 tantek: specific response to AmeliaBR: without any successful evidence of authors doing so, it's irresponsible and a bit arrogant from us to tell authors what to do 19:52:45 astearns: I suggest adding a note to the spec mentioning that light / dark themes won't always be white / black 19:52:53 fantasai: there is such a note IIRC 19:53:43 ... we can add a note in the color spec to tell it that system colors should be used in pairs 19:53:54 tantek: i'd object to that 19:54:11 myles has joined #css 19:54:15 astearns: is the light / dark theme note ok? 19:54:18 tantek: that seems fine 19:54:29 ... we should not give authors advice without evidence 19:54:51 I specifically object to all the assumption about "pairs of system colors" 19:55:05 jensimmons: I'd propose to have the note say "don't assume light / dark means white / black", and "think of color contrast" 19:55:10 q? 19:55:27 fremy: I think that's the point, we can't compute contrast correctly, we went all around 19:56:05 ... (repeats the initial proposal about the minimmum contrast / darkness / lightness) 19:56:08 I also said that any such advice should be checked with WCAG and if we can't find a WCAG citation for the advice, we should assume that there's a good chance we may be mistaken 19:56:33 Rossen_: you can choose your own colors, if you want to follow WCAG 19:56:48 q+ to wrap up with some proposals 19:56:50 ... that's all we're saying 19:56:58 astearns: I'm happy with jensimmons' suggestions 19:57:06 fremy: it's about UA advice 19:57:09 Rossen_: no it's not 19:57:25 in some cases WCAG suggestions may be necessary but not sufficient, that is, it is possible there are WCAG recommendations that are not backed by evidence or possibly even existence 19:57:26 fremy: it is, we have color provided by UA and you cannot apply WCAG if you don't know the color 19:58:33 +1 to what jen said, that is what I was suggesting we were all saying in several ways 19:58:43 emilio: I think Rossen_'s point makes sense, we expose these colors in getComputedStyle, and you can adhere to the guidelines with either color-modifying functions, JS, or using system colors 19:59:04 AmeliaBR: I agree with fremy that we can't say "you can't know what the color is, but care about contrast" 19:59:20 s/there is such a note IIRC/we can add a note that "light" doesn't mean "black on white"/ 19:59:34 ... we can say "you don't know the colors, so if you use non-system colors you should set your background / foreground" 19:59:50 +1 to what AmeliaBR just said, that would be acceptable to me 19:59:50 ... we should also tell the system colors that are supposed to go together 20:00:03 ... so those are my two recommendations 20:00:12 going to state that system color "pairings" are fundamentally broken and we shouldn't even pretend that it's anything remotely workable for authors 20:00:15 ... one saying that you don't know what you're going to get 20:00:19 +1 to AmeliaBR's proposal 20:00:26 opposed to Amelia's proposal 20:00:36 ... and another for the pairs system colors are supposed to be used together 20:00:37 -1 to any even description of such "pairings" because no one has actually made them work 20:00:44 we've been telling people to specify foreground and background colors together for 20 years, and it hasn't worked 20:00:46 even without any "shoulds" 20:00:49 astearns: so we have agreement on the first note but not on the system color stuff 20:00:56 if it had worked, we'd have been able to do dark system colors by default without pages having to opt in 20:00:58 ... so I propose resolving for the first 20:01:04 dbaron++ 20:01:07 dbaron's analysis is correct 20:01:23 astearns: and leave the pairing of system colors for another time 20:01:29 astearns: objections 20:01:32 I'd like to close on "pairs" of system colors until someone comes back with actual new information / evidence that such "pairings" are workable 20:01:55 tantek, it's required for authors to work with such pairs for MSFT forced-colors mode 20:02:17 and the system colors as a concept are unworkable without pairs 20:02:35 fantasai I don't believe you - show me such an example 20:03:19 RESOLVED: Add a note to color-scheme to warn authors that the exact colors for dark and light mode are not specified, and that if they need to guarantee contrast against their own colors, they need to specify both foreground and background pairs. 20:16:29 s/RESOLVED: Add a note to color-scheme to warn authors that the exact colors for dark and light mode are not specified, and that if they need to guarantee contrast against their own colors, they need to specify both foreground and background pairs.// 20:17:44 RESOLVED: Add a note to color-scheme to warn authors that dark and light modes are not necessarily black and white colors, and that if they are specifying any of their own colors they should specify enough colors to satisfy WCAG requirements (with a link) 20:23:07 Rossen_ has joined #css 20:23:38 ScribeNick: fantasai 20:23:53 Topic: future value sepia 20:23:54 github: https://github.com/w3c/csswg-drafts/issues/3853 20:24:05 AmeliaBR: Discussing idea of having sepia color scheme 20:24:06 myles_ has joined #css 20:24:13 AmeliaBR: to reflect reader mode options 20:24:20 AmeliaBR: discussed whether it's just a different type of light scheme 20:24:24 AmeliaBR: We have two different use cases 20:24:31 AmeliaBR: We have prefers-color-scheme MQ 20:24:38 AmeliaBR: which author use to set their own colors 20:24:54 AmeliaBR: And we have color-scheme which is about requesting or indicating which sets of UA color schemes you can work with without breaking 20:24:59 AmeliaBR: These use cases are different 20:25:16 AmeliaBR: Suggestion from Tab was for color-scheme property we could keep generic light/dark and maybe other 20:25:19 una has joined #css 20:25:38 AmeliaBR: for prefers-color-scheme could have more nuanced options, so within 'light' might distinguish bright white vs sepia 20:25:46 AmeliaBR: Author could figure out which scheme user prefers the most 20:25:54 AmeliaBR: If we have nested hierarchical preferences, how does that look like? 20:26:20 florian: From MQ mechanics, no problem with multiple values matching atthe same time. Jus tneed to says so 20:26:39 florian: whether we want to do that is a separate question 20:26:52 rachelandrew_____ has joined #css 20:26:54 AmeliaBR: So if we define nested categories, then MQ can handle it 20:27:15 AmeliaBR: Question is do we want a comprehensive set of queries light/dark/other? 20:27:21 TabAtkins: What would other be? 20:27:26 AmeliaBR: Brightly colored 20:27:33 q+ 20:27:34 AmeliaBR: Like blue-on-yellow 20:27:41 ack AmeliaBR 20:27:41 AmeliaBR, you wanted to wrap up with some proposals 20:27:43 TabAtkins: I don't think that's realistic anywah 20:27:54 TabAtkins: Every scheme we've seen in practice can be described as light or dark 20:28:11 TabAtkins: I've seen maybe a few middling schemes, like light red on dark red 20:28:27 TabAtkins: but otherwise seen stark colors, low-contrast grays, and sepia 20:28:37 AmeliaBR: Also talked about color-scheme: any; 20:28:55 AmeliaBR: decided any was problematic 20:29:02 AmeliaBR: what about adding other 20:29:12 TabAtkins: Not quite as opposed, but don't think we need it yet 20:29:23 q? 20:29:24 TabAtkins: If we have a definitive third category, then willing to reconsider 20:29:33 AmeliaBR: User would pick specific scheme, e.g. dark red on light red 20:29:43 AmeliaBR: But author has to say "this website can work with light scheme, dark scheme, or other scheme" 20:29:50 una: I think something as general as other is too generic 20:29:56 una: maybe call it contrast 20:29:59 s/willing to reconsider/happy to reconsider, and leaning toward that strategy for it/ 20:30:04 una: like idea of sepia, but depends on so many things like ambient light 20:30:18 una: I like thought of considering that and giving authors more power 20:30:23 ack jensimmons 20:30:30 jensimmons: I feel pretty strongly that the controls that we want to provide for authors 20:30:44 jensimmons: needs to match what browser makers are going to do in revealing user-facing controls 20:30:51 jensimmons: Right now we're responding to light mode dark mode toggles 20:31:04 jensimmons: It's in the news and popular media right now, switching entire OS to dark 20:31:08 jensimmons: or browser to dark 20:31:17 jensimmons: What I don't see is any browse rmaker stepping forward 20:31:24 jensimmons: to provide more complex controls for users 20:31:34 jensimmons: to opt into sepia or chocolate-fudge-brownie-cake or whatever 20:31:42 jensimmons: if we provide these controls to authors, they don't go anywhere 20:31:49 jensimmons: there's no demand for them, not hooked up to anything 20:31:58 AmeliaBR: non-browser UAs offer controls for more variants 20:32:01 q+ 20:32:03 jensimmons: Or FF reader mode 20:32:11 q+ 20:32:12 jensimmons: But as author I can't style within reader mode anyway 20:32:19 jensimmons: there's nothing for me as an author to do 20:32:37 jensimmons: I have no access to that as an author 20:32:46 jensimmons: having a sepia mode in reader mode is not relevant to me as an author 20:32:54 i (again) completely agree with jensimmons 20:32:55 jensimmons: if Firefox wanted to hook that up to something else then we could consider 20:33:22 TabAtkins: If sepia mode shows images, might want to alter images 20:33:35 fantasai: Reader mode can apply sepia filter 20:33:47 jensimmons: Also want us to separate ideas that we personally have about how we want to surf the Web 20:33:57 jensimmons: from the reality of what browsers will actually implement wrt controls for users 20:34:11 jensimmons: Right now I don't think sepia reader mode will be hooked up to images like yo udescribe 20:34:24 jensimmons: This is one case where I really want browsers to say "we want this in CSS" 20:34:37 hober: We have a sepia mode in our ereader, and I don't want a sepia mode here. 20:34:48 q- 20:35:06 TabAtkins: Do these books have CSS in them? 20:35:08 hober: of course they do 20:35:23 hober: Even if ? solves the problem for itself, I don't want to do it here 20:35:27 florian: EPUB is HTML + CSS 20:35:39 jensimmons: As person making a website, you can't control how reader mode presents content on any level 20:35:44 q? 20:35:47 ack florian 20:35:59 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 20:36:12 aja has joined #css 20:36:12 jensimmons: Are there any ebook readers that want us to expose this to authors 20:36:20 dauwhe: I can also ask Readium about it 20:36:29 hober: As for a *positive request* from an implementer. 20:36:35 hober: I'm not saying never ship it 20:36:43 hober: if someone ships an OS-level control for it, we can do that 20:36:45 s/As for/Absent/ 20:36:46 hober: but I'm not seeing that 20:36:48 TabAtkins: I'm fine with that 20:36:50 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 20:37:04 e.g. https://github.com/w3c/csswg-drafts/issues/3853#issuecomment-499244493 20:37:05 TabAtkins: largely because behavior of "not sepia" and "not supported value" are identical 20:37:11 q+ to reiterate Rossen's comment about users wanting different modes for content vs UI 20:37:19 TabAtkins: More general idea, what if any is the necessary correlation between color-scheme property and prefers-color-scheme 20:37:23 but I don't know how much demand for this there is / would be? so I'm ok with or without it 20:37:29 TabAtkins: I think we can have them diverge in value space and meaning a bit 20:37:39 TabAtkins: Light vs dark we should keep 20:37:52 TabAtkins: prefers-color-scheme can deliver more detail as we wish it, sepia being a likely candidate 20:38:04 TabAtkins: When we have an existence proof of an implementation then we can add it later 20:38:10 TabAtkins: maybe put a note in the spec that this could happen 20:38:45 florian: I think I agree with Tab that MQ and prop are separate 20:39:03 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 20:39:03 ack tantek 20:39:03 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 20:39:20 tantek: I think similar to some of the previous questions, we should gauge it also by what are web author spublishing today 20:39:29 tantek: I've seen some sepia style pages, would be easy to opt in 20:39:29 issue was mostly to stop thinking of (supports-)color-scheme as binary dark/light, since it's spec'ed to support other values 20:39:36 tantek: but haven't seen a lot of them, so dunno how much demand there is 20:39:46 tantek: demand would have to be demonstrated to consder adding such a mode 20:40:13 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" 20:40:47 what Tab said 20:40:47 tantek: To assess that plausibility in the future, we can look at what web authors are publishing to see if that would motivate browsers 20:40:59 TabAtkins: I don't care, it's not relevant to me 20:41:14 TabAtkins: I didn't say "please implement a new color scheme, browsers" Just establish how we will handle this in the future. 20:41:42 https://github.com/w3c/csswg-drafts/issues/3853#issuecomment-494472950 20:41:47 tantek: which of the three options are we going with? 20:41:54 Options here: 20:41:54 Add it to the spec as a legal value with a description 20:41:54 Don't add it to the spec, but use it in an example of handling unknown names from the future 20:41:57 Don't mention it 20:42:33 TabAtkins: I want a note in the spec so I remember in the future 20:42:38 fantasai: Add a comment in the source code 20:42:47 myles_: Audience of the spec isn't just ppl in this room 20:42:48 q? 20:43:04 AmeliaBR: There's a note already mentioning possibility of future values 20:43:17 ack AmeliaBR 20:43:17 AmeliaBR, you wanted to reiterate Rossen's comment about users wanting different modes for content vs UI 20:43:24 AmeliaBR: Wanted to respond to no demand from UAs 20:43:32 AmeliaBR: Nobody exposing these other modes 20:43:42 AmeliaBR: Want to go back to Rossen's comment about nested hierarchies 20:43:52 AmeliaBR: There's the OS color scheme, app UI scheme, and content color scheme 20:43:58 AmeliaBR: There is no demand for sepia in the outer levels 20:44:08 AmeliaBR: There is demand for color scheme selectors that focus only on content 20:44:15 I suppose if there was a sepia color scheme I could change the photo on my site to use an old-timey outfit / hat. 20:44:26 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 20:44:48 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 20:44:56 q+ 20:45:02 AmeliaBR: WE do have in the spec trying to be forward-focused with idea that there might be additional color schemes 20:45:27 AmeliaBR: so proposal is to clearly state that the color scheme keywords and prefers-color-scheme are not going to be 1:1 20:45:35 AmeliaBR: color-scheme property will focus on general classes of color scheme 20:45:50 AmeliaBR: and prefers-color-scheme exposes those classes but may in the future expose more specific subsets 20:46:00 AmeliaBR: to distinguish e.g. sepia mode vs bright white mode 20:46:10 florian: I don't disagree with what you're saying 20:46:19 q+ 20:46:22 florian: but it's overly prescriptive for what the WG might do in the future 20:46:58 TabAtkins: I'm done with this topic, we got the feedback we needed 20:47:05 ack jensimmons 20:47:15 jensimmons: It's a good idea to think about future-forward and make sure we don't engineer ourselves into a corner 20:47:25 jensimmons: I also feel strongly that I don't want to put into any spec any values that don't exist yet 20:47:35 jensimmons: because it will really clutter up the discussion we have to have with designers 20:47:44 jensimmons: to explain all this dark mode light mode stuff 20:47:49 jensimmons: We already have to do a lot of education 20:47:58 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. 20:48:00 jensimmons: we don't need it to be excessively complicated or overwhelming 20:48:06 s/with user/without user/ 20:48:10 more color modes = more job security for visual web designers! bring it! 20:48:23 jensimmons: I don't want to overengineer anything 20:48:35 jensimmons: keep ourselves from blocking into a corner, but don't try to anticipate a future that doesn't exist yet 20:48:41 RESOLVED: No change 20:48:54 tks for the (more serious than i'd even imagined) consideration 20:48:58 Topic: What has Apple done? 20:49:12 TabAtkins: Talked to Tess already, so don't need to discuss here 20:49:26 TabAtkins: Can we get smfr on the call in two weeks? 20:49:31 hober: yes 20:49:36 TabAtkins: I want that information please 20:49:44 hober: I can't guarantee that smfr will know the things 20:50:06 Topic: UA guidance on light vs no-preference 20:50:10 github: https://github.com/w3c/csswg-drafts/issues/3857 20:50:13 q+ 20:50:39 ScribeNick: myles 20:50:42 ScribeNick: myles_ 20:51:12 fantasai: The bakcground is we have a wide variety of content types on teh web. some are application-like, and some are art-like. For the use case of night reading, authors need to perceive dark not as a UI choice, but as a global choice for all content. 20:51:16 fantasai: anyone disagree? 20:51:34 jensimmons: are we saying that every part of a page should be on a dark background with white text? 20:51:56 fantasai: no. It means the user wants a dark mode (such as being in a dark environment) so please adapt to that expectation. It's not just "i think black looks cool" 20:52:22 jensimmons: There are cases where 1 blog designer might say the article textshould be light on dark in dark mode. But a different one might only want to do that to the sidebar, not to the body text 20:52:30 jensimmons: I think what you're saying is the first is good, but not the second 20:52:38 I think the text fantasai read was "The Web consists of a wide variety of content types, some of which are application-like, and others which are art-like: for dark mode to be useful for e.g. night reading, as has been suggested, authors need to perceive (prefers-color-scheme: dark) not as a preference for UI in app-like interfaces, but as a global 20:52:38 preference for content." 20:54:08 myles has joined #css 20:54:11 fantasai: it means "it is difficult for me to work with a light-mode scheme", or " 20:54:40 We need to distinguish between "I want my apps to be dark mode, but content whatever, because I want the app interfaces to fade into the background wrt the content I'm focusing on" 20:54:52 vs. "I'm in a dark room or otherwise have difficulty with light-mode theming, please make things dark for me" 20:55:19 q? 20:55:46 q+ 20:55:47 fantasai: the other thing: light has the same weight as preference/desire as dark. If an implementation wants to have a no-preference mode, it maps to a no-preference mode. I don't carewhat the UI is, but the default mode of the web is no preference. The default mode that is communicated is no-preference. 20:56:07 TabAtkins: Current dark websites should not be told "everyone on the web prefers light, please use a light mode" when in reality most users don't have a preference, use any mode 20:56:20 TabAtkins: Even though you only have two states, you should map it to "no preference" and dark. 20:56:22 ack hober 20:56:52 hober: We have no notion of no-preference on our platforms. At OS install time, we prompt the user to pick light or dark. You have to to move on to the next screen. There is no system concept of no preference. We're not interested in pretending otherwise. 20:57:12 a website I designed over a decade ago: http://runesofgallidon.com 20:57:22 rachelandrew______ has joined #css 20:57:51 florian: You're describing what you call the buttons in the UI. On macOS, there is a light and dark button. If you pick dark, all apps are dark. If you pick light, only some are light. So yes, you call it light, but in reality it doesn't mean that. Apps don't get forced into light mode. The mode you ahve been calling light is a no preference mode. It's not a preference for light. 20:57:57 florian: all the pro apps are still dark in teh light mode 20:58:12 hober: Not all websites are going to listen for this thing. That's okay. 20:58:49 jensimmons: I disagree with the first statement: Dark mode means everything has to be dark. We don't need that. That belongs in teh hands of the designer. Some sites can interpret "dark" differently than other sites. Authors can interpret it differently. 20:59:02 TabAtkins: If i want dark mode because i'm in bed, I would be unhappy with any light 20:59:15 jensimmons: Your'e speaking as a user. Websites can do tha tto their users. 20:59:22 florian: We are describing what this preference means. 20:59:27 jensimmons: That is not how this is going to work out. 20:59:41 TabAtkins: You are arguing that the notion of dark mode is not useful 21:01:14 dbaron: I think you started from the assumption that this should be symmetric. In reality, it is not symmetric. So saying "therefore it should be symmetric" is not helpful. The reality we're starting from is that existing content wouldn't work if users had dark defaults. If you want a mdoe where all we bcontent is dark, then you need a browser that is going to make destructive modifications to websites 21:01:33 q+ 21:02:07 ack dbaron 21:02:07 I'd like "I (webpage) can handle dark mode, except can you take care of dark form controls and scrollbars for me" ? 21:02:16 TabAtkins: That's not what I'm saying. I know I"ll get blasted by light sites sometimes. But *if* I say Dark Mode, and I visit a reasonable site that pays attention to it, I expect the site to be dark. That's just the general expectation of what that value means. 21:03:36 bradk has joined #css 21:04:40 dbaron: I think we're starting from a world where most web pages are light. And some pages are going to be willing to design two options, some aren't. That's the reality. We're also ina. world where a bunch of OSes have introduced these dark mode preferences. It's a request that a lot of stuff be dark. So, we have preferences htat users have chosen where one option in that preference is "the legacy behavior where most stuff but not all was light" and the 21:04:40 other is "i request more stuff be dark". Those are the preferences that people are asking to be reflected to the web. Those aren't symmetric. Trying to map into a thing that's symmetric or pretend that one is an expression of no preference at all, where the light one is a weak preference for maybe no preferences, and maybe "i have not chosen the dark mode". The dark mode preference is a stronger preference. It's not "no preference at all' but it's pretty 21:04:40 weak. The other is strong. That' sthe thing we have. Trying ot map that onto a tri-state, wehre two optinos are symmetric, and one must express no preference at all is not going to work 21:05:51 q+ 21:05:52 florian: I don't think no-preference means no preference. No-preference mode means "the state of today". Most websites tend to be white. Some websites are dark, and some are fuscia, and I'm okay with that, which results in most content being light. This is No-preference. If we had two states, it would be "what you've been doing" and "dark". If we had 3 states, it would be "light", "dark", and "no-preference" 21:06:35 But what in the world are the browsers / OSes going to do with three states? What are Authors going to do with three states? 21:06:38 florian: THe default shouldnt' mean "i really need you to be light". If an UI has 3 states, it should map to 3. If it has 2 states, the one that isn't dark, the one remaining should be a no-preference value. Or, we shouldn't have al ight mode at all, but the default one should nto be a request to be light 21:06:41 q+ 21:06:46 +1 for florian's summary 21:06:51 +1 to dbaron 21:06:54 ack florian 21:07:00 ack una 21:07:56 una: Yes, a lot of websites tend to be light with dark text on light background. That's true for media websites with text, but landing pages are often dark. We have light and dark modes; I see them, and people interpret modes where their current astehtic is not sufficient, then use light to create a light version of the website. Mercedes is a dark theme, with many dark pages. There are use cases for both. There's no benefit in separating out no-preference 21:07:56 from light and dark. 21:08:05 florian: i am confused. 21:08:20 una: no-prefernce is equal to brand identity 21:08:20 florian: Yes, and it should be the default 21:08:57 florian: In macOS, one is dark and one is the default. Even though you labelled it as light, it means no-preference 21:09:16 florian: so the request is to for macos to map what is called "light" to no-preference 21:09:22 hober: no 21:09:33 21:09:37 florian: so mercedes can continue to be dark 21:09:45 astearns: we are asking for changes in UA behavior 21:09:49 q? 21:10:02 TabAtkins: in dark mode, you expect all apps to be dark, right? 21:10:09 hober: no. i agree with dbaron 21:10:21 TabAtkins: A well-behaved app should be dark, right? 21:10:34 hober: I don't know what "well-behaved" means 21:11:00 hober: If I'm in photoshop, the canvas's background is white, I don't expect it to be black in dark mode 21:11:11 hober: If I change the preference, I expect many things to change, and some things not to. 21:11:14 ack jensimmons 21:11:14 q+ 21:12:51 Do we agree that browsers should give users a no-preference option? Or is that also controversial? 21:13:00 jensimmons: Priority of constituency. This is a theoretical purity vs practicality argument. Theoretically, users should pick light and everything should be entirely light. but that won't happen because of the history. So we should explain how dark means everything should be dark, and vice versa? I'm not on board with that. The control that's presented to users is light and dark. Sometimes it's in the OS, and some are in the browser, and this doesn't make 21:13:00 sense to me. I don't know how to tell authors how to make 3 designs? Should some AI do it for the artist? So why do we want 3 options? What should the browser hook up to each option in the media query? 21:13:41 jensimmons: The reality is that we don't know yet what designers are going to want to do with a vague idea of dark "mode" and the vague idea of light "mode". Users might hate it, but it's their right to make something users hate. Maybe both modes will be lightish, but that's just the design of the page 21:13:48 ack fremy 21:14:31 fremy: We have been saying that all OSes have 2 themes: light and dark, where light doesn't mean anything strong. In the latest windows, there is 3 options: no preference, dark, and light. 21:14:46 q+ 21:14:54 Light on windows means, all dark things that are dark by default get light. 21:15:07 There is this new mode that is "light" in which case the start menu and settings become light 21:15:24 fremy: This is how the media query should be modelled 21:15:25 q+ 21:15:44 q+ 21:15:49 jamesn has joined #css 21:15:57 fremy: Maybe we should revisit this issue in a little while. It doesn't sound crazy to me to map 2 preferences to no-preference and dark 21:16:22 ack TabAtkins 21:17:07 TabAtkins: dark mode means something. Applications/pages can respond to it and do something. There is an expectation about what a page responding to dark mode is. Something will happen to a page. And it will be dark. 21:17:42 TabAtkins: What is the expectation for a page in light mode? 21:17:51 hober: As mild as the preference for dark 21:18:02 florian: For the pages that do respond, what do they do? 21:18:25 TabAtkins: If you respond to the query, and you do something with your colors, is the expectation that they will be light? 21:18:37 q? 21:18:49 heycam: The expectation is that for pages and apps that have both, they will chose the light, but that's not the expectation that all pages will do that. Some ::more:: will be light or dark. 21:19:49 fantasai: Specific example of the mercedes page. Let's say they make a light and dark background pages. My branding strategy is that I want most people to see the dark one, but if they want light, they will turn that one on. On macOS, are they going to switch into the light mode, or would the expectation be that they get the branding colors they ideally want the users to have in light mode? 21:20:10 if someone want to learn about the new windows light mode aka "the perfect antithesis of the dark mode", here is a blog post: https://www.windowschimp.com/windows-10-light-theme/ 21:20:11 TabAtkins: In dark mode, we expect mercedes to use dark colors. In the other mode, we expect them to use their normal brand colors, which are light 21:20:39 astearns: we can't be that black or white about our expectations. Given the desires of advertisers, I can certainly see one saying "theyr'e in dark mode, I'll use light colors to stand out" 21:20:49 TabAtkins: People can be assholes no matter what 21:21:10 TabAtkins: What do teh values mean? What should authors do with the media query? If we can't answer those questions, we remove the media query 21:21:13 I think most of the time ‘light’ and ‘no-preference’ would be designed the same way. But Mercedes might have a ‘light’ version that is not shown for no-preference. 21:21:28 q? 21:21:28 q? 21:21:28 q+ 21:22:33 jensimmons: Your example: team at mercedes, they have had a design for years, so they design two more versions of the site: light and dark. So what do they do with the no preference mode? I don't want to give them three options 21:23:31 q- 21:24:14 jensimmons, we're not expecting to design three options. Either the website doesn't care (ignore all options, one design only) 21:24:16 No preference doesn't mean, design a third color scheme. It means the website author gets to pick whether to use the dark scheme or the light scheme. 21:24:18 I simply don’t understand how three options will work. 21:24:20 +1 to astearns plan 21:24:24 myles_ has joined #css 21:24:33 astearns: We are done for the day. 21:24:33 jensimmons, or it designs two: light mode and dark mode. In no-preference mode, they pick whichever one they like the most 21:24:52 And liaBR: +1 21:24:52 topic: end 21:25:16 no preference, light-mode-preference, dark-mode-preference is three sets of code to think about and plan for…. to design & engineer. 21:25:21 no, just two 21:25:27 AmeliaBR +1 21:26:14 github-bot: end topic 21:26:19 fantasai: +1 21:26:28 unless your website prefers lime green on fuchsia, in which case it might be difficult to call that "light" or "dark" ;) 21:27:21 That’s for ‘god-awful’ mode 21:27:49 Today, FooCorp Inc has dark branding guidelines; all their printed material is dark background with a light-color icon. 21:28:05 The website team wants to be responsible, so they use (prefers-color-scheme). 21:28:21 jensimmons: In reality, it's about the choice between whether the website code uses dark and not-dark media queries (no-preference uses light), versus light and not-light (no-preference uses dark). You don't need three media queries, you usually only need one versus your default styles. 21:28:39 I don't understand really why that is 'be responsible' ? 21:29:38 That’s a good point AmeliaBR 21:30:18 Me too 21:30:35 😀 21:31:37 If MacOS is set to dark, (prefers-color-scheme:dark) matches, cool, the default corp branding works. The website as already designed works. 21:33:15 If MacOS is set to the non-dark option, does that mean the site should do an opposite style, with dark logo on light background? 21:33:30 (I submit that that is *not* the expectation currently.) 21:34:10 It’s not a CSS thing, but I hope browsers let user opt out of web page dark mode even when the OS setting is dark mode. Apple does that for mail.app 21:34:55 So window chrome and menus etc are dark, but documents in the browser are not. 21:36:06 Like hober’s photoshop example. 22:04:40 rego has joined #css 22:18:16 dbaron, you asked to be reminded at this time to go home 22:32:30 bradk has joined #css 22:52:05 aja has joined #css 23:35:49 cabanier has joined #css 23:49:21 Zakim has left #css