Meeting minutes
astearns: While we wait, does anyone have changes for the agenda?
florian: Item 0 should have been happy new year :)
astearns: Fair.
astearns: We'll skip item 6. Delan wanted us to skip that one
astearns: I believe first was from fantasai. Are you on yet?
astearns: Happy new year everyone. Thank you for coming back after the break
astearns: On private list we have a backlog so we'll look for a longer form meeting. If anyone has preference for when please post to the private list
[css-flexbox] Flexbox alignment and fragmentation
github: https://
alisonmaher: This is about handling alignment when fragmeneting. Issue also applies to grid and tables
alisonmaher: According to spec it suggest align per fragment. Flexbox is only that makes this suggestion. Can confuse impl and may imply flexbox is unique.
alisonmaher: Would it make sesne to change to suggest align prior and can ignore
alisonmaher: Advantage of ahead of time is it layout more similar to non-fragment. Consiquence is how to handle margins. Spec says truncate at soft break and they can affect alignments so may not want to truncate
alisonmaher: FF does not truncate
alisonmaher: prop: update to match FF for margins during fragmentation and add similar language in grid and tables
iank_: broadly supportive
iank_: When fragmenting, doing it globaly somewhat makes most sense when you look. Otherwise you can get things in unexpected columns and not aligning at the end
astearns: I'm not entirely convinced of the preference for stitching back together in way that looks more like unfragmented, but not against the change
astearns: If there is a use case for align per fragment is that a switch we can add, maybe like how we do box decoration breaks where an author can choose?
iank_: Potentially. I think for that case what we might do is treat everything as start aligned and do alignment then
iank_: one thing that should be said is this would match what impl do in reality. Blink at the moment b/c we're adding proper fragmentation and fixing bugs
iank_: Theoretically possible to haev a switch. Place where per fragment makes sense is content-alignment. But that's different
dholbert: Justify content?
iank_: No, talking about...what's the keyword...we don't have it, I think only FF does. Let me look it up
dholbert: first-basline and last-baseline?
iank_: Ignore my last comment. I'm confused.
florian: Usually when it comes to things that relate to fragmentation print formatters have spent more time on this. prince at least supports both fragmentation and flexbox. Might be worth looking at what they do. If it's not what we're proposing we should think about it more
iank_: This is slightly larger than flexbox since it applies to grid and table
florian: I don't remember if they do grid. Might
iank_: For grid doesn't make a lot of sense to do by fragment
florian: I don't have an objection, but given it applies to things important to print formatters it's worth looking at what they do. We can make a revision and put a to do to look and revisit if needed
astearns: Is there a good person to tag? I would go to Dave Cramer but I'm not sure how much time he has for CSS
florian: That was my answer as well
<GameMaker> present_
astearns: Maybe we can tag Dave and see if he can give us an idea of what Prince is doing. Somewhat convinced we should take the proposal since it's what FF is doing. If there is a difference we can think again
dholbert: FF supports the change. It feels like most coherent thing to do
iank_: That's what I came to as well. It falls out to make most sense
astearns: Prop 1: We will spec that grid, flex, and table fragmentation align globally before fragments are created
alisonmaher: Correct
astearns: Do we need anything about margins in that resolution?
alisonmaher: Sep
astearns: Concerns about that resolution?
astearns: Obj?
RESOLUTION: We will spec that grid, flex, and table fragmentation align globally before fragments are created
alisonmaher: Margins want when handling alignment globally shouldn't truncate margins at soft breaks
astearns: Can we do that without causing any cycles in determining if a soft break
alisonmaher: I think FF already doesn't truncate margins in flexbox case so I think there's a prior for it
astearns: Okay. Interested in seeing test cases we can apply for this. Seems to me lots of weird edge cases for particular kinds of margins. I suspect not well tested
alisonmaher: Yeah
astearns: Anything more to discuss about margins?
dholbert: Additional point, when doing global alignment the thing aligned is the margin box which is why it makes sense to preserve the margins
astearns: when we are aligning globally we will not truncate margins at any break
alisonmaher: We could say it generally
astearns: Prop: we will not truncate margins at any break when aligning globally for fragmentation
RESOLUTION: we will not truncate margins at any break when aligning globally for fragmentation
astearns: Blink is going through this and will be adding new fragmentation code. Test cases as you go?
alisonmaher: Yeah
astearns: alisonmaher would you ping Dave Cramer?
alisonmaher: Sure
[css-conditional-3] Setting .conditionText interop is terrible
TabAtkins: Wait for fantasai on this
[css-values-4] Validity of generic interpolation function mix()
github: https://
TabAtkins: Making sure we agree what generic interpolation does and if it's valid
astearns: Only concern is last comment asked for fantasai to clarify
TabAtkins: True. But not relivent for this, I think.
TabAtkins: We have a couple of mixing functions lick color-mix and calc. These functions have a type. Color-mix is a color, valid whereever a color is. But generic interpolation function, currently called mix, I don't believe can be same
TabAtkins: It can interp things without describable types. Interp of a box shadow is only valid in box shadow.
TabAtkins: Prop is mix is only allowed as top-level value of a property. That's all it would be produced as by UA, but if authors use it they could not combine with other things. Can't mix 2 box shadows and then add inset.
TabAtkins: I believe that's all this is about, verifying that's what we want for the grammar of this function
TabAtkins: If no one disagrees we can resolve
smfr: Questions- if you have prop with comma sep values like backgrounds, can you use mix in the list or is the whole list a mix?
TabAtkins: Great question. Hmm.
TabAtkins: I think still the entire thing. Even in lists of comma sep we can have distinct syntaxes at a position like bg where only color in the last. We couldn't interp a mix with a color unless it's final. So would have to be the entire thing
smfr: High level, how does this interact with animations? Can I use it in keyframes?
TabAtkins: SHould be usable anywhere that accepts a value. Value is generatable by an animation so it should be a valid value. You can interp to this. Things you can do by hand should allow explicitly.
smfr: keyframe? only animatable properties?
TabAtkins: Yes, if prop wasn't animatable then mix wouldn't have a meaning. Great question and not in spec. I suspect should be properties that are not animatable mix isinvaid at parse time.
smfr: If you can spec in keyframes implies mix can nest
TabAtkins: because you can mix between and mixed value and something?
smfr: Yeah
TabAtkins: True. Good clarification. mix should be able to be an entire argument of the mix. You should be able to mix mixes
smfr: Shorthands vs longhands when mix is the enitre value?
TabAtkins: We had an answer. I believe it needs to be similar to variable in shorthands, but don't recall exactly. Whatever it was, we can't rely syntaxtically that something is a shorthand so whatever we define has to work well for shorthands.
TabAtkins: Mix should be allowed in a shorthand. Exact interp I can't answer but should be as reasonable as can make it
smfr: SOunds good
astearns: Looking for resolution to define mix as only top level
astearns: Issue also talks about adding another lower level value. punt that for now?
TabAtkins: Yeah, it's separate
astearns: But if we expect lower question is which gets the shorter name
TabAtkins: My arguement is the existing lower-level have longer names like color-mix. Completely usuable anywhere should get the shortest name. no way to be generic low-level because we need to know type to parse. Interp at the value level will be type specific. mix should have short names and others longer and more specific
astearns: Other questions or ideas?
astearns: Prop: The mix interpolation function will only be used for top-level values with various discussed caveats
TabAtkins: Sound also resolve on name
astearns: And mix is the name of the top level interpolation
astearns: Objections
RESOLUTION: The mix interpolation function will only be used for top-level values with various discussed caveats. mix is the name of the top level interpolation
astearns: Since this issue discusses lower level, is that captured elsewhere or should we open another issue
TabAtkins: One talked about is numeric and that does have an issue for it
astearns: I'll see if I can find it and link it
[cssom][css-break] getComputedStyle and fragmentation
github: https://
florian: A while ago looking at def of gCS and it does not mention fragmentation. problem b/c element frag gives multiple answer to value of property. What to do?
florian: GH suggestion which is roughly okay with commentors is other APIs are fragment aware so people who want per frag should use those. This API we should do simpliest with tweak for compat
florian: Simpliest is return first fragment. Might need to tweak based on historic impl. Assuming hoz writing mode, height of the block chrome returns sum, though FF returns first. Probably not compat porblem there, but might have it elsewhere
florian: Suggestion is doc that gCS returns based on first fragment and we document compat issues sep
florian: Suggestion from fremy to make it a little smarter and answer on last for other writing modes. I think I would suggest not taking the suggestion. This will not be smart enough to describe everything so you need frag away APIs
florian: If compat dictates smarter this could be one of the things, but would rather not if we can keep it simple
TabAtkins: I think I agree. Don't think we can get smarter without being complex. Going with simple answer of first frag is easier
iank_: Not wild about first fragment. Larger set of problems about client width and height and how they interact
iank_: In a lot of libraries they compute to witdh and height and used interchangably. Someone using this naively they would get unexpected results when printing. If you sum as I suggest in the issue you get broadly expected
iank_: I don't expect a large compat issue, but it's a little unintuitive
florian: Can we say unless documented we go with first fragment but with block dimensions we sum up. And maybe for padding, border, margin we take last for inline-end and block-end. Maybe that's enough of an excpetion?
iank_: What properties return funcy used? width height padding border margin?
florian: More. Offsets as well
florian: width height margin padding, top left bottom right
florian: Another complication is we're baking selectors that let you style different fragments differntly and then any property could have a different answer. Not exposed, but might be coming
iank_: With that we would start not to return...you can't really...a lot will break if you set different margin-top per fragment. Skeptical we'll need to do something for that case
florian: Even if we don't get that. for margin-bottom return the first, last, depend on box-decoration-break? If compat dictates we should take that
iank_: Rathr then applying general rule would be good to go through cases individually and come up with answers. I suspect I agree with amrgina nd padding for first/last fragment but width and height we want different.
iank_: It would be better to do case by case
Rossen_: I'm more closely aligned with iank_ then the simplicity. Generally I'm all for simplier and more definitive answer. I believe there will be unfortunate compat breakage we'll see for apps building pagination-ish presentations
Rossen_: I've seen a number of apps using multicol to drive book-like experiences. For them, back in the time this is why we into getClientRects and go down patch of fragment aware things. Zooming out, not being able ot know where a box starts which is what you will run into if you only give results on first frag which could give you a result under the 2nd, that would be unfortunate
Rossen_: I'm closer aligned with iank_ 's point
florian: Strongly agree we need something that's fragment aware. But gCS isn't fragment aware. As to breaking interop, we don't have interop.
florian: Another thing I forgot to mention is we don't need to get to fancy APIs to get into troble. We could sum heights, but what to do with width when frag have different width? Or an inline that breaks 2 lines? Block that's across 2 pages? No answer in the spec
florian: We can go property by property as iank_ said. Having done that for height there's no interop
astearns: Not that we break interop but that we break compat. There are likely sites that rely on Blink's behavior. Risk breaking them if we spec differently
florian: But if it's engine specific should we also not change FF?
Rossen_: If they don't have bugs they're either not used for these presentations or they've coded to adapt. I want to udnerscore the point about compat vs interop. I'd be more concerned about compat at this point
astearns: If concerned about compat and there isn't anything that we can spec as safe, perhaps we explicitly say gCS is not frag aware, different enginres return different and we don't spec what to do
florian: Not terribly helpful
astearns: It's not. but going through what to do with every layout property with interesting frag when we can't spec something interop, is that a wild goose chase?
Rossen_: Sounds more academic than applicable. Do we have use cases for alignment? These properties have existed for quite some time so people work around it
florian: Confsed how it can be true simultaniously that this is sufficently used that we can't change but unused that we don't have to answer. If people aren't using this spec simple or say undefined. If it is used would be good to haev a known behavior for interop
smfr: Might have legacy content on each browser relying on the behavior
Rossen_: epub viewers are built against 1 engine and for these apllications they have very specific code with very specific behavior for the engine. Whatever that engine does is what they'll get
florian: Not so sure. Paginators are frequent cross-engine.
iank_: Specific example, a lot of people run chrome in headless to generate pdfs. A lot of people doing that
iank_: To my previous point, only properties we'd use layout dependent is margin, padding, width, height, and the insets
florian: Also borders. Sizes don't change but box-decoration-break might or might not have
florian: But yes, it's those
iank_: I wonder if we can go through these and pick what is reasonable. for example, for the edge type things, border padding margin and insets I'll agree picking first or last will be pretty compat. not huge burden on engines to sum on block and take max on inline
iank_: I think blink and wk do that already. Would be interested to hear for gecko
florian: Not particuarly hard. But in viviostyle there is a measure of lazy rendering for a many 1000 book and having a blocking call that forces you to layout isn't great. Maybe no way around
iank_: I can come up with examples that will render incorrect due to that
florian: Yeah. For block maybe no way around. For inline maybe we can just do first?
iank_: Yeah. I'd like this consistent with client height. A bit of precedence with inline element fragmentation. might be wrong there
chrishtr: No strong opinion, but maybe take this offline for specific proposals?
chrishtr: There is #6588 on the agenda which we need for progress
astearns: Okay, will go back to GH on this issue and get a list of properties we want to consider fully
[cssom-view] Needs more details for offsetWidth and offsetHeight
github: https://
chrishtr: Discussed Oct 6 and resolved that they should be computed out of principle css box
chrishtr: If you have an inline split into mult frag with a child that's block shoudl the balance of the block be included
chrishtr: No strong opinion in discussion. Weak opinion not to, but impl difficulty should be a factor
chrishtr: Enginers have been trying to simplify code and have found that including it would be simplier to impl and give same answer as getBoundingClientRect. Suggest include block box in the bounds
astearns: Make sense.
astearns: Prop: When an inline box is split by a block box, offsetWidth and Height will include dimensions of block box
astearns: Obj?
RESOLUTION: When an inline box is split by a block box, offsetWidth and offsetHeight will include dimensions of block box
[css-contain-3] What happens to other @rules inside @container?
github: https://
miriam: Dealt with a version of this problem before
miriam: Containers don't have a global resolution. Specific to elements and contexts
miriam: Need to know if allowed and what happens to have global @rules like property or fontface inside @container
miriam: On thread agreed for these rules we think @container should be treated as true for all cases like these to be consisten with previous decisions
astearns: No difference in having @fontface inside or outside a container
miriam: Right
astearns: reasonable to me
TabAtkins: yep, agreed
dbaron: At first glance seems surprising. Are there other things that work this way?
astearns: Talked about layer order previously
miriam: Yeah, layer order. I feel like also some name defining @rules, but that's this so maybe we didn't. I think there was previous art on this
TabAtkins: Ultimately they're always true or false, we can't make them dependant on the query. The always true is consistent. But we oculd say it's always false if that's more reasonable.
dbaron: Curious why it's not syntax errors and drop. That was one of Rune's options
astearns: Would you like more time to consider and consult?
dbaron: If nobody else thinks it makes sense okay resolving. My intuition is if we don't know how to process it shouldn't be allowed
astearns: We can process fine. Slightly less surprising the rules don't disappear
dbaron: Maybe. Okay
astearns: We are at time. Prop: Property and fontface rules always work in an @container rule
miriam: Prior art was for @layer where @layer has no effect on name defining rules
astearns: Anyone want to chew on this more?
RESOLUTION: Property and fontface rules always work in an @container rule
end
astearns: Thanks for calling in for the first meeting of the year. We'll talk for the hour next week and have a longer call later in the month