IRC log of css on 2021-06-23
Timestamps are in UTC.
- 15:56:58 [RRSAgent]
- RRSAgent has joined #css
- 15:56:58 [RRSAgent]
- logging to https://www.w3.org/2021/06/23-css-irc
- 15:57:00 [Zakim]
- RRSAgent, make logs Public
- 15:57:02 [Zakim]
- Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
- 15:59:30 [Morgan]
- Morgan has joined #css
- 16:00:44 [Rossen_]
- present+
- 16:00:52 [dholbert]
- dholbert has joined #css
- 16:01:19 [argyle]
- present+
- 16:01:23 [leaverou_]
- leaverou_ has joined #css
- 16:01:27 [chrishtr]
- present+
- 16:01:33 [alisonmaher]
- alisonmaher has joined #css
- 16:01:37 [alisonmaher]
- present+
- 16:01:38 [rachelandrew]
- present+
- 16:01:45 [leaverou_]
- present+
- 16:02:07 [dholbert]
- present+
- 16:02:11 [Morgan]
- present+
- 16:02:20 [IanPouncey]
- IanPouncey has joined #css
- 16:02:31 [miriam]
- present+
- 16:02:39 [TYLin]
- present+
- 16:03:41 [plinss]
- present+
- 16:04:27 [fantasai]
- present+
- 16:04:31 [fantasai]
- ScribeNick: fantasai
- 16:04:41 [fantasai]
- Topic: Scribing
- 16:04:46 [chris]
- chris has joined #css
- 16:04:50 [chris]
- present+
- 16:04:52 [smfr]
- smfr has joined #css
- 16:04:57 [fantasai]
- Scribing will not be able to scribe the 9am calls anymore.
- 16:05:02 [cbiesinger]
- present+
- 16:05:09 [fantasai]
- s/Scribing/Dael/
- 16:05:32 [fantasai]
- Rossen: We're going to try to rotate scribes.
- 16:05:34 [leaverou_]
- q+
- 16:05:35 [oriol]
- oriol has joined #css
- 16:06:07 [jfkthame]
- present+
- 16:06:08 [fantasai]
- Rossen: We'll try to organize that outside the calls
- 16:06:10 [oriol]
- present+
- 16:06:11 [smfr]
- present+
- 16:06:17 [emeyer]
- emeyer has joined #css
- 16:06:18 [dbaron[m]]
- Present+
- 16:06:18 [jensimmons]
- jensimmons has joined #css
- 16:07:02 [Rossen_]
- ack leaverou_
- 16:08:40 [fantasai]
- [discussion of scribing candidates]
- 16:08:58 [fantasai]
- Topic: CSS Fonts 5
- 16:09:28 [fantasai]
- chris: Merged PR listed in the agenda
- 16:09:32 [fantasai]
- Rossen: so ready for FPWD?
- 16:09:33 [fantasai]
- chris: yes
- 16:09:39 [fantasai]
- Rossen: Any other comments?
- 16:09:42 [fantasai]
- [silence]
- 16:09:50 [fantasai]
- Rossen: Any objections to FPWD on css-fonts-5?
- 16:09:58 [fantasai]
- RESOLVED: css-fonts-5 to FPWD
- 16:10:08 [fantasai]
- Topic: CSS Color 4
- 16:10:20 [fantasai]
- Rossen: suggestion to add Lea as co-editor
- 16:10:24 [fantasai]
- Rossen: Any reason not to?
- 16:10:27 [florian]
- +1
- 16:10:28 [sanketj]
- sanketj has joined #css
- 16:10:29 [fantasai]
- +1
- 16:10:34 [emeyer]
- +1
- 16:10:34 [dbaron[m]]
- +1
- 16:10:37 [miriam]
- +1
- 16:10:43 [chris]
- +1
- 16:10:48 [fantasai]
- RESOLVED: Add leaverou_ as co-editor css-fonts-4
- 16:10:59 [fantasai]
- Topic: CSS Contain 3
- 16:11:08 [leaverou_]
- s/RESOLVED: Add leaverou_ as co-editor css-fonts-4/RESOLVED: Add leaverou as co-editor css-color-4/
- 16:11:12 [miriam]
- https://drafts.csswg.org/css-contain-3/
- 16:11:48 [chris]
- +1 to fpwd
- 16:11:56 [florian]
- q+
- 16:12:07 [fantasai]
- Rossen: There are some open topics and issues, but is there any reason to hold the FPWD?
- 16:12:18 [fantasai]
- florian: I'm not worried about the issues, it's FPWD, not Last PWD.
- 16:12:18 [Rossen_]
- ack florian
- 16:12:25 [fantasai]
- florian: Concerned about parts that are missing
- 16:12:45 [fantasai]
- florian: description of queries is good enough, but the description of containment is mostly missing
- 16:13:02 [fantasai]
- florian: There are some experiments, maybe something can be written up
- 16:13:10 [chris]
- rrsagent, here
- 16:13:10 [RRSAgent]
- See https://www.w3.org/2021/06/23-css-irc#T16-13-10
- 16:13:14 [fantasai]
- florian: Similarly, state and style querying, they're stated to exist, but there's nothing about how they work at all
- 16:13:29 [fantasai]
- florian: For state and styles, can do it later probably
- 16:13:35 [chris]
- rrsagent, make logs public
- 16:13:39 [chris]
- rrsagent, here
- 16:13:39 [RRSAgent]
- See https://www.w3.org/2021/06/23-css-irc#T16-13-39
- 16:13:40 [fantasai]
- florian: but description of 1D size containment needs something
- 16:13:45 [fantasai]
- Rossen: There are open issues for this
- 16:14:17 [Rossen_]
- ack fantasai
- 16:15:11 [emeyer]
- fantasai: If we have stuff to write, we should usually do that before FPWD. We’re just not sure what to write on this, and that shouldn’t block FPWD as long as there’s enough material to understand what’s missing.
- 16:15:50 [fantasai]
- florian: Fair, but 1D containment for awhile was not thought to be doable.
- 16:16:04 [fantasai]
- florian: So we should have an explanation of how it's become doable.
- 16:16:44 [fantasai]
- Rossen: OK, that's fair. Request to the editors then, to work on this and maybe FPWD next week or so?
- 16:16:47 [fantasai]
- miriam: OK
- 16:17:05 [fantasai]
- Rossen: Appreciate pushback, what Florian is saying is valid.
- 16:17:15 [fantasai]
- Rossen: Hopefully next week we can come back and go to FPWD
- 16:18:07 [fantasai]
- Topic: SVG degenerate aspect ratios
- 16:18:13 [fantasai]
- github: https://github.com/w3c/csswg-drafts/issues/6286
- 16:19:18 [fantasai]
- iank_: We were going to ask Amelia, but she had to defer
- 16:19:21 [fantasai]
- iank_: So it's up to us
- 16:19:30 [fantasai]
- iank_: I posted a comment describing the various behaviors
- 16:19:38 [fantasai]
- iank_: I still slightly prefer the WebKit/Blink behavior
- 16:20:07 [fantasai]
- iank_: ...
- 16:20:36 [fantasai]
- iank_: Reminder that this is just about interop on an edge case for which we have testcases in WPT, not something that impacts web devs
- 16:20:53 [fantasai]
- Rossen: can you summarize?
- 16:21:12 [fantasai]
- iank_: With negative widths, Blink/WebKit will treat as invalid whereas Firefox will treat as zero
- 16:21:28 [fantasai]
- iank_: Blink/WebKit will use the viewbox aspect ratio as a fallback
- 16:21:36 [fantasai]
- iank_: whereas Firefox will have no aspect ratio
- 16:22:04 [fantasai]
- iank_: If there is a negative width/height specified, it gets clamped to zero and then continue
- 16:22:23 [fantasai]
- iank_: Firefox's behavior from there was to treat aspect-ratio as null
- 16:22:33 [fantasai]
- iank_: Whereas when we have a negative width/height, we treat as invalid
- 16:22:40 [fantasai]
- iank_: So we use fallback aspect ratio
- 16:22:59 [fantasai]
- iank_: Separate issue of when we have explicit width of zero and height of 50
- 16:23:11 [fantasai]
- iank_: Blink/WebKit will fallback to viewbox of 1:1
- 16:23:17 [fantasai]
- iank_: and Firefox will behave as if there is no aspect ratio
- 16:23:46 [fantasai]
- Note: spec currently says “If the <ratio> is degenerate, the property instead behaves as auto.”
- 16:24:35 [fantasai]
- Rossen: so your preference is to fall back from degenerate width/height on SVG to the viewbox aspect ratio
- 16:25:11 [fantasai]
- iank_: Right. This mirrors how the aspect-ratio property itself falls back from degenerate ratio value to intrinsic ratio of image
- 16:25:22 [GameMaker]
- GameMaker has joined #css
- 16:25:28 [fantasai]
- dholbert: Are you proposing just for negative case, or also for zero case?
- 16:25:29 [GameMaker]
- present+
- 16:26:25 [emeyer]
- fantasai: So the proposal is to fall back to the intrinsic aspect ratio
- 16:26:32 [emeyer]
- fantasi: In all degenerate cases
- 16:26:37 [fantasai]
- s/intrinsic/viewbox/
- 16:26:43 [fantasai]
- dholbert: OK, would not object to that
- 16:26:45 [emeyer]
- s/fantasi/fantasai/
- 16:27:46 [dholbert]
- iank_, got it, thanks
- 16:28:04 [fantasai]
- fantasai: So the proposal is that in the same way that the aspect-ratio property's explicit degenerate aspect ratios fall back to the intrinsic aspect ratio of the image, the proposal is that a degenerate aspect ratio from an SVG derived from its width/height attributes also falls back: to its viewbox ratio
- 16:28:41 [fantasai]
- RESOLVED: degenerate aspect ratios derived from SVG width/height attributes fall back to viewbox aspect ratio (whether due to negative values or zero values)
- 16:29:06 [fantasai]
- Topic: CSS Contain
- 16:29:14 [fantasai]
- github: https://github.com/w3c/csswg-drafts/issues/6325
- 16:29:32 [fantasai]
- florian: Had not realized earlier, but there's a problem with paint containment
- 16:29:54 [fantasai]
- florian: The point of paint containment is to ensure that if anything changes inside an element with paint containment, nothing leaks in terms of changing painting outside it
- 16:30:18 [fantasai]
- florian: However, filter-effects, when specified on an ancestor of the contained element,
- 16:30:33 [fantasai]
- florian: e.g. consider a large blur radios
- 16:30:55 [fantasai]
- florian: In order to calculate the result of pixels outside the box, need to consider the painting of pixels inside the box
- 16:31:08 [chris]
- q+
- 16:31:09 [Rossen_]
- q
- 16:31:30 [fantasai]
- florian: I think there's no infinite-range filter? So maybe you just need to calculate a margin of error to repaint.
- 16:31:55 [fantasai]
- chris: FE-flood, which can fill an entire region?
- 16:32:04 [fantasai]
- florian: Fills the entire region, but does it take the entire region as input?
- 16:32:05 [fantasai]
- chris: no
- 16:32:10 [fantasai]
- florian: yeah, that's the trouble. Blur does that.
- 16:32:29 [fantasai]
- smfr: Also FE-displacement, which can take arbitrary displacement.
- 16:32:35 [fantasai]
- florian: can be arbitrary, but can't be infinite at least
- 16:33:09 [fantasai]
- Rossen: ... considering chrishtr's comment
- 16:33:26 [fantasai]
- florian: If talking about bg of element or things inside it, issue still applies. Filter on parent will still fetch those
- 16:33:34 [fantasai]
- florian: If you have a 15px blur filter on BODY element
- 16:33:40 [fantasai]
- florian: and somewhere inside tree have a paint-contained element
- 16:33:59 [fantasai]
- florian: then even if it's 3px off-screen, have to repaint it so you know what pixels to spread into the screen area
- 16:34:13 [fantasai]
- florian: Because you have a 15px blur on the BODY, know it's within a range
- 16:34:21 [chris]
- standard deviation of feGaussianBlur is not bounded, but can't be infinite
- 16:34:25 [chris]
- https://drafts.fxtf.org/filter-effects/#element-attrdef-fegaussianblur-stddeviation
- 16:34:31 [fantasai]
- florian: but you have to walk up the tree to figure out what filters might apply
- 16:34:37 [chrishtr]
- I don't think it's a problem.
- 16:34:39 [fantasai]
- smfr: Do any implementers think this is a problem?
- 16:34:46 [fantasai]
- Rossen: do you?
- 16:34:52 [fantasai]
- smfr: I haven't implemented yet, I think it's fine.
- 16:35:12 [fantasai]
- florian: Well, the spec says as soon as element is off-screen can stop painting, that point definitely is not true
- 16:35:29 [fantasai]
- chrishtr: Yes, spec will need to be updated to account for filters.
- 16:35:47 [fantasai]
- florian: Is that good enough? or do we need to find some other solution
- 16:35:49 [fantasai]
- chrishtr: I think it's good enough
- 16:35:59 [fantasai]
- Rossen: How about we start with this, and if we find additional evidence we'll come back
- 16:36:20 [fantasai]
- florian: Alternative might be to say that paint-contained elements are not taken as input into filters
- 16:36:33 [fantasai]
- fantasai: That sounds worse
- 16:36:36 [fantasai]
- chrishtr: Sounds weird
- 16:36:42 [fantasai]
- chrishtr: Browsers can compute this, don't see a big problem
- 16:36:52 [fantasai]
- florian: If you don't think it'll be expensive, then fine
- 16:37:32 [fantasai]
- chrishtr: e.g. browser could apply simple heuristic if page doesn't have an any pixel-moving filters on it, then apply reasonable margin, or whatever
- 16:37:53 [fantasai]
- fantasai: proposal: update spec to acknowledge effects of filters?
- 16:38:13 [fantasai]
- RESOLVED: Update spec to acknowledge effects of filters. No other change.
- 16:39:14 [fantasai]
- Topic: Grid 1 - sum of flex factures < 1
- 16:39:16 [fantasai]
- github: https://github.com/w3c/csswg-drafts/issues/6078
- 16:39:57 [fantasai]
- oriol: The specification says when taking into account the intrinsic contributions of items spanning flexible tracks, we distribute according to flex ratios of the tracks
- 16:40:14 [fantasai]
- oriol: We had a problem that all flexible tracks have 0fr, then have to divide by zero which is not well-defined.
- 16:40:20 [fantasai]
- oriol: So we resolved that in that case the distribution is done equally
- 16:40:31 [fantasai]
- oriol: Now we have the problem that this is not continuous
- 16:40:52 [fantasai]
- oriol: If you have 0fr to 0.00001fr, suddenly change from distributing equally to that track getting all the contribution
- 16:40:57 [fantasai]
- oriol: So proposal is to do the distribution continuously
- 16:41:11 [fantasai]
- oriol: If sum is >= 1 no change from now
- 16:41:19 [fantasai]
- oriol: if sum is zero, equal distribution as before
- 16:41:31 [fantasai]
- oriol: in between, we would [...]
- 16:41:53 [fantasai]
- oriol: we would multiply the space by the sum (which is < 1) and distribute that space proportionally
- 16:41:58 [fantasai]
- oriol: and distribute the rest of the space equally
- 16:42:03 [fantasai]
- oriol: This gives continuity between 0 and 1
- 16:42:31 [fantasai]
- Rossen: Any feedback?
- 16:42:50 [emeyer]
- fantasai: I think it’s a good change that makes sense and gives us continuity between 0 and 1.
- 16:43:24 [emeyer]
- dbaron: Does anything else in CSS act like this?
- 16:43:30 [emeyer]
- fantasai: Flex acts a little like this.
- 16:43:32 [dholbert]
- yeah, the flexbox spec says something similar for flex-grow < 1 -- we should be sure to make this as similar as possible.
- 16:43:36 [dholbert]
- for coherence
- 16:43:37 [fantasai]
- iank_: table percentage distribution acts a bit like this
- 16:44:13 [emeyer]
- fantasai: The main difference between this and flex is that here you distribute all the space but in flex you distribute some of it.
- 16:44:26 [fantasai]
- dbaron[m]: ok, seemed a little weird to only make the change in this place
- 16:44:38 [fantasai]
- iank_: Modulo web-compat...
- 16:44:45 [fantasai]
- iank_: I have a bug about 0frs and things
- 16:44:55 [fantasai]
- iank_: Depending on how widespread that is...
- 16:45:06 [fantasai]
- oriol: I don't think web-compat is problematic for this specific thing
- 16:45:20 [fantasai]
- oriol: Currently implementations are not taking into account intrinsic contributions of items spanning multiple flexible trakcs
- 16:45:26 [fantasai]
- oriol: gridNG implemented the right hting
- 16:45:32 [fantasai]
- oriol: if we had a compat problem, it would be more general problem
- 16:45:50 [fantasai]
- Rossen: not hearing any objections
- 16:46:06 [fantasai]
- RESOLVED: Accept proposal for continuous distribution of space to intrinsic grid tracks
- 16:46:24 [fantasai]
- Topic: baseline-alignment and auto margins
- 16:46:28 [fantasai]
- github: https://github.com/w3c/csswg-drafts/issues/5923
- 16:48:31 [emeyer]
- fantasai: The interaction isn’t well defined. We found there’s a lot missing about grid and auto margins. We made a non-normative section normative. We brought some alignment into harmony with flexbox.
- 16:49:20 [emeyer]
- fantasai: When you have content baseline alignment across multiple items, and you’re trying to add padding, the ‘align-self’ property can move the box.
- 16:49:54 [emeyer]
- fantasai: If boxes are moved, baseline alignment gets weird. We have some working in alignment that says you have to have a coordinating alignment, start or end.
- 16:50:03 [emeyer]
- fantasai: We didn’t account for how auto margins can move boxes.
- 16:50:44 [emeyer]
- fantasai: Option 1, we require a coordinated alignment effect. If the auto margin cause the box to be centered, baseline alignment is diabled.
- 16:50:59 [emeyer]
- fantasai: Option 2, any auto margins diable baseline alignment.
- 16:51:08 [emeyer]
- fantasai: We went with option 1 but are open to other options.
- 16:51:15 [fantasai]
- iank_: We don't implement content baseline alignment yet
- 16:51:19 [fantasai]
- iank_: but I think it sounds fine
- 16:51:32 [fantasai]
- iank_: for self-alignment though, any auto margins don't participate in baseline alignment, right?
- 16:51:49 [emeyer]
- fantasai: If that’s what’s implemented, the spec should say so.
- 16:52:14 [fantasai]
- iank_: If we have align-self: baseline and any auto margin, we ignore that align-self
- 16:52:30 [fantasai]
- fantasai: Right, they're both trying to align the box, so have to pick one
- 16:52:42 [fantasai]
- iank_: but for content alignment, this seems fine
- 16:53:16 [fantasai]
- iank_: One thing I might need to check is, if they participate in the propagation of a baseline
- 16:53:23 [fantasai]
- iank_: but that might be a separate issue...
- 16:54:21 [fantasai]
- [discussion of javier's comments, possible mixing up self- vs content-alignment causing confusion]
- 16:54:33 [dholbert]
- which option are we proposing?
- 16:54:37 [dholbert]
- (1 vs 2)
- 16:54:45 [fantasai]
- I think we're proposing 1, unless anyone has a problem with 2
- 16:54:48 [dholbert]
- (I'm fine with either, I think)
- 16:54:58 [fantasai]
- s/with 2/with it
- 16:55:05 [fantasai]
- Rossen: Anyone else with an opinion?
- 16:55:55 [fantasai]
- proposed: alignment via auto margins disables content baseline-alignment the same way as align-self values with the same effect
- 16:56:29 [fantasai]
- RESOLVED: alignment via auto margins disables content baseline-alignment the same way as align-self values with the same effect
- 16:56:48 [fantasai]
- Rossen: if Javier or Tab has concerns, can come back to it later
- 16:57:56 [emeyer]
- [search for a topic that can be covered in ~3 minutes]
- 16:58:12 [fantasai]
- topic: overflow-clip-margin and border-radius
- 16:59:06 [emeyer]
- fantasai: The border radius applies to the border edge but it affects the padding contant edges. Are you offsetting from the shape of the offsetting box, or against the border edge?
- 16:59:16 [emeyer]
- s/contant/content/
- 16:59:31 [smfr]
- github: https://github.com/w3c/csswg-drafts/issues/5896
- 16:59:44 [emeyer]
- fantasai: The border radius should not be affected by overflow-clip-margin.
- 17:00:28 [emeyer]
- Florian: the question is how these should interact
- 17:00:41 [fantasai]
- florian: There's a formula for rounding, it will give different results depending on how you apply it
- 17:00:50 [fantasai]
- florian: maybe we just need to spec what's implemented so far?
- 17:00:57 [fantasai]
- Rossen: we're at time
- 17:01:11 [fantasai]
- chrishtr: sounds like we should go back to issue
- 17:01:17 [fantasai]
- [note: smfr asked for pictures also]
- 17:01:49 [iank_]
- fantasai: Why was https://github.com/w3c/csswg-drafts/issues/4791 on the adgenda?
- 17:02:17 [fantasai]
- Meeting closed.
- 17:03:11 [emeyer]
- emeyer has left #css
- 17:03:30 [fantasai]
- iank_: good question... I think maye to confirm that we're editing in the 'zero area elements don't take up space' rule?
- 17:04:03 [iank_]
- ok sg.
- 17:52:08 [fantasai]
- Topic: none
- 18:54:49 [Zakim]
- Zakim has left #css
- 19:25:29 [projector]
- projector has joined #css
- 19:26:00 [leaverou]
- leaverou has joined #css
- 19:26:30 [Rossen]
- Rossen has joined #css
- 19:27:00 [shans]
- shans has joined #css
- 19:27:31 [sylvaing]
- sylvaing has joined #css
- 20:11:12 [jensimmons]
- jensimmons has joined #css
- 21:58:47 [jfkthame]
- jfkthame has joined #css
- 23:05:15 [jfkthame]
- jfkthame has joined #css