16:00:16 RRSAgent has joined #css 16:00:16 logging to https://www.w3.org/2022/05/11-css-irc 16:00:18 RRSAgent, make logs Public 16:00:19 Meeting: Cascading Style Sheets (CSS) Working Group Teleconference 16:00:38 emeyer has joined #css 16:01:09 ydaniv has joined #css 16:01:20 oriol has joined #css 16:02:06 present+ 16:02:15 present+ 16:02:15 present+ 16:02:15 present+ 16:02:22 scribenick emeyer 16:02:30 alisonmaher has joined #css 16:02:35 present+ 16:02:38 bmathwig has joined #css 16:03:04 present+ 16:03:09 present+ 16:03:13 flackr has joined #css 16:03:17 present+ 16:03:21 gtalbot has joined #css 16:03:34 present+ 16:03:42 present+ 16:03:48 present+ 16:04:07 present+ 16:04:48 Present+ 16:04:55 Topic: [css-backgrounds] Specify exact pixel values for border-width: thin, medium, thick 16:05:01 Github: https://github.com/w3c/csswg-drafts/issues/7254 16:05:17 fremy has joined #css 16:05:20 present+ 16:05:31 present+ 16:05:36 lea has joined #css 16:05:40 present+ 16:06:12 TabAtkins: Was noticed that we still leave the keyword thicknesses undefined. But all browsers agree on widths at 1px, 3px, 5px. 16:06:39 …Not sure of the exact history, but absent that, the widths are very consistent and don’t see a good reason to leave them undefined. 16:06:51 smfr has joined #css 16:06:57 ack fantasai 16:07:02 present+ 16:07:30 fantasai: Maybe it was that these were like font-size keywords and left open to interpretation. We should maybe recommend but not require specific widths. 16:08:00 My suggested wording was “For Web compatibility, it is recommended that these keywords be mapped to 1px, 3px, and 5px, respectively.” 16:08:00 TabAtkins: On the other hand, we specify a lot of things that could be adjusted by e-readers. I don’t know that this needs to be left undefined. 16:08:21 …I argue we should go stronger than suggested. 16:08:23 ack dbaron 16:08:50 Rossen_ has joined #css 16:08:51 dbaron: This is one of those things that was left up in the air in CSS1, and I don’t remember a proposal to define more precisely. I support the precise definition. 16:09:05 fantasai: If everyone else agrees, that’s fine. 16:09:34 RESOLVED: thin, medium, and thick will be defined as 1px, 3px, and 5px respectively. 16:09:41 chris has joined #css 16:09:44 Topic: [css-lists] counter-reset in UA sheet causing some compat issues. 16:09:51 Github: https://github.com/w3c/csswg-drafts/issues/7227 16:10:06 present+ 16:10:25 Topic: [css-values][css-backgrounds][css-animations][css-transitions][fill-stroke] How to handle linked list-valued properties? 16:10:31 Github: https://github.com/w3c/csswg-drafts/issues/7164 16:12:30 TabAtkins: Issue 4431 asked to turn box-shadow into a shorthand. Very reasonable. Because it’s a list-valued property, we’d have to make all longhands the same. It was brought up by dbaron that whenever you have these groups of longhands and have to sync up all the values, it’s problematic for implementations. 16:13:10 …What exactly are the reasons, and to what degree should we be avoiding them? This touches on some things being proposed and probably coming, like Toggles. It would be good to know how careful we need to be. 16:13:55 dbaron: I’m most familiar with an implementation that no longer exists, so this may be questionable input, but my experience was that it was a LOT of code to implement these. 16:14:24 …Given that, it’s not a that strong a preference. It’s a case where you can get properties where 90% of the work is parsing, not implementation on the other end. 16:14:26 syncing up list-valued longhands is also a problem for authors. This does not match a human's mental model about this at all 16:14:44 TabAtkins: Do you recall if it was a particular type of syncing up, or if it was all equally hard. 16:15:08 dbaron: I think it was they were all equally difficult and yet things were sufficiently different that you couldn’t coalesce. 16:15:31 TabAtkins: We should get input from people working on extant rendering engines. Anyone on the call that knows about that? 16:16:50 vmpstr has joined #css 16:16:55 astearns: Doesn’t sound like we have current implementation experience here on the call. Lea did mention a problem for authors. 16:17:40 +1 leaverou 16:17:41 lea: When authors think about list-value properties, they think of each thing as a unit. They think, I want this image at this size in this place, and the syntax forces them to do things in a way they don’t think about it. 16:18:14 TabAtkins: Agreed. 16:18:25 lea: Right, this makes sense with single values. 16:18:39 TabAtkins: We’re asking if it’s okay to expand for things that are list values. 16:19:14 florian: When used with a single value on the list, it’s useful to break up. Authors can help by defining custom properties that define certain combinations. 16:19:56 TabAtkins: That’s partially true. Authors can work around the present situation, and that’s good. But forcing them to work around a lot when we could take that need away isn’t great. 16:20:21 …If we can avoid this being necessary in common cases, that would be great. 16:20:46 astearns: The issue is whether we’re going to more closely specify computed values of list values. 16:21:22 Sebastian: It’s not completely defined yet but most or all list-valued properties base their logic on the definition for background. So they’re just referring to that and still differ on implementation. Even within one engine. 16:22:07 astearns: The difference is something we need to address even if implementation difficulty is a problem. I’m wondering whether we can get to a resolution about that specific difference and then people can start implementation to give feedback on difficulty. 16:22:18 TabAtkins: I’d like to have an idea of the matrix of current possibilities. 16:22:21 ack fantasai 16:23:25 fantasai: The main question is are the lists truncated or extended at compute time or use-value time? Specification says use-value. It was suggested this might be easier if compute time was used. The difference in behavior will affect inheriting, which most of these properties don’t do, and might affect result of getComputedStyle. 16:23:49 …I don’t think it would be a problem to switch over to say list-matching happens at computed value time, but don’t know if that would make implementation easier. 16:24:06 present+ 16:25:01 astearns: We need to clarify what the current implementations do, how difficult it would be to change, and what we’d like to do in general at computed value time. We should take it back to the issue. 16:25:22 Topic: [css-overflow-3] Clarify padding in overflow content 16:25:38 Github: https://github.com/w3c/csswg-drafts/issues/129#issuecomment-1113489051 16:26:19 iank_: Browser have been very inconsistent about when something is a scroll container to apply block- or inline-end padding. 16:26:49 …Chrome very slowly has been moving towards end padding in both inline and block directions in block layout mode. 16:27:14 nigel has joined #css 16:27:29 https://wpt.fyi/results/css/css-overflow/scrollable-overflow-padding.html?label=master&label=experimental&aligned&q=css-overflow 16:28:07 …I added an exhaustive set of tests that’s linked in the comment. This test creates a zero-area div and then relposed out of the way, but that zero area div is used to push padding out in either inline or block direction is various writing modes. 16:29:31 …As I was reading back through the issue, there was a conception that there are two cases that should behave the same. If you’ve got inline content that’s very long in a scroll behavior, it should behave the same as if it’s been warpped in a div. But the div isn’t intrinsically sized and won’t push parent padding out. 16:29:44 astearns: The test cases you’re talking about are supported by spec text? 16:29:47 iank_: Yes. 16:30:29 florian: We have a conceptual agreement that there might be web compatibility issues because if scrollbars show up where they didn’t used to be, that could be a problem. 16:30:48 iank_: The spec text has written down our curtent behavior. We’re shipping that behavior now. 16:30:53 spec text: "Including this padding is optional for block containers in the inline axis if align-content is normal." with a note saying "hopefully this isn't optional, we're waiting for web compat" 16:30:59 s/We have a conceptual agreement that/We have a conceptual agreement that adding the padding would be good, but/ 16:31:03 s/curtent/current/ 16:31:27 fantasai: Do we want to tighten up the spec now, or wait to tighten it up once there’s field data? 16:31:41 astearns: Has there been enough time to evaluate web compatibility? 16:32:05 iank_: We think so. We shipped the “scary” behavior a couple of months ago and got zero pushback. 16:32:44 florian: If other implementors are happy with it, would be happy to tighten the spec now. 16:33:25 dholbert: This sounds fine to me, speaking from Firefox’s perspective. Having that barrier removed makes this pretty straightforward. 16:33:34 smfr: Seems reasonable. 16:34:52 s/that barrier/the Web-compat concern/ 16:35:27 present+ 16:35:53 RESOLVED: Always require inline-end padding to be added against the inline-end alignment edge for block/flow layout when it’s a scroll container, thus matching the tests. 16:36:10 Topic: [css-pseudo] highlight pseudos and emphasis/underline properties 16:36:18 Github: https://github.com/w3c/csswg-drafts/issues/7101 16:37:44 delan: Highlight pseudos have a restricted subset of applicable properties. Not all properties in the text-decoration spec start with text-decoration-*. Question originally was, can we add those and make them applicable. I initially thought we should. fantasai and rego have mentioned most of the text-emphasis-* properties shouldn’t be applicable. 16:38:08 …Maybe only text-emphasis-color should be applied. That’s where we are now. 16:38:57 astearns: I’m a little worried that the proposed patch is still a little vague. Should we be very specific about what can be applied? 16:39:36 fantasai: I don’t think we should be very specific, because as more things are added elsewhere, user agents should be free to add them here. I think the proposed wording is good enough for now. 16:39:44 +1 fantasai 16:39:51 q+ 16:39:52 delan: In general, we’re happy with all the properties related to line decorations being applicable? 16:39:55 fantasai: Right. 16:40:11 delan: So it’s the emphasis marks that are contentious. 16:40:19 ack smfr 16:40:25 smfr: Are we avoiding properties that can cause ink or layout overflow? 16:40:38 delan: Ink overflow yes, layout overflow no. 16:41:15 fantasai: Ink overflow doesn’t trigger scrollbars. We want to avoid anything that could cause scrollbars. 16:41:31 delan: So actually ink overflow no, layout overflow yes. Sorry, got those backwards. 16:42:13 astearns: Ink overflow is okay, layout overflow is not okay. We could have a note in the specification saying that’s how we determine the list of properties. 16:42:33 delan: We sort of do say that about the layout, but we could be more explicit about ink overflow. 16:42:38 changes in layout overflow implicitly effects layout. 16:42:59 astearns: The bit we have about not affecting overflow layout is sufficient, I think. 16:43:23 RESOLVED: Accept the proposed PR 16:43:35 fwiw fwiw spec says “The highlight pseudo-elements can only be styled by a limited set of properties that do not affect layout and can be applied performantly in a highly dynamic environment—and additionally (to ensure interoperability) whose rendering within the required area is not dependent on the exact (UA-determined) bounds of the highlight overlay.” 16:44:12 Topic: [filter-effects-2] backdrop-filter and visibility 16:44:23 Github: https://github.com/w3c/fxtf-drafts/issues/455 16:45:18 emilio: Browsers are weird and inconsistent about backdrop-filter, which we hit when starting our own implementation. 16:45:50 …We haven’t found content with visibility: visible in the backdrop in the wild, but we should be clear about what should happen. 16:46:58 smfr: My mental model is that you generated a bimap the size of the element with the filter and render the content. So you end with a texture with transparent around the edge and then use that to composite with the backdrop. 16:47:11 …So to my thinking, the Safari behavior looks correct, minus the toggle bug. 16:47:29 emilio: Doesn’t that mean you should render the whole thing even when the backdrop filter is hidden? 16:47:43 smfr: That is a bit weird, I guess. 16:48:11 smfr: I think we’d be willing to change to what you suggest. 16:49:03 emilio: I think determining the visibility by the element the filter is on is simpler, rather than rendering the whole thing. 16:49:41 …Are there other filters that depend on the background behind the element? For most stuff you end up filtering transparent. 16:49:57 smfr: mix-blend-mode is the only one I can think of. 16:50:38 …I think the way forward is to test with the filter property and maybe propose that visibility hidden will always hide the whole backdrop. 16:51:04 dbaron: For what it’s worth, I think of visibility: hidden as a paint-time effect. It should be mostly independent of this compositing things. 16:51:37 …It’s sort of inherited and controls whether things are painted or not. 16:52:02 emilio: That’s what Gecko did, but breaks sites that are set to have backdrops hidden. 16:52:21 …I’ll add some links to examples. 16:52:47 smfr: To dbaron’s point, it’s like saying it’s basically opacity: 0 but affects hit testing. 16:52:54 https://bugzil.la/1765862 is the Gecko bug ftr 16:53:19 astearns: Sounds like we need more information and will need to do testing around filter as well as backdrop-filter. Take back to the issue? 16:53:36 I was saying I think it's like a middle ground between color:transparent and opacity:0 16:53:41 (I might have been muted when I said it) 16:53:51 Topic: [css-lists] counter-reset in UA sheet causing some compat issues. 16:53:57 Github: https://github.com/w3c/csswg-drafts/issues/7227 16:54:46 emilio: This is about pages that do their own counters and adding them makes things add oddly. Not many examples of this, but we found some. 16:55:07 …I tend to think there should be a magical reset, which is unfortunate, but there are things you wouldn’t be able to do otherwise. 16:56:23 TabAtkins: Elika had two objections. 1: this wouldn’t be overridable, as it is now. If you mention a counter, it gets reset. There’s no way to do a no-op. But we got lucky here. We could allow `none` as a counter-reset value alongside integers, which would mean “don’t reset the counter”. 16:57:15 … 2: this triggers on specific HTML elements with no CSS reason for it. We’d like to avoid that if possible. I’m okay with some weird rules, especially around lists, but Elika strongly believes that’s a problem. 16:57:38 fantasai: I think we should avoid it if we can. How strong of a web compatibility problem is it? 16:57:51 +1 to fantasai 16:58:12 …So that’s a question for the Safari and Blink teams. 16:58:14 i'd need Rune to comment. 16:58:36 smfr: No info at the moment from the WebKit side. 16:58:48 astearns: Who should we ping at WebKit? 16:59:02 smfr: I’ll be the conduit. 16:59:06 Question is, can we get Blink and WebKit to align with Firefox on this, or do we really need to introduce this magic into the Web platform 16:59:14 astearns: So we’re taking this back to the issue for more information. 16:59:48 …It might be good to outline the possible ways forward for this there as well. if someone could add a summary after minutes are posted, that might help. 17:00:16 Topic: That’s all, folks! 17:00:23 reminder: please go vote for the MQ3 proposed corrections: https://www.w3.org/2002/09/wbs/33280/mediaqueries-3-proposedcorrections-2022/ 17:01:01 astearns: Similar; I’ll be attending BlinkOn. 17:14:03 emeyer has left #css 17:23:58 nigel has joined #css 17:34:35 nigel has joined #css 17:48:07 nigel has joined #css 18:00:44 nigel has joined #css 19:38:44 projector has joined #css 19:39:14 leaverou has joined #css 19:39:45 Rossen has joined #css 19:40:15 shans has joined #css 19:40:45 sylvaing has joined #css 19:59:45 RRSAgent, make minutes 19:59:45 I have made the request to generate https://www.w3.org/2022/05/11-css-minutes.html tantek 20:29:46 Zakim has left #css 22:06:48 demoNick has joined #css 23:50:59 chris, I noticed that https://www.w3.org/Style/Group/meetings.html is missing the 1998 May 28-29 meeting in Paris, EDF host, agenda: https://lists.w3.org/Archives/Member/w3c-css-wg/1998AprJun/0210.html — could you perhaps add this meeting to the bottom of the list on that Style/Group page?