Meeting minutes
<astearns> github-bot, take up w3c/
[css-overflow-4] nowrap and block-ellipsis
<github-bot> OK, I'll post this discussion to https://
florian: there seems to be some ambiguity about text spec
… when you remove content next to elipsiss it should disappear
… up to the next soft wrap oppertunity
… but the way the white space is currently specified, nowrap and pre do not supress it
… so reading it says that even if it says nowrap they do not suppress the wrapping oppertunity, just not to take them for line break processing
… so literal reading would have it do something else
… proposal is to not do that, and leave to the editor to find exact spec wording, and confirm that when you can't wrap you remove the whole thing to insert the elipsiss
andreubotella: if you have a forced line break inside pre or nowrap then it forces to <missed>
<florian> andreubotella: and there is enough room at the end of the line to fit the ellipsis, that is allowed
andreubotella: only when it doesn't fit and you try to find next oppertunity it tries to find it
<florian> andreubotella: it's only when the ellipsis doesn't fit and you're looking for a previous placement point that nowrap would require removing the whole content
astearns: so editorially if not specified, could spec editor specify that?
… is there some reason why nowrap is specified that way?
florian: my suspision is editorial accident
astearns: proposed resolution is to clarify the interaction between nowrap and block elipssis
fantasai: I would prefer to define this on the line clamp side
… that opportunities don't exist unless we need to know where they are for other reason
… say it ignores them with in nowrap
astearns: that's the safeset, wondering if it's enough
fantasai: question whether the information is there and can be accessed
florian: I think editors can take that, since me and fantasai are editors we could
astearns: objections?
… none
RESOLUTION: clarify the interaction between nowrap and block elipssis
<astearns> github-bot, take up w3c/
[css-overflow] [css-text] Interaction between whitespace collapsing and line-clamp
<github-bot> OK, I'll post this discussion to https://
andreubotella: Block finds the last soft wrap opportunity and removes content from that point to end of line
andreubotella: What does that mean in terms of whitespace?
andreubotella: wrt unicode line breaking algo, line breaking opportunity is after the space, not before
andreubotella: This is probably not what we want
andreubotella: Way I conceptualize this is, rather than finding last opportunity that fits, remove the width of ellipsis from the available width of the line, do regular line breaking based on that, and then add the ellipsis
andreubotella: in that model, if the ellipsis is placed after white space processing part II, which removes collapsible spaces, it will be placed at the end of the word
andreubotella: I don't necessarily want to require that the line-breaking algo has to take into account the ellispsis, that's an implementation strategy
andreubotella: proposed resolution, if you have clamp point at white space, make it work as if line break happened there, and ellipsis was placed after WS Processing Part 2
andreubotella: which removes the space
florian: I agree with the proposal
florian: Don't want to require a particular implementation strategy, but describing this way is helpful and easy because we invoke existing spec text
florian: that's a very complicated logic depending on which spaces and white space properties are at the end of the line
florian: so saying we do "as if" at the end of the line is a good idea
andreubotella: Another complication related to hanging white space
andreubotella: You can have space at the end of the line that isn't collapsible, but can hang off the end of the line (width isn't accounted for in line breaking or alignment)
andreubotella: Only space at the end of the line can hang. If you put ellipsis there, can't hang anymore.
andreubotella: We could make the ellipsis hang... so not impossible
andreubotella: but idk if we want to require that or what
astearns: Let's say that's a separate issue for now, and take a resolution on what we do with collapsible white space
andreubotella: "Rendering should be equivalent to line breaking at that soft wrap opportunity, and applying white space processing part 2 before inserting ellipsis at the end"
astearns: Makes sense
PROPOSED: Rendering should be equivalent to line breaking at that soft wrap opportunity, and applying white space processing part 2 before inserting ellipsis at the end
RESOLUTION: Rendering should be equivalent to line breaking at that soft wrap opportunity, and applying white space processing part 2 before inserting ellipsis at the end
fantasai: fwiw, if we put ellipsis after the spaces, then nothing should hang anymore
florian: yeah, question is whether that's where the ellipsis should go
<astearns> github-bot, take up w3c/
[css-overflow-4] [css-break] How does `widows` and similar properties affecting fragmentation interact with `continue: discard`?
<github-bot> OK, I'll post this discussion to https://
andreubotella: Here's an implementation of continue:collapse. You can see when the height is reduced to zero, the lines get hidden one by one.
andreubotella: continue:discard is the previous version of this, which was handled with fragmentation
andreubotella: You don't see the same thing, you see that first two lines are hidden together
andreubotella: If you only leave space for first line, both discarded.
andreubotella: Reason for this is 2 properties called widows/orphans
andreubotella: Names are typographical terms, somewhat confusing, maybe we need to rename? But that's off-topic
andreubotella: They control how many lines can be by themselves at the start or end of a fragment
andreubotella: The default value is 2, meaning a single fragment isn't allowed
<astearns> fantasai: do you have an incorrect assumption?
<astearns> fantasai: widows shouldn’t affect the first fragment
fantasai: There's no breaking opportunity between the start of the container and its first line box
fantasai: You will always place at least some content
florian: If you have a 2-line paragraph, and a many line paragraph ... in fragmentation it is what you want, but in this case maybe not
florian: My suggestion is that line-clamp also sets widows/orphans to 1.
florian: Otherwise if there's room for 3 lines, and you only get 2, it will be surprising
andreubotella: My suggestion was to make line-clamp ignore widows/orphans
dbaron: Principle is that you always place something.
dbaron: One reason it exists is not getting into an infinite loop when all fragmentainers are identical.
dbaron: In this case, you have to place something.
dbaron: In context where fragmentainers are not all identical, you may or may not want that principle.
dbaron: But I think we're coming to another solution here...
florian: Andreu's and mine would do the same thing by default, but mine allows authors to set things so that they do take effect, whereas in Andreu's there's no option
astearns: Chair hat off, I'm a little more comfortable with just defining interaction between the properties, rather than having one property set another...
florian: I'm split here. Andreu's version is less magic
florian: If you're doing a very small height in which you're line-clamping, but if people are doing it on a bigger chunk of content, room for 10 lines
florian: maybe in that case would want to have widows and orphans take effect
florian: Completely suppressing most of the time might not be the right call
<astearns> fantasai: suppose you have clamp that’s large and you are fragmenting?
<astearns> fantasai: there you’d want widows to take effect
andreubotella: Question of whether line-clamp container should fragment. It's very buggy and non-interop in browsers.
andreubotella: If we allow these containers to fragment, then probably continue:discard, rather than block effects of this property, it should say that they don't apply for setting the region break
florian: Ok, my earlier pref for setting to 1 rather than ignoring, is not an objection. I'm now on the fence, see arguments both ways.
florian: Long-term, if we really need an opt-in, we can create one.
astearns: Let's go with andreubotella's suggestion for now. It's the least we can do to fix this particular issue.
astearns: We can make that interaction more complicated in the future if we need to
PROPOSED: The region break set by line-clamp ignores widows/orphans
RESOLUTION: The region break set by line-clamp ignores widows/orphans
[css-overflow] How do empty blocks affect line-clamping by height?
andreubotella: Split off from a previous discussion on abspos and stuff.
andreubotella: When clamping by height, the last possible clamp point that doesn't overflow is chosen.
andreubotella: If you have a block element that has no content, it would clamp after it.
andreubotella: That's probably fine, except it means that if there's a line before that empty block, it will not be ellipsized.
andreubotella: The presence or absence of that block before/after clamp point, if that block is empty it doesn't matter. But if the block has position:relative, and contains an abspos, it does matter because it affects whether abspos is hidden or shown
andreubotella: this can also affect boxes that have non-zero content, but height set to zero
andreubotella: In those cases, the content of the box would also be shown or not shown depending.
andreubotella: I think it makes sense to clamp after zero-height boxes. Find the last possible clamp point before the height overflows
florian: Main downside is because last thing before clamp point isn't the line, we don't see the ellipsis
florian: Although in case of zero height *and* content, ellipsis would be seen on that content.
florian: but I guess it's ok, don't put empty <div>s where you don't need them.
andreubotella: If you have a box which is zero-height, but does have content (whether overflowing or abspos), you probably don't want the ellipsis to be placed on the previous line
andreubotella: should we depend on that?
<astearns> fantasai: if you have a para and then a block that’s a horiz rule
<astearns> fantasai: do you want that para to be ellipsised?
andreubotella: Currently it's not
andreubotella: block-ellipsis applies to the last line before clamp point if only thing in between are abspos or end of element
<astearns> fantasai: is that the behavior you want?
florian: We discussed earlier, and resolved on this behavior given no perfect solution.
andreubotella: For some use cases you might want it, and for others you might not.
andreubotella: if you have a line, and then an independent formatting context, you don't want the line before it to have the ellipsis
astearns: So proposed resolution is no special handling for zero-height or empty blocks?
<astearns> fantasai: could we just say the kinds of blocks that inhibit margin collapsing…
florian: Are you saying we should lean more on margin-collapsing-through??
astearns: Could close no change and then explore later
florian: It's not interaction with margin-collapsing, it's trying to identify which blocks we consider and those we don't
fantasai: No special handling, if people complain we'll reconsider
PROPOSED: Close no change until/unless users complain.
RESOLUTION: Close no change until/unless users complain.
[css-overflow] Floats and line-clamp
andreubotella: For continue:collapse, defiinition says if block container contains a clamp point, automatic size will not take into account the content after the clamp point
andreubotella: What does that mean for the line clamp container? It is an independent formatting context, so it is subject to float clearance
andreubotella: If you have a float that is not hidden, it will add clearance to the line clamp container
andreubotella: This is not always what authors expect
andreubotella: In this case, changing webkit-line-clamp to lines 3 or 4, it means float would make the box taller than you would expect by the lines
andreubotella: but if you're clamping by height, the moment you reach the end of the float and you try to push the height upwards, then you would be clamping up to the line before the float
andreubotella: the float is anchored to line 3
andreubotella: I like the consistency with regular sizing, but this is not intuitive
andreubotella: It is also different from behavior you would get with continue:discard, because the float would fragment
florian: Behavior is surprising, but consistend and explainable
florian: If we try to do better, might be able to say that a float that grows the box by adding clearance is treated as invisible, and you remove the float
florian: Don't remove floats in general, because they can cause content to wrap differently
florian: but if it's increasing height of container, then remove it
florian: but then that would change the wrapping of earlier lines..
florian: so maybe put a dummy float?
florian: Anyway, current behavior is not terrible.
andreubotella: I'm worried about implementability even if it doesn't cause lines to wrap differently
dbaron: I'm not sure how much the underlying mechanism here is related to fragmentation
florian: meant not to
dbaron: but even if it doesn't, thinking about it analogously might help
dbaron: The way floats fragment is not well-specified, and probably not interoperable across engines
dbaron: but my memory of how it works in Gecko, you can push the float to the next fragment without pushing the lines adjacent to it
dbaron: In some cases you can also fragment the float
dbaron: that might not make sense here
dbaron: so idk how well analogy to fragmentation works
<astearns> I think fragmenting floats is not terribly interoperable
dbaron: but the other behavior I could imagine is the float goes away at a shorter height in the first case, but lines do what you expect simultaneously
dbaron: that said, idk how hard it is to implement
andreubotella: I worry it's not easy, but I will have to check
<astearns> fantasai: I think that second case seems surprising
<astearns> fantasai: if we did fragment it would be more in line with author expectations
<astearns> fantasai: where we introduce the line clamp could be treated as a frag break
andreubotella: for continue:collapse, it doesn't work based on fragmentation
andreubotella: it just sizes the container based on the size it would have if you ignored the hidden content
andreubotella: and floats can be either shown or hidden
florian: So based on this, my suggestion is to close no change
florian: "we're doing collapse, but these advanced cases want fragmentation", in that case use fragmentation
florian: But that assumes we'd actually define and implement continue:discard.
florian: But I worry we'll end up with something as complicated as fragmentation.
florian: [first picture is clamping by line number, second is clamping by height]
andreubotella: Another possibility is to not include float clearance in the sizing
andreubotella: the float would overflow the box essentially
andreubotella: That is a possibility that is easier than current behavior. I think that's what Firefox and WebKit do currently
andreubotella: This behavior is not what chromium does yet
<astearns> fantasai: so you’re saying we would size basedon the in-flow content only
<astearns> fantasai: the float would clip?
<astearns> fantasai: you’d want to clip it to the content edge of the box
<astearns> fantasai: would be reasonable
florian: So clip at that point, without needing to specify it
fantasai: Yes. In particular to content edge, not padding edge
astearns: You're saying this is what other engines do?
andreubotella: FF and WebKit have the float overflow.
florian: That's oversimplifications. Not just overflow but *everything* overflows and is visible, unless you make it hidden.
astearns: Do we have a quick resolution?
PROPOSED: Floats do not increase the height of a line clamp container. They are clipped to its content edge.
andreubotella: Comfortable with resolving this for now. Unsure how to implement the clipping.
andreubotella: I suspect it won't be a blocker. Not opposed.
astearns: As you look into clipping to content edge, you can open up a new issue if you come up with something that makes more sense.
astearns: Any objections to proposed resolution?
RESOLUTION: Floats do not increase the height of a line clamp container. They are clipped to its content edge.
Regular Telecon - Break - Administrative
Regular Telecon
github-bot, take up w3c/
[css-env] Add environment variables defined in WebKit
<github-bot> OK, I'll post this discussion to https://
SebastianZ: we wanted to publish fpwd of css-env-1
… we had 1 issue that is blocking publication which is deciding whether to add the variables defined in webkkit to the spec or not
bramus: on the thread we looked into these env vars
… smfr mentioned that they were introduced back in the day but they are not aware of any sites that have adopted
… I ran a query on httparchive to be sure
… checking for env(fullscreen-*) in width height etc.
… result came back with 0 sites out of 16 million+ had it in CSS
… which is quite reassuring
… smfr also mentioned they are open to renaming or unshipping these properties
… given 0 sites matched, I think unshipping is the answer
… so not add to css-env spec
Rossen4: seems like a reasonable proposal
ntim: I think it's reasonable
… even if there are some use cases for this env var we probably want to rename anyway
… for now removing it is the right call
<kbabbitt> +1
Rossen4: let's try to resolve
… any objections to dropping this list of env vars that are webkit specific from the spec?
<emeyer> +1
PROPOSED: drop the fullscreen-* vars
RESOLUTION: drop the fullscreen-* vars
Rossen4: SebastianZ do you have a resolution to republish?
SebastianZ: It would be republish or publish, don't remember if we have one
Rossen4: any objection to publishing?
SebastianZ: this would be level 1
Rossen4: FPWD of css-env-1
Rossen4: since this is first public I'd like to have attention and make sure we're ready to publish
fantasai: as long as TabAtkins has reviewed and think it's complete, it's fine
TabAtkins: yes I think we should go for it
Rossen4: objections?
RESOLUTION: publish FPWD css-env-1
<bramus> Yay!
github-bot, take up w3c/
[css-ui] The interactivity property should not be included in the all shorthand
<github-bot> OK, I'll post this discussion to https://
masonf: just read it over and added a comment, question is about whether `interactivity` should be included in `all`
… there was breakage in chrome related to inert attribute being reset by `all:initial`
… best fix seems to be making that UA stylesheet rule !important
… and putting interactivity back into all
… should fix bug and keep important behaviors
flackr: we used to allow un-inerting subtrees that were interactivity inert
… which is I think why this was problematic
… but now that we don't is the problem that it's on same element?
masonf: yes that's the problem
… afaict the only problematic case is when inert attribute is on an element and on same element you do all:initial
… you probably want inert attribute to win
… I think adding !important does exactly that
<flackr> sounds reasonable
lwarlow: just to double check does this have any impact on modal dialogs?
… that was the other case where interactivity came up
… wasn't clear to me what solution was
masonf: 2 ways it can impact modal dialogs
… direct way should not be affected, modals should stay uninerted with rest of page inerted regardless of all property
… reason UA stylesheet has a modal rule that sets interactivity auto, corner case
… it will automatically have that behavior but if author wants to make entire page inert, they have to contend with CSS rules about setting [missed]
… other than that corner case, modal dialog inertness should just work
lwarlow: makes sense
masonf: and there's a way around it if they want to do that weird thing
masonf: everything I've said is my speculation about behaviors, if we go this route we will probably want to test it out
Rossen4: have you?
masonf: no
Rossen4: any other feedback or suggestions?
<lwarlow> +1
<flackr> +1
masonf: Proposal is to add !important to UA stylesheet rule for the inert attribute
Rossen4: objections?
RESOLUTION: add !important to UA stylesheet rule for the inert attribute
<dbaron> +1
github-bot, take up w3c/
Add a property to retrieve plural instances of pseudo elements with the same selector
<github-bot> OK, I'll post this discussion to https://
flackr: proposal is to extend what we have in CSS pseudo to allow retrieving the pseudo elements that have multiple instances
… if a browser does implement CSS pseudos, this is probably a good thing to do because we have many pseudos that can be matched with generic selectors
… I agree with the proposal that it should behave a lot like querySelectorAll
TabAtkins: also agree with use case and proposed ordering behavior flackr suggested in the issue
seems reasonable to me as well
fantasai: 3 different proposals, which one?
flackr: element.pseudo is already in the css-pseudo-4 spec
… proposal would be to add a method that gets all pseudos
… first one I believe, something qSA-like
… that returns all matching pseudos
TabAtkins: yes, the one listed under the Recommendation heading
flackr: open to bikeshedding
fantasai: okay with this
… for element.pseudo would that return first?
flackr: yes
TabAtkins: yes, same as qS vs qSA
… for bikeshedding purposes we should make it pseudoAll? not most grammatical but parallel naming is important
Rossen4: actualy it's not bad
<ydaniv> +1
flackr: seems reasonable
<JakeA> Also things like `matchAll` exist
<TabAtkins> true!
Rossen4: any other suggestions?
Rossen4: Proposal is to add element.pseudoAll that returns a list of nodes
Rossen4: objections?
<JakeA> List of `CSSPseudoElement`
flackr: yes, not list of nodes, list of CSSPseudoElement
RESOLUTION: add element.pseudoAll that returns a list of CSSPseudoElement
ntim: I think element.pseudo was resolved on different issue
Rossen4: if you feel we need to discuss more, bring up that other issue or open a new one
<flackr> +1 we'll keep the names in sync
github-bot, take up w3c/
[css-forms-1] Password visibility toggle
<github-bot> OK, I'll post this discussion to https://
<ntim> (It should be element.pseudoElement)
kbabbitt: in April we resolved to add a pseudo-element for password vis toggle on input type=password
kbabbitt: left name to be bikeshedded
kbabbitt: have been some discussion in the issue, especially about naming form control pseudos in general
kbabbitt: as a general principle, use the word "icon" to indicate graphical indicators, "button" to indicate clickable
kbabbitt: from that, suggests we call it ::reveal-button
kbabbitt: and as an additional proposal, should rename the other Forms 1 pseudos to be consistent with this pattern
<lwarlow> +1
<TabAtkins> +1
fantasai: things get a little ambiguous with, sya, ::picker-icon, which is both clickable and an icon
fantasai: do we really want to be so clear about which is a button and which is an icon in our naming?
kbabbitt: I think there is some inconsistency in the naming, yes in some cases the picker would be a button in others it's an icon...
fantasai: I think that would be confusing for authors, yeah. should be consistent
fantasai: but that brings up whether we want to be so explicit in the names, or if we do want to lean into being ambiguous about whether it's an indicator or button
kbabbitt: personally id' lean toward consistency when possible
lwarlow: I've been thinkinga bout this for a bit, think I mentioned the step-up/down buttons
lwarlow: ideally something that's a button we'd call a button, I think
lwarlow: there are some weird cases tho
lwarlow: in a select element the picker icon is an icon, it's not actually a button. it's not really clickable, the select itself is what's clickable. so picker-icon makes sense there
lwarlow: but in a date input, the picker would be an actual button; you can click on the element but only the button actually summons the picker
lwarlow: file-selector is the other case - it looks like a button, acts like one. but really the whole element is clickable. so arguably that's not a "button" either....
lwarlow: agree that making authors write ::picker-icon sometimes and ::picker-button sometimes isn't ideal
lwarlow: but for new names, I do recommend having button in the name if it's a button
fantasai: for date picker, it depends on the platform, some pop it when you click anywhere
fantasai: so there's some ambiguity on whether it's an icon or button
<lwarlow> We'd probably want to specify that though ideally?
fantasai: we have things that act differently between controls, and things that act differently on a single control depending on time or paltform
fantasai: so that raises the question - if these aren't really two distinct categories, should we even lean into categorizing everything, or lean away and not categorize them?
masonf: was gonna say a lot of that too
masonf: agree it's very ambiguous
masonf: picker-icon was chosen because it was indeed not a button (the whole control is)
masonf: so i'd lean towards using -icon for everything because whether it's a button or not is ambiguous, but it's always an icon in some way
ntim: I lean toward simplicity, like ::step-up (no suffix)
ntim: but in this case I think simplicity would be using the -icon suffix everywhere
ntim: making the distinction is really hard, yeah
ydaniv: from what I know in UIs, button is something you activate with a click/keypress, and icon is activated by hover/focus, so I lean towards button
lwarlow: wanted to push back on "it's always an icon", not sure that's always true
<masonf> It's an icon with the words "choose a file" ... :-)
lwarlow: file-selector-button is actually a button, not an icon. step-up/down can be arguable, but they're rendered as a button. does depend on stylesheet to some extent
lwarlow: I do agree ::reveal should have a suffix, ::reveal on its own isn't clear enough
lwarlow: it even reads more as a pseudo-class on its own, not right as a pseudo-element
lwarlow: so id' be okay with ::reveal-icon if the group likes it. but i'd be a bit more against ::step-up-icon
<JakeA> `revealer`?
<ntim> I like ::reveal-icon because it also opens the possibility for other things than just an interactive button
kbabbitt: I just need a name so I can write down a spec, can explore the more general case in another issue. fine with either icon or button
<lwarlow> It's not an icon with words though... it's just some text in all 3 engines.
fantasai: we should focus on the author experience and what they'll have to memorize, and how we can reduce the memory load. so staying away from categorizing too much is best
<ntim> +1 to fantasai
<lwarlow> +1 I'd be okay with that
fantasai: for this issue, seems like we might just say ::clear-icon and ::reveal-icon (and leave the other pseudos alon/e for now)
<TabAtkins> +1 for me too
<kbabbitt> +1 I'd be happy with that
<fantasai> s/undecided/alone/
<masonf> +1
RESOLUTION: Go with ::clear-icon and ::reveal-icon
github-bot, take up w3c/
[css2][css-flow][css-sizing] How do min/max block sizes affect bottom margin collapse with last child?
<github-bot> OK, I'll post this discussion to https://
<djmarland> Is there a distinction between things that edit the contents of the field, and things that do other things
<fantasai> github: none
github-bot, take up w3c/
[css-backgrounds-4] Using logical keywords in background-position shorthand with multiple backgrounds
<github-bot> OK, I'll post this discussion to https://
weinig: basically this boils down to a discussion about how we should expose these things
… and whether we need a special wording or special value to represent the fact that this is a logical property
… in a way that's not usually done
… not sure there's a resolution to be had yet, probably needs specific spec text proposal
… before there's motion forward
fantasai: I think we need to hash out some specifics
… would it be useful to introduce people?
TabAtkins: I would find it useful to have a quick summary
Rossen4: yes especially if we want to resolve
weinig: problem statement is that we want to add the logical versions of background-position
… b-p-block, -inline
… because these are list properties, you can wind up in a position where it's not clear ...
fantasai: the issue is that, in background-position, we have some logical, some physical, some both ways of specifying position
… we also have longhands for background-position
… x and y, and probably want block and inline longhands as well
… mapping these two together ends up requiring some kind of way of tracking which was specified later in the cascade
… also requires a way to represent computed value of each of these things
… for the first problem, proposal was to add a `defer` keyword
… the author would usually not use, but implementation would use to track each individual longhand whether it's setting something
… or the other property is setting something
… if both say defer, resolve to initial value
… in terms of representing computed value, there's been some discussion, if you set background-position-inline to start-edge, what is value of background-position-x and y
… latter half of discussion is about tracking that information about which side you're setting from
… into computed value
… and then serializing out the appropriate depending on which longhand it came from
weinig: that sounds right. it has to do with the fact that the logical properties usually have e.g. margin: left maps very clearly to inline start or end always
… but because background takes a 2-value thing there's no clear mapping from e.g. background block to regular background
… and so we need additional state
fantasai: for example background-position-x 0% has same meaning as background-position-inline 100% in rtl
… with other shorthands we have all 4 sides and each one maps exactly and computed value space is the same
… so you can have a single value
<dbaron> The main problems seems to be that there are *both* logical keywords *and* logical sub-properties, and it's a list valued property that allows mixing logical and physical within the list.
fantasai: whereas for these properties, in that example you can't return 0% because that would give you the opposite
SebastianZ: what fantasai said is what I posted in one of my later commments
… there are some examples regarding physical and logical properties and how to handle them
… idea would be to add a new defer keyword for that
… like fantasai said
… if you set background-position left bottom
… and later read background-position-inline
… question is what you get back
… idea was to add a defer keyword
… was wondering if we need that keyword or if we can resolve that you use start or end in those cases
fantasai: I think weinig is right, we need to do a thorough writeup of details
weinig: issue contains a lot of examples, work through a lot of edge cases
… sticking point was that the way logical properties are currently defined has certain assumptions about being able to map directly
… either we need to change those base assumptions or add some additional state here that works with that structure
… ultimately we can work through all of the examples to see they do make sense, and you can map them
… we just need the foundational logic to be updated to allow this more complicated mapping
… we need to write something up, I can try to do that
Rossen4: wondering if we should continue that discussion in the issue
fantasai: yes
… that's the next step
<dbaron> I think another question is whether the logical subproperties are actually desirable, or whether we should just add new logical keywords.
github-bot, take up w3c/
[css-flexbox-2] Add flex-wrap: balance;
<github-bot> OK, I'll post this discussion to https://
TabAtkins: we've been wanting some way fo balanancing flex lines forever
… ian spent some time putting together an experimental impl
… available in chrome 138 with experimental web platform features
… quick description of what we've proposed, details are malleable:
… syntactically this is just an addition to flex-wrap property
… balance keyword with optional integer with # of lines to balance
… behavior is: figure out how many lines flexbox will have, or estimate with basic layout
… and distribute in balanced fashion instead of greedy fashion
… current behavior is to use same size as for line breaking
… potentially other ways to balance things nicely across multiple rows
… minimum lines feature, integer, is required for cases where it's a column flexbox where available space is infinite and you would never wrap
… in wikipedia bibliography, cuyrrently done using expensive manual code
… could insteadf be done with a flexbox with 2 columns
… ends up being a simple feature overall
… precise details we can continue to work out
… we're asking to be able to add this to flexbox 2
fantasai: we have several things that should go into flex 2
TabAtkins: this is mature, we can open spec with it
<iank_> Received very positive developer feedback - https://
fantasai: how gaps interact with flex algorithm
TabAtkins: request is open a new draft, flexbox 2, editor's draft, include at least this flex-wrap balance feature
… and at editor's discretion whatever else we want to put in
fantasai: I think having a flex-wrap balance feature is a good idea and we should do it
… some discussion about having balance stuff on item-pack instead of flex-wrap
… in any case you probably want to split out whether you're wrapping and what direction from the style
… just like we do for text balancing
… the kind of, how you prefer to place items is a separate control
… so I think it should be a separate property
… last time we talkd about it, we tralked about item-pack: balance
… happy with that or we can consider other things
TabAtkins: we need to resolve those remaining items questions sooner rather than later but I don't want to take one right now
fantasai; in any case it should be a separate property
TabAtkins: happy to figure that out in the draft
… not looking to ship tomorrow, but ready to explore
Rossen4: proposal is to open new ED for flex level 2
… and flex-wrap balance, and continue to work on it there
Rossen4: objections?
fantasai: happy to take a resolution to add a flex balance feature as long as it's a separate property
TabAtkins: happy to have flex balance feature, syntax TBD
<dholbert> I'm a little uneasy about the "leave how to balance up to implementations" part; want to be sure the behavior is reasonably specified
<dholbert> but not objecting to the feature in general
Rossen4: any objections?
<fantasai> PROPOSED: Add a flex wrap balance feature, as a property separate from flex-wrap
TabAtkins: syntax TBD as part of wrap up of item discussion
fantasai: but put something in spec right?
TabAtkins: yes, doesn't matter what yet, don't need to resolve on syntax yet
… don't want to resolve on syntax until we have the wider discussion
fantasai: draft something into ED but draft as separate property
TabAtkins: we don't need that as part of the resolution
Rossen4: syntax TBD is good enough, we'll figure out what that syntax is
fantasai: happy to leave syntax TBD, would like it to not be flex [missed]
TabAtkins: will mark it off as flex bikeshed
RESOLUTION: Add a flexbox level 2 with flex balance feature, syntax TBD
github-bot, end topic