17:07:19 RRSAgent has joined #css 17:07:19 logging to https://www.w3.org/2021/12/15-css-irc 17:07:21 RRSAgent, make logs Public 17:07:22 Meeting: Cascading Style Sheets (CSS) Working Group Teleconference 17:07:47 present+ 17:07:52 Topic: MediaQueries length units in video-* 17:07:55 github: https://github.com/w3c/csswg-drafts/issues/5044 17:08:00 present+ 17:08:01 florian: Issue has evolved since opened 17:08:10 florian: reminder, we specified video-width/height/resolution 17:08:37 florian: video prefix is about video playing that some devices like TVs have, where they superimpose a special canvas with different characteristics for playing video 17:08:50 florian: About a year ago we were talking about this and thinking that actually, maybe MQ isn't what's wanted 17:09:02 florian: The typical query of width is about whether bigger or smaller than some value 17:09:05 florian: but not used for that 17:09:19 florian: use cases were that ppl wanted to ask "what is the size of the screen, in physical pixels" 17:09:29 florian: The only way to do via MQ is via binary search in MQ, which is not great 17:09:53 florian: So conclusion of discussion is not to have an MQ, and instead have some extension to CSSOM where you can query for the pixel ratio of the video playing of the device 17:10:03 florian: since can already know size of viewport, can get the size of the whole screen 17:10:08 Rossen_ has joined #css 17:10:12 florian: or if interested in size of an element, can go from the size of that element 17:10:25 florian: So the suggested resolution for MQ is to remove video-width/height/resolution MQ 17:10:26 q? 17:10:31 TYLin has joined #css 17:10:38 florian: and another resolution would be for CSSOM to add window.deviceVideoPixelRatio 17:11:01 Rossen_: Opinions on this? 17:11:10 castastrophe has joined #css 17:11:25 smfr: I'm a little concerned about multi-screen systems 17:11:26 lea has joined #css 17:11:36 smfr: window is associated with a single screen 17:11:47 smfr: if showing video, is it on the same screen/window? 17:11:50 smfr: idk how to know that 17:12:12 smfr: imagine you have two screens, right hand is dedicated to video presentation 17:12:20 smfr: somehow magically when you present video, it shows up on the right 17:12:28 smfr: but window object is associated with the left hand screen 17:12:44 smfr: so would be weird if it reported characteristics of right hand screen 17:12:51 ???: Is this possible today? 17:13:01 smfr: UA thing, UA could decide to send fullscreen video to a particular screen 17:13:07 present+ 17:13:11 s/???/chrisneedham/ 17:13:19 florian: I think as far as TVs are concerned, and things with this multiplane rendering, it doesn't behave the way you described 17:13:30 florian: more general browsers/setups, could be other setups 17:13:44 florian: the window object is probably not designed for that, but this is a more generic problem than video specifically 17:13:52 florian: 2nd Screen effort is trying to deal with that 17:13:58 florian: but for the TV use case, I don't believe that's how they work 17:14:10 s/chrisneedham/cpn/ 17:14:25 Rossen_: to go one step further, in conjunction with some of the newer foldables and dual-screen efforts 17:14:41 Rossen_: I know of at least one effort that is work happeneing on ??? that have to do with dividing up the window into multiple segments 17:14:57 Rossen_: multiple screen divided by segments or hinge 17:15:07 Rossen_: here we have one window spanning two surfaces 17:15:16 Rossen_: video having controls on one different screen is very typical 17:15:23 florian: Does this device have a multiplane rendering thing? 17:15:25 antonp has joined #css 17:15:44 florian: typically TVs do this, typical screens don't have two planes that can be queried separately 17:15:55 Rossen_: we have one window object that will be present on both physical screens 17:16:04 Rossen_: is expectation that devicePixelRatio returns ... 17:16:22 florian: I think the question is legit, if you have this multiplane thing with two resolutions on one screen, we have this problem for the window object in general 17:16:34 florian: this is a good problem to address if such devices exist, but there's nothing specific to video about it 17:16:49 Rossen_: there are some laptops that have a pane over the keyboard, so you can present into those 17:17:09 Rossen_: but might be represented by two different screen objects 17:17:47 emeyer has joined #css 17:18:19 fantasai: don't smfr 's concern apply to the regular to the regular device pixel ratio as well? 17:18:22 emeyer has left #css 17:18:30 fantasai: if so, we need to address it there as well 17:18:35 smfr: devicePixelRatio doesn't have this same issue 17:18:45 smfr: if I drag window over, devicePixelRatio will change 17:19:04 fantasai: I understand the concern. We need to address the multi-resolutions for devicePR and other API. Adding a parallel API for these is what makes most sense. 17:19:04 smfr: issue with video one is that video presentation is special, and UA chooses that it will be displayed in magic extra plane with different properties 17:19:22 florian: We're not talking about picture in picture or displaying window in other places 17:19:34 florian: but for TVs, they have two framebuffers layered over each other in the same spot 17:19:51 florian: They have the normal layer transparent, punch video through to underlying layer 17:20:03 florian: which has different resolution 17:20:15 florian: in current devices, this would be on the same scree 17:20:20 ack fantasai 17:20:33 florian: a browser could have two different videos on different screens, but that's a very different setup than here 17:20:51 smfr: I understand, I just don't want us to design a problem for foldables 17:21:00 florian: Let's just resolve to remove the MQ for now 17:21:10 florian: and maybe we can open an issue for the deviceVideoPixelRatio 17:21:27 florian: I don't quite see the problem, because whatever problem you're describing seems to apply equally to devicePixelRatio 17:21:44 Rossen_: Anyone from the video group want both resolutions? 17:22:32 fantasai: smfr, why does your concern apply to deviceVideoPixelRatio and not devicePixelRatio? 17:22:44 smfr: Because it applies to fullscreen, which is more likely to be on a different screen 17:22:51 florian: This isn't necessarily about fullscreen video. 17:22:59 ack fantasai 17:23:09 florian: if you have youtube playing in the middle of your web page, you would apply this ratio within the video 17:23:17 smfr: No, I don't think so, I think it only applies to fullscreen 17:23:48 Rossen_: If presentation spans multiple screens, e.g. projector, very different characteristics than PC, wouldn't problem apply to that as well? 17:23:55 florian: And doesn't necessarily apply to fullscreen only, that's up to the author 17:24:09 florian: Yes, youtube or hulu or whatever video service can be played fullscreen sometimes 17:24:21 florian: but might also want to query in normal rendering mode 17:24:31 florian: and since hardware accelerated, would still go into special plane 17:24:36 smfr: wouldn't be the case in Apple devices 17:24:41 smfr: I think we should ask experts for feedback 17:24:50 smfr: I think it would be very confusing for author 17:24:59 Rossen_: Let's go with resolving to drop the MQ 17:25:06 Rossen_: it's clear we need to work more on the rest of the API 17:25:16 Rossen_: Any objections to dropping MQ? 17:25:25 smfr: I support that 17:25:34 RESOLVED: Drop video-width/height/resolution media queries 17:25:42 Rossen_: send rest of conversation back to the issue 17:25:58 florian: Should I retitle the issue, or file a new one? 17:26:24 Rossen_: new issue might be helpful to have clear slate, but history etc. might be useful 17:26:50 Topic: Mediaquery dynamic-range 17:27:19 florian: had a discussion awhile ago, explored idea that dynamic-range was a complicated concept 17:27:30 florian: because maybe some devices have modes where high dynamic range is active or not 17:27:52 florian: and maybe UA supports for videos, but not CSS, or for images but not canvas 17:28:09 florian: Could say the same thing in theory about other things like color depth, but we didn't expose this per element or anything 17:28:19 florian: idea is to clarify and fix the spec to match what Safari is currently shipping 17:28:45 florian: One difference is that we have standard and high as values, and want to align this media feature to the same sort of behavior we have with color-gamut 17:28:55 florian: where the smaller one matches when larger one is matched 17:28:58 florian: so that modes nest 17:29:03 q? 17:29:11 florian: so that if more extended values exist in the future, compatible with content now 17:29:23 florian: Wrt querying device or UA 17:29:39 florian: text puts more emphasis that needs to be the combination of UA and device 17:29:53 florian: but no particular need to draw attention to that here, since true of all MQ 17:30:10 florian: tldr is spec what Safari does, because that's what we want 17:30:30 Rossen_: proposal is? 17:30:46 florian: Currently spec doesn't say that standard and high can match simultaneously, it's either-or 17:30:56 florian: change it that if match high also match standard 17:31:01 florian: everything else is editorial 17:31:09 Rossen_: We have other MQ like that 17:32:34 i agree 17:32:36 RESOLVED: dynamic-range: standard also matches when dynamic-range: high matches 17:32:38 +1 17:33:09 Topic: Allow empty functions in 17:33:18 github: https://github.com/w3c/csswg-drafts/issues/6803 17:34:07 TabAtkins: We had some leftover grammar from a previous change that accidentally implied that if you had a in functional form it had to ahve something inside the parens 17:34:13 TabAtkins: previously could be empty 17:34:22 TabAtkins: small change to make the value optional, so that foo() would be valid 17:34:26 tantek has joined #css 17:34:28 @media fn() {...} 17:34:40 @media fn(foo) {...} 17:34:42 TabAtkins: wanted to make sure this counts as with unknown value rather than syntax error 17:35:10 florian: asking for approval because spec is in CR 17:35:12 Peter has joined #css 17:35:25 RESOLVED: Accept change to allow empty functional notations in 17:35:32 Topic: Highlights and currentcolor 17:36:11 delan: Started discussing this issue last week, but only got partway through 17:36:18 delan: about special case of setting 'color: currentColor' 17:36:25 delan: outside of highlights, it means 'color: inherit' 17:36:30 delan: for highlights, actually means something else 17:36:35 delan: there were 2 questions originally, now 3 17:37:11 delan: 1st question, double-checking, spec says when setting to currentColor, do we want to grab color from next highlight layer below regardless, or only active highlight layers 17:37:26 delan: fantasai said it only makes sense to use active highlight layer, and I think everyone agrees on that 17:38:10 florian: I'm a little unsure, agree with that assessment, but discussion last time suggested maybe there was a whole different way to think about this 17:38:19 delan: that's the 3rd question, whether this is the right way to solve the problem that it solves 17:38:55 delan: 2nd question is, if it is the next active highlight specifically, then what happens when you getComputedStyle? 17:39:10 delan: getComputedStyle needs to return resolved colors, so has to return an actual color 17:39:18 q+ 17:39:23 delan: if you have an element with multiple underlying colors, what do you do 17:39:31 delan: currntly a few ideas on how to address that 17:39:45 present+ btw, whoops :) 17:39:52 delan: 3rd question, which emilio brought up, this exceptional behavior of currentColor for highlights is odd and complicated 17:39:59 present+ 17:40:03 delan: wondering if this was the right way to solve the problem, or if better way to solve the problem 17:40:15 delan: To clarify, best example of a use case for this, is the spelling and grammar error pseudo-elements 17:40:26 delan: a typical styling for that would be to add a red or green squiggly line to the text 17:40:37 delan: but you're just adding the decoration, you don't want to change the color of the text 17:40:45 delan: if you spell a word, still want to have the same text color 17:40:55 s/cpn/chcunningham/ 17:41:10 delan: but given way highlight painting works, if we didn't have this rule for currentColor, then there would be no way to highlight something without changing the color to 'initial' (black) 17:41:26 delan: it's complicated and an odd exception, but we need some solution to this problem 17:41:48 florian: one extra bit, suggestion last time is that this might be similar to ::first-line 17:42:02 florian: we don't redefine how currentColor works, we redefine what inherits from what 17:42:20 florian: if you set currentColor on first line, it'll get its color from ::first line 17:42:33 q+ 17:42:40 ack TabAtkins 17:42:51 TabAtkins: I'm not certain about best way to handle property itself, but for purpose of getComputedStyle I think it's reasonable to say "pretend it's not selected at all", so just get underlying style 17:42:56 q+ 17:43:00 TabAtkins: that seems the most straightforward, and doesn't leak info about spelling/grammar errors 17:43:12 scribe+ TabAtkins 17:43:16 q+ to ask clarification from Tab 17:43:18 gtalbot has joined #css 17:43:18 ack fantasai 17:43:33 present+ 17:43:39 fantasai: WE also have to consider that when you set the - we have paired cascading, and it sets to "the color it would have already been" it sets the background, so this behavior needs to represent that as well 17:43:42 ack emilio 17:44:10 emilio: does this really only apply to currentCOlor? seems applies to inherited properties applied to highlights 17:44:16 emilio: maybe color is the only one atm 17:44:32 emilio: seems you'd have the same problem with text-fill and other things 17:44:49 emilio: so, in general, I think the right fix would be inheritance, but that might be annoying to implement 17:44:55 q? 17:45:09 ack delan 17:45:46 delan: Tab, is it true that you mean same thing as emilio, wrt Q2, my understanding is that if you ask for getComputedStyle for ::selection, we pretend everything is selected and no other highlights apply 17:45:59 TabAtkins: no opinion on pretending selected or pretending not selected, defer to impl on that question 17:46:06 TabAtkins: but ignoring any other highlights is the important bit 17:46:15 delan: sounds like a straightforward solution to that, I agree 17:46:23 delan: wrt Q3, inheritance and possible parallels with ::first-line 17:46:33 delan: I'm not that fresh on ::first-line and ::first-letter 17:47:14 delan: can someone explain how it would work for us to sometimes inherit from another highlight (grab color from ancestor highlight) while still inheriting within this inheritance tree for ??? 17:47:15 q? 17:47:23 q- 17:47:27 emilio: I think that's the hard part 17:47:42 github: https://github.com/w3c/csswg-drafts/issues/6818 17:47:50 emilio: My selection styles inherit from my parent selection styles 17:48:16 q? 17:48:21 emilio: E.g. selection style inherits from other highlight which inherits from regular text which inherits from parent selection style 17:48:26 delan: ... 17:48:34 delan: ::target-text inherits from ::selection style?? 17:48:40 emilio: whichever order we decide on... 17:49:00 emilio: for simplicity, say we have ::selection and ::spelling-error 17:49:14 emilio: say ::selection inherits from ::spelling-error, and ::spelling-error inherits from parent ::spelling-error 17:49:22 emilio: I think that would get you the right behavior 17:49:38 q? 17:49:49 fantasai: It would not, because if ::selection inherits from ::spelling-error, and that inherits from parent ::spelling-error, it'll never inherit from the parent selection 17:50:06 emilio: ::spelling-error inherits from ::selection 17:50:10 fantasai: Why would spelling-error inerit from selection? 17:50:20 emilio: ::spelling-error inherits from ::selection 17:50:27 fantasai: that doesn't work 17:50:53 fantasai: can you give me an example of the zigzag? 17:51:08 fantasai: there's two pseudos - selection paints over spelling-error - what's the inheritance chain? 17:51:30 delan: So you go in a zigzag, our ::selection inherits from our ::spelling error, and our ::spelling-error inherits from our parent's ::selection, which inherits from parent's ::spelling-error, etc. 17:51:34 child selection -> child spelling error -> parent selection -> parent spelling-error 17:51:55 fantasai: Why would it make sense for ::spelling-error to inherit from parent's ::selection? 17:51:55 fantasai: Why would it make sense for spelling error to inherit from the parent's selection? 17:52:02 emilio: I guess it doesn't quite... 17:52:17 delan: when you jump back in the zigzag, you have a lower layer inheriting from a higher layer 17:52:26 delan: it's hard for me to imagine this 17:52:45 fantasai: imagine spelling was red, seleciton was blue 17:52:51 fantasai: you highlight some things 17:53:09 q? 17:53:13 fantasai: the zigzag means you'll get red text when you highlight, if the parent has an spelling error 17:53:14 This (special inheritance across pseudo-elements) seems confusing enough to the WG that I can't imagine authors actually coming up with a predictive mental model for what is going on. 17:53:16 fantasai: seems weird 17:53:41 Rossen_: Seems work to do here, need to decide if we are going to rethink through inheritance or to tweak existing model 17:53:51 q+ 17:54:17 delan: This is a valid conversation, about solving via other mechanism 17:54:36 delan: but wondering if we can resolve Q1 and Q2, based on assumption that things work the way specified now using currentColor 17:54:46 delan: and later if we want to solve a different way, we can do that? 17:54:51 Rossen_: Makes sense to me 17:55:01 q+ 17:55:10 I *think* one of he goals here is that which of grammar-error/spelling-error/target-text/selection's styles wins does *not* depend on which elements are associated with the selectors (and how they nest), but rather on a spec-defined order of the pseudos. 17:55:16 ack florian 17:55:36 q+ 17:55:40 florian: I support doing this. Earlier Tab suggested that you put either everything selected or nothing is, suggest assuming everything because otherwise no point in querying ::selection 17:56:03 ack delan 17:56:04 delan: I thought question was between nothing or pretending that just the pseudo you asked for 17:56:07 florian: that's the one 17:56:16 florian: answering that just the pseudo you asked for is everywhere and nothing else 17:56:26 florian: It's not useful to assume no highlights at all 17:56:33 emilio: I think that's the current behavior 17:56:47 emilio: I'm moderately sure that querying ::selection will get you the ::selection styles 17:57:14 delan: pretendign everything else not selected also solves, what happens if ::selection leaks a color from ::spelling-error or ::grammar-error, which we made it forbidden for privacy reasons so this solves that problem 17:57:19 emilio: it's also simpler, fixes privacy leak 17:57:40 florian: alternative we mentioned last time was to fragment things, and answer question about first one, but overkill for no good reason 17:57:45 delan: don't think anyone needs that answer 17:57:59 florian: if we really needed that answer, we'd need an API to reply on each individual fragment 17:58:33 vmpstr has joined #css 17:58:43 fantasai_ has joined #css 17:59:24 delan: For Q1, proposing that we say that when you say 'color: currentColor' on a highlight pseudo, you grab the next active highlight's color 17:59:38 delan: so that color is as if this highlight wasn't applying 18:00:06 emilio: ... 18:00:11 fantasai_: currentColor computes to itself 18:00:17 emilio: except in 'color' property 18:00:21 emilio: I'll double-check 18:00:28 emilio: anyway, seems fine 18:00:52 RESOLVED: 'color: currentColor' on a highlight takes the next *active* highlight color, so that text is drawn as if highlight weren't taking effect 18:01:00 scribe+ 18:01:39 delan: For Q2, when you call getComputedStyle() with a highlight pseudo, the color of the result should behave as if the pseudo you passed in is highlighted, but all other highlight pseudos are not highlighting 18:01:45 delan: we pretend 18:01:55 +1 18:02:25 RESOLVED: getComptuedStyle() with a highlight pseudo takes color as if that highlight applied and no other highlight applied 18:02:31 Rossen: we'll take Q3 back to the issue 18:02:41 Topic: Break 18:02:48
18:05:10 Are there any real timezones where the hour in UTC is *:15 in that timezone? There are definitely some for :45 (Nepal; Eucla, WA, Australia). 18:05:39 present- 18:09:11 present+ 18:12:19 present+ 18:12:46 Topic: Paired Cascading of Highlight color/bgcolor 18:13:07 github: https://github.com/w3c/csswg-drafts/issues/6386 18:13:34 delan: for compat reasons, highlights have a "paired cascade", at least for ::selection (but we decided to apply to all) 18:13:40 delan: for background-color and color 18:13:50 delan: if you have some browser default colors for ::selection, e.g. white on blue 18:14:08 delan: if you then go and set one of those two properties, then both of the defaults get suppressed 18:14:09 ::selection { background: yellow; } 18:14:13 delan: defaulting to their initial value 18:14:30 delan: e.g. if you set selection's background to yellow, then the default foreground color at used value time is no longer going to be white 18:14:53 delan: This issue was pretty big, I asked 7 questions about it in the issue 18:15:02 delan: pretty much none of the questions have disagreement in the issue 18:15:12 delan: the main open question is, which origins should this apply to? 18:15:27 delan: Original spec text says that when author sets one of these two properties, then we suppress highlight color 18:15:36 delan: but there's also animation and transition origins, and also user orgin 18:15:44 delan: will talk about aimation and transition first 18:16:07 delan: I think it doesn't matter whether animation or transition is included in this rule or not 18:16:29 delan: we used to think it mattered for consistency with 'appearance', but I realized it doesn't matter because the animation and transition properties are not applicable for highlights 18:16:39 delan: so as far as I'm aware, can't use them in highlights 18:16:50 emilio: I think ?? you should be able to 18:16:57 emilio: don't know if propertly supported, though 18:17:11 dholbert: can a property that is inherited be animated or transitioned? 18:17:34 delan: Wondering if it is allowed by the spec right now 18:17:45 delan: if not allowed, then doesn't matter whether those origins included in this rule 18:17:54 delan: at least until they become allowed 18:18:05 florian: I believe delan is right, not part of the list of allowed properties 18:18:16 delan: no way for some way for them to sneak in, despite being applicable properties? 18:18:20 florian: I don't think we designed one 18:18:23 s/being/not being/ 18:18:39 dholbert: if animate color of parent, and it inherits through? 18:18:47 s/dholbert/emilio/ 18:18:59 fantasai_: That wouldn't be in the animation or transition origin on the highlight itself 18:19:18 delan: if not possible to come into highlight overlay, and it doesn't matter 18:19:26 florian: I think we should talk some other day whether they should, but until they do... 18:20:07 delan: For the user origin, I did some playing around with user style sheets 18:20:22 delan: afaict, the question here about user origin and paired cascade comes down to 18:20:37 delan: if the user sets one of the two properties (bg color or color) in their user style sheet 18:21:03 delan: do we want that to suppress the UA default for the other property or do we want it to not suppress it and leave the other property as UA-default 18:21:27 florian: Can implementations guide us? This rule was just for compat 18:21:34 emilio: I don't think there's any compat requirements on user origin 18:22:05 emilio: User origins don't disable appearance, so let's follow that precedent 18:22:22 fantasai_: My reading is that we really don't care, so we should do whatever is easiest 18:22:35 delan: works out 18:22:48 delan: even if you go with compat angle, it doesn't suppress default UA colors in Firefox 18:23:18 Rossen: other opinions? 18:24:00 RESOLVED: Author origin rules, and not user-origin rules, trigger paired cascade fallback 18:24:24 delan: In the issue, we all agree on the other 7 questions 18:24:55 delan: do we need resolutions? 18:25:06 fantasai_: IIRC they're minor enough that I'd close them under Editor Discretion 18:25:23 Topic: Compat risk for ::selection defaulting one color from originating element 18:25:32 github: https://github.com/w3c/csswg-drafts/issues/6774 18:25:56 https://github.com/w3c/csswg-drafts/issues/2474 18:26:02 delan: The highlight inheritance and cascade in the spec is a pretty big change compared to processing model in implementations right now 18:26:15 delan: previously our position was that we consider the compat risk of this big change to be acceptable 18:26:26 delan: because the old model that exists in old browsers is kindof useless and broken 18:26:39 delan: the styles don't inherit so you have the set them everywhere, unless writing a really awkward selector 18:26:54 delan: while implementing in Blink, we found a WPT that broke as a result of turning on highlight inheritance 18:27:05 delan: unclear if aware of that breakage, are we still happy with the compat risk? 18:27:52 span { background-color: red; color: fuchsia; } 18:27:53 delan: what the test did is essentially it has the originating element with colors of fuchsia on red 18:28:01 span::selection { background-color: green; } 18:28:07 delan: there's a selection rule that just sets a gree background color 18:28:20 delan: paired cascade from earlier means that because one of the two highlight properties 18:28:31 delan: there is no UA default for 'color', so we use whatever color we get normally 18:28:44 delan: existing model in browsers has ::selection inherit styles from originating element 18:28:52 delan: so test expects color to be fuchsia 18:28:55 delan: but now the test fails 18:29:08 delan: because under new rules, we don't inherit color, it's black 18:29:14 q? 18:30:20 fantasai: I think the test is correct, actually, and paired cascading is also correct 18:30:31 fantasai: inheriting all the way up, should get currentColor, not black 18:30:38 fantasai: though I'm not sure the spec is clear about that 18:30:47 emilio: Goes back to currentColor discussion 18:31:07 emilio: all implementations resolve 'color: currentColor' to an actual color 18:31:13 GameMaker has joined #css 18:31:29 emilio: so I think we need to solve the problem of 'initial' and 'currentColor' being different 18:31:32 emilio: and we need a resolved color 18:31:47 emilio: I think the computed value is wrong, and it uses a computed color 18:31:55 emilio: nobody implements that, it has terrible perf implications 18:32:09 florian: Delan, can you point out to which bit of the spec made you think that you would go to black rather than originating element? 18:32:12 dino has joined #css 18:32:15 florian: wondering if it's ambiguous or wrong 18:32:44 delan: ... value found by inheritance ... do we say what happens when we get to the top? 18:32:52 delan: I don't think it says what to do if you get all the way to the root 18:33:01 delan: was it wrong to assume it would work the same way as in the the normal tree? 18:33:07 emilio: I think the spec is right 18:33:23 emilio: but if everything worked by spec, color is initial which is currentColor and it would work 18:33:30 emilio: but that's not how it works right now 18:33:49 delan: so we'd change spec so that for highlights, we get to root, and have a value we get essentially what currentColor does now 18:33:57 emilio: per spec should get currentColor as computed value 18:34:05 emilio: so I think the spec for the color property is wrong 18:34:16 delan: if we did that for all properties ... 18:34:30 emilio: I think the only issue is with the color property 18:34:36 emilio: all current impls store as computed color 18:34:56 emilio: otherwise need to go figure it out every time resolving a color for a given style 18:35:04 emilio: I think the spec doesn't reflect that 18:35:16 emilio: didn't make a difference until now, that we want currentColor to behave specially 18:35:27 Rossen: so do we need to move this discussion back to GH? 18:36:18 delan: I suppose these questions are useful and interesting, but I'm not sure they necessarily change the original question, which was do we still want to move to paired cascade 18:36:36 s/paired cascade/new cascading and inheritance model/ 18:36:44 emilio: I think we want the testcase to continue to pass 18:37:03 emilio: Depending on how we resolve the issue 18:37:09 delan: so can take to GH 18:37:15 emilio: this seems complex enough discussion 18:37:23 emilio: per spec everything works magically and it's great 18:37:28 emilio: but I don't think that's reasonable 18:37:35 emilio: so we should figure out the solution that works as we want 18:37:40 delan: ok sounds good 18:37:55 Topic: Publications 18:38:28 Topic: Fonts publication 18:39:08 Topic: Conditionals publication 18:39:12 https://lists.w3.org/Archives/Member/w3c-css-wg/2021OctDec/0116.html 18:39:29 fantasai: I wanna publish another level 3 CR. A couple of minor fixes we'd agreed to. 18:39:42 fantasai: Very close to REC, just a few bugs in impls, and one interop issue to review. 18:39:48 fantasai: So first ask for repub as CR 18:40:04 Rossen_: objections? 18:40:18 RESOLVED: Publish Conditionals 3 as CR 18:40:27 fantasai: Next is Conditionals 4, published as fpwd in march 2020 18:40:37 fantasai: Only contains new selector() function, been shipping in browsers for a while. 18:41:03 fantasai: We resolved to add a bunch of features to conditional, but since this feature is CR-ready, I propose we defer the rest and take this to CR. 18:41:34 TabAtkins: If this is CR-ready, why not fold into 3? 18:41:43 fantasai: 3 is Rec-ready, it'll pull us back 18:41:51 chris: Agree, this sounds like a good plan 18:41:59 Rossen_: opinions or objections? 18:42:25 RESOLVED: Publish a CR of Conditional 4, adding just the selector() function 18:42:50 fantasai: For level 5 we proposed font-format(), font-tech(), @when, @else 18:43:01 fantasai: Propose we publish as fpwd 18:43:04 dlibby has joined #css 18:43:19