15:55:57 <RRSAgent> RRSAgent has joined #css
15:55:57 <RRSAgent> logging to https://www.w3.org/2021/08/11-css-irc
15:55:58 <Zakim> inviting RRSAgent
15:56:00 <Zakim> RRSAgent, make logs Public
15:56:00 <Zakim> Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
16:00:11 <plinss> present+
16:00:37 <argyle> present+
16:00:56 <jensimmons> present+
16:00:57 <sanketj> sanketj has joined #css
16:01:00 <GameMaker> GameMaker has joined #css
16:01:08 <GameMaker> present+
16:01:25 <vmpstr> vmpstr has joined #css
16:01:42 <dlibby> dlibby has joined #css
16:02:20 <emilio> present+
16:02:27 <Rossen_> present+
16:02:30 <dlibby> present+
16:02:50 <jfkthame> jfkthame has joined #css
16:03:07 <bradk> bradk has joined #css
16:03:08 <dholbert> dholbert has joined #css
16:03:10 <smfr> smfr has joined #css
16:03:18 <smfr> present+
16:03:21 <TYLin> present+
16:03:24 <sanketj> present+
16:03:27 <jfkthame> present+
16:03:28 <fantasai> Scribenick: fantasai
16:03:30 <bradk> present+
16:03:51 <fantasai> Rossen_: Any other items?
16:03:55 <fantasai> plinss: wanted to talk about draft server
16:04:27 <dholbert> present+
16:04:46 <vmpstr> present+
16:05:04 <fantasai> Topic: content:none
16:05:12 <Rossen_> github: https://github.com/w3c/csswg-drafts/issues/6503
16:05:28 <bradk> bradk has joined #css
16:05:33 <fantasai> emilio: We implemented it, broke tons of sites
16:05:46 <fantasai> emilio: We should at least fix the spec to say that content:none has no effect on non-pseudo elements
16:06:01 <fantasai> emilio: It's a bummer because 'content' does have effects on some elements
16:06:08 <fantasai> emilio: We could add another value to the content property to represent that behavior
16:06:27 <fantasai> Rossen_: how broken?
16:06:34 <fantasai> emilio: content:none suppresses boxes for children of element
16:06:47 <fantasai> emilio: sites were specifying it on a bunch of stuff using e.g. * { content:none; }
16:07:12 <fantasai> emilio: initial value is normal
16:07:26 <futhark> futhark has joined #css
16:07:30 <fantasai> florian: I wouldn't have expected it to be Web-compatible, has been a no-op for a long time, so mistakenly applied in lots of places
16:07:42 <fantasai> emilio: any objection to change the spec to match reality?
16:07:49 <fantasai> emilio: other question is should we add a new value
16:07:56 <Rossen_> q?
16:08:00 <futhark> present+
16:08:06 <Rossen_> ack fantasai
16:08:12 <florian> fantasai: we should spec it
16:08:24 <florian> fantasai: if we need a new keyword, I'd suggest "empty"
16:08:46 <florian> fantasai: not too sure what the use cases are though
16:09:02 <fantasai> Rossen_: any other comments?
16:09:27 <alisonmaher> alisonmaher has joined #css
16:09:31 <fantasai> emilio: not sure we should even add the keyword, we implemented for completeness
16:09:34 <rachelandrew> it would be interesting to see if authors have use cases
16:09:48 <fantasai> ??: I think there could be some interesting cases for having the box but not its contents
16:09:59 <bradk> That was me
16:10:00 <emeyer> emeyer has joined #css
16:10:01 <astearns> s/??/bradk/
16:10:01 <TabAtkins> we can just leave the discussion out of this issue for now, and open a fresh issue arguing for adding this new keyword
16:10:06 <fantasai> emilio: also interesting question about interaction with content-visibility:hidden
16:10:06 <TabAtkins> no reason to tie it to this discussion
16:10:16 <astearns> +1 to new issue for use cases
16:10:32 <fantasai> bradk: maybe ask authors
16:10:48 <emilio> +1
16:10:50 <fantasai> Rossen_: ok, let's deal with that in a separate issue
16:11:05 <fantasai> RESOLVED: spec content:none as having no effect on elements
16:11:35 <fantasai> Topic: identity transforms
16:11:41 <fantasai> github: https://github.com/w3c/csswg-drafts/issues/6488
16:12:04 <fantasai> emilio: I wasn't on last week's call
16:12:10 <fantasai> emilio: seems fine to add a new value to represent this
16:12:17 <fantasai> emilio: ...
16:12:24 <smfr> q+
16:12:35 <Rossen_> ack smfr
16:12:40 <fantasai> smfr: I'm ok with something like perspective(infinity)
16:12:43 <astearns> we ran out of time last week to get to a resolution
16:12:52 <fantasai> smfr: I do wonder about the lack of units, wonder if it adds complexity to animations and blending
16:13:04 <fantasai> TabAtkins: perspective is normalized to matrix, so shouldn't be a problem
16:13:38 <fantasai> TabAtkins: addition with infinity would swamp whatever value the other side was, so don't have to worry in that case either
16:13:47 <fantasai> Rossen_: sounds like we're going forward with infinity?
16:14:26 <fantasai> astearns: there was also the suggestion of perspective(none)
16:15:02 <fantasai> TabAtkins: smfr brought up that animation-iteration-count uses 'infinite' whereas calc() uses 'infinity', so 'none' would dodge the issue
16:15:06 <jfkthame> +1 to perspective(none)
16:15:10 <fantasai> Rossen_: is everyone ok with none?
16:15:16 <fantasai> RESOLVED: Add perspective(none)
16:15:36 <fantasai> Topic: Compressible elements with aspect ratio
16:15:49 <fantasai> github: https://github.com/w3c/csswg-drafts/issues/6341
16:16:03 <fantasai> Rossen_: is this ready for discussion?
16:16:23 <fantasai> github: none
16:16:52 <fantasai> Topic: Draft Server
16:17:05 <fantasai> plinss: As many noticed, drafts server has been unreliable lately
16:17:13 <fantasai> plinss: fundamental issue is it puts a lot of load on database
16:17:20 <fantasai> plinss: when get hit by ton of crawlers
16:17:36 <fantasai> plinss: fix is to make code less reliant on database, serve static files
16:17:44 <fantasai> plinss: unfortunately it's 1-2 weeks of time for me
16:17:50 <fantasai> plinss: which I can't take off from work
16:18:04 <fantasai> plinss: if anyone wants to sponsor it, I can just do it
16:18:14 <fantasai> plinss: server also needs a bunch of other tuning, which is why estimating up to 2 weeks work
16:18:22 <fantasai> plinss: alternatively, look for a different solution
16:18:51 <fantasai> plinss: but that would not have the same features as the draft server, e.g. regenerating to ensure cross-links continue to work
16:18:54 <tantek> tantek has joined #css
16:19:05 <fantasai> plinss: I would not be doing the alternative work. I would not recommend that.
16:19:10 <fantasai> plinss: my recommendation is to just fix the infrastructure
16:19:45 <fantasai> gsnedders: Alternative where any of us, not just plinss, can do maintenance might be better.
16:19:56 <fantasai> plinss: either way, someone else has to do the work
16:20:07 <fantasai> plinss: doesn't have to be done by me, I'm happy to give access to the current infrastructure
16:20:14 <fantasai> plinss: just I'm the most familiar with it, so can do it the fastest
16:20:51 <tantek> present+
16:20:58 <TabAtkins> yup, will look into this
16:21:07 <fantasai> plinss: so looking for anyone to sponsor the work, or to take on the work for setting up alternatives
16:21:18 <bradk> bradk has joined #css
16:22:02 <fantasai> Topic: replaced elements percentage-sized within rows
16:22:07 <fantasai> s/rows/grid areas/
16:22:15 <fantasai> github: https://github.com/w3c/csswg-drafts/issues/6278
16:22:32 <fantasai> github: https://github.com/w3c/csswg-drafts/issues/6278
16:23:19 <fantasai> iank_: There's concept of compressible elements, if you put a percentage width in one axis, it will compress to min-size
16:23:35 <fantasai> iank_: Chrome did a bunch of fixes in this area (replaced elements) recently
16:23:45 <fantasai> iank_: that brought our behavior more inline with the spec here
16:23:59 <fantasai> iank_: which applied an automatic minimum size in this case
16:24:11 <fantasai> iank_: web author found this really surprising behavior, filed issue
16:24:16 <fantasai> iank_: Question is do we want to ...?
16:24:22 <Rossen_> q
16:24:34 <fantasai> iank_: Firefox behaves as expected, because there is some behavior around transferred sizes that they still don't do correctly.
16:25:02 <florian> s/.../follow the spec, and if not, how do we match the author's expectation/
16:25:20 <fantasai> https://github.com/w3c/csswg-drafts/issues/6278#issuecomment-863439988
16:25:21 <florian> fantasai: tab and I looked over this
16:25:30 <florian> fantasai: our conclusion is summarized in the issue
16:25:44 <florian> fantasai: the author's expectation is reasonable in this case
16:26:05 <florian> fantasai: chrome and firefox used to match that, until chrome fixed to match the spec
16:26:44 <florian> fantasai: [explains example]
16:28:53 <fantasai> [ fantasai insert summary later]
16:28:59 <Rossen_> 1fr has an auto min implied and that's what's causing the breakage.
16:29:44 <Rossen_> fantasai: the auto min size is supposed to be xtronger constraint of specified height... and that's what's happening because the % isn't taking affect
16:30:28 <fantasai> s/xtronger/weaker/
16:30:31 <Rossen_> fantasai: the sln we are interested in is to make % resolve against min definite height. resolving against 0 is to clamp the min size. do it for compatible elements and potentionally all els
16:31:15 <Rossen_> fantasai: does that makes sense?
16:31:26 <Rossen_> iank_: I did :)
16:31:34 <TabAtkins> Summary: During Grid layout, we first lay out to figure out row heights, then lay out given that height to figure out column widths (then maybe do both of those again). A 1fr item size has an automatic minimum; during the first layout both dimensions are unknown so the auto-min doesn't trigger, but in the second layout there is a height so it *does* trigger, and this ends up giving us the bad behavior where the height is frozen as "large"
16:31:44 <fantasai> s/does that makes sense/did everyone follow, or should I explain something again
16:31:53 <fantasai> iank_: I'd be concerned about doing this for all elements
16:32:00 <fantasai> iank_: if we do, should only do for compressible elements
16:32:02 <TabAtkins> But our intention was always that auto-min be a relatively weak constraint - it shouldn't be taken as gospel in the middle of this algo and have this effect.
16:32:26 <fantasai> Rossen_: what's downside to doing it for all elements?
16:32:35 <fantasai> iank_: Currently, if you've got a non-replaced element with width:100%
16:32:40 <fantasai> iank_: that would change behavior pretty drastically
16:32:59 <fantasai> fantasai: what if we only clamp the transferred size
16:33:21 <TabAtkins> (because of the ordering of row vs height resolution, this behavior doesn't have a bad effect when the space is tall; it only makes the element too-large when the space is wide, which is an annoying discontinuity)
16:33:29 <fantasai> iank_: so only things with aspect ratio ...
16:33:34 <fantasai> iank_: would need to think about that a bit more
16:33:42 <fantasai> Rossen_: can add aspect-ratio to anything, now, right?
16:34:46 <fantasai> fantasai: 2 inputs into auto min size: content size in that axis, and for items with aspect ratio (previously only replaced elements), size trasferred
16:35:05 <fantasai> fantasai: suggestion would be to make transferred size weaker than percentage size
16:35:44 <fantasai> iank_: there's a difference between spec and implementations atm with this stuff
16:35:57 <fantasai> iank_: spec says to resolve lengths against zero, whereas implementations will actually ignore that length
16:36:05 <fantasai> iank_: ignoring that difference, your suggestion and mine are effectively equivalent
16:36:23 <fantasai> fantasai: no, yours was to do it to it for compressible elements
16:36:31 <emilio> fantasai: no, because you are saying to do it only for compressible elements and I'm suggesting to do it for all elements with a-r
16:37:01 <emilio> iank_: if I change my suggestion then it agrees right?
16:38:05 <emilio> fantasai: [missed]. It'd be more consitent if we only clamp the transferred size. If we do clamp AMS if you have an aspect-ratio then it changes behavior
16:38:13 <futhark> futhark has joined #css
16:38:27 <emilio> iank_: if a replaced element has an intrinsic size I don't think that we'll want to respect that in this case
16:38:34 <emilio> ... if you have width 100%
16:38:46 <emilio> ... that'd break the person's initial issue, the intrinsic size was actually quite large
16:39:14 <emilio> fantasai: in that case I wonder if that should depend on whether they're compressible. Clamp transferred size always, clamp content-based size if it's compressible
16:39:20 <emilio> iank_: why not do it for both then?
16:39:44 <emilio> fantasai: mainly because it means that aspect-ratio affects sizing in an axis where it'd otherwise not have any effect
16:39:51 <emilio> ... I don't have an objection but it's a bit weird
16:40:09 <Rossen_> q?
16:40:18 <emilio> ... if you apply an aspect-ratio to a div where we apply the content size, then it'd clamp to zero
16:40:32 <fantasai> s/clamp/suddenly clamp/
16:40:40 <emilio> Rossen_: can we go back to the previous proposal, to make it apply to all elements?
16:40:49 <emilio> ... we can try to constrain later if we have strong reasons to
16:41:20 <emilio> fantasai: I think we may have problems if we try to apply to all elements
16:41:40 <emilio> Rossen_: this is something we should be able to figure out quite quickly
16:42:20 <emilio> iank_: I think we can do the change for compressible and a-r elements quite easily. I need to think about non-replaced elements with a-r inside an auto-sized thing, dunno how to implement that yet
16:42:23 <TabAtkins> ian, let's do a video chat about this soon
16:42:50 <emilio> Rossen_: so, let's start with compressible, would that work?
16:42:51 <iank_> sure
16:43:39 <emilio> fantasai: I think my preferred suggestion would be all elements, but if we can't we should do it for compressible elements, do it for transferred and content size, and for a-r elements just the transferred size
16:44:10 <emilio> Rossen_: not opposed, but it's weird to make special elements more and more special, specially if the behavior is useful for all elements
16:44:18 <emilio> ... so I'd prefer to pursue that if possible
16:44:25 <tantek> +1 agreed with Rossen_
16:44:32 <tantek> and with that methodology in general
16:44:43 <emilio> fantasai: I'm fine with all elements, but if not I prefer the suggestion above, I think it's the closest
16:45:16 <emilio> Rossen_: can we resolve on all elements and if you come back with strong reasons why it doesn't work we can consider the other suggestion
16:45:33 <emilio> iank_: when we say all elements we mean all elements with a-r?
16:45:47 <emilio> fantasai: we meant all elements
16:45:56 <fantasai> s/fantasai/rossen/
16:46:06 <emilio> iank_: That's a very big change, I don't think that'd be ok
16:46:12 <emilio> fantasai: I'm also skeptical about that
16:46:37 <emilio> Rossen_: so should we resolve on compressible elements + a-r?
16:46:51 <emilio> fantasai: [explains her suggestion again]
16:47:06 <emilio> Rossen_: sounds reasonable, other comments / objections?
16:47:10 <Rossen_> s/a-r/aspect-ratio/
16:47:45 <fantasai> proposal: clamp automatic minimum size of compressible elements, and the transferred size suggestion of non-compressible aspect-ratio elements
16:48:14 <tantek> sounds reasonable to limit to those elements
16:48:24 <fantasai> RESOLVED: clamp automatic minimum size of compressible elements, and the transferred size suggestion of non-compressible aspect-ratio elements
16:48:59 <fantasai> fantasai: Thanks everyone. That was a complicated issue, and I understood it better by talking it through with all of you.
16:49:51 <fantasai> Topic: percentage resolution of row tracks and gutters with indefinite height
16:49:55 <fantasai> github: https://github.com/w3c/csswg-drafts/issues/5566
16:50:04 <fantasai> [ discussion of whether we have time for this issue ]
16:50:13 <fantasai> Rossen_: [ reads mrego's comment ]
16:50:21 <fantasai> https://github.com/w3c/csswg-drafts/issues/5566#issuecomment-886483173
16:50:33 <fantasai> Rossen_: would be nice to close the issue and move on, if we all already agree
16:50:46 <fantasai> Rossen_: Anyone object to closing the issue with no change?
16:50:52 <gtalbot> gtalbot has joined #css
16:51:04 <fantasai> RESOLVED: Close no change
16:51:25 <fantasai> Topic: visibility: visible and a11y
16:51:40 <fantasai> github: https://github.com/w3c/csswg-drafts/issues/6123
16:52:04 <fantasai> TabAtkins: some a11y folks brought up that the visibility property is tricky
16:52:22 <fantasai> TabAtkins: in particular, visibility:hidden on visibility:visible ancestor
16:52:42 <fantasai> TabAtkins: problem is invisible items gets stripped from a11y tree
16:52:52 <fantasai> TabAtkins: very similar to 'display:contents' a11y bug
16:53:09 <fantasai> TabAtkins: our proposal is to specify impact of 'visibility:hidden' as similar to 'display:contents'
16:53:13 <fantasai> TabAtkins: wrt a11y
16:53:24 <fantasai> TabAtkins: to do that, pull visibility property definition from CSS2 to css-display-3
16:53:50 <fantasai> TabAtkins: and add a warning to authors that in special cases (like tables) can cause problems to have invisible ancestor of visible child
16:54:01 <fantasai> TabAtkins: this proposal got a thumbs up from the original commenter
16:54:04 <fantasai> florian: ...
16:54:13 <fantasai> florian: unlike table cell example, what if these hidden boxes have text content?
16:54:19 <fantasai> florian: do we retain the box but not the text, or what
16:54:36 <fantasai> TabAtkins: text isn't an issue here, because invisible to everyone
16:54:47 <fantasai> TabAtkins: it's the implicit structural relationships that shouldn't get lost
16:54:54 <fantasai> florian: so text shouldn't be in box tree either, just the box structure
16:54:56 <fantasai> TabAtkins: yes
16:55:14 <fantasai> Rossen_: referring to text inside cell made visible?
16:55:18 <fantasai> TabAtkins: no, invisible text
16:55:22 <florian> s/in box tree either/in accessibility tree either/
16:55:25 <fantasai> Rossen_: so text inside of other cells
16:55:38 <fantasai> florian: that, or if div with text in it that's hidden, and span that's visible
16:55:45 <fantasai> florian: do we hide all the text outside the span
16:56:17 <fantasai> Rossen_: yes, this is expected behavior and implemented
16:56:27 <fantasai> florian: is it implementable
16:56:54 <fantasai> fantasai: shouldn't be any problem, text has its own boxes in implementations
16:56:58 <fantasai> Rossen_: ...
16:57:12 <fantasai> Rossen_: text for role/description can be taken from hidden areas, but that's a known pattern that works
16:57:23 <fantasai> Rossen_: current implementations already support display of visible text inside of hidden elements
16:57:39 <fantasai> Rossen_: the issue is only when there's structure part of the invisible elements, then want to be able to recreate that
16:57:48 <fantasai> Rossen_: Tab, one question I have is
16:58:03 <fantasai> Rossen_: the use case here is very specific to when a table has visibility:hidden and cell is visibility:visible
16:58:17 <fantasai> Rossen_: is the same behavior here, are we trying to specify same for table which is inside of visibility:hidden?
16:58:23 <fantasai> TabAtkins: I don't believe the issue is specific to that
16:58:36 <fantasai> TabAtkins: applies the same if you visibility:hidden a link, and visibility:vissible some contents of the link
16:58:57 <fantasai> TabAtkins: We don't want that to strip the linkness of the text inside which is still visible
16:59:09 <fantasai> Rossen_: ok, didn't want to make it too specific
16:59:13 <fantasai> fantasai: no, going to make it quite general
16:59:25 <fantasai> proposal is https://github.com/w3c/csswg-drafts/issues/6123#issuecomment-893890561
16:59:58 <fantasai> Rossen_: so expected behavior is to provide the structural role of the invisible ancestors of visible elements in the a11y tree
17:00:09 <fantasai> TabAtkins: yes, same as display:contents
17:00:28 <fantasai> Rossen_: anything else?
17:00:41 <fantasai> fantasai: we're pulling visibility propdef from CSS2 to css-display-3 (not defined anywhere else than CSS2 atm)
17:00:47 <fantasai> Rossen_: hearing no objections here
17:00:56 <fantasai> RESOLVED: accept proposal
17:01:26 <fantasai> Meeting closed.
17:01:34 <Rossen_> Zakim, end meeting
17:01:34 <Zakim> As of this point the attendees have been plinss, argyle, jensimmons, GameMaker, emilio, Rossen_, dlibby, smfr, TYLin, sanketj, jfkthame, bradk, dholbert, vmpstr, futhark, tantek
17:01:37 <Zakim> RRSAgent, please draft minutes v2
17:01:37 <RRSAgent> I have made the request to generate https://www.w3.org/2021/08/11-css-minutes.html Zakim
17:01:39 <Zakim> I am happy to have been of service, Rossen_; please remember to excuse RRSAgent.  Goodbye
17:01:44 <Zakim> Zakim has left #css
17:02:33 <iank_> TabAtkins: I can VC today - but out the next two days.
17:04:53 <emeyer> emeyer has left #css
17:04:57 <gtalbot> gtalbot has left #css
18:36:32 <futhark_> futhark_ has joined #css
20:48:52 <fantasai> TabAtkins: Do we have data that we can look up for how much of the Web uses two values for scroll-snap-align?
20:49:03 <TabAtkins> i have no idea!
20:49:20 <fantasai> wasn't there some tool that aggregated css property value usage?
20:49:28 <fantasai> MSFT had one, but they seem to have shut it down
21:07:46 <astearns> There’s https://chromestatus.com/metrics/css/popularity#scroll-snap-align that shows usage of the property, but not values