23:00:16 RRSAgent has joined #css 23:00:16 logging to https://www.w3.org/2020/07/01-css-irc 23:00:18 RRSAgent, make logs Public 23:00:19 Meeting: Cascading Style Sheets (CSS) Working Group Teleconference 23:00:27 present+ 23:00:32 present+ 23:00:38 ScribeNick: dael 23:00:44 Rossen_: We'll give it a couple minutes 23:00:44 Rossen_ has changed the topic to: Agenda for July 1/2 2020 at: https://lists.w3.org/Archives/Public/www-style/2020Jul/0000.html 23:00:52 present+ 23:01:07 present+ 23:01:11 present+ 23:01:22 faceless2_ has joined #css 23:01:26 present+ 23:01:26 smfr has joined #css 23:01:38 present+ 23:01:41 present+ but webex not cooperating just yet. 23:01:56 present+ 23:01:58 Rossen_: We're a minute away from starting 23:01:59 present+ 23:02:03 leaverou, btw, if you were hoping to resolve on the hue stuff today, I just made a PR with a few tweaks at https://github.com/w3c/csswg-drafts/pull/5278 23:02:17 dbaron: did you pull in my recent changes? 23:02:22 I also integrated your edits today 23:02:22 I'm waiting for lists.w3.org to load to give me the URL to webex 23:02:24 leaverou, yes 23:02:42 Rossen_: It's 2 minutes past 23:02:47 present+ 23:02:52 Rossen_: That is our usual starting time so let's get started 23:03:04 Rossen_: I wanted to ask for any last minute agenda items or changes 23:03:16 jensimmons has joined #css 23:03:27 present+ 23:03:32 present+ 23:03:32 dholbert has joined #css 23:03:36 present+ 23:03:38 Rossen_: I'm aware of 3 changes; items to skip b/c already discussed or will be covered futher in GH. Issue #4, #8, and #9 23:03:48 webex page from lists.w3.org says go to https://mit.webex.com/mit/j.php?MTID=m34e7a273ee0398395b9408821caaa184 23:03:52 present+ 23:03:53 Rossen_: Besides skipping 4, 8, and 9 other changes? 23:04:04 dino has joined #css 23:04:07 Rossen_: I'll take that as a no 23:04:11 present+ 23:04:16 Topic: [css-images-3] clarify which images image-orientation applies to 23:04:20 jensimmons has joined #css 23:04:24 github: https://github.com/w3c/csswg-drafts/issues/5245 23:04:58 heycam: We have image orientation property that allows us turn off auto-re-orientation. 23:05:25 heycam: Some discussion about widening to all images a few months ago. Resolution from there was orientation meta data should be honored for decorative images. Makes sense. 23:05:51 heycam: Wasn't discussed if properties should be extended. As MIke noticed we have contradictory WPTs. Should image-orientation apply to decorative images? 23:06:18 q+ 23:06:20 heycam: My feeling is it should b/c real purpose of property is let authors opt-out and it doesn't make sense to limit that to a subset of images 23:06:37 ack dino 23:06:43 dino: Question is what would you do if want decorative to do one thing and non-decorative do another 23:07:05 heycam: You would need to introduce some other way of override orientation, maybe with image value syntax, or correct images 23:07:26 dino: Sort of leading question. In many cases will have to fix image or change content. Is it worth having this apply everywhere? I don't know 23:07:33 present+ 23:07:39 present+ 23:08:00 heycam: From experience of bug reports they were all content images. jpegs with image data rotated but tool didn't update meta data so new image-orientation made them wrong. Didn't get cases on decorative 23:08:58 fantasai: We had this discussion before and I believe resolution was only to apply to content. Idea was if we needed to apply to other we would introduce image notation syntax. This discussion was before auto xif but that was original discussion and conclusion 23:09:08 Rossen_: Is that 4165? 23:09:18 fantasai: older 23:09:24 fantasai: Let me change DoC 23:09:42 s/change/see if it’s in the/ 23:09:43 s/xif/EXIF 23:09:46 https://lists.w3.org/Archives/Public/www-style/2012Mar/0412.html 23:09:52 Rossen_: Where does this leave the current issue? 23:09:59 huijing has joined #css 23:10:12 fantasai: Here's the issue. #50 in DoC. Conclusion was repalced elemtns and generated content but not background image 23:10:18 fantasai: Or any other images in CSS 23:10:30 fantasai: Images which are considered part of content are effected but no other 23:10:50 faceless2_: If purpose is undo exif makes sense to apply, but it's not weird to not. As long as it's documented. 23:10:55 "It applies only to content images (e.g. replaced elements and generated content), not decorative images (such as background-image)." 23:11:00 fantasai: Spec says applies to content not decorative. 23:11:18 https://drafts.csswg.org/css-images-3/#the-image-orientation 23:11:19 fantasai: Anything that's a replaced element in css model it applies to that. Everything else is not effected. 23:12:06 q+ 23:12:16 ack fantasai 23:12:16 fantasai, you wanted to discuss history 23:12:22 heycam: Seems like notion of this property has changed over time. Original I want to set an orientation on an image. Now proprty is forI I have a problem caused by change in browsers and this gets me the old way back so I don't have to fix images I'm serving. In that PoV makes sense to apply as broadly as possible. Let's author set one property which goes to all images 23:12:28 This was issue 50 in the 2012 LC Disposition of Comments https://drafts.csswg.org/css-images-3/issues-lc-2012 23:12:47 chrishtr: I agree with heycam reasoning and that's what Chrome impl. There were cases where it was useful behavior for site compat 23:12:56 webkit agrees with cameron too 23:13:08 fantasai: If we make this change it should only affect none value and others shouldn't apply to decorative 23:13:09 ack chrishtr 23:13:23 heycam: I think we have resolution to remove other values. 23:13:50 fantasai: It's deprecated but has been impl and shipped in multiple impl, jsut nto browsers. We can remove from next spec level, but there needs to be a spec with those. 23:13:54 chrishtr: Who impl? 23:14:11 fantasai: Some printer based technology sihpped with onboard layout in printer chipset. 23:14:30 chrishtr: Okay so we say rotate ones won't apply to style images 23:14:39 tantek has joined #css 23:14:45 present+ 23:14:52 fantasai: And support for that is marked as optional so browsers don't need to impl. But there needs to be spec for it 23:14:57 Rossen_: Any changes to L3 images? 23:15:21 fantasai: Yes if we want to make from-image and none value apply to background and other images we need to change spec to say it's all images associated with element 23:15:35 Rossen_: Is this going to be still valid for printer or are they okay b/c L2? 23:15:42 fantasai: They don't impl from-image I believe 23:15:52 Rossen_: Sorry, confused by statement that there were impl 23:16:08 fantasai: If we make change for other values than yes. THat's why I'm saying it shouldn't apply to the other values 23:16:18 Rossen_: Would that solution work for everybody 23:16:23 heycam: sgtm 23:16:46 Rossen_: Prop: Make from-image and none value apply to background and any other images? 23:16:55 fantasai: angle only applies to content 23:17:07 Rossen_: none value on from-image 23:17:13 Rossen_: Additional comments? 23:17:26 smfr: Can we resolve on cursor behavior and linked meta that are in GH issue? 23:17:44 Rossen_: Would this be the exception on cursor? 23:18:06 smfr: Makes sense for cursor to have same. Link and meta I don't know since usually don't apply CSS to them 23:18:16 fantasai: Not sure what a link or meta element would do 23:18:29 heycam: Some cases about favicons and similar images 23:18:58 smfr: First comment in issues has list of interesting items like embed object. We need to be explicit which of these we include 23:19:17 chrishtr: Canvas is an imparative API 23:19:35 smfr: Not sure abotu canvas I think right is API to expose exif to JS or extend draw image API 23:20:12 presumably you can put images on link or meta via background-image or ::before and content property etc. 23:20:15 fantasai: Rest it should apply, every image associated to the element is effected as far as CSS is concerned. If it's a replaced element it's applied. Decorative elements would include background iamge and cursor 23:20:20 smfr: Source graphic in SVG 23:20:26 fantasai: Replaced element, isn't it? 23:20:34 smfr: I think it's paint source or whatveer it's called 23:20:46 heycam: I think that's rendered content of some subelement on dom tree 23:21:03 fantasai: Do you do image orientation of source, using, or neither element 23:21:37 heycam: Similar to canvas-draw-image b/c can reference another image element. Have minor incompat on where to look already. I think those cases can be handled in specs that define what it's referencing 23:21:52 smfr: Agree. We can resolve on what we discussed and say SVG may need refining 23:22:05 heycam: I'm happy to make cursor effected 23:22:30 Rossen_: Should we try to resolve on this and heycam or someone can open an issue on SVG to makes sure there's no additional items to associate to this decision? 23:22:36 smfr: sgtm 23:22:44 s/smfr/heycam/ 23:22:45 Rossen_: Still previous resolution. Objections? 23:23:01 RESOLVED: Make from-image's none value apply to background and any other images 23:23:11 Topic: [css-color-5] When mixing hue, there are two ways round the hue range 23:23:13 present+ 23:23:22 github: https://github.com/w3c/csswg-drafts/issues/4735 23:23:48 leaverou: When interpolate between hues usually you don't want interpolate in same way. If going between hue 0 and hue 400 you don't want a whole rainbow 23:24:49 leaverou: What we put in spec is by dfault use shortest arc which does expected in common. Have keywords for longest arc etc and also as-specified keyword to allow raw interp 23:25:08 leaverou: Wasn't sure if all needed. Esp specified one. If impl want to store value as normalized keyword doesn't allow 23:25:22 leaverou: I put algo in spec which tweaked by dbaron. Good to get sanity check. 23:25:34 https://drafts.csswg.org/css-color-5/#hue-interpolation 23:25:36 q? 23:25:36 fantasai: Can you summerize the proposal? 23:25:43 leaverou: Do we need all 5 keywords? 23:26:24 leaverou: We need shorter b/c that's what you expect in most cases. Do we need specified which is interp as specified so if you go between 0 and 720 2 rainbows. Need increasing, decreasing, longest or is that completist 23:26:54 fantasai: Are there use cases? We can add keywords. If there's not a use case might want to note possibility for future reference in case we need to add later. If not a use case don't need to add. 23:27:14 fantasai: I think it's usefult o think of all and makes sure keywords are a set that make sense even if we only include 1 or 2 in spec 23:27:32 dbaron: Intent is these would eventually apply to all gradients, animations, and color mix funct or only some? 23:27:58 leaverou: Good to design with that in mind. Not sure how text for animation snad gradients but if we have a syntax making sense it would be good to have the option 23:28:15 q+ 23:28:48 for gradients and animations the workaround would be to add more steps/stops to mimic the non-short behavior? 23:28:55 fantasai: My suggestion is draft all in spec, put an issue in saying we're not sure if we need all and we might limit to a subset with the subset that makes sense to you and also note might expand to gradients. Encourage people to think what that would look like 23:28:56 +1 to publishing at least one draft with more keywords to get the ideas published 23:29:12 fantasai: Early stage WD so makes sense to put ideas and poke at them with people like Una to make cases 23:29:13 http://localhost:8002/csswg-drafts/css-color-5/Overview.html#hue-interpolation 23:29:20 https://drafts.csswg.org/css-color-5/#hue-interpolation 23:29:28 leaverou: Does math make sense? This is the section ^ 23:29:34 q+ 23:29:42 ack miriam 23:29:54 miriam: THinking of specified I'd have use cases when comes to gradient. As pointed out in chat that could be do with extra stops. 23:30:27 miriam: Can't think of cases when mixing colors. I don't know if that's separate but might be. Math makes sense. Shorter and longer fall apart at 180 which maybe implies need to determine direction without them 23:30:34 ack florian 23:31:04 florian: I haven't reviewed math for correctnss, but intuitive seems right. Longer seems least useful. Wanting longer for being longer seems odd. Might pick if gives right thing. 23:31:11 +1 to longer being less useful than increase/decrease 23:31:17 florian: Approach about putting in spec now with note for use cases sounds good 23:31:46 dbaron: On math have a PR to tweak. I think set notation doesn't match pseudo code and I think pseudo code is right. I have some weaks for 180 case but it's not clear that's what we want 23:32:02 leaverou: 180 chris said we can pick one as long as it's well defined. Doesn't matter increasing or decreasing 23:32:12 florian: Makes sense. If you have a preference you can say it. 23:32:28 fantasai: We use 'closest' in radial gradients so maybe that instead of 'shorter'? 23:32:32 leaverou: Than what longer? 23:32:37 fantasai: 'father'? 23:32:52 florian: I don't think longer is needed so I don't mind not having a good replacement 23:32:58 s/father/farthest/ 23:32:59 near and far, close and distant, short and long ? 23:33:00 fantasai: We have farthest and closest side 23:33:08 leaverou: That's differ than angles 23:33:28 present+ 23:33:39 Rossen_: Apart from bikeshedding I hear 2 proposals. 1) let's push a version of the spec with all the keywords initially or as many as we want so we encourage more incubation. 23:34:04 Rossen_: 2) I hear agreement that longer doesn't seem useful. I didn't hear a use case to prove otherwise. 23:34:10 Rossen_: I don't want to bikeshed. 23:34:23 Rossen_: SHould we resolve to keep the keywords becides longer and publish? 23:34:34 leaverou: I'd rather hear from Una and Adam before we resolve. 23:35:07 fantasai: This isn't final. We're drafting for dicussion to encourage participation. I think it's fine to put it all in the draft, explain the thoughts, and enougage feedback. We can publish often 23:35:22 Rossen_: Objections to Publish a version with all keywords but longer? 23:35:23 "Publish early, publish often" 23:35:26 +1 23:35:32 RESOLVED: Publish a version with all keywords but longer 23:35:43 Topic: [css-values] Fallback value of ex height 23:35:52 github: https://github.com/w3c/csswg-drafts/issues/5243 23:36:30 fantasai: There's been discussion since I did agenda+ so might want to kick to GH to see if there's changes to spec text. Does seem like point 8 is not what's impl 23:36:49 Rossen_: Sure. Chatter on issue started after posted agenda. Let's give it more time. 23:36:53 github: none 23:37:01 TOpic: Allow specifying the "accent color" of a form control element 23:37:09 github: https://github.com/w3c/csswg-drafts/issues/5187 23:37:26 chrishtr: Form controls are styled and painted in UA specific way in all browsers 23:37:43 chrishtr: There tends to be a concept of an accent color used to indiacte checked or marked state of form controls. 23:38:18 chrishtr: UAs pick a default color for that that's consistent in page. There are also OS settings on some OSs to change accepnt color which is respected by some browsers. 23:38:33 chrishtr: COlor might conflict with brand of site, like site with orange theme but checkboxes are blue 23:38:54 chrishtr: Proposal is to ahve css property which says form controls should use this color as basis of accent color when painting form control 23:38:59 Rossen_: Opinions on this? 23:39:02 the other big use-case is for sites that want to make "darker" versions of form controls that match their site styling, similar to scrollbar colors 23:39:07 q? 23:39:24 fantasai: Main concern is it's not clear what accent color is used for. B/c that it's nto clear what's expected contrast between that, text, and background. 23:39:43 +1 agree with fantasai, needs to be predictably specified so it makes sense across OSs and devices 23:40:06 fantasai: Concern people will choose colors that are good on some OS but won't contrast with background enough in other rows. For example a select multiple it needs to contrast with text. But on a selected checkmark it's background 23:40:24 fantasai: Understand what you're trying to do but concerned we won't get something robust across browsers 23:40:35 needs to be sufficiently predictable across browsers 23:40:37 florian: Can we split into foreground and background or does that not generalize well 23:41:36 myles: We had internal discussion and general feeling is good for web in general. Not sure mech to expose. We have a general idea good to style lots of form control aspects. Good to do in general not just one piece. In general feel this has value for web. 23:41:38 +1 myles that's a good summary 23:41:47 jensimmons has joined #css 23:41:52 tantek, that use case is handled by the 'color-scheme' property fwiw 23:41:54 tantek, https://www.w3.org/TR/css-color-adjust-1/#preferred 23:42:29 chrishtr: Re: general styling point. Agree that there are other things devs wish to style and hopefully can. This one seems to be simple and common and immediately solves a specific conern. THat's why I think do it as a one-off for the moment and general in future 23:42:35 q? 23:42:45 q+ 23:42:45 fantasai, not talking about not dark mode. hence I said darker deliberately 23:43:19 q? 23:43:21 florian: General will take time. Seems most of time accent color is related to backgrou,d but not always. If it's background or foreground matters. Having the pair would be a step which could make sense. There can be many aspects of form control we can do later. Knowing if your'e in foreground or background matters. 23:44:09 heycam: Ignoring select multiple issue which might nto be accent color all other colros are contrasting separately. For checkbox and radio you'd got icon inside which authors can't control. I think for most cases where accent color can be changed any contrasting color can be painted by UA. 23:44:37 jensimmons: Has anyone working on open UI on the call? I know a lot of work has gone into form controls and what it means to style them 23:44:57 myles: On iOS there's no concept of the accent colors. Whatever is in spec needs affordences for OS where it doesn't apply 23:44:58 q? 23:45:04 ack jensimmons 23:45:28 florian: If we look at range of historical OS to get diversity the buttons were a shade of blue. If that was still the fashion accent color wold be there and it's very background-y 23:45:38 https://66.media.tumblr.com/e0c02215356306ee52298451ac25685e/tumblr_o5a0h4UIDN1v0jfsto2_1280.png 23:46:17 huijing has joined #css 23:46:29 http://pcdesktops.emuunlim.com/pictures/skins/wb/macosx-aqua-bjb.gif 23:46:30 chirsh: Answering jensimmons, I'm working with gregwhitworth and others on longer term project for form controls. I don't know if enought o discuss here. In general I think compat. I don't think enough to say about OpenUI to clarify 23:46:37 Rossen_: Is there a resolution you're looking for? 23:47:18 chrishtr: I'm hoping to get to agreement on name and set of text what's it's supposed to be for UA and says UA should make sure sufficent contrast and only where it makes sense 23:47:41 dauwhe has joined #css 23:48:04 fantasai: Fine to try and draft language. Requires more release to make so it works on a variety of OSs. I'm a little skeptical this will work but understand we want it. I'm concerned about having it work for all OSs. 23:48:34 fantasai: If we can show that would be the case across current and past OSs and there's a reasonable interpretation for all the OS/browser combos I would feel more comfortable moving forward 23:48:44 +1 to what fantasai said 23:48:55 chrishtr: Hearing general support but need mroe research to understand compat as well as foreground/background comments 23:49:21 fantasai: I think we should do that evaluation in GH. Might be right design, but might be diversity of form controls requires something different. 23:49:33 we're also looking preliminarily at a more longer term project for form controls as well, if existing work is happening in the open, please share that in CSSWG! Thanks! 23:49:34 chrishtr: We'll come back with more concrete proposal 23:50:15 florian: What I'd liekt os ee in research is wide variety of form control and show form controls is always background or neither. If it's in foreground sometimes we need to split it up. 23:50:23 Topic: [css-sizing-4] Should aspect-ratio be used for abspos `top: 0; bottom: 0;`? 23:50:31 github: https://github.com/w3c/csswg-drafts/issues/5151 23:50:32 just going to note that existing OS UI use of color is insufficient to determine feature flexibility, new OS's may and will do new things with colors etc. 23:51:22 PR: https://github.com/w3c/csswg-drafts/commit/9594b70729ff481ea933a3e3d07a85423122e0eb 23:51:44 fantasai: Issue raised was if you have abspos element with top, bottom, left set non-auto but right is auto should that use aspect-ratio in sizing width. TabAtkins and I thought it made sense so drafted spec fot hat. 23:52:25 fantasai: If width and height are both auto we ignore a-r for width and use it for height. In this case it's easy to determine. Width has only one constraint so it's variable and makes sense to use height for deterministic value 23:52:36 https://github.com/w3c/csswg-drafts/commit/9594b70729ff481ea933a3e3d07a85423122e0eb 23:52:39 fantasai: Drafted wording into positioning spec. Wanted to check with WG if it's acceptable 23:52:56 Rossen_: Would align-stretch work the same or have same behavior in this case? 23:53:11 fantasai: Don't remember which align-stretch does 23:53:39 Rossen_: My understanding is align-stretch should behave same as if fixed height which should then have the same expected behavior for a-r, wouldn't it? 23:54:00 Rossen_: Not sure if this is related to position spec 23:55:33 fantasai: align-stretch takes prescience over a-r. Neight is stretch, width and heigh auto, but can stretch b/c top:- bottom:0. Take that as a definite height where we can calculate the width 23:55:44 s/prescience/precedence/ 23:55:58 s/Neight/If neither/ 23:56:15 Rossen_: Back to top and bottom 0. Other opinions or reasons why the aspect-ratio shouldn't behave this way? 23:56:31 cbiesinger: On behalf of Chrome I support 23:56:57 Rossen_: This isn't just about top:0 bottom:0 it would be same with top:10. 23:57:03 fantasai: Right. It's non-auto 23:57:14 dholbert: This is any element with an aspect ratio? 23:58:02 fantasai: Problem is we have compat requirements for images. For a replaced element it's slightly different. Replaced elements don't stretch between constrained insets and we can't change due to compat. aspect-ratio on non-replaced we figured we can do the thing that makes most sense. 23:58:27 dauwhe has joined #css 23:58:29 fantasai: Question is do we use it to resolve height or width in this case since height can come from size of containing block. 23:58:47 Rossen_: Objections or other comments? 23:59:09 RESOLVED: Accept proposal 23:59:19 Topic: end 23:59:38 Rossen_: Let's call it for today and we'll chat again next week. Thank you everyone and we'll chat on the 8th 00:00:15 Zakim, end call 00:00:15 I don't understand 'end call', Rossen_ 00:00:21 Zakim, end meeting 00:00:21 As of this point the attendees have been alisonmaher, dael, Rossen_, plinss, florian, miriam, smfr, but, webex, not, cooperating, just, yet., bkardell_, heycam, chrishtr, 00:00:24 ... jensimmons, dbaron, dholbert, cbiesinger, dino, drousso_, fantasai, tantek, chris, hober 00:00:24 RRSAgent, please draft minutes 00:00:24 I have made the request to generate https://www.w3.org/2020/07/01-css-minutes.html Zakim 00:00:26 I am happy to have been of service, Rossen_; please remember to excuse RRSAgent. Goodbye 00:00:30 Zakim has left #css 01:35:35 drousso has joined #css 01:59:20 dauwhe has joined #css 02:10:08 dauwhe has joined #css 02:41:06 Tavmjong has joined #css 03:29:11 drousso has joined #css 03:41:58 Tavmjong has joined #css 04:11:00 dauwhe has joined #css 04:21:49 dauwhe has joined #css 04:38:18 drousso has joined #css 04:45:34 rego has joined #css 06:22:41 dauwhe has joined #css 06:33:29 dauwhe has joined #css 08:34:23 dauwhe has joined #css 08:45:10 dauwhe has joined #css 10:46:02 dauwhe has joined #css 10:56:50 dauwhe has joined #css 11:06:52 dauwhe has joined #css 11:24:51 Tavmjong has joined #css 11:59:22 Karen has joined #css 12:02:30 plh has joined #css 12:47:57 Tavmjong has joined #css 13:49:41 Karen has joined #css 13:53:25 projector has joined #css 13:53:55 leaverou has joined #css 13:54:25 Rossen has joined #css 13:54:56 shans has joined #css 13:55:26 sylvaing has joined #css 14:13:07 marie has left #css 14:51:17 Karen has joined #css 14:58:14 dauwhe has joined #css 15:00:01 nigel has joined #css 15:49:16 Karen has joined #css 15:50:45 Karen has joined #css 15:57:19 Karen has joined #css 16:33:18 nigel has joined #css 18:02:00 drousso has joined #css 18:06:41 Tavmjong has joined #css 18:21:40 dauwhe has joined #css 19:06:26 drousso has joined #css 20:06:04 jensimmons has joined #css 20:08:26 projector has joined #css 20:08:57 leaverou has joined #css 20:09:27 Rossen has joined #css 20:09:57 shans has joined #css 20:10:27 sylvaing has joined #css 21:03:33 Karen_ has joined #css 22:03:11 bkardell_ has joined #css 22:22:46 jensimmons has joined #css 22:24:22 Tavmjong has joined #css 01:25:28 Tavmjong has joined #css 01:45:07 dauwhe has joined #css 03:26:08 dauwhe has joined #css 04:42:04 rego has joined #css 05:45:26 dauwhe has joined #css 06:49:30 dauwhe has joined #css 08:53:43 dauwhe has joined #css 09:10:57 ankh___ has joined #css 10:39:32 Karen has joined #css 11:39:52 Tavmjong has joined #css 13:07:45 dauwhe has joined #css 13:10:30 innovati has joined #css 16:37:03 FYI, I finally got frustrated about having to keep deleting the calendar entry for the time we don't use for CSS on the first week of the month and hand-edited my calendar entry for it to be for the 2nd, 3rd, 4th, and 5th Wednesday of the month. (If you're interested, RRULE:FREQ=MONTHLY;INTERVAL=1;BYDAY=2WE,3WE,4WE,5WE.) 18:10:57 dauwhe has joined #css 18:23:14 dauwhe has joined #css 18:26:45 Tavmjong has joined #css 18:33:45 rawtext has joined #css 18:41:05 rawtext has joined #css 18:45:46 wow, https://github.com/triple-underscore/triple-underscore.github.io seems to maintain Japanese translations of a lot of web specs, and keep them up-to-date. (Just saw it thanks to a github notification since a commit message mentioned my username...) 18:51:51 rawtext has joined #css 18:55:58 rawtext has joined #css 18:56:50 jensimmons has joined #css 19:04:55 rawtext has joined #css 19:30:32 rego has joined #css 19:40:37 rawtext has joined #css 19:54:31 dauwhe has joined #css 20:14:36 rawtext has joined #css 20:30:43 rawtext has joined #css 20:35:09 rawtext has joined #css 20:39:16 rawtext has joined #css 20:45:08 rawtext has joined #css 21:19:37 drousso has joined #css 21:42:10 Tavmjong has joined #css 22:17:01 dauwhe has joined #css 22:40:31 liam has joined #css 22:42:45 Tavmjong has joined #css 23:22:49 liam has joined #css 23:43:37 Tavmjong has joined #css 23:49:37 dauwhe has joined #css 23:51:53 dauwhe has joined #css 00:10:11 dauwhe has joined #css 01:02:14 Karen has joined #css 02:23:42 dauwhe has joined #css 02:24:17 dauwhe has joined #css 02:34:36 dauwhe has joined #css 03:38:12 I wish I'd stop facepalming at nonsense in CSS2. "real computed value"?! 03:54:34 liam has joined #css 07:29:02 antonp has joined #css 09:07:20 drousso has joined #css 10:38:07 Tavmjong has joined #css 14:55:51 jensimmons has joined #css 16:47:05 Tavmjong has joined #css 17:52:22 Tavmjong has joined #css 21:49:47 Tavmjong has joined #css 21:51:07 dauwhe has joined #css 21:58:17 Tavmjong has joined #css 00:03:47 dauwhe has joined #css 00:10:26 dauwhe has joined #css 00:32:37 liam_ has joined #css 00:45:47 dauwhe has joined #css 02:02:31 dauwhe has joined #css 02:13:15 dauwhe has joined #css 03:52:19 Tavmjong has joined #css 04:14:08 dauwhe has joined #css 04:24:55 dauwhe has joined #css 04:43:14 zcorpan_ has joined #css 06:25:48 dauwhe has joined #css 06:36:35 dauwhe has joined #css 08:14:55 liam has joined #css 08:37:28 dauwhe has joined #css 08:48:16 dauwhe has joined #css 10:16:11 projector has joined #css 10:16:42 leaverou has joined #css 10:17:12 Rossen has joined #css 10:17:42 shans has joined #css 10:18:13 sylvaing has joined #css 10:21:56 Tavmjong has joined #css 10:49:08 dauwhe has joined #css 10:50:55 liam has joined #css 10:59:56 dauwhe has joined #css 13:00:49 dauwhe has joined #css 13:11:37 dauwhe has joined #css 14:17:48 Tavmjong has joined #css 14:30:22 dauwhe has joined #css 14:32:06 dauwhe has joined #css 18:37:05 dauwhe has joined #css 19:40:24 Tavmjong has joined #css 20:02:06 projector has joined #css 20:02:36 leaverou has joined #css 20:03:06 Rossen has joined #css 20:03:36 shans has joined #css 20:04:07 sylvaing has joined #css 22:11:12 Tavmjong has joined #css 23:46:12 innovati has joined #css 01:20:46 projector has joined #css 01:21:16 leaverou has joined #css 01:21:47 Rossen has joined #css 01:22:17 shans has joined #css 01:22:47 sylvaing has joined #css 02:04:52 Karen has joined #css 03:16:03 dauwhe has joined #css 03:58:08 dauwhe has joined #css 04:47:10 rego has joined #css 06:24:53 Karen has joined #css 06:39:00 dauwhe has joined #css 08:57:00 Ms2ger has joined #css 09:58:25 zcorpan has joined #css 10:30:25 zcorpan has joined #css 10:39:48 dauwhe has joined #css 10:51:31 Tavmjong has joined #css 11:42:07 dauwhe has joined #css 11:43:00 zcorpan has joined #css 11:43:29 rq has joined #css 11:45:29 rq_ has joined #css 11:54:08 zcorpan has joined #css 11:55:15 zcorpan has joined #css 11:57:36 zcorpan_ has joined #css 12:02:28 antonp has joined #css 12:40:22 dauwhe has joined #css 13:36:21 Karen has joined #css 15:15:44 dauwhe_ has joined #css 15:36:36 aja has joined #css 15:54:23 TabAtkins, have a few minutes? 16:01:45 myles has joined #css 16:02:17 jensimmons has joined #css 16:03:44 aja: what up? 16:05:19 TabAtkins, have something I'd like your input on before I file issues/bugs: https://codepen.io/a-ja/pen/LYGdPez 16:06:48 leaverou may be interested as well ^ 16:11:05 Karen has joined #css 16:14:04 TabAtkins, thinking of filing browser bugs/issues, but what I really wanted from you was whether you think spec language change might be appropriate? e.g. adding a SHOULD 16:18:22 Just checking - what's the color of HighlightText you're seeing? I'm getting black on my chromebook, so your examples are getting progressively worse for me. ^_^ 16:22:29 TabAtkins, yes, black 16:24:31 I see rgb(255, 255, 255) in Firefox, so the examples get better there 16:24:38 Hm, still confused then. I do see that my Highlight is lighter than you're claiming the Chrome/Gecko color should be, but still, the "minimum" and "better" examples are putting progressively darker blues under the black, and you're claiming it's *better*? 16:24:41 Ah ok 16:25:39 Ok, so you should probably not group Chrome and Gecko together in that example, since our opposite Highlight colors have dramatically different effects and make the example impossible to puzzle out on Chrome. ^_^ 16:25:46 But back to your main question. 16:25:50 TabAtkins, 1 blue bit darker passes AA, better passes AAA 16:26:12 Yes, I think a SHOULD is appropriate for color pairs, with the possible exception of GrayText against Canvas. 16:27:18 TabAtkins, k...that's what I kinda figured, tks 16:30:17 will add note that my testing was on chromium/ff on win10...and taking someone else's word for webkit 16:33:32 TabAtkins, fwiw, think a AAA recommendation for link colors vs canvas wouldn't fly (looks too garish in dark mode) 16:34:21 kk, so for whatever reason, on a Chromebook running 83, HighlightText is a significantly lighter blue than the rgb() you have commented in the CSS, so it should definitely pass even without rounding errors. ^_^ 16:34:25 Ah that's probably true, yeah. 16:35:13 you mean Highlight? 16:36:08 HighlightText was always black anywhere I checked 16:36:42 Note that Highlight and HighlightText are supposed to match the OS settings 16:36:53 and that they're customizable by the user 16:37:00 in many OSes 16:40:03 fantasai, if only used for :selection, no big deal, IMHO. but it's getting used on form controls w/small text, too...think that matters more 16:40:55 aja: We can spec that if the UA is using colors *other* than the OS or user-chosen colors they should have AAA contrast 16:40:59 e.g. on combobox/listbox option:checked 16:41:21 aja: but as they're defined to match the OS, we can't also define them to have a particular contrast ratio 16:43:23 fantasai, think matching OS would qualify as forced-colors? 16:43:50 aja: no 16:44:04 forced colors is about forcing colors other than the system colors to match the system colors 16:44:33 TabAtkins: filed a minor PR against the Highlight/HighlightText description btw https://github.com/w3c/csswg-drafts/pull/5290/files 16:44:59 looking 16:45:12 aja: Sorry, yes, I meant Highlight 16:55:23 TabAtkins, wonder if on Chromebook it's using alpha, ala webkit?? odd 17:01:29 Karen has joined #css 17:03:26 fantasai, what do you think of SHOULD match AAA, and MUST pass AA (with the *other* caveat, of course) 17:04:17 think that'd cover the link colors v canvas garishness case 17:05:00 "if the UA is choosing the colors independently of OS or user settings"? 17:05:39 yes, the *other* caveat in your earlier comment 17:09:03 while you're at it, please can you add form fields for colour contrast? 17:11:31 Tavmjong has joined #css 17:12:48 gsnedders has joined #css 17:13:00 liam: what? 17:13:54 aja: Nope, no transparency. 17:14:43 hi fantasai! i just get fed up of black text on a black background in forms in dark mode 17:15:07 It's just #b5d5ff 17:15:08 liam, know the concern. perhaps easier to address for authors wanting accessibly-colored forms once standardized pseudo-element names get implemented, ala Open-UI. right now it's a mess. 17:15:09 well, sure but what does it mean "add form fields for colour contrast"? 17:15:21 (most oftem from a color:black !important; or whatever) 17:16:00 if speccing min contrast for highlighted text, another place where min contrast is useful and often a problem is in textarea & input 17:16:31 (both with highlighted and non-highlighted text) 17:16:53 liam: We're talking about min contrast of the system color pairs; insofar as they use the system colors, they'll be affected too; if they don't, what we're discussing won't affect them. 17:17:02 ok 17:17:17 probs with Field vs FieldText, too? sigh 17:17:31 but also liam, I repeat fantasai's question asking what you actually mean with "form fields for color contrast" 17:18:15 yeah, the problem seem to be browser using a system colour for the form elements (textarea let's say) and allowing the author stylesheet to override foreground colour, but the author didn't think of also specifying background colour 17:18:36 Yeah, we can't fix authors writing bad code, short of activating forced-colors mode 17:19:21 no, but a forced-contrast mode might help, i'm not sure, when system colours are used, which is why it seemed possible relevent, sorry about not being clear 17:20:25 liam: so ... like a 'force' option to forced-color-adjust? 17:20:26 https://www.w3.org/TR/css-color-adjust-1/#forced-color-adjust-prop 17:21:08 Would be interesting to have an option that *just* forces colors when *one* of a bg/fg pair are system colors, to make them both system colors instead 17:21:19 hahaha 17:21:27 forced-color-adjust: fix-stupid 17:21:28 TabAtkins, yes 17:21:31 lol 17:21:37 having to do all this kinda thing is bad news: color:var(--FieldText, FieldText); background:var(--Field, Field); 17:22:25 aja: Why would you do that, tho? That's only necessary if you don't know whether the --FieldText property will be defined on the element. 17:22:27 fantasai: forced-color-adjust: do-what-i-mean-not-what-i-coded; 17:27:21 fantasai, --Field and --FieldText so author can ensure proper contrast (cuz you can't trust system colors to be contrasty enough), Field and FieldText for when you can't (forced-color mode)...seems to WFM 17:29:26 i doubt many authors would do it though. 17:29:47 then again, still a mess of different pseudo-elements to discover. really hard for authors 17:30:55 right, for sure. 17:46:55 maybe a :root mode switch to say 1)leave system colors alone(default), or 2) leave system colors alone unless they're not contrasty enough, in which case force them to be. should be doable once some of the color-5 functions exist, might rely on LCH implementations first 17:47:19 liam has joined #css 17:48:09 dunno, brainstorming 17:50:43 maybe 2)force to AA if necessary, 3)force to AAA if necessary 17:52:42 better, but still not a11y by default 19:13:15 dauwhe has joined #css 19:14:22 dauwhe has joined #css 19:30:55 Ms2ger has joined #css 19:39:21 Karen has joined #css 20:15:01 Tavmjong has joined #css 21:29:19 Tavmjong has joined #css 21:37:39 dauwhe has joined #css 22:49:34 dauwhe has joined #css 23:19:09 Karen has joined #css 00:15:25 Tavmjong has joined #css 00:27:43 aja: That should just be handled by user settings. 00:30:07 Tavmjong has joined #css 00:36:16 fantasai, if they're truly user settings, I agree...always respect user settings! 00:36:52 I'm saying if you want something the other than the OS default, then you can make that change in user settings 00:37:42 no way to disguish between them 00:43:07 right now, even with no author stylesheet, no way for a page with various form elements to pass AA much less AAA...due to use of highlight/highlighttext in UA sheets. to pass need hundreds of line of author CSS. 00:43:32 perhaps *slight* exageration, but still. 00:45:43 That's a problem with the OS's accessibility settings, then 00:48:06 true....but resulting in authoring nightmare. and required by govt for most businesses 00:48:06 Tavmjong has joined #css 00:49:02 Wouldn't the same requirements apply to the OS maker? 00:49:33 tell it to your auditor! :) 00:49:57 it would, indeed 00:52:24 fwiw, was reading some post-WCAG2.1 "Silver" docs of techniques. One "sufficient" one says just go CSS-naked (paraphrasing, of course).. 00:52:48 fail! 01:09:13 am reminded to update my local test...to override highlight/highlighttext on a half-dozen or so forms pseudo-elements (mostly on spinboxes).) 01:45:28 aja, sorry, i didn't mean to derail conversation about selections, but felt forms (and selections in them!) to be relevant to it. but, i've just been working on improving the accessibility of a conference's web site and fed up of wrong advice to authors, too! 01:49:12 liam, have workarounds for inputs, still trying to finagle around select option, though 01:49:53 i'd rather see UAs changed to disallow low contrast combinations if possible, i think! 01:50:10 since so few authors even of big sites get this remotely close to right 01:50:11 yeah 01:55:11 fwiw, touch target sizes should be easier, too 02:35:29 Karen has joined #css 03:30:16 true