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