20:53:38 RRSAgent has joined #css 20:53:38 logging to https://www.w3.org/2021/04/08-css-irc 20:53:40 RRSAgent, make logs Public 20:53:41 Meeting: Cascading Style Sheets (CSS) Working Group Teleconference 20:53:58 present+ 20:58:08 Morgan has joined #css 20:58:50 dholbert has joined #css 20:58:52 dauwhe has joined #css 20:59:11 Ah, I'm in now 20:59:17 was wondering why I was alone 20:59:22 GameMaker has joined #css 20:59:29 present+ 20:59:58 heycam has joined #css 21:00:23 present+ 21:00:29 present+ 21:00:36 present+ 21:00:43 present+ 21:00:53 present+ 21:01:08 alisonmaher has joined #css 21:01:19 present+ 21:01:20 dlibby has joined #css 21:01:20 present+ 21:01:21 present+ 21:01:33 present+ 21:02:25 present+ 21:02:34 leaverou2 has joined #css 21:03:48 dlibby_ has joined #css 21:03:48 sanketj has joined #css 21:03:59 myles has joined #css 21:04:07 present+ 21:04:19 present+ myles 21:04:50 present+ 21:05:15 ScribeNick: TabAtkins 21:05:40 Topic: questions about text decorations on highlight pseudos 21:05:50 present+ 21:05:52 github: https://github.com/w3c/csswg-drafts/issues/6022 21:05:56 present+ 21:06:23 castastrophe has joined #css 21:06:31 present+ 21:06:38 present+ 21:06:46 fremy has joined #css 21:06:51 present+ 21:07:04 fantasai: This is about painting order of text decorations on ::highlight pseudos 21:07:12 fantasai: There is a stacking order fo the highlights 21:07:28 fantasai: Original text is bottom layer, and things stacked above that: spellcheck, grammar check, target text, selection, something like that 21:07:32 fantasai: defined in spec 21:08:01 fantasai: When you draw text, text and decorations are also layered spearately: overline, underline, text, strikethru, so over/under are below text and strikethru is above 21:08:13 fantasai: so what's the interaction between these two stacking orders 21:08:45 fantasai: the proposal is that you maintain the same order between over/under, text, and strikethrus 21:09:08 fantasai: highlight pseudos are defined by only the topmost pseudo painting the text, so it's not painted multiple times; in that topmost layer's color 21:09:13 fantasai: but over/under/etc stack 21:09:27 fantasai: If you have spelling, grammar error and are highlighting, you'll see all the different underlines 21:09:58 fantasai: Suggestion is that we do all the underlines in z-index order, then overlines, then the topmost text, then all the strikethrus 21:10:10 fantasai: So CSS2 ordering is the "outer" ordering 21:10:22 fantasai: This makes strikethru always on top, regardless of where it's from. 21:10:24 fantasai: thoughts? 21:10:31 q? 21:10:42 TabAtkins: sounds reasonable to me, ignoring implementation 21:10:53 dholbert: Do you know how browsers currently do? 21:11:05 present+ 21:11:07 fantasai: i haven't tested who supports the various new highlight pseudos yet. 21:11:21 fantasai: I know there is some weird behavior wrt text decorations... 21:11:22 present+ 21:11:43 smfr: can you give the ordering again? 21:11:57 fantasai: custom highlights are between text and built-in higlights, with selection on top 21:12:14 fantasai: under/overlines defined by non-selection highlights will interleave 21:12:28 present+ 21:12:29 fantasai: So proposal is all the underlines, then all underlines, then the text (only once), then all the strikethrus on top. 21:12:44 fantasai: I think this generally makes sense; selection has some trickiness on some platforms that i'm not sure about 21:13:20 TabAtkins: I know iOS has a special ordering for ::selection, but not sure if they do text decorations there 21:13:38 smfr: No, ::selection is drawn on top of the text, and doesn't allow text deco 21:14:11 fantasai: [gives example, i missed some early bits] 21:14:41 i dm'd tantek the ur4l 21:15:04 smfr: So is is true that custom highlights can contribue text decos? And they're sorted in that order with the built-ins? 21:15:06 fantasai: yes 21:15:10 smfr: Okay, now I understand 21:15:30 fantasai: So we could draw the text decors for the lower layers below the text, and draw the text decos for higher layers above the text 21:15:39 fantasai: problem is that strikethru on lower layers would be below the text 21:15:49 fantasai: maybe that's what we want, i dunno 21:16:20 q+ 21:16:58 TabAtkins: I think the fact taht any arbitrary layer can co-opt the text painting role means that having the underlayers draw their strikethrus under the text when necessary is a bad thing; it's not easy to predict what layer will actually draw the text. So we should do the full grouping instead 21:17:01 leaverou_ has joined #css 21:17:38 ack chrishtr 21:17:40 smfr: Okay, as long as ::selection is on top, it's fine for us - the rest can sort their decorations together 21:18:04 chrishtr: before we resolve, i'd like to have the proposed resolution be written down and tested on impls, so i can double check that there aren't issues 21:18:10 chrishtr: no interop or complexity issues 21:18:32 fantasai: The person who raise dthe issue is implementing in Chrome 21:18:33 present+ 21:18:35 ack fantasai 21:18:57 fantasai: I wanna be clear, smfr, that the strikethrus of a custom highlight can paint atop a selection 21:19:23 fantasai: What we could do is special-case ::selection and say that, *aside* from that, everything sorts as described, but ::selection text/etc can paint in a single layer on top of everything else 21:20:02 fantasai: The point that Tab brought up - that the existence of another custom highligh shouldn't cause a previous custom highlight to have its strikethru go below - is correct, but due to the nature of ::selection, that's probably fine. 21:20:15 fantasai: So like if spelling error used a strikethru, that shoudl paint over the text 21:20:29 fantasai: If you have ::text-target as well, we don't want this to cause the spellcheck strikethru to go under the text 21:20:57 fantasai: But if you select the text, and we say that it causes the text to come to the forefront and paint over the decos, I think taht's reasonable behavior and would solve your concerns on iOS. 21:21:27 smfr: We don't paint the text itslef on that top layer, but just the 'blue wash' the highlights it. I'm fine with reordering the decos, as long as the user selection is atop everything else 21:21:39 fantasai: So if you specify ::selection { color: yellow; background: blue; }, waht happens? 21:21:48 smfr: Text will be yellow, don't know if we support the background 21:22:04 GameMaker: Let me check... 21:22:05 q? 21:22:19 florian: So you'e proposing we *allow* ::selection to be on top, or *require* it? 21:22:29 fantasai: I can go either way. I think ::selection overpainting isn't unreasonable. 21:22:43 s/overpainting/overpainting all lower-level text decorations/ 21:23:07 florian: The iOS thing doesn't seem to be *only* on top, it just works differently than the other highlight pseudos. Background isn't 'background', it's a magic transluscent thing, etc. 21:23:09 smfr: Yes, it's special 21:23:43 GameMaker: We already do something special with making even user colors slightly transluscent 21:24:12 GameMaker: It doesnt' affect text, but if you ahve a red background and yellow selection, it'll be a little transluscent [and look a little orange] - it's not solid color 21:24:27 fantasai: Cool, we have another issue on that. So do you paint that transluscent bg over the text? 21:24:39 GameMaker: Yes. 21:24:50 fantasai: So you can't have yellow text if you have a blue bg, it'll always be a little green? 21:25:00 GameMaker: Yes, but it's a subtle effect, not as green an effect as you think. 21:25:25 florian: So based on this I suggest we *allow* ::selection to be painted atop - don't need to clone iOS. 21:25:32 fantasai: I'm fine with that. 21:25:44 fantasai: Proposal is that the "outer" ordering is CSS2 ordering - what type of deco it is. 21:25:52 fantasai: "Inner" sort is what type of highlight you hae. 21:26:14 fantasai: And as an option, the impl *may* paint all the aspects of the ::selection as a topmost layer above the rest. 21:26:47 Rossen_: Objections? 21:26:48 fantasai: let's handle background in a separate issue though 21:27:07 chris has joined #css 21:27:25 chrishtr: I'd just like to have some time to review 21:28:11 [chatter about this being provisional for review or what] 21:29:34 present+ 21:29:57 RESOLVED: Text decos of highlight pseudos sort *outermost* by deco category (per CSS2) then by highlight type. ::selection has an out to allow it to paint on top of everything else. 21:30:48 Topic: maplike vs setlike 21:30:53 github: https://github.com/w3c/csswg-drafts/issues/5910 21:31:25 fantasai: A custom highlight is made of three things: the Highlight object (a bunch of ranges), then a priority to know where it stacks, then a name so it's addressable from teh stylesheet 21:31:30 s/fantasai/florian/ 21:31:38 florian: Question is how to group these 21:31:47 florian: Could say priority is an attribute of the highlight object 21:31:51 florian: But what about the name? 21:32:00 florian: One is a Map where key is name and vlaue is Highlight 21:32:13 florian: Another is a Set where name is a property of Highlight. 21:32:30 s/maplike vs setlike/Highlight API collection, maplike vs setlike/ 21:32:31 florian: If you use a Map, you coudl potentially register the same highlight multiple times under multiple names. 21:32:35 dauwhe has joined #css 21:32:38 florian: Has some odd ergonomics for user. 21:33:03 florian: You style ::custom-spelling and ::custom-grammar, but they have the same priority, it's got some odd stacking. 21:33:12 florian: Not *hard* to explain or implement, just unintuitive. We consider it a footgun. 21:33:25 florian: So we decided to make it impossible to set up the same highlight multiple times. 21:33:44 q+ 21:33:46 florian: So we switched to a Set that throws if you register multiple times. We could also have a Set that just ignores if you set multiple. 21:33:54 florian: Or a Map that throws if you register multiple. 21:34:01 florian: Or we could just ignore it all and let it happen. 21:34:05 q+ 21:34:16 florian: Currently the spec has it as a Set where name is an attribute, and it throws if you register the same thing twice. 21:34:21 florian: But that's unusual. 21:34:32 florian: Simplest is a Map that doesn't throw, but that might not make sense. But maybe that's fine. 21:34:47 hober: This came up in a TAG review 21:34:52 ack hober 21:35:03 hober: been several months so convo is swapped out by now... 21:35:25 hober: But i remember being surprised about, it would be common to write code that says "have I registered this yet? No? then add it" 21:35:40 hober: Might have a few libraries that use highlights for various purposes, and they don't want to clobber themselves 21:35:45 hober: With a Map that's super easy 21:35:51 hober: just check the key 21:35:55 hober: With a set you have to iterate 21:36:09 hober: We thought that's weird, we expected checking to see if it's registered to be a common op 21:36:32 hober: I think we saw the ergonomic downside as more of dev inconvenience than the dev registering the same thing multiple times 21:36:44 hober: So I think we're inclined to just let the dev hurt themselves if they want to register things twice 21:36:53 hober: Not a hill we want to die on, just want common operations to be easy. 21:37:10 q+ 21:37:11 florian: With time that has passed since original decision, sounds good to me 21:37:17 ack leaverou_ 21:37:29 leaverou_: Agree with hober, she said most of what I wanted to 21:37:40 leaverou_: I think using try/catch every time you register a highlight isn't ideal 21:37:54 leaverou_: I think there might even be use-cases for doing this - providing aliases for the same highlight 21:38:25 leaverou_: Sanket pointed out the problem is the priority (can't set it in that case), but that sounds like priority is associated with the name rather than the Highlight... maybe it's misplaced? 21:38:36 florian: I thougth about that, but then how would you set it? 21:38:55 sanketj: Design I had in mind originally was every Highlight has one name and one priority, and that's reflected in the spec we have today. 21:39:06 present+ 21:39:13 sanketj: You could say the prio is associated with the name rather than the highlight, but you'd need a different data structure 21:39:31 Rossen_: What's your position on the change to use Map? 21:39:33 sanketj: likely want an options arg for the ctor, e.g. "new Highlight({name: 'hi', priority: 2})" 21:39:58 Yeah, it'd take a sequence or options object instead, i guess 21:40:25 can't it be a maplike with an additional convenince function? 21:40:26 sanketj: hober and leaverou_'s argumetns make sense. And I think associating prio with highlight is convenient; I'd prefer not to change that if there's not a big reason to 21:40:42 sanketj: If we do allow a highlight to have multiple names, what's the messaging around it? 21:41:03 sanketj: Lea mentioned a use-case; I always thought about this as making a separate Highlight object, then they can prio against each other properly 21:41:19 sanketj: Sounds like you were suggesting having the same highlight be prio'd two different ways, which might be more complicated 21:41:25 q? 21:41:32 florian: I think the proposal is to just do it the naive way - same highligh under two names would share prio 21:41:44 florian: So painting order would use the fallback of registration order 21:41:55 florian: A bit limiting, but it's not there *because* of the use-case, it's just the natural fallout. 21:42:02 florian: And if people find ways to make it nice for them, sure. 21:42:06 +1 to florian 21:42:10 florian: Probably it's a footgun, but possibly there's good things to come out of it 21:42:17 e.g. ```interface Highlights { readonly maplike; addHighlight(Highlight or HightlightDictionary); }``` 21:42:19 sanketj: Do we want something in the spec warning against it? 21:42:26 Yes, this would need to be a note in the spec 21:42:36 sanketj: Seems could be unexpected results 21:42:50 florian: Don't think we should have a normative thing, but a Note saying this would be odd if you did it woudl be approriate 21:42:52 leaverou_: agreed 21:43:02 sanketj: We could just document the case from the issue 21:43:04 sanketj: Seems fine 21:43:13 Rossen_: Sounds like we're approaching a reoslution? 21:43:30 iank_: I left some IRC comments 21:43:54 iank_: You don't need to strictly make it a setlike - could add convenience functions 21:44:02 iank_: Dunno if this changes the discussion particularly 21:44:14 florian: Not sure what's being proposed to help here 21:44:53 iank_: could make it a readonly maplike, then provide an add() that takes a Highlight, plus a remove() 21:45:02 florian: Does that bring us back to what we have today? 21:45:34 sanketj: I think the impl is that the name would live on the highlight, and also be exposed as a key on the readonly maplike 21:46:04 TabAtkins: I don't think the3re's enough worth innovating in data structures, versus just letting authors do this 21:46:36 porposed resolution: Switch Highlights back to a maplike of (name)=> Highlight, add a Note about what happens if you register the same highlight with multiple names 21:47:33 leaverou_: Just wnat to make sure that if you register to an existing key, it doesn't throw - that was mentioned in the ear4ly options 21:47:39 florian: Right, normal Map behavior 21:47:48 RESOLVED: Switch Highlights back to a maplike of (name)=> Highlight, add a Note about what happens if you register the same highlight with multiple names 21:48:29 Topic: Ensuring selection foreground/background contrast 21:48:38 github: https://github.com/w3c/csswg-drafts/issues/6150 21:49:21 chrishtr: ::selection can set fg and bg color. What happens if they're not contrasty enough? 21:49:28 chrishtr: If they're the same, you can't read the text 21:49:44 chrishtr: For that reason, wk/chrome has special code to invert one of them in that case 21:50:15 chrishtr: There's at least one site reported as "can't see selections" in Gecko, because fg and bg were both white, and dev might not have noticed it in testing because wk/chrome intervene and fix it 21:50:33 chrishtr: so should we remove the intervention, or require it? 21:50:46 q+ 21:50:48 ack sanketj 21:50:51 ack fantasai 21:51:00 fantasai: So someone was using white ::selection 'background' and 'color'. This works in wk/chrome because neither uses an opaque bg 21:51:12 fantasai: Gecko, following the spec, paints the color as specified 21:51:44 fantasai: So that brings up an interesting question of - we need to decide either the specified bg is what's used, or the bg is modified in some way 21:51:53 fantasai: If UA's differ, you'll get these interop issues 21:52:06 fantasai: They're either assuming the tranparency is there, or assuming it's not, and it might not work in the other cases 21:52:16 fantasai: So we need to have interop on the alpha of the bg color in ::selection 21:52:23 CSS Color 4 "The following system color pairings are expected to form legible background-foreground colors ... Highlight background with HighlightText foreground. 21:52:32 chrishtr: Our code is flipping the color, definitely - I checked 21:52:40 q? 21:53:06 chris: In Color 4, certain combos of system colors are required to be legible 21:53:20 q? 21:53:25 chris: One of those pairings is HighlightColor and HighlightBackground 21:53:31 q+ 21:53:39 WebKit is using semi-transparent white, though, and that's probably what the author was expecting 21:53:39 TabAtkins: This is about author-chosen colors tho 21:53:42 chris: Ah, sorry 21:53:57 q+ 21:54:09 leaverou_: I'm skeptical about UA intervening in author choices here... 21:54:21 leaverou_: Sounds like this issue happened because author was setting bg and not text? 21:54:25 fantasai: They were setting both 21:54:27 q? 21:54:29 ack chris 21:54:31 ack leaverou_ 21:54:48 leaverou_: Wonder if we could set better defaults? Set default bg to always contrast with text color using Color 5 colors 21:55:06 This is a case where the author explicitly asked for white text and white background 21:55:09 https://bugzilla.mozilla.org/show_bug.cgi?id=1589539#c5 21:55:13 myles: We think the spec should say *at least* that UAs should do something to make sure text is legible when highlighted 21:55:19 myles: No opinion on how far the spec shoudl go 21:55:29 myles: If the spec had an algo, that's fine 21:55:37 myles: If the spec just says "UA must do something", that's fine with us too 21:56:00 florian: Gets interesting when fg and bg are coming from different pseudos 21:56:16 florian: As an author you ought to set fg and bg together, but you can make this mistake 21:56:41 florian: So ahving a req that the UA must ensure the topmost fg and bg colors must contrast... 21:57:09 florian: Just making sure it's clear this can happen accidentally from different pseudos interacting, and that should be considered 21:57:17 fantasai: Cause of the bug: 21:57:27 fantasai: Person filing was assumign a semi-transparent whitewash with white text 21:57:29 fantasai: Chrome used to do that 21:57:39 fantasai: In Moz, it was rendering as solid white on white 21:57:42 maybe we should adopt the previously proposed currentBackground keyword? Then UA default could be color: color-contrast(to 4.5 currentBackground vs white, black); (or appropriate system colors) 21:57:51 https://bugzilla.mozilla.org/show_bug.cgi?id=1589539#c5 21:57:54 fantasai: Author literally wrote ::selection { color: white; background: white; } 21:58:20 fantasai: They were expecting a particular rendering, which they were getting in Chrome and WebKit, but not Gecko, bc both were applying magic opacity 21:58:28 fantasai: So I think ti's harmful for some browsers to have magic opacity and osme not 21:58:43 agreed with fantasai that if author specifies both, they should be respected 21:58:58 fantasai: So we need to align on some behavior here. 21:59:37 florian: I agree the state we're in is bad. Your proposal is one possibility. Myles's too - require all browsers to require legibility, but not specify how 22:00:02 florian: So if you're in a non-legible combo (for any reason, including the browser applying magic opacity or wahtever), the UA must change something to make it legible. 22:00:11 florian: Mandating one algo woul be great, but not sure we can do that. 22:00:44 fantasai: So example: authors choose a semi-transparent color for the bg. It's just enough to show a selection, but not enough to be probablematic against the bg 22:01:12 fantasai: In WK browsers, they'll compound the opacity, so it's even more faint of a bg. No legibility problem, but there's no longer a visible highlight, which is another problem. 22:01:26 fantasai: Now author has a problem despite making good choices originally. 22:01:38 fantasai: Whether we adjust or not is fine, but having it work differently across browsers is problem. 22:01:41 myles has joined #css 22:01:52 florian: So from Apple pov, if we specify a particular transparency, is that a problem for y'all? 22:02:18 smfr: Unsure if we have an answer to that. We want our selection to match the OS convention, so there's magical opacity 22:02:30 smfr: Dont' know if we'd be willing to turn off magic opacity in some cases, seems hard... 22:02:45 florian: If we specify exactly *your* opacity, woudl that work? Or do you reserve the right to change the exact method? 22:02:53 smfr: I don't think it's just opacity, there's a blend mode involved too 22:03:00 florian: So your behavior is too magic to spec? 22:03:16 smfr: Could probably spec it, but not all platforms might want to match the Mac OS conventions 22:03:34 I agree with fantasai there 22:03:37 fantasai: Don't think people have problems with amtching OS conventions by defautl, just when the author says something specific, it should be predictable 22:03:51 s/predictable/predictable across platforms/ 22:03:56 smfr: Generally we solve this by adding a CSS property that lets authors opt out of the correction 22:04:24 fantasai: We do have a long-standing request for a bg-opacity property 22:04:35 florian: So a default value of "auto" that can do magic things in some OSes? 22:04:37 fantasai: Maybe. 22:04:41 q? 22:04:48 florian: I think we should explore more in this area. 22:04:58 florian: We *will* get interop problems if we don't ahve something like this. 22:05:03 Rossen_: So should we take this back to the issue? 22:05:05 q+ 22:05:17 q- myles 22:05:25 ack hober 22:05:31 hober: I think this action sounds reasonable. 22:05:49 hober: Could we resolve on the direction to go in - to require UAs to ensure there be sufficient contrast, exact details TBD? 22:05:56 hober: UAs do need to do something, right? 22:06:25 florian: I think elika pointed out that if you do that, you can hit the opposite situation, where a good fg/bg contrast gets magicked into a lack of contrast between selection and page bg? 22:06:32 hober: I think we can word the reoslution to avoid that 22:06:42 hober: I hope we can end up with simple details 22:06:51 hober: We just shouldn't punt on this, right? 22:07:04 fantasai: Yes, shouldn't punt. I just think I can throw a lot of wrenches into this. ^_^ 22:07:22 fantasai: [another example] 22:07:31 fantasai: So there will be a lot of thought needed for the details 22:07:42 fantasai: And I think we should start be having an ability for authors to specify a more exact interop 22:07:48 if you do it post composite you could but it would be a bad perf path but would ensure contrast so the text scenario would result in no adjustment by the UA 22:07:56 florian: I think we overall agree, just resolving to "browsers must do X" is a little premature at the moment 22:08:12 [another example] = author intended transparent selection background (so UA detection of no contrast between selection bg and page would be a problem) and is using color change on the text to indicate the selection 22:08:27
22:08:30 Topic: end 22:08:41 we discussed having a smart focus rect to ensure contrast and decided to not do it since to truly ensure contrast you'd need to do it post composite 22:12:03 s/the impl is that the name would live on the highlight, and also be exposed as a key on the readonly maplike/the impl is that the name would not live on the highlight, but be the key to the maplike/ 22:12:32 No I was describing Ian's thing, sanket 22:12:55 the readonly maplike would be a view into the underlying setlike unique'd by name 22:13:42 dauwhe has joined #css 22:15:18 Dael: don't make the above replacement 22:19:03 present+ 22:20:41 @tabatkins, I see. It got minuted as "sanketj: " 22:21:28 hm, indeed, was that not waht you were describing? 22:21:41 apologies if I mistranscribed, then 22:22:52 present+ 22:23:32 The replacement above is what I was intending to say. We should fix that up, unless Tab was intending to transcribe someone else. 22:23:52 scribenick: dlibby_ 22:24:25 Topic: Are normal and light synonymous for color-schemes? 22:24:31 github: https://github.com/w3c/csswg-drafts/issues/5898 22:25:39 dholbert has joined #css 22:26:03 TabAtkins: Answer is no, not the same, not all UAs display on a light background by default 22:26:25 TabAtkins: despite current browser that ship do this, this is not a requirement 22:26:36 emilio: tons of things break if you use dark background by default 22:26:45 TabAtkins: indeed, but works reasonably 22:27:12 florian: users of console-based UAs tend to expect oddness, VR browsers might not assume this as well 22:27:34 emilio: how many of these will implement color scheme, and prefers-color-scheme media feature? 22:27:54 TabAtkins: more VR UAs will show up and assumptions they make are still valid to consider 22:28:17 fantasai: some UAs are not browsing the web, might be browsing books, requirements different from browsing the web in general 22:28:32 Rossen_: back to TabAtkins' short original answer: "no" 22:29:00 Rossen_: perhaps a bit more is needed, proposed resolution is no, due to various requirements across UAs and devices 22:29:16 Rossen_: other comments, objections? 22:29:36 RESOLVED: normal and light are not synonymous, they will stay 22:29:45 Topic: Combine forced-color-adjust and color-adjust properties somehow? 22:29:56 github: https://github.com/w3c/csswg-drafts/issues/3880 22:30:56 leaverou: I was in the breakout, there are many use cases where you want both. should be an easy way to enable both 22:31:05 leaverou: perhaps a shorthand would provide flexibility 22:31:37 TabAtkins: i think these are sufficiently different that we shouldn't turn them off at one. printing well is conceptually similar but different that color adjustment for forced colors 22:32:00 TabAtkins: wouldn't want to trigger one, but accidentally the other (i.e. if authors optimize for screen media, not print) 22:32:10 TabAtkins: suspect they shouldn't be done at the same time 22:32:32 Rossen_: in two environments, the properties have almost opposite effect (on-by-default vs. off-by-default) 22:33:03 Rossen_: historically they have different usage as well, increasing adoption, i'm on the side of keeping these separate for the same reasons 22:33:28 fantasai: agree with reasons to keep them separate. color swatches is a use case for using them in both situations. 22:33:56 fantasai: would be nice for authors be able to have something that works for future color adjustments, but currently color-adjust is specific to print 22:34:04 s/a use case/the one use case I can think of / 22:34:21 Rossen_: Proposed resolution no change - any objections? 22:34:41 RESOLVED: no change, keep both forced-color-adjust and color-adjust 22:35:05 Topic: Capitalization: "User Agent" or "user agent" 22:35:13 github: https://github.com/w3c/csswg-drafts/issues/5200 22:35:48 q+ 22:36:04 florian: writing some spec text and wanted consistency, but we're completely inconsistent everywhere. using fully lowercase a bit more often 22:36:26 florian: hard to do this in an automated fashion. uppercase can be done unconditionally. maybe we don't care 22:36:49 hober: i don't actually care, can't pretend. w3c style guide says lowercase so lets follow that 22:36:58 hober: should update the guide or follow 22:37:19 regex FTW 22:37:23 florian: hard to do in practice and hard to enforce. you might automate replacement by being sentence aware 22:37:44 fremy: not sure i follow, maybe we can put up a warning, think its doable 22:37:50 florian: yes sounds doable 22:38:04 Rossen_: do we care enough to resolve one way or another 22:38:17 TabAtkins: I volunteer florian to implement the lowercasing 22:38:32 I'm fairly sure zero interop bugs are caused by this 22:38:53 s/not sure i follow/user agent at the start of a sentence would be User agent not User Agent, so User Agent is detectably wrong/ 22:38:59 RESOLVED: Match the style guide of lowercase for "user agent" 22:39:14 Topic: [css-values-4] inherit() function: like var() for parent value, for any property 22:39:23 github: https://github.com/w3c/csswg-drafts/issues/2864 22:40:04 leaverou: numerous request to extend var() to arbitrary properties, can't do this generally due to cycles. seems to be a less powerful pattern that may be possible 22:40:17 leaverou: we can use it to get the value from the parent 22:40:33 dauwhe has joined #css 22:40:38 leaverou: should we do work to pursue this? I volunteer if consensus that it is a good idea 22:40:50 leaverou: I can point to many use cases, in case they are not obvious. 22:41:04 q? 22:41:08 ack hober 22:41:11 emilio: seems implementable, but we want it to work like var() at the token level 22:41:25 emilio: you need to define for each property how it serializes, etc.. it's a lot of work 22:41:34 leaverou: would be equivalent to the token sequence 22:41:55 emilio: but what sequence? font-stretch as an example. you need to get interoperable serialization for all properties 22:42:03 leaverou: don't you need that anyways? 22:42:12 emilio: yes, just pointing out it is a lot of work 22:42:25 Rossen_: this is indiciative of how long it might take to implement 22:42:33 emilio: seems fine to implement 22:42:37 q+ 22:42:41 [what emilio is saying is that as a prerequisite to this, we need to get interop on serialization of all properties, which is something we don't have yet] 22:43:11 [that requires a bunch of spec work, QA work, and implementer follow-up to fix all the inconsistencies] 22:43:29 castastrophe: for container queries, computing ancestors comes down to a 'contract' as things are flagged as cascading 'down' 22:43:38 q? 22:43:38 q+ TabAtkins 22:43:46 castastrophe: can we use a similar mechanism (!inherited) to indicate such a pattern 22:43:50 ack castastrophe 22:43:52 ack TabAtkins 22:44:13 emilio: i don't think that is necessary, as long as you inherit with the same property, you already need the complete ancestor style 22:44:19 q+ 22:44:26 TabAtkins: shouldn't need that since there is no circularity 22:44:28 ack smfr 22:44:57 q? 22:45:02 smfr: concerned about impl complexity vs. usefulness. in the example, you could say inherit z-index to a font property 22:45:22 leaverou: there are use cases that you have to use a mixture of properties 22:45:57 emilio: this would be implemented via existing serialization rules, so this doesn't explode, you don't convert between properties, use serialization syntax, then reparse token stream 22:46:16 leaverou: in most cases you'll probably end up with an invalid declaration 22:46:40