15:52:35 RRSAgent has joined #css 15:52:35 logging to https://www.w3.org/2020/08/26-css-irc 15:52:37 RRSAgent, make logs Public 15:52:38 Meeting: Cascading Style Sheets (CSS) Working Group Teleconference 15:54:30 AmeliaBR has joined #css 15:58:18 present+ 15:58:24 ScribeNick: dael 15:58:52 present+ 16:00:05 jfkthame has joined #css 16:00:25 masonfreed has joined #css 16:00:28 present+ 16:00:32 present+ 16:01:07 Guest60 has joined #css 16:01:14 dholbert has joined #css 16:01:23 present+ 16:01:27 Rossen_ has joined #css 16:01:30 present+ 16:01:30 alisonmaher has joined #css 16:01:35 present+ 16:01:35 present+ 16:01:44 present+ 16:01:51 astearns: We'll give people another minute to call in 16:02:07 present+ 16:02:13 present+ 16:02:18 present+ 16:02:55 present+ 16:02:58 present+ 16:03:08 astearns: I think we have enough to go 16:03:13 present+ 16:03:15 astearns: Does anyone have any adjustments to the agenda? 16:03:25 Topic: Allow specifying the "accent color" of a form control element 16:03:28 myles has joined #css 16:03:35 github: https://github.com/w3c/csswg-drafts/issues/5187 16:03:56 astearns: Discussed last week, bringing it up first this week. I'm guessing to give masonfreed a chance to give an update 16:04:19 https://github.com/mfreed7/accent-color/blob/master/proposal.md 16:04:19 masonfreed: I heard a few action items. Main was people wanted examples of existing form controls across browser/platform/time perioeds 16:04:27 masonfreed: Added to proposal doc ^ 16:04:33 masonfreed: You can see 5 different form controls 16:04:40 masonfreed: There were several questions discussed on thread 16:04:48 present+ 16:05:04 GameMaker has joined #css 16:05:11 present+ 16:05:16 masonfreed: One was radio button. Question was on Chrome latest there's a large center blue dot on white, rest are white on blue. Q is doesn't that argue for single color and allow platform to decide. 16:05:25 masonfreed: My view is no if color is spec we should follow 16:05:34 masonfreed: Similar for gradients, what does accent color do. 16:05:38 present+ 16:05:41 present+ 16:06:00 masonfreed: My view that is up to impl but try and respect accent color. Replace graident with flat fill or integrate into gradient into whatever way makes sense. 16:06:23 masonfreed: Only other open was back to the amount of power to open w/ API. Single color or more specified with multiple colors. 16:06:34 masonfreed: That's all I heard on the thread. Can open for discussion. 16:06:46 ack fantasai 16:07:10 fantasai: Based on what I've seen starting with one color makes sense since not much evidence of multiple. Figuring out how 2 colors would work together is complicated. 16:07:18 q? 16:07:21 q+ 16:07:50 +1 to fantasai's points 16:07:52 fantasai: In terms of handling gradients if you set parent none everything is flat. If none is not set try and match platform convention. We can encourage use of accent color but I don't think that should disable platform styling 16:08:22 present+ 16:08:34 present+ 16:08:36 masonfreed: single vs 2 color there are a number of controls in proposal. Even the radio button there are at least 2 colors. If you only open one I would say you have to specify which part you control which leaves other uncontroled. Devs want both controls on the thread 16:09:09 present+ myles 16:09:24 masonfreed: appearance:none is a big hammer. It turns off all styling. Radio becomes an empty div. That is a complaint that brought us to this proposal. radio and checkbox you do appearance:none and have to rebuild everything. This proposal was to give some control without having to rebuild. 16:09:27 ack gregwhitworth 16:09:50 present+ 16:10:17 gregwhitworth: I was initially going to +1 to fantasai in regards to spirit but heard masonfreed on complexity. Maybe have multi color but don't play into gradients. Where we leverage primary|contrast proposal we provide one color and allow UA to do what's best to keep spirit of spec 16:10:18 smfr has joined #css 16:10:39 masonfreed: You mean take current proposal and chop of contrasting color but keep spec as to where first color should apply? 16:10:49 gregwhitworth: No, this started on handling of gradients, correct? 16:10:54 masonfreed: And radio. 16:11:18 gregwhitworth: Was thinking same accent color applied within mac on focus. That's where I was using as use case to have gradients in future. Didn't want to discount that. 16:11:27 bradk has joined #css 16:11:33 gregwhitworth: Contrasting and primary I would keep. Too many scenarios where need to exist. 16:12:00 gregwhitworth: Goes into try to follow this and we don't make this normative. So Safari says bg is primary stay true to author expectation is what you recommend. 16:12:04 present+ 16:12:38 gregwhitworth: Radio, I could see Safari say primary is contrast in Chrome. To that end I don't know how you coalesce without lopping them off and hinder feature or get much more prescriptive. 16:12:38 present+ 16:12:43 gregwhitworth: Basically, I don't know 16:12:49 ack fantasai 16:12:49 fantasai, you wanted to talk about primary/contrasting 16:13:04 fantasai: Thing with primary vs contrast the way accent color is used varies a lot. Sometimes fg sometimes bg. 16:13:15 q 16:13:20 q+ 16:13:35 fantasai: They are sometimes both. Back to aqua there was a solid color highlight with bg color text b/c it's a dark color. vs gradient and lighter gradient is fg on top 16:13:55 fantasai: If intention is set accent colors UA should auto generate variations on color and match against fg or bg as appropriate. 16:14:13 fantasai: If you are creating variations on the color the pair of colors may no longer contrast. 16:14:24 fantasai: I don't know how you would use the contrasting color in a situation like that 16:14:27 masonfreed: I see that point. 16:14:59 masonfreed: I did include some lang that UA doens't have to use exact color. That's one of the cases where you take it as input to the algo but don't have to use exactly that if it doesn't make sense to the gradient. 16:15:01 ack Rossen_ 16:15:51 Rossen_: I'm hearing strong dev need that has been sampled over long time. And a good example of document that motivates and explains why we need and how to go about it. I hope all features have this level of detail and consideration when we bring them 16:16:22 q+ 16:16:35 Rossen_: Question is where do we go from here. Discussed over a few weeks. I do see pushback for various reasons. Continuing forward I'm trying to tease out obsticle here. What's the obsticle or are we pushing back just for sake of pushing back 16:16:36 ack hober 16:17:11 hober: Trying to answer. For me I generally like being able to spec accent color. Very important we preserve browser ability to adopt different designs in future and to deploy on different platforms and meet conventions. 16:17:29 q+ 16:17:39 hober: Pushing back to preserve impl flexibility to match platform conventions. Platforms have color conventions and want to be able to use those. 16:17:47 q+ 16:17:53 q- 16:17:53 q+ 16:18:33 Rossen_: How is this different than what we do with appearance today? The cat is out of bag when introduced webkit-appearance:none. Agree in principle to preserve browser innovation but I'm not sure taking away this flexibility is warrented here. Can you expand? 16:18:41 hober: Don't udnerstand your question 16:18:59 masonfreed: I understand what you asked hober but what do you think in proposal is constraining the future developments? 16:19:15 hober: Basic, like what if browser wants to use accent for checkmark, not background of checkbox 16:19:40 masonfreed: That's why I kept it non-normative. It's guidance but not a constraint. If that makes more sense with a new design there's a good reason so go ahead. 16:20:02 hober: Okay, gregwhitworth had said earlier if you didn't want to use accent in where it's spec you shouldn't use at all. Maybe previous call. That's different? 16:20:30 masonfreed: Current lang is accent colors are spec, guidance for what supposed to mean, but tried to thread needle between constrained and open. That's the intention. Open to clarify language 16:20:43 "However, the 16:20:43 intention is that if the same or similar accent parts exist on a given form 16:20:43 element, it should be associated with the "primary" or "contrasting" colors in the 16:20:43 same way across user agents." 16:20:45 fantasai: We need to clarify if that's intent. Text says should be same across all browsers 16:21:10 astearns: Acceptable to put intent behind text in spec. Be explicit about attempt and then put normative text so people can interpret. 16:21:38 fantasai: Disagree accent color should be on same pieces across browsers. Intent is use as appropriate, not find and accent color and try and match web os convention. 16:21:48 masonfreed: That sounds like a core disagreement we should discuss. 16:21:51 +1 again to fantasai :) 16:21:55 yep 16:22:00 s/find and/use/ 16:22:43 masonfreed: What I was going for is if there's a very good reason, like a brand new checkbox with a completely new thing and no way to apply prior history you shouldn't be constrained. But if we're all building a box with a check we should try and be the same so dev can expect similar across browsers 16:22:58 masonfreed: In document all checkboxes are widely the same so we should hope impl uniformly 16:23:32 q+ 16:23:42 ack florian 16:23:45 florian: I think there's a tension in requirements. Desire if some platform has check blue and another box blue and you say make a thing pink and we can do that. But if you don't know if it goes to fg or bg it's hard to know it would lookr ight against everything else on the page. 16:23:49 hober, re: "Don't understand your question" - How is webkit-appearance:none different in terms of overriding UA native controls compared to this proposal? (besides the fact that we won't force authors to rebuild the entire kitchen around the sink) 16:24:14 florian: Current you know if it's fg or bg so you can pick other colors but at the expense of forcing the accent on a specific part. Not sure how to satisfy both parts. 16:24:15 ack gregwhitworth 16:24:20 gregwhitworth: florian hit nail on head 16:24:22 Rossen_: appearance: none is an escape hatch 16:24:42 gregwhitworth: To circle back in the proposal to masonfreed i put if it computes to auto it's the webdev saying I want OS. 16:25:06 hober: yes, and if your position is to keep anyone from escaping this hatch is a much worse optino 16:25:14 gregwhitworth: No one disagrees with hober about forward innovation. But the second someone finds interop differences it will get replaced. THat's what we see. I get it and I agree but I don't htink it's pragmatic for use. 16:25:33 Rossen_: sorry, i'm not trying to be dumb, but i don't understand what you're getting at. 16:25:59 gregwhitworth: If we say this is limited styling and you have outside of broder have accent color the outline becomes blue and my bg is blue and I won't like it. We can go that route but people will find a barrier. The second we hit that people willr eplace it 16:26:42 gregwhitworth: Worried by making this so loose people will just replace it. We can say you can spec accent color and UA will do best and hope experience is great. We can spec that and say we recommend using these 16:26:45 ack myles 16:26:48 hober: your pushback was about keeping the ability to ship UAs that can continue comply with the native platform right? 16:27:25 myles: Partially responding I don't htink that nec a bad thing. There are different classes of desire. If web author wants form control same everywhere they have tools for that. Modifying native form controls will be different on every OS. Has to have flexibility 16:27:45 q 16:27:59 Rossen_: my pushback is about making sure that browsers can change their form control designs in the future, and use the author-provided accent color(s) in ways appropriate to their new form control designs. 16:28:11 florian: Design as is has flexibility, but nudges you in a specific direction. If you say accent color blue and you expect a blue check you'd see that and it's fine, but the background is blue on another and you can't see it against your blue bg then you can't see it. 16:28:37 q 16:28:38 florian: Having a nudge to say it's this part it gives you more interop to match with the rest of the page. I would be tempted to say spec as proposed probably gets the bias right 16:29:50 fantasai: I agree with myles and hober. I think if youre appearance:auto goal should be match platform. One thing we can consider is to handle contrast levels instead of spec 2 colors say this if contrast with fb and this if contrast with bg. Most of time not using sep for contrast, you're matching fg or bg. 16:29:59 florian: You means spec both with expectationbrowser uses one? 16:30:00 fantasai: Yes 16:30:22 q+ 16:30:34 fantasai: And if you give 1 you give permission to browser to modify along brightness however it thinks appropriate. If you give 2 you can be more precise, but you don't get to say which part is used. 16:31:01 fantasai: If you want to do that more manually I think we need to make checkboxes more stylable generally. I don't think accent color is place to do that 16:31:07 q+ 16:31:25 zakim, close queue 16:31:25 ok, astearns, the speaker queue is closed 16:31:38 masonfreed: Can we use example from dev in thread which is the time control with glyph and bg behind the glyph? Author wanted to control the glyph and bg behind to match control. How would they achieve that with your proposal? 16:32:05 q+ 16:32:45 fantasai: I think that get's into...if there's a time icon on my control there's different ways to impl. glyph could be on tex tinput bg or on a button-looking thing. I don't know approach. They are all reasonable for platform. If author want sto control that specifically we need a model for that form control. I don't htink accent color is way to control b/c browser may not be using accent color for that icon 16:33:03 Karen has joined #css 16:33:29 masonfreed: I see that but way it is says there might or might not be a glyph. If a glyph may not have backplace. If both use contrast for glyph and accent for backplate. If we impl that author would be happy. Leaves image of glyph to UA but controls colors. 16:33:41 +1 to what fantasai said as it sounds like we need a master switch which appearance is. We should tie the two in some meaningful way and if appearance isn't adjusted we can achieve what hober myles was saying 16:33:55 I don't think it's helpful to talk about this in isolation; there are other efforts (e.g. Open UI) that will help add form control customization knobs, so the whole "if accent-color is too loose, people will use appearance: none" is a false dichotomy. 16:33:56 fantasai: But if button-like accent color is buttony part so convention would be bg of icon is accent color. Trying to say something different wouldn't work 16:34:26 +1 to masonfreed point, but there in lies the problem :) 16:34:33 masonfreed: That's what text says. if buttony the bg should be accent. And that's why you need contrast color to control the stuff on the button. Lacking the contrast color the dev would be lost and have to replace the control. 16:34:46 ack Rossen_ 16:35:50 Rossen_: To hober point earlier I agree browsers and UA should be able to differentiate or go to native conventions. Question is given that we have webkit-appearance as an escape which forces devs to complain for years b/c tired of having to use that and re-impl everything. My question is how is this better. Is this best way can do as a presentation platform? 16:36:13 Rossen_: Best we can do is make it apperance:none? Seems like should be better answer and middle ground to allow and expose these parts. 16:36:55 hober: I feel like false dicotomy. Talking about this is isolation and not in context of other prop and features. If we think about all together we can see this question is moot. I'm not saying that the only options are appearance:none or accent color. 16:37:02 hober++ 16:37:15 hober: Hoping openUI will increase customizability in a number of ways which willenable people to use more and not use escape hatch 16:37:35 s/willenable/will enable/ 16:37:39 hober: I don't see accent color as alternative but as a complement to those efforts. Platforms with accent color use somewhat similar and somewhat different. 16:38:08 hober: Accent color on the spectrum of control is advice to the browser. OpenUI exposing specific parts is more at the full toolbox where we do what dev says. 16:38:41 that last point that hober made is what I think we should explore at breakout. florian had noted he thought about this. I'll start whipping up a doc that explores this with concrete examples 16:38:49 hober: If dev wants it on a specific part of a control I'm saying use what openUI exposes for that control. Accent color is a more general feature that should be more of a hint to the UA to do the right thing. You should have the extra control which is why openUI is exciting 16:39:15 +1 to hober's multi-level model. accent-color as a hint for modifying native styling, other options for more direct piece-by-piece control. 16:39:15 hober: I think at root question misses the point. If accent color only possible option there's a point. In a world where we'll have other tools like openUI it doens't hold water 16:39:20 ack chrishtr 16:39:39 chrishtr: Summary on what I see where we can maybe make progress today. We all agree UAs shoudl have ability to create new UI types over time 16:40:00 chrishtr: I think any accent color we agree should be when possible interop in ways it applies so there isn't first mover advantage. 16:40:12 hober: thank you for elaborating - that was the answer I was hoping and looking for :) 16:40:25 chrishtr: I think spelling out non-normative text to do so will also help inmaking sure corner cases with contrast and darkmode are taken care of 16:40:58 chrishtr: accent color is good to add, make sure text does n't prevent future design, we could encourage interop, and have text that can work the corner cases 16:41:05 chrishtr: Is that a reasonable thing to resolve? 16:41:28 astearns: I think it's more than we can currently agree on in part because recommend interop isn't agreed on definition 16:41:34 I think that UAs should have ability not just ot create new UI types over time, but to alter the design of existing UI types over time and across devices and platforms 16:41:37 q+ 16:41:41 astearns: Have consensus this is good to add but details of what's normative and not is good to work out 16:41:50 fantasai++ 16:42:09 astearns: May be useful to break out current interop goals from future proofing. As we discuss it slides between what people want now and what people imagine in future. 16:42:31 astearns: Might be good to have explicit note that this could all change due to thing we haven't discovered. For current UA this is level of interop to achieve 16:42:32 Yeah, I don't agree with that either :) See above 16:42:46 masonfreed: Should I take action to futher update spec text to try and thread needle? 16:43:12 astearns: I think we should have more text to keep up and more discussion on issue. I think we could resolve this is a thing we want to add, but not other details. 16:43:21 chrishtr: Could we resolve on other two points? 16:43:32 astearns: We've already spent 45 minutes on this 16:44:10 jensimmons: Briefly I think there's a lot of reason for optimism. Desire is to make sure this will be complex enough for future rather than drag into past. I'm personally very interested in and haven't been able to be as involved as I want. 16:44:26 jensimmons: We can get somewhere great and this is hard b/c it's hard not b/c desire to not do it. 16:44:29 So far no disagreement that we should have accent-color 16:44:35 astearns: Can we resolve this is something we want to add? 16:44:41 Just disagreement on how prescriptive its definition is 16:44:43 astearns: Objections to continue to work on this? 16:45:04 RESOLVED: The group wants to add accent-color and discussion on details will continue 16:45:44 astearns: Helpful to break items into separate issues. masonfreed as you update text and look at particular items in contention if you can raise separate issue for each so we can have scoped discussion and resolution on pieces as we good may be good way to make progress. 16:45:48 masonfreed: Will do and thank you all 16:45:57 Topic: [css-cascade] Custom Cascade Layers (formerly "custom origins") 16:46:05 github: https://github.com/w3c/csswg-drafts/issues/4470 16:46:21 miriam: Take everyone through the proposal? 16:46:29 astearns: Yeah. Summary would be helpful 16:46:53 Proposal: https://gist.github.com/mirisuzanne/4224caca74a0d4be33a2b565df34b9e7 16:47:17 miriam: Starting at the top, first question is where in cascade would author custom origin layer fit. Felt it could achieve all goals as higher then specificity. Putting it above shadow dom creates additional problems so putting it between solves problems 16:47:21 zakim, open queue 16:47:21 ok, astearns, the speaker queue is open 16:47:27 miriam: Question about shadow dom at bottom of doc 16:47:37 bradk has joined #css 16:47:38 tantek has joined #css 16:47:53 miriam: Interacting with !important we suggest layers exist entirely within defined origin. They work like orgins so reverse in !important layers. 16:48:13 miriam: normal layers styles not explicit are at the top followed by named layers in order set up 16:48:20 present+ 16:48:24 miriam: Reversed in importat so unlayers are at bottom. 16:48:41 miriam: Keeps meaning and intent of !important more clear and working similar but internally 16:49:21 miriam: Talked about style attribute and suggestion is it continues to be above these layers. Have to redefine but I think has to anyway with scope being removed. Keeps style attribute like other styles. 16:50:11 miriam: Levels for managing layers; does it happen at selector or declaration or block or importing. Suggesting block similar to MQ and as with existing @rules blocks can nest. Then layering based on order of first appearance in code 16:50:34 miriam: Example reset-base components reset. reset lowest, base on top of that. Order they're first discovered is order of layering 16:51:09 miriam: In terms of ordering layers there's a way to cheat and declare them all. Could be with empty blocks but also proposing layers shorthand to let you define. That's above imports 16:51:58 miriam: Suggesting an import syntax. Way to name and group everything inside a file. Helps with encapsulation. Bootstrap exposes layers but we can create a wrapping alyer that keeps all boostrap inside. Nesting doesn't impact order, just naming 16:52:13 miriam: Various discussion on syntax and if it builds on @import or unique 16:52:44 miriam: Nesting doesn't change order, jsut groups. If wrapping layer has name can interact with nested layers by calling that with some syntax for getting to layers within layers. 16:53:01 bkardell_ has joined #css 16:53:13 miriam: By allowing unnamed layers allow a tool like bootstrap to have private layers. Wrap in unnamed layer and removes ability to call them later. 16:53:27 present+ 16:53:28 miriam: More detail in the proposal 16:54:00 miriam: Migration path since this is between specificity and style this can be mimiced with specifiity so clearest way to show is list of IDs. 16:54:04 bradk has joined #css 16:54:19 miriam: Can be more clean using IS to get specificity of IDs. Path to polyfill 16:55:01 miriam: Weakness on refactor use case. Since layers reverse in !import not idea but doesn't seem changes are extensive. Have to do something with !import styles in legacy to make sure they don't override in new. Not a perfect solution but works with a little manipulation 16:55:30 miriam: Questions from thread, does load order of stylesheet matter so if a sheet is lazyload but lazyload first does it matter? no. 16:55:50 miriam: Can you nest layer blocks, yes. Specificity is unchanged inside layers. Just subsuming it. 16:56:10 miriam: If stylesheet is in multi layers it's in multi which is true currently 16:56:33 miriam: Best syntax is open question still. Are unnamed layers feature or a problem? Allow hiding which is risky but powerful. 16:56:43 miriam: Way to revert layers? Do we want that? 16:57:07 q+ 16:57:14 miriam: How does light dom layers affect shadow dom layers with same name. Complex but think a wrapper may be able to resolve that powerfully 16:57:16 ack emilio 16:57:40 emilio: regarding shadow dom; how does it matter? rules in different trees are sorted diff on top of specificity. I don't know how that is a problem. 16:57:53 miriam: Comes into play b/c ordering of names determining the layering order 16:58:15 miriam: If there are layers inside shadow dom named main and base and layers outside named base and main which order are they used? 16:58:17 Karen has joined #css 16:58:34 +1 to scoping layers to a shadow context 16:58:39 +1 16:58:55 emilio: I see. I think layers should scope to a tree. Inside a tree is where you sort by specificity. Doens't make sense to me to have names interact between trees. I think that's wha tyou prop with anon. 16:59:09 miriam: Could be interesting to let you access layers inside a shadow dom. 16:59:21 emilio: Why would you want? But does seem different discussion 16:59:41 astearns: My prop is get this proposal into the spec and start opening issues to dig through 16:59:50 astearns: Objections to move this proposal into the spec? 16:59:58 RESOLVED: move this proposal into the spec 17:00:20 astearns: Doesn't mean we're done, means we open separate issues to discuss each bit instead of whole. Thanks so much miriam for putting this together. 17:00:31 topic: publishing 17:00:40 fantasai: Can I publish new WD of inline layour? 17:00:44 astearns: Objections? 17:00:45 +1 17:00:52 RESOLVED: publish new WD of CSS Inline 17:00:55 yay! 17:00:58 Topic: end 17:01:07 astearns: Thanks everyone for calling in 17:01:18 bkardell_: Please reply to the email about a MathML meeting! 17:01:50 I have made the request to generate https://www.w3.org/2020/08/26-css-minutes.html fantasai 17:02:01 dauwhe what? 17:02:36 zakim, end meeting 17:02:36 As of this point the attendees have been dael, dauwhe, miriam, rachelandrew, jensimmons, dholbert, alisonmaher, Rossen_, TabAtkins, chrishtr, florian, emilio, jfkthame, 17:02:39 ... melanierichards, dandclark, fantasai, GameMaker, argyle, gregwhitworth, plinss, hober, myles, oriol, bradk, AmeliaBR, smfr, tantek, bkardell_ 17:02:39 RRSAgent, please draft minutes 17:02:39 I have made the request to generate https://www.w3.org/2020/08/26-css-minutes.html Zakim 17:02:41 I am happy to have been of service, astearns; please remember to excuse RRSAgent. Goodbye 17:02:45 Zakim has left #css 17:13:21 faceless2 has joined #css 17:52:38 masonfreed fantasai hober florian chrishtr I spun up a doc that I hope captures my thoughts well enough about trying to solve the holistic issue that Florian fantasai and hober presented. I've tried to build off of a suggestion from florian and fantasai but also discuss how this (very rough proposal) can help accent-color discussion: https://docs.google.com/document/d/1LEkDvTrhZuediHfyg6TSAQpPFTX0wMiaLueZhxjC2PQ/edit?usp=sharing 17:52:55 of course - anyone else can provide comments as well 17:53:12 I'll link to it in the GH issue as well 18:39:08 jess has joined #css 19:11:32 Jemma has joined #css 19:48:30 Guest60 has joined #css 23:32:18 Guest60 has joined #css 23:44:07 plh has joined #css 23:57:47 liam has joined #css