Meeting minutes
github-bot, topic w3c/
[css-anchor-position] `anchor-size()` should fallback to `auto`, not zero
<github-bot> OK, I'll post this discussion to https://
<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.
<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.
<chrishtr> TabAtkins: later in the thread there was a proposal to describe it as "invalid at computed value time" instead of auto, to simplify things. This seems fine to me.
<chrishtr> TabAtkins: there would have had to be special cases though if we went with auto, so invalid is more complete and consistent IMO
<fantasai> sgtm
<chrishtr> TabAtkins: propose that we go with the "invalid" definition.
<chrishtr> +1 to proposed resolution
<kizu> ICVT sounds good
"invalid at computed-value time", specifically
<chrishtr> emilio: this would be a first case of that happening, which is a bit odd.
<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
<chrishtr> emilio: if the developer passes auto to calc-size explicitly then it should work once that is defined right?
<emilio> Instead of calc-size(anchor-size(<invalid>) + 20px), calc-size(auto + 20px)
<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
<chrishtr> emilio: ok then I'm fine with the ICVT definition
<chrishtr> proposed resolution: if an anchor-size can't resolve and doesn't have a fallback, then it is ICVT
RESOLUTION: if an anchor-size can't resolve and doesn't have a fallback, then it is ICVT
<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
<chrishtr> TabAtkins: propose that we apply the same resolution to the anchor() function as well
RESOLUTION: if an anchor() can't resolve and doesn't have a fallback, then it is ICVT
github-bot, topic w3c/
[css-anchor-1] Need ability to say "don't render" when anchor is off-screen
<github-bot> OK, I'll post this discussion to https://
<chrishtr> TabAtkins: this is a call for review on the details of position-visibility as defined in the ED spec
<chrishtr> TabAtkins: there was a previous resolution for the feature, but some details have been filled in
<chrishtr> TabAtkins: call to please review and otherwise we'll consider the ED spec text accepted
github-bot, topic w3c/
[css-anchor-position-1] Define `CSSPositionTryRule.style` as `CSSPositionTryProperties`
<github-bot> OK, I'll post this discussion to https://
<chrishtr> TabAtkins: the CSSOM interface for position-try has a CSSStyleDeclaration object to hold the properties at present.
<chrishtr> TabAtkins: however, some similar @ rules like page rules, have been done by exposing the properties valid on it directly
<chrishtr> TabAtkins: do we want to follow that same pattern?
<chrishtr> TabAtkins: currrently only spec prose prevents exposing all CSS properties since the type allows it
<chrishtr> TabAtkins: but page rules only accepts the properties specified by what that spec accepts
<chrishtr> TabAtkins: should we go with the page rules approach and settle that as as a precedent as well for future patterns?
https://
<chrishtr> TabAtkins the page rules object has a CSSPageDescriptors interface that explicitly lists the allowed properties
<chrishtr> emilio: page is different because there are some properties that don't exist in CSSStyleDeclaration
<chrishtr> emilio: a better comparison to try rules is keyframe rules, which disallow some properties
<chrishtr> TabAtkins: yes that's similar but since they exclude some of the properties and copying that mechanism could be annoying (?)
<chrishtr> emilio: prefer to be consistent with keyframe rules for consistency
<chrishtr> emilio: if we did that then also future extensions to position-try would be more easily feature detectible
<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.
<chrishtr> dbaron: not sure whether this happens for animation properties in keyframes
<chrishtr> fantasai: seems unlike that developers will rely on whether these properties are stored on keyframes, so we could likely change that
<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 regular box layout.
<chrishtr> emilio: don't want another interface with hundreds of properties on it just to prevent animation properties in keyframes, that seems not useful
<chrishtr> emilio: this would be a waste because there would be some basically useless generated code and spec to maintain
<fantasai> that's a fair point, dbaron
<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
<chrishtr> emilio: that would be fine
<chrishtr> TabAtkins: it seems people think that aligning with page descriptors makes more sense because it's a small subset of properties
<chrishtr> proposed resolution: define a new interface type for position-try similar to how page descriptors are defined, with every allowed property included
RESOLUTION: define a new interface type for position-try similar to how page descriptors are defined, with every allowed property included
github-bot, topic w3c/
[css-text-3] Disambiguation about soft wrap opportunities around replaced elements
<github-bot> OK, I'll post this discussion to https://
fantasai: There's an ambiguity in the spec
fantasai: we talk about how line-breaking properties affect breaking between characters
fantasai: and we talk about how line-breaking occurs before/after rpelaced elements
fantasai: But we don't connect to the idea of line-breaking controlling breaks between replaced elements, or between replaced and characters
fantasai: So proposal is to repalce references to "between or aroudn characters" with "between or around characters or atomic inlines"
fantasai: This aligns with Chrome/WebKit behavior, and we think is more expected behavior than what Firefox is doing.
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
kizu: So if you have this combination of elements, white-space:no-wrap prevents wrapping; if you want wrapping you can remove it
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
<emilio> https://
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.
fantasai: If we had two characters in those spans, wrapping woudl be allowed. But two images, it is ambiguous in the spec.
fantasai: So I don't think white-space *in* the element should affect wrapping *outside* the element
fantasai: Controlling the wrapping of images would probably be useful, there's been suggestions for properties controlling that
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.
fantasai: but that's a seaprate issue. This is just about behavior at element boundaries.
fantasai: There is one thing I"m not sure is implemented yet, we tweaked the spec, and it might help your use-case
fantasai: for webcompat we require there's a softwrap before and after each repalced, even if the next char is a nbsp
fantasai: But we previously said it doesn't matter what it's next to - it just *always* gets a soft-wrap
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.
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.
fantasai: (In addition to any future property that controls breaking beahvior)
<kizu> Sounds good.
Rossen__: Any feedback? Otherwise we'll resolve
RESOLUTION: Clarify spec about soft-wrap oppos before/after characters to also reference atomic inlines.
<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: "正"
github-bot, topic w3c/
[css-text-4] Rename `trim-auto` to `trim-both`
<github-bot> OK, I'll post this discussion to https://
fantasai: text-spacing has a bunch of values.
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
fantasai: And we have trim-start, trim-all, space-all, space-first
<fantasai> w3c/
fantasai: There's also trim-auto which is baseically trim-start + trim-end + the baseline "trim in the middle" behavior
fantasai: It makes sense to rename to trim-both, then
fantasai: Murakami-san seems to align on that
fantasai: I believe this is the one keyword not yet shipped by Chrome, so it should still be fixable
proposed resolution: rename trim-auto to trim-both
RESOLUTION: rename trim-auto to trim-both
[css-align] Inconsistent fallback alignments for space-between and space-around/evenly
fantasai: this is about fallback behavior of the content-distribution keywords: space-between/around/evently
fantasai: Oriol pointed out the inconsistentcy, around/evenly do "safe" alignment
fantasai: So if the lone item overflows, the item won't overflow the start edge, to avoid clipping
fantasai: but -between doesn't have that
fantasai: So proposal is to change the fallback from "flex-start" to "safe flex-start"
TabAtkins: [explains the issue]
fantasai: start doesnt' overflow into unscrollable region
fantasai: but flex-start *can* if you reverse a flexbox, then it's end-aligning
dholbert: This makes sense to me
chrishtr: Do you think there's a compat risk?
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.
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
chrishtr: okay
<dbaron> This is changing the failure fallback case inside of a different failure fallback case :-)
iank_: We've taken some compat pain for these properties, it would be nice to have the other browsers get some safety here
<iank_> looks good
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)
proposed resolution: Update the fallback for space-between to add "safe"
RESOLUTION: Update the fallback for space-between to add "safe"
github-bot, topic w3c/
[css-grid] Introducing overlapping cells in grid-template-areas syntax
<github-bot> OK, I'll post this discussion to https://
TabAtkins: Suggestion in the issue that sometimes it's useful to have overlapping areas in your grd
TabAtkins: always possible to position explicitly, but can't use named area syntax
TabAtkins: some reasonable use cases in the thread, and reasonable syntax proposed for it
TabAtkins: if you want to give a cell multiple names, use [ ] to surround the multiple names
w3c/
TabAtkins: So question is, does this sound OK to people?
TabAtkins: it's possible to do manually, but this makes it easier
<rachelandrew> +1 to this, I've been asked for this type of thing reasonably often.
<bramus> looks good
<oriol> Sounds reasonable
miriam: I like it.
<kizu> +1
<davidleininger> +1
TabAtkins: proposal to accept suggestion to use [ ] to allow multiple names for a grid cell
jensimmons: We had often assigned things like this to Grid 4, or should this go in 3?
TabAtkins: I don't like having multiple EDs or WDs running at the same time for a given module
TabAtkins: want to treat one level as current trunk
TabAtkins: no particular problem otherwise
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
<JaseW> proposal looks good +1
fantasai: we were still making changes to the Grid algo
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
(un-delta-ing 3)
jensimmons: makes sense to me
miriam: any objections to proposed resolution?
RESOLUTION: Add bracketed syntax for multiple grid cell area names, as proposed in issue (to Grid Level 3)
github-bot, topic w3c/
[css-grid] Include scrollbar gutter in #subgrid-edge-placeholders
<github-bot> OK, I'll post this discussion to https://
github-bot, topic w3c/
[css-grid] Ability to clamp track spanning
<github-bot> OK, I'll post this discussion to https://
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
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
<jensimmons> YYEEEESSSSS This is such a pain to do manually.
miriam: There's been many requests for this, been chatting with Elika, wanted to push a proposal for fixing this
miriam: Suggest a `span(min, max)` function
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. Could maybe also be an `all` value.
miriam: happy to bikeshed the specifics, but wanted to know if we can start working on it
fantasai: in favor generally, i think the syntax is reasoanble
fantasai: currently span is a keyword, this would shift it to a function, we could maybe make the second argument optional
<rachelandrew> +1 in general, again something people really would like to do
fantasai: one naming concern is that "all" would span only the explicit tracks, not the implicit
<iank_> this adds a bunch of complexity with mansonry, and they willl span a variable amount of columns
Ethan: so in order to determine implicit gridlines you'll use the min span
Ethan: but for placement you use the max - how does that work?
miriam: You'd use max, clamped by the number of columns avaiable.
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
fantasai: I think for sizing they'd span the min
miriam: I'd also assume that
iank_: I don't know if that's correct
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
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
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
fantasai: That's why when you're calculating sizes, assume it's spanning the min
fantasai: Since it'll usually not span more than that
Rossen__: we're out of time, let's continue discussing in the issue
github-bot, end topic
<Rossen__> Zakim end meeting