15:59:57 <RRSAgent> RRSAgent has joined #css
16:00:02 <RRSAgent> logging to https://www.w3.org/2024/04/10-css-irc
16:00:02 <Zakim> RRSAgent, make logs Public
16:00:03 <Zakim> Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
16:00:52 <kizu> kizu has joined #css
16:01:11 <Rossen__> present+
16:01:15 <chrishtr> present+
16:01:33 <keithamus> present+
16:01:35 <kizu> present+
16:01:37 <kbabbitt> kbabbitt has joined #css
16:01:43 <kbabbitt> present+
16:01:47 <bramus> present+
16:01:50 <flackr> present+
16:02:07 <miriam> present+
16:02:12 <davidleininger> davidleininger has joined #css
16:02:15 <masonf> masonf has joined #css
16:02:19 <rachelandrew> present+
16:02:22 <masonf> present+
16:02:23 <YehonatanDaniv> present+
16:02:24 <davidleininger> present+
16:02:42 <jensimmons> jensimmons has joined #css
16:02:53 <jensimmons> present+
16:03:18 <TabAtkins> github-bot, topic https://github.com/w3c/csswg-drafts/issues/10005
16:03:18 <github-bot> Topic: [css-anchor-position] `anchor-size()` should fallback to `auto`, not zero
16:03:18 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10005.
16:03:19 <dbaron> Present+
16:03:25 <dholbert> present+
16:03:26 <emilio> present+
16:03:28 <oriol> oriol has joined #css
16:03:49 <fantasai> present+
16:04:53 <chrishtr> TabAtkins: currently the anchor pos spec says that an anchor-size refers to an invalid anchor then it resolves to 0px. We do the same with the anchor function.
16:05:34 <chrishtr> TabAtkins: fantasai pointed out that for anchor-size in particular this doesn't seem ideal, and would result in a broken page. Suggestion originally proposed was to resolve to auto if there is no valid fallback.
16:05:51 <jfkthame> jfkthame has joined #css
16:05:55 <luke> luke has joined #css
16:05:59 <chrishtr> TabAtkins: later in the thread there was a proposal to describe it as invalid instead of auto, to simplify things. This seems fine to me.
16:06:33 <chrishtr> TabAtkins: there would have had to be special cases though if we went with auto, so invalid is more complete and consistent IMO
16:06:42 <fantasai> sgtm
16:06:46 <Rossen__> present+
16:06:48 <Rossen__> q?
16:06:49 <chrishtr> TabAtkins: propose that we go with the "invalid" definition.
16:06:50 <jfkthame> present+
16:06:58 <chrishtr> +1 to proposed resolution
16:07:00 <alisonmaher> alisonmaher has joined #css
16:07:03 <kizu> ICVT sounds good
16:07:05 <TabAtkins> "invalid at computed-value time", specifically
16:07:06 <fantasai> s/invalid instead/"invalid at computed value time" instead/
16:08:13 <chrishtr> emilio: this would be a first case of that happening, which is a bit odd.
16:09:17 <chrishtr> TabAtkins: otherwise calc that contains anchor-size would remove and go to auto; the cyclic cases in other places also were defined to do that
16:09:48 <chrishtr> emilio: if the developer passes auto to calc-size explicitly then it should work once that is defined right?
16:10:07 <emilio> Instead of calc-size(anchor-size(<invalid>) + 20px), calc-size(auto + 20px)
16:10:41 <khush> khush has joined #css
16:10:50 <chrishtr> TabAtkins: auto is fine in calc-size, but that doesn't allow you to put it in arbitrary locations when it can't resolve to a length
16:10:58 <vmpstr> present+
16:11:05 <chrishtr> emilio: ok then I'm fine with the ICVT definition
16:11:36 <schenney> schenney has joined #css
16:11:50 <PaulG> PaulG has joined #css
16:11:56 <chrishtr> proposed resolution: if an anchor-size can't resolve and doesn't have a fallback, then it is ICVT
16:12:21 <chrishtr> RESOLVED: if an anchor-size can't resolve and doesn't have a fallback, then it is ICVT
16:13:24 <chrishtr> TabAtkins: anchor makes a bit more sense than anchor-size to resolve to 0px, but for consistency perhaps we should align with the anchor-size resolution
16:13:39 <chrishtr> TabAtkins: propose that we apply the same resolution to the anchor() function as well
16:14:08 <chrishtr> RESOLVED: if an anchor() can't resolve and doesn't have a fallback, then it is ICVT
16:14:30 <TabAtkins> github-bot, topic https://github.com/w3c/csswg-drafts/issues/7758
16:14:30 <github-bot> Topic: [css-anchor-1] Need ability to say "don't render" when anchor is off-screen
16:14:30 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/7758.
16:14:51 <chrishtr> TabAtkins: this is a call for review on the details of position-visibility as defined in the ED spec
16:15:04 <chrishtr> TabAtkins: there was a previous resolution for the feature, but some details have been filled in
16:15:27 <chrishtr> TabAtkins: call to please review and otherwise we'll consider the ED spec text accepted
16:15:53 <TabAtkins> github-bot, topic https://github.com/w3c/csswg-drafts/issues/10108
16:15:54 <github-bot> Topic: [css-anchor-position-1] Define `CSSPositionTryRule.style` as `CSSPositionTryProperties`
16:15:54 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10108.
16:16:07 <emeyer> emeyer has joined #css
16:16:21 <emeyer> present+
16:16:43 <chrishtr> TabAtkins: the CSSOM interface for position-try has a CSSStyleDeclaration object to hold the properties at present.
16:16:49 <emilio> q+
16:17:09 <chrishtr> TabAtkins: however, some similar @ rules like page rules, have been done by exposing the properties valid on it directly
16:17:20 <chrishtr> TabAtkins: do we want to follow that same pattern?
16:17:42 <chrishtr> TabAtkins: currrently only spec prose prevents exposing all CSS properties since the type allows it
16:17:56 <chrishtr> TabAtkins: but page rules only accepts the properties specified by what that spec accepts
16:18:26 <chrishtr> TabAtkins: should we go with the page rules approach and settle that as as a precedent as well for future patterns?
16:18:29 <TabAtkins> https://drafts.csswg.org/cssom/#the-csspagerule-interface
16:19:03 <bkardell_> bkardell_ has joined #css
16:19:04 <chrishtr> TabAtkins the page rules object has a CSSPageDescriptors interface that explicitly lists the allowed properties
16:19:34 <chrishtr> emilio: page is different because there are some properties that don't exist in CSSStyleDeclaration
16:19:46 <bkardell_> present+
16:19:51 <chrishtr> emilio: a better comparison to try rules is keyframe rules, which disallow some properties
16:20:39 <chrishtr> TabAtkins: yes that's similar but since they exclude some of the properties and copying that mechanism could be annoying (?)
16:21:05 <chrishtr> emilio: prefer to be consistent with keyframe rules for consistency
16:21:28 <SebastianZ> SebastianZ has joined #css
16:21:45 <Rossen__> ack emilio
16:21:49 <chrishtr> emilio: if we did that then also future extensions to position-try would be more easily feature detectible
16:21:50 <SebastianZ> present+
16:22:58 <chrishtr> dbaron: another thing to keep in mind is whether properties that do not apply in position try should be parsed and stored in the CSSOM object.
16:23:11 <chrishtr> dbaron: not sure whether this happens for animation properties in keyframes
16:23:43 <chrishtr> fantasai: seems unlike that developers will rely on whether these properties are stored on keyframes, so we could likely change that
16:24:24 <chrishtr> fantasai: think position try should be more like keyframes, because both apply to regular elements. but page descriptors are a special context that is not quite like visual display on the screen.
16:24:53 <chrishtr> emilio: don't want another interface with hundreds of properties on it just to prevent animation properties in keyframes, that seems not useful
16:25:43 <chrishtr> emilio: this would be a waste because there would be some basically useless generated code and spec to maintain
16:26:16 <fantasai> that's a fair point, dbaron
16:26:17 <chrishtr> dbaron: the part that is more like page descriptors than keyframes is that position-try has a short list of properties allowed whereas keyframes has a very long list
16:26:35 <chrishtr> emilio: that would be fine
16:27:01 <fantasai> s/visual display on the screen/regular box layout/
16:27:08 <chrishtr> TabAtkins: it seems people think that aligning with page descriptors makes more sense because it's a small subset of properties
16:27:49 <chrishtr> proposed resolution: define a new interface type for position-try similar to how page descriptors are defined, with every allowed property included
16:28:00 <chrishtr> RESOLVED define a new interface type for position-try similar to how page descriptors are defined, with every allowed property included
16:28:19 <Rossen__> s/RESOLVED/RESOLVED:/
16:28:28 <TabAtkins> github-bot, topic https://github.com/w3c/csswg-drafts/issues/9964
16:28:28 <github-bot> Topic: [css-text-3] Disambiguation about soft wrap opportunities around replaced elements
16:28:28 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/9964.
16:28:56 <TabAtkins> fantasai: There's an ambiguity in the spec
16:29:07 <TabAtkins> fantasai: we talk about how line-breaking properties affect breaking between characters
16:29:15 <TabAtkins> fantasai: and we talk about how line-breaking occurs before/after rpelaced elements
16:29:36 <TabAtkins> fantasai: But we don't connect to the idea of line-breaking controlling breaks between replaced elements, or between replaced and characters
16:29:52 <TabAtkins> fantasai: So proposal is to repalce references to "between or aroudn characters" with "between or around characters or atomic inlines"
16:30:08 <TabAtkins> fantasai: This aligns with Chrome/WebKit behavior, and we think is more expected behavior than what Firefox is doing.
16:30:17 <kizu> q+
16:30:42 <Rossen__> ack kizu
16:31:02 <TabAtkins> kizu: I encountered this recently. I remember wanting to not allow breaks, aligning with firefox, because otherwise i don't think there's a way for an author to disallow the wrapping
16:31:18 <TabAtkins> kizu: So if you have this combination of elements, white-space:no-wrap prevents wrapping; if you want wrapping you can remove it
16:31:41 <TabAtkins> kizu: If you want it to work differently, it would be nice to add another way to avoid introducing soft-wrap opportunities between replaced or replaced and text
16:31:41 <emilio> https://bugzilla.mozilla.org/show_bug.cgi?id=225382 suggests this might be quirks-mode dependent too?
16:32:11 <TabAtkins> fantasai: This is specifically cases where there's a span around an image, and another span around an image, and they're adjoining. Between those two spans, the white-space property allows wrapping.
16:32:26 <TabAtkins> fantasai: If we had two characters in those spans, wrapping woudl be allowed. But two images, it is ambiguous in the spec.
16:32:42 <TabAtkins> fantasai: So I don't think white-space *in* the element should affect wrapping *outside* the element
16:32:54 <TabAtkins> fantasai: Controlling the wrapping of images would probably be useful, there's been suggestions for properties controlling that
16:33:15 <TabAtkins> fantasai: Web-compat behavior, which allows more breaks, or like an Enlgihs letter, or like a Japanese character. Those are the common ways you'd want it to behave.
16:33:30 <TabAtkins> fantasai: but that's a seaprate issue. This is just about behavior at element boundaries.
16:33:47 <TabAtkins> fantasai: There is one thing I"m not sure is implemented yet, we tweaked the spec, and it might help your use-case
16:34:02 <TabAtkins> fantasai: for webcompat we require there's a softwrap before and after each repalced, even if the next char is a nbsp
16:34:20 <TabAtkins> fantasai: But we previously said it doesn't matter what it's next to - it just *always* gets a soft-wrap
16:34:40 <TabAtkins> fantasai: But there are some other gluey characters in Unicode that are less commonly used, so we recently updated the spec to not break between an image and *those* characters.
16:34:54 <TabAtkins> fantasai: we probably don't ahve interop on that yet, it's a recent change. But that would allow you more control over breaking if you use those characters.
16:35:05 <TabAtkins> fantasai: (In addition to any future property that controls breaking beahvior)
16:35:06 <kizu> Sounds good.
16:35:29 <TabAtkins> Rossen__: Any feedback? Otherwise we'll resolve
16:36:04 <TabAtkins> RESOLVED: Clarify spec about soft-wrap oppos before/after characters to also reference atomic inlines.
16:36:10 <dbaron> One off-topic thought is that a property for controlling the breaking behavior of an image could take a string that means "have the breaking behavior of this text", e.g., replaced-break-as: "A" or replaced-break-as: "正"
16:36:19 <TabAtkins> github-bot, topic https://github.com/w3c/csswg-drafts/issues/10161
16:36:19 <github-bot> Topic: [css-text-4] Rename `trim-auto` to `trim-both`
16:36:19 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10161.
16:36:38 <TabAtkins> fantasai: text-spacing has a bunch of values.
16:37:03 <TabAtkins> fantasai: as we've tweaked 'normal' and the proeprty syntax, we've gotten to a place where we have "normal" being a baseline behavior where we allow spacing at start/end of th eline, but collapse within the line
16:37:22 <TabAtkins> fantasai: And we have trim-start, trim-all, space-all, space-first
16:37:27 <fantasai> https://github.com/w3c/csswg-drafts/issues/10161#issuecomment-2033649072
16:37:40 <TabAtkins> fantasai: There's also trim-auto which is baseically trim-start + trim-end + the baseline "trim in the middle" behavior
16:37:48 <TabAtkins> fantasai: It makes sense to rename to trim-both, then
16:37:54 <TabAtkins> fantasai: Murakami-san seems to align on that
16:38:07 <TabAtkins> fantasai: I believe this is the one keyword not yet shipped by Chrome, so it should still be fixable
16:38:34 <TabAtkins> proposed resolution: rename trim-auto to trim-both
16:38:48 <TabAtkins> RESOLVED: rename trim-auto to trim-both
16:39:04 <github-bot> Topic: [css-align] Inconsistent fallback alignments for space-between and space-around/evenly
16:39:25 <TabAtkins> fantasai: this is about fallback behavior of the content-distribution keywords: space-between/around/evently
16:39:40 <TabAtkins> fantasai: Oriol pointed out the inconsistentcy, around/evenly do "safe" alignment
16:39:51 <TabAtkins> fantasai: So if the lone item overflows, the item won't overflow the start edge, to avoid clipping
16:40:06 <TabAtkins> fantasai: but -between doesn't have that
16:40:18 <TabAtkins> fantasai: So proposal is to change the fallback from "flex-start" to "safe flex-start"
16:41:19 <TabAtkins> TabAtkins: [explains the issue]
16:41:25 <TabAtkins> fantasai: start doesnt' overflow into unscrollable region
16:41:39 <TabAtkins> fantasai: but flex-start *can* if you reverse a flexbox, then it's end-aligning
16:41:55 <TabAtkins> dholbert: This makes sense to me
16:42:07 <TabAtkins> chrishtr: Do you think there's a compat risk?
16:42:23 <TabAtkins> fantasai: I doubt it. If you're using these keywords you expect yoru content to have mutliple items, and the items smaller than the CB.
16:42:43 <TabAtkins> dholbert: Agree, "safe" coming into play seems rare here, so it seems nice from a consistency perspective, and when it *does* activate it's an improvement in behavior
16:42:49 <TabAtkins> chrishtr: okay
16:43:01 <dbaron> This is changing the failure fallback case inside of a different failure fallback case :-)
16:43:20 <TabAtkins> iank_: We've taken some compat pain for these properties, it would be nice to have the other browsers get some safety here
16:43:34 <iank_> looks good
16:44:11 <TabAtkins> failure 1: you only have one item instead of multiple. failure 2: that item is bigger than the containing block. (and qualifier 3: you're in a reverse flexbox)
16:44:19 <TabAtkins> proposed resolution: Update the fallback for space-between to add "safe"
16:44:22 <TabAtkins> RESOLVED: Update the fallback for space-between to add "safe"
16:44:49 <TabAtkins> github-bot, topic https://github.com/w3c/csswg-drafts/issues/2808
16:44:49 <github-bot> Topic: [css-grid] Introducing overlapping cells in grid-template-areas syntax
16:44:49 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/2808.
16:45:15 <fantasai> scribe+
16:45:37 <fantasai> TabAtkins: Suggestion in the issue that sometimes it's useful to have overlapping areas in your grd
16:45:53 <fantasai> TabAtkins: always possible to position explicitly, but can't use named area syntax
16:46:18 <fantasai> TabAtkins: some reasonable use cases in the thread, and reasonable syntax proposed for it
16:46:32 <fantasai> TabAtkins: if you want to give a cell multiple names, use [ ] to surround the multiple names
16:46:38 <TabAtkins> https://github.com/w3c/csswg-drafts/issues/2808#issuecomment-450992779
16:46:57 <fantasai> TabAtkins: So question is, does this sound OK to people?
16:47:13 <fantasai> TabAtkins: it's possible to do manually, but this makes it easier
16:47:28 <rachelandrew> +1 to this, I've been asked for this type of thing reasonably often.
16:47:32 <bramus> looks good
16:47:33 <oriol> Sounds reasonable
16:47:43 <fantasai> miriam: I like it.
16:47:45 <kizu> +1
16:47:45 <davidleininger> +1
16:48:23 <fantasai> TabAtkins: proposal to accept suggestion to use  [ ] to allow multiple names for a grid cell
16:48:41 <fantasai> jensimmons: We had often assigned things like this to Grid 4, or should this go in 3?
16:48:57 <fantasai> TabAtkins: I don't like having multiple EDs or WDs running at the same time for a given module
16:49:09 <fantasai> TabAtkins: want to treat one level as current trunk
16:49:19 <fantasai> TabAtkins: no particular problem otherwise
16:50:04 <TabAtkins> fantasai: I think this can go in 3, there's several other reoslutions we wer eplanning to put in 3 and ahven't added them yet, mainly because we hadn't merged the stable text of Grid into 3 yet
16:50:07 <JaseW> proposal looks good +1
16:50:09 <TabAtkins> fantasai: we were still making changes to the Grid algo
16:50:28 <TabAtkins> fantasai: But since that's stabilizing now, once we publish 1 and 2 with the current text it would probably be a godo time to merge it up into 3 and edit these all in
16:50:33 <TabAtkins> (un-delta-ing 3)
16:50:39 <TabAtkins> jensimmons: makes sense to me
16:50:54 <fantasai> miriam: any objections to proposed resolution?
16:51:23 <fantasai> RESOLVED: Add bracketed syntax for multiple grid cell area names, as proposed in issue (to Grid Level 3)
16:51:47 <TabAtkins> github-bot, topic https://github.com/w3c/csswg-drafts/issues/9935
16:51:47 <github-bot> Topic: [css-grid] Include scrollbar gutter in #subgrid-edge-placeholders
16:51:47 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/9935.
16:52:37 <TabAtkins> github-bot, topic https://github.com/w3c/csswg-drafts/issues/5852
16:52:37 <github-bot> Topic: [css-grid] Ability to clamp track spanning
16:52:37 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/5852.
16:53:20 <TabAtkins> miriam: especially ins ituation where you use auto-fit/fill repeating grid, there's a pain point where you want element to span multiple columns *if avaialble*, but not add new columns if they're not needed
16:53:46 <TabAtkins> miriam: This is a problem with auto grids, you have to reach for MQ/CQ, figure out the breakpoints, and use that to change the span size
16:53:57 <jensimmons> YYEEEESSSSS This is such a pain to do manually.
16:54:09 <TabAtkins> miriam: There's been many requests for this, been chatting with Elika, wanted to push a proposal for fixing this
16:54:21 <TabAtkins> miriam: Suggest a `span(min, max)` function
16:54:48 <TabAtkins> miriam: so `span(1, 3)` - for the sake of determining what columns are *needed* we use the min, and for the sake of placement we use the max
16:55:06 <TabAtkins> miriam: happy to bikeshed the specifics, but wanted to know if we can start working on it
16:55:16 <TabAtkins> fantasai: in favor generally, i think the syntax is reasoanble
16:55:34 <dbaron> s/placement we use the max/placement we use the max.  Could maybe also be an `all` value./
16:55:43 <TabAtkins> fantasai: currently span is a keyword, this would shift it to a function, we could maybe make the second argument optional
16:55:46 <rachelandrew> +1 in general, again something people really would like to do
16:56:00 <TabAtkins> fantasai: one naming concern is that "all" would span only the explicit tracks, not the implicit
16:56:03 <iank_> this adds a bunch of complexity with mansonry, and they willl span a variable amount of columns
16:56:25 <TabAtkins> ???: so in order to determine implicit gridlines you'll use the min span
16:56:36 <TabAtkins> ???: but for placement you use the max - how does that work?
16:56:50 <TabAtkins> miriam: You'd use max, clamped by the number of columns avaiable.
16:57:53 <fantasai> s/???/Ethan/
16:57:54 <fantasai> s/???/Ethan/
16:58:55 <oriol> q+
16:58:57 <TabAtkins> iank_: With the current masonry spec, this makes it... when you place masonry items, they can span variable # of tracks for sizing, that's a somewhat complex interaction
16:59:04 <TabAtkins> fantasai: I think for sizing they'd span the min
16:59:09 <TabAtkins> miriam: I'd also assume that
16:59:18 <TabAtkins> iank_: I don't know if that's correct
16:59:31 <ethanjv> ethanjv has joined #css
16:59:46 <TabAtkins> fantasai: It's a bit awkward for masonry in general. even if you're doing placement, because of the way masonry works you want to palce it into the shortest column, but then you won't bea ble to span anyway
17:00:09 <TabAtkins> fantasai: Some cases where you can, but it's rare - you need similar-height items lining up in rows, and then you probably dont' need masonry anyway
17:00:40 <TabAtkins> iank_: Yeah, for final palcement. But for track sizing, if you're running "place everywhere in ever position", you can have something that'll span 10, then 9, then 8, etc
17:00:59 <TabAtkins> fantasai: That's why when you're calculating sizes, assume it's spanning the min
17:01:05 <TabAtkins> fantasai: Since it'll usually not span more than that
17:01:31 <TabAtkins> Rossen__: we're out of time, let's continue discussing in the issue
17:02:00 <TabAtkins> github-bot, end topic
17:02:25 <emeyer> emeyer has left #css
17:02:34 <Rossen__> Zakim end meeting
17:02:46 <Rossen__> Zakim, end meeting
17:02:46 <Zakim> As of this point the attendees have been Rossen__, chrishtr, keithamus, kizu, kbabbitt, bramus, flackr, miriam, rachelandrew, masonf, YehonatanDaniv, davidleininger, jensimmons,
17:02:49 <Zakim> ... dbaron, dholbert, emilio, fantasai, jfkthame, vmpstr, emeyer, bkardell_, SebastianZ
17:02:49 <Zakim> RRSAgent, please draft minutes v2
17:02:50 <RRSAgent> I have made the request to generate https://www.w3.org/2024/04/10-css-minutes.html Zakim
17:02:57 <Zakim> I am happy to have been of service, Rossen__; please remember to excuse RRSAgent.  Goodbye
17:02:57 <Zakim> Zakim has left #css
17:03:06 <davidleininger> davidleininger has left #css
17:04:54 <jensimmons> jensimmons has joined #css