15:56:21 RRSAgent has joined #css 15:56:21 logging to https://www.w3.org/2020/09/23-css-irc 15:56:23 RRSAgent, make logs Public 15:56:24 Meeting: Cascading Style Sheets (CSS) Working Group Teleconference 15:56:43 masonfreed has joined #css 15:58:19 present+ 15:58:23 ScribeNick: dael 15:58:23 regrets+ 15:58:48 present+ 15:59:09 aja has joined #css 15:59:45 present+ 16:00:25 drousso has joined #css 16:00:50 futhark has joined #css 16:00:51 dlibby has joined #css 16:00:55 present+ 16:00:59 present+ 16:01:02 present+ 16:01:11 alisonmaher has joined #css 16:01:15 present+ 16:01:16 present+ 16:01:20 astearns: We'llw ait a minute or two for more people to join 16:01:21 zhengxu has joined #css 16:01:24 present+ 16:01:29 chris has joined #css 16:01:31 present+ 16:01:35 present+ 16:01:56 present+ 16:02:00 Guest60 has joined #css 16:02:07 jfkthame has joined #css 16:02:09 GameMaker has joined #css 16:02:14 present+ 16:02:16 present+ 16:02:20 present+ 16:02:29 present+ 16:02:51 present+ 16:03:34 dholbert has joined #css 16:03:46 astearns: I think we have enought o start 16:04:00 astearns: One change to the agenda is not talk about item 1 since we discussed last week. 16:04:21 astearns: GH thread is long and we said last week we'd wait for it to be agenda+ again 16:04:36 smfr has joined #css 16:04:41 chris: Looks like we're sort of resolving but let's give another week. Unless jfkthame joined for this 16:04:42 present+ 16:04:53 jfkthame: Partly but happy to leave another week 16:04:58 astearns: Any other changes? 16:05:07 Topic: [css-scoping] Consider aligning ::slotted() for fallback content with implementations 16:05:07 present+ 16:05:15 github: https://github.com/w3c/csswg-drafts/issues/5482 16:05:18 present+ 16:06:09 rune: Case is none of browsers impl spec. Spec says fallback should be styled by ::slotted() but all browsers style elements which are slotted following assigned slot chain so you can get not just first slot scope but if child of shadow host it's flattened to next scope. 16:06:31 rune: Question is if we should change spec to match impl or if we should try to agree all impl should move to what spec says. 16:06:37 present+ 16:07:06 rune: Started as a bug reported by Salesforce. Bug in corner case in WK which makes Salesforce think they impl incorrectly, but mostly in agreement with Blink and WK. 16:07:36 rune: First level of slotting possible to style with a normal child selector on the slot. If you want to style the fallback in a nested slotting that's currently not possible. 16:07:37 present+ 16:08:10 rune: Talked to polymer team at Google and people working on web components and they think should stick with current. Worried this has web compat concerns if we shift to match spec 16:08:26 una has joined #css 16:08:30 gregwhitworth: As I said in GH I'd like to understand what compat they're worried about. Is it their own specific compat? 16:08:33 present+ 16:08:44 rune: I don't think they have specific cases. Worried in general there is content that will break 16:09:00 gregwhitworth: Not sure why Polymer that's a component library...i'm confused. 16:09:07 rune: Need to check again 16:09:57 gregwhitworth: Chrome status data it's low in utilization. Part of me feels the scenario you outlined is not unheard of. My expectation...I would phrase do you match spec now or do we come up with another method that enables that use case? 16:10:26 gregwhitworth: The use case is not invalid. Browsers aren't impl to support it. We can fix by browsers match spec or we add new functionality to ::slotted() 16:10:28 q+ 16:10:33 q+ 16:10:52 rune: Most common use case is style fallback in same scope where we have a solution. this is case of slot child of shadow host which slotted into a different scope. 16:11:05 rune: Possibility to have syntax to target the reslotted as fallback. 16:11:30 oriol has joined #css 16:11:45 rune: I don't think we would like to change Blink impl unless there's a plan to change in all browsers. I saw WK didn't have immediate plans to do anything about it. Not sure if anyone from WK has specific thoughts or if it's just low priority 16:11:54 ack TabAtkins 16:11:54 smfr: I don't know status, guessing low priority for us 16:12:04 present+ 16:12:54 TabAtkins: As I put in comment late in the bug the fact that spec says the selector passed to ::slotted() should match fallback content as well as actual slotted is more accidental. Easiest way to spec what I wanted. I don't have opinion on one way or other. Weak behavior that current browser is probably right b/c usually want fallback styled diffeerently. 16:13:22 lol 16:13:52 TabAtkins: I'm fine with browsers keeping current. I found on investigation that how spec is written I don't think does what we want. Everyone is doing some funky I think you know what I mean behavior. The algo in the spec if you have nested shadow roots so slot going into light dom as written that doesn't matter for ::slotted() and it just sees slot children 16:14:06 TabAtkins: Apparently works in Safari but Safari styles actual children? Confused 16:14:24 myles has joined #css 16:14:34 rune: Bug is Safari is they match the slot which is not what's in spec. In Salesforce they styled the color and in Safari targetted the slot. If they set hte border wouldn't have worked. 16:14:45 TabAtkins: GOt it. I thought border styles also applied but if they don't that's fine. 16:14:55 rune: Behavior in Safari is corner case 16:14:59 present+ myles 16:15:13 TabAtkins: Find slottables is you find the slot elements themselves 16:15:32 rune: Flattening in HTML collapses all the slots. Only thing you style is the elements. Can't style slots themselves 16:15:47 TabAtkins: I'm pretty sure that's wrong. It's want I wanted, but not what I wrote. 16:16:00 TabAtkins: I would like to change to match current Chrome and FF behavior. I support that. 16:16:08 ack emilio 16:16:53 https://drafts.csswg.org/css-scoping/#slotted-pseudo Or hell, maybe I did write it correctly; it does say "assigned, after flattening", and links over to the "find flattened slotables" algo. 16:17:01 emilio: Going to say along lines of TabAtkins opinion. Regardless of which way you go if you want one or the other behavior you need to work around it. If you want fallback and sloted identical style you need to spec 2 selectors. If style differently you need to add a bunch of rules which is tricky for specificity. 16:17:12 smfr: https://bugs.webkit.org/show_bug.cgi?id=169948 16:17:44 emilio: As far as I can tell only thing you can't do in FF and Chrome is style fallback of nested slots. That doesn't seem like something a lot of people would want to do b/c don't know dom hierarchy of nested slot. Could be wrong. 16:18:05 rune: Share understanding with emilio. You're correct about case where you cannot targer 16:18:23 emilio: Like current b/c if you want style and slotted children the same it's way easier to do than if we impl what spec says. 16:18:59 TabAtkins: I prop we resolve to change the spec so fallback content are not part of content matched by ::slotted() to have spec match current Chrome and FF behavior 16:19:07 TabAtkins: Does that work? 16:19:41 gregwhitworth: Addendum request; I would love some examples about here's what flattening does. I understand that's WHATWG but examples in our spec as to what happened 16:19:47 TabAtkins: I agree, could use examples 16:19:57 gregwhitworth: If we can defautl style the default content it works for us 16:20:16 astearns: Prop: change the spec to match Chrome and Gecko behavior so fallback content is not matched by ::slotted() 16:20:31 rune: Noted Safari is mostly correct. It is mostly aligned 16:20:37 astearns: Yeah, it's the edge case 16:20:46 gregwhitworth: Yeah, it's that one bug 16:21:01 RESOLVED: change the spec to match current web behavior so fallback content is not matched by ::slotted() 16:21:06 astearns: Obj to add more examples? 16:21:14 RESOLVED: Add more examples to this section of the spec 16:21:40 astearns: If there is a further use case for finding some way to have a style that matches slotted and fallback content we can add that in the future, but not necessary right now 16:21:42 TabAtkins: umhum 16:21:47 rune: Need tests 16:22:04 rune: When I changed impl in Chrome I didn't fail any tests so we need more 16:22:15 emilio: I think the tests are for what should match but not for waht should not 16:22:30 gregwhitworth: Leo on our side is good with tests and I can loop him in if you need help on adding tests 16:22:42 Topic: [accent-color] Should interoperability be a goal for the `accent-color` spec? 16:22:50 github: https://github.com/w3c/csswg-drafts/issues/5480 16:22:57 https://github.com/mfreed7/accent-color/blob/master/proposal.md#motivation-and-intent 16:23:15 masonfreed: Heard 2 things from last time. One is ^ to add motivation and intent to help interpret written spec. I wrote that. 16:23:30 AmeliaBR has joined #css 16:23:39 masonfreed: tl;dr is it's to provide a compromise between interop and not constraining browser impl. 16:24:09 masonfreed: Today is interop question. Are we going for interop? It's fundamental. Depending on your answer the spec changes. Should it be same across or hint to browsers? 16:24:22 masonfreed: My opinion is useful either way but lose a lot if don't strive for interop. 16:25:15 masonfreed: 2 reasons. 1 is not easily usable by devs without browser sniffing. Could also cause a11y and contrast issues if different expectation as to where the color goes. blue background, white accent for checkbox and you assume that's the background. If browser colors the check white you have contrast problems. 16:25:59 masonfreed: I started this with the idea of a single color and went through how it works for each control. Realized it's hard to use without language on how it's used for all controls. Helpful to look at examples section 16:26:12 masonfreed: Question today is should accent color be interoperable. 16:26:52 myles: Background concern is being able to match platform form controls is valuable. Some browsers system framework needs to fit in. Don't want to have 2 sets of form controls for web content vs rest of OS 16:26:56 q+ 16:27:19 masonfreed: I think if you as a dev want to make form controls match platform it's easy, don't spec anything for fonm controls and it matches. If you spec colors you're trying to change away. 16:27:36 ack emilio 16:27:51 q+ 16:27:55 bradk has joined #css 16:28:03 q+ 16:28:22 emilio: I feel a bit the same as myles. If we try and spec form controls...dev may spec accent color b/c chrome handles it and they don't look native but look better if you change accent color. I'm not sure your argument applies that some browsers will honor colors and others won't. 16:28:32 Present+ 16:28:40 q+ 16:28:46 q- 16:29:05 emilio: For some platforms like Windows and MacOS (I think) we don't have much control over which colors are native and which are for form controls. Alternatives are remove native but you don't want to do same as appearance:none, right? 16:29:21 masonfreed: Right. Idea here is make basic style of color easier for developers. 16:29:54 q+ 16:30:19 masonfreed: The intention of proposal is that it's open to not do anything. It's explicit you can disregard a color. It says if you are going to respect it you should try and use it same way as everybody else. If you don't want to control colors of native form controls you can do that. But if you use accent color you should do it same as everyone else 16:30:45 emilio: But if Gecko and Wk want to keep native appearance we have to impl form controls twice if we want to honor it sometimes. 16:31:25 myles: Another way to say this, this is a world where some browsers impl intentionally and some done. Some browsers use own native design and others use non-native custom design. That doesn't sound like consistency. That world answers the question, it isn't consistent. 16:31:49 masonfreed: Agree form controls are all different. Is that what we want is the question. If we're adding something new should we point it toward interop? 16:31:55 q+ 16:31:55 ack jensimmons 16:32:17 jensimmons: I think there's 2 ways to look at this. One is what we're discussing from impl. From author PoV is the other. 16:32:38 q- 16:33:05 jensimmons: I think some of what you're asking masonfreed gets at the root of the idea where coming up with accent color as the property...another way to do is pseudo class for checkmark and another for checkbox....having something more vague implies the idea we're not giving you a bunch of hooks 16:34:07 jensimmons: If I expect to say my checkbox bg is blue I expect that everywhere. But when it comes to saying accentColor: blue it's impled by the property and the name that hey author welcome to the wide world of chaos and there is not consistency even in the same browser what's happening 16:34:50 jensimmons: I thought the idea is hey we know it's chaotic so we're going to give authors something that's more generic and we'll give authors a way to say my accent color is blue and it's not interop in a way that pixel perfect designs would imagine 16:35:10 dholbert has joined #css 16:35:57 masonfreed: I appriciate and understand that. That is still my intent. Range looks different across everything. I think the realization I made going through each control is there are in a lot of cases 2 places where accent color comes in. There's background-y and foreground-y thing. I think we're still trying to spec something vague but add a bit more information and provide more of a hint what the dev is trying to do. 16:36:05 q+ 16:36:32 masonfreed: Providing 2 colors and some guidance feels to me helpful even to devs. Definitely helpful to devs. If building a checkbox and looks like other checkboxes it's helpful to me. 16:36:36 q+ 16:37:05 masonfreed: I hear we're not going pseudo classes for everything. Maybe that's down the road. This is low hanging fruit that solves a bunch of dev problems that want to make the controls the right color for their site. 16:37:21 masonfreed: I feel you need some level of intent about doing the same thing if you're going to do it. 16:38:15 jensimmons: Makes sense to put something in spec so impl aren't just making it up and everyone gets to a different idea. Say in general we think accent is here and other color is here so impl can have some guidance and not make it up from scratch or look at other browsers. But maybe just a gentle suggestion 16:38:32 jensimmons: You're asking should we try and get everyone to be definitely the same way and I don't know that we can say yes 16:39:19 bradk_ has joined #css 16:39:20 masonfreed: Adding one more thing. Way we got here is there was concern about first mover problems. If one browser impl accent color then other browsers would be stuck matching. Work I did to go through each control was in response to this call saying let's discuss first up front. 16:39:28 ack TabAtkins 16:39:30 q+ 16:40:29 TabAtkins: Two things. 1 to talk to myles and emilio about browsers wanting native on particulr platforms. I think that should be fine. Goal of form elements being stylable will continue to be impossible. Native form controls are weird. Spec allowing browsers to stick with native and ignore accent color is necessary and doesn't make us any worse. 16:41:29 TabAtkins: When talking interop, saying we need interop is nonsense. We need interop to make this a property. We need at min if it's a fg or bg color. Required to ensure element looks good against parent. This will be complex b/c things liek Chrome redesign from where checkign a checkbox swaps the bg and fg colors 16:42:37 TabAtkins: This means chrome cannot be using blue as fg accent and use that to draw bg. Needs to set in UA that when checkbox is checked it uses flipped. It's a work around. If we're clear that if you give 2 colors one wis fg and one is bg I think we're okay. Given there's no control what so ever right now that bit of requirements should insure enough interop even if there's a first move 16:42:56 TabAtkins: Means we'd have to be careful about how we spec 16:42:59 ack una 16:43:09 q- 16:43:32 like, `input { accent-color: blue white; } input:checked { accent-color: white blue; }` needs to be in the Chrome UA stylesheet 16:43:55 una: I want to speak to intent of prop. Give authors more control over form styling. Problem for 20 years. If we're giving authors more control the authros that would case want consistency across brands and OSs. My worry is it seems to be about consistency. If there's not consistency about how colors applied it doesn't solvet he issues the property tries to solve. 16:44:18 present+ 16:44:25 present+ 16:44:36 una: Even with having BG color it's different in Safari where there's a gradient. Solving those issues is key to making this something authors adopt. If we say here's the color and good luck and it's different across browser and OS it takes away the power of the property 16:44:59 ack gregwhitworth 16:44:59 una: Want to argue to authori ntention in wanting consistency. If we're introducing new properties and options it should be top of mind 16:45:51 gregwhitworth: I would like to 100% agree with TabAtkins and una. This was something we were hoping to tackle at joint meeting and it's b/c masonfreed hit nail on head. Need to resolve if we agree this is a problem we're solving 16:46:03 q+ 16:46:45 gregwhitworth: There's a reason author is putting this in there. They're saying I need to change this for a meaningful reason. Way we start to address is recognizing there's potential buckets, potential capabilities we can unlock these things. We're going after the extreme far end to unlock everything. This property is more like intent 16:47:33 gregwhitworth: There is a spirit and an intent to say I'm coke and I want checkboxes to be coke-red. I love your checkbox but it's blue and it feels Chrome not Coke. I'm proving you a brand hint, please apply to your control in a meaningful way. That's the way it's spec. 16:47:38 bradk has joined #css 16:47:57 gregwhitworth: Trying to thread the needle of allowing author to have limited control, but some control, while not biting entire problem. Feel it's a good first step. 16:48:10 +1 to CocaCola example 16:48:43 gregwhitworth: I agree with TabAtkins that if they're using the property you should leverage it. I guar everyone has primary, secondary, etc. colors. We should be able to commit to if they're native render or not it's not un-implable. 16:49:35 ack emilio 16:49:36 gregwhitworth: jensimmons and una hit on it. Author problem and if we feel our controls are superior to the problem author is trying to solve. Agree with TabAtkins about we should lock down. Appriciate masonfreed trying to have the spirit 16:49:40 +1 to gregwhitworth "please use this color in a meaningful way"; -1 to defining what "use in a meaningful way" means in terms of which parts get which color 16:49:41 emilio: Agree with sentiment 16:49:54 Important bit here is that the role of the colors *cannot* be semantic like "primary, secondary, tertiary". They *must* be functional like "foreground, background, shadow". Otherwise a page using "black white" for a checkbox, expecting a white box with a black check, and putting it against a black background, would look bad on Chrome where the bg is the "primary" color when checked. 16:49:55 q? 16:50:07 q+ 16:50:13 +1 TabAtkins 16:50:43 need to ensure contrast 16:50:49 emilio: Concern is implementablity. We can do the work to make it work. If WK commit they can add coco APIs for Mac but no control over windows. Only alternative is re-write form controls. We may end up doing that. I don't know. If you force engines to apply it then you prevent using native form controls 16:50:54 q? 16:51:02 emilio: If you don't it's not all that useful to authors b/c they can't customize 16:51:34 TabAtkins: yeah, my point was that everyone does have colors in their control that will be able to map to the property value set 16:51:36 astearns: Compromise is for a browser using native controls without any capability of changing the browser could say they do not support on that platform. lets author know styles won't work as intended. 16:51:45 emilio: It's an option but pages could rely on colors to work 16:51:46 I disagree that it should say backwards vs. foreground. If one native control has a border and another doesn’t, saying the background should be white would be much worse on the one with no border. 16:51:54 wrt accent-color, I don't think making a list of "primary/tertiary/etc" makes sense. But listing colors, against which the browser will use a "pick color with most contrast against [color/bgcolor as needed for this particular use of accent coloring]", could be a good way to do this 16:51:58 ack jensimmons 16:51:58 gregwhitworth: Yeah, I was just countering your use of "primary" in your description. ^_^ 16:52:00 astearns: There will always be browsers that won't support. 16:52:31 agree with jensimmons; this has been circling for twenty minutes when it's actually just a debate over the existence of the feature itself 16:52:40 q+ 16:52:48 jensimmons: I'm just confused as to where disagreement is. Feels like a high level debate about if we should use must/may/should in every part of the spec. Maybe some of spec should say must, some should be may, some should. 16:53:45 masonfreed: For me the debate is the way prop is written is the interop version. Alternative is strip away most of that to just say accent color looks like this and browsers us as they say fit. Debate is spec as written vs another spec that reads that accent color is a hint, use as you'd like 16:54:08 q- 16:54:16 astearns: Put another way we dsicussed and asked masonfreed to make non-normative suggestions. masonfreed is coming back for validation. I think we should say yes this is what we want or no, dial back on interop 16:54:21 ack emilio 16:54:23 my main point here was that we can pick up this discussion at the Open UI + CSSWG meeting 16:54:29 I have this as an agenda item 16:54:37 as it's paramount to land on aspects of interop 16:54:46 whether we do or do not 16:54:55 ack fantasai 16:54:55 emilio: Assuming we spec this feature I think it should be sufficiently well spec so browsers and impl can do something consistent. 16:55:07 masonfreed: I'll make it easy: if the spec says "here's some colors, do what you want with them", I'll formally object to it. ^_^ 16:55:19 Seems like dark-color, secondary-dark-color, light-color, secondary-light-color would work better 16:55:51 fantasai: I think I would go with saying spec shouldn't mandate use of color and instead say it's a hint. If we're switching to a mode of form control with a lot of author controls we can mandate. There is a desire for authors to influence without changing render at a fundemental level. 16:55:53 bradk: That doesn't work for Chrome's checkboxes vs everyone else's checkboxes. 16:56:52 bradk: That's what I meant by "cannot use semantic roles, must use functional roles" 16:56:55 q+ 16:56:59 fantasai: Main concern should be how do we get enough contrast. Some checkmarks use fg and some bg. Need to make sure we can get enough contrast. Having examples which are here's how it's used in some browsers is good, but you're using native controls and accent color should be a hint that says I'd like to use this accent color and please use it meaningfully. But shouldn't define meaningful 16:57:14 astearns: So you think dial back on non-normative text of what you should do with accent color 16:57:19 q- 16:57:25 fantasai: I don't think we should have should or must requirement 16:57:35 astearns: It's all non-normative. So you're okay with spec as-is? 16:57:41 fantasai: I'm fine with it being examples 16:57:48 masonfreed: All non-normative examples 16:58:07 myles: WE said difference is today with non-normative vs deleting the examples. What's the functional difference between the two 16:58:49 https://github.com/mfreed7/accent-color/blob/master/proposal.md#per-control-guidance 16:58:56 masonfreed: Functionally means every impl can do own thing and may be completely different. Chrome will impl the way they want. If we delete all the text. It will just be a rough desc and no guidance as to how to use it. 16:59:04 And I"ll strongly object to a version fo the spec without guidance on using the colors 16:59:16 Unrelated to current topic - I've added a comment to the overflow model issue: https://github.com/w3c/csswg-drafts/issues/129#issuecomment-697691447 16:59:20 astearns: Back to original issue, should interop be a goal? non-normative examples will likely get better interop. Removing is more likely for non-interop 16:59:24 No guidance = browser-specific, so this is a prefixed property, not a real property. 16:59:26 TabAtkins++ 16:59:41 emilio: you're confusing me bud 16:59:46 TabAtkins: agreed 16:59:49 fantasai: I think the section labeled non-normative is written with normative language. It needs to say this is how it could be done but it could be done in a different way. 16:59:56 gregwhitworth: if we specify the property, we should specify what it does 17:00:05 gregwhitworth: (that's what I said when I last spoke) 17:00:08 If someone doesn't want the property *at all*, say that; trying to water down the requirements by removing guidance doesn't do the job. 17:00:18 astearns: My way of thought is here's an example where if form control looks like this here's what it should do. If it looks different do what you want. But if you have something liket his should is appropriate 17:00:28 gregwhitworth: That is regardless of my concerns about implementability in Gecko / WebKit 17:00:50 fantasai: In this case might want 2 examples. If it looks like this here's what changes and if it looks like that here's what else would change. So you can say your form control doesn't have to look exactly like that 17:00:59 gregwhitworth: But I think we decided a bit ago that debating implementability was specifically a non-goal of this issues 17:01:01 astearns: Can we resolve to say this non-normative section is way we want to proceed? 17:01:05 this issue* 17:01:11 zhengxu has joined #css 17:01:12 astearns: Would anyone object to keep with advice on impl? 17:01:22 fantasai: Don't want as is, but fine with a bunch of examples 17:01:30 myles: Need resolutions for non-normative text? 17:01:33 gregwhitworth: So I think I'm not contradicting myself, but maybe I'm wrong :)) 17:01:36 masonfreed: Looking for next steps 17:01:52 fantasai: Happy to give more specific feedback. We can resolve on the normative 17:01:57 astearns: This issue is about non-normative 17:02:07 astearns: myles do you object to keeping non-normative? Want more time? 17:02:19 I would like this to wait for the OpenUI talk; this 40min discussion did very little. :( 17:02:22 myles: We're kind of out of time 17:02:30 masonfreed: Can I get more specific feedback on the issue? 17:02:32 Let's not talk about this again until there's a focused topic on it 17:02:40 Thanks! 17:02:48 astearns: Anyone with specific concerns please put them in the issue and we'll do this first thing next week 17:02:50 Topic: edn 17:02:54 Topic: end 17:03:39 futhark has joined #css 17:04:05 masonfreed, the issue I have with your "non-normative" section is that it's worded as a set of normative recommendations rather than illustrative examples 17:04:59 masonfreed, for example - The shaded background of the progress bar should be considered a "contrasting" accent, while the filled "value" portion of the progress bar should be considered "primary". 17:05:53 masonfreed as opposed to something like "In this example, the shaded part uses the OS theme accent color; therefore it should be affected by accent-color" 17:06:21 fantasai, I understand your objection, but I don't know how to improve it exactly. If you would like to propose an alternative that says "you can use the first color as the background, or the foreground, or somewhere else", then I don't see the point of having that entire non-normative section in the first place. 17:07:17 masonfreed, if you're not allowing for those possibilities, then your section isn't non-normative 17:07:48 or at least, isn't really behaving as such 17:08:59 futhark has joined #css 17:14:17 fantasai - let's continue the discussion on the issue. I'm curious to hear your specific suggestions about how the proposal is written. 17:14:27 masonfreed: happy to make specific suggestions :) 17:14:33 Thanks! 17:14:38 masonfreed: Largely, I agree 100% with Tab's comment here - https://github.com/w3c/csswg-drafts/issues/5480#issuecomment-682242811 17:14:51 masonfreed: I think his first two paragraphs are basically my core position 17:15:17 masonfreed: and my desire is for this non-normative section not to take away from that core position in any way 17:15:31 I think his first two paragraphs are *my* core position as well! And I believe (perhaps incorrectly) that I've written a spec that does exactly that. 17:16:08 I think it's important to read the non-normative text in the context of the normative text. 17:16:29 futhark has joined #css 17:16:30 futhark has joined #css 17:21:04 futhark has joined #css 17:24:01 futhark has joined #css 17:25:04 futhark has joined #css 17:46:44 futhark has joined #css 18:03:27 GameMaker has joined #css 18:21:18 gtalbot has joined #css 18:50:44 jfkthame_ has joined #css 18:51:30 futhark has joined #css 19:05:55 zhengxu has left #css 19:15:35 GameMaker has joined #css 19:20:31 Zakim has left #css 19:37:55 jfkthame_ has joined #css 20:18:29 GameMaker has joined #css 20:50:50 krit has joined #css 20:50:56 oriol has joined #css 20:51:02 jcraig_ has joined #css 20:51:08 svoisen has joined #css 20:51:09 JonathanNeal_ has joined #css 20:51:11 war2 has joined #css 20:51:22 hayato has joined #css 20:51:25 dandclark has joined #css 20:51:33 eae has joined #css 20:51:37 miriam_ has joined #css 20:52:13 astearns has joined #css 20:52:27 rachelandrew has joined #css 20:52:49 nainar has joined #css 20:53:06 falken has joined #css 20:53:14 gregwhitworth has joined #css 20:54:02 jyasskin has joined #css 20:54:06 drott has joined #css 21:30:46 GameMaker has joined #css 22:51:29 argyle has joined #css 22:51:31 svoisen has joined #css 22:51:31 chrishtr has joined #css 22:51:52 nainar has joined #css 22:51:54 hayato has joined #css 22:52:08 slightlyoff has joined #css 22:52:08 foolip has joined #css 22:52:08 eae has joined #css 22:52:13 faceless2 has joined #css 22:52:13 ojan has joined #css 22:52:14 Travis has joined #css 22:52:16 iank_ has joined #css 22:52:19 esprehn has joined #css 22:52:20 sangwhan has joined #css 22:52:20 cmp has joined #css 22:52:20 war2 has joined #css 22:52:21 jcraig has joined #css 22:52:22 NavidZ_ has joined #css 22:52:22 koji_ has joined #css 22:52:27 oriol_ has joined #css 22:52:27 Letze_ has joined #css 22:52:27 majidvp_ has joined #css 22:52:27 falken_ has joined #css 22:52:27 cbiesinger_ has joined #css 22:52:27 gregwhitworth_ has joined #css 22:52:27 krit has joined #css 22:52:29 mrodland_ has joined #css 22:52:29 rbyers_ has joined #css 22:52:29 boris_ has joined #css 22:52:30 emilio_ has joined #css 22:52:39 TabAtkins_ has joined #css 22:52:40 surma_ has joined #css 22:52:41 lukebjerring has joined #css 22:52:46 timeless_ has joined #css 22:53:24 dandclark has joined #css 22:53:30 kereliuk has joined #css 22:53:39 BoCupp_ has joined #css 22:53:51 tobie_ has joined #css 22:53:52 Domenic has joined #css 22:53:56 melanierichards_ has joined #css 22:54:32 ZoeBijl_ has joined #css 22:55:20 rachelandrew has joined #css 23:01:33 GameMaker has joined #css 23:38:57 jfkthame_ has joined #css