Meeting minutes
github-bot: take up w3c/
[css-position-3] Absolute positioning - Is the new inset & auto-size behaviour web-compatible?
<github-bot> OK, I'll post this discussion to https://
oriol: this was discussed a few weeks ago and I couldn't attend
… not sure if the consequences of the resolution were fully understood
<miriam> present
oriol: the implication is that you can have an abspos with auto margins that if it has normal alignment it'd stretch, but if you change self-alignment to be stretch, then it will stop stretching
… I think that doesn't really make sense and would just cause confusion
… in flex and grid auto margins don't stretch even if they have stretch alignment
… but this happens both for stretch and normal alignment
… so I think it's better to have abspos be consistent
… and avoid having the align-self: stretch align with flex / grid
… also the argument for making consistent with flex/grid feels weak
… in block layout auto margins don't prevent block level items
… from stretching
… so I'd like to change the previous resolution
… so that if some stretch with normal alignment they also stretch with stretch alignment
fantasai: whichever way we go we are going to introduce inconsistencies
… in terms of alignment I think being consistent with flex/grid is more important because that's what authors are used to
… in block layout only blink has implemented and it's very recent so we can probably change it
… for normal we're stuck with css2, but for the other keywords it'd introduce inconsistencies
… are you proposing that auto margins are stronger than centering in flex/grid but not abspos? That seems like a bad idea
… maybe changing stretch only is better than the current situation, I admit it's quite weird that stretch is less stretchy than normal
oriol: not sure the right way to look at this is props winning over other
… the way i see it is both margin and alignment have some effect simultaneously
… e.g. both may affect the auto size to be fit-content
… also auto-margins work by changing the margin box and alignment works in terms of that box
… so if you have auto margins that fills the whole container alignment won't do anything, but it's not like it is disabled
… it's more like it doesn't matter which value you use
… whether we decide that self-alignment forces auto size to be fit-content or auto margins do that I think it's independent decisions
… and it's not like some values win and don't don't
… e.g. even tho in flex and grid auto margins prevent stretching
… then center alignment could prevent stretching even with a 0 margin
… so we could say that center alignment is "winning" over the 0 margin
… so what wins and loses can be subjective
… I prefer seeing it as different things applying simultaneously
fantasai: so iiuc, if you have auto margins and stretch, the first thing you do is stretch
… then auto margins end up having no effect (unless max-size is involved)
oriol: exactly
… so in this case for abspos neither auto margins nor stretch alignment force fit-content size (so it can stretch)
… typically alignments won't matter because auto margins will resolve to 0 and then alignment would do nothing
… but if you have a max-size then you can align stuff using the alignment properties
fantasai: I think that makes sense. There's a weird clause about negative and auto in this case, need to go back and check, but should be fine
astearns: so prev resolution is no change to the spec, what should the spec say
oriol: a way to word could be "change stretch alignment case to allow the size to stretch when the normal alignment case allows stretching"
astearns: makes sense, wdyt fantasai?
fantasai: yeah
<emilio> +1
RESOLUTION: change stretch alignment case to allow the size to stretch when the normal alignment case allows stretching
github-bot: take up w3c/
[cssom][css-grid] Do shorthands serialize with the resolved value of their longhands?
<github-bot> OK, I'll post this discussion to https://
oriol: Some longhands have special getComputedStyle behavior, so you get the resolved rather than computed value
… it's not clear what happens when you're serializing a shorthand that involves these
… in the issue I have various examples
… e.g. margin: auto and you serialize margin-top you might get zero, but if you try to serialize the margin longhand itself you get auto in firefox but 0 in blink/webkit
… it's particularly weird in grid properties
… because the implicit tracks and repeat() expansion
… we have cases where all browsers are different
… I think I prefer what webkit does
… which is you serialize the shorthand as if the computed value of each longhand was set to each special resolved value
… I think that's the most consistent
emilio: I agree.
emilio: FWIW, I consider the Firefox behavior to be a bug. Haven't gotten around to fixing, because the getters are in C++ and ...
emilio: What WebKit is doing, resolving each individual longhand, and then serializing shorthand with that is the right thing to do.
emilio: This is what Firefox does for all things that don't involve layout
astearns: web compat concerns or other opinions?
oriol: If webkit isn't having compat issues this is probably fine?
<TabAtkins> +1, I *suspect* this is reasonably safe
<TabAtkins> and we can always add exceptions as necessary
<fantasai> +1 TabAtkins
PROPOSED: Shorthands serialize using the resolved value of the individual longhands
RESOLUTION: Shorthands serialize using the resolved value of the individual longhands
github-bot: take up w3c/
[css-grid] grid-gap is still taking up space when an element defined in grid-template-area is not on the page.
<github-bot> OK, I'll post this discussion to https://
oriol: the problem here is that's typical for authors when using grid to define some tracks in case some optional content is there
… if the optional content is not there, then if they use grid-gap you get extra space
… they basically want gaps to collapse together if there's no content in the track
… proposal is an `empty-tracks` property with an initial value of `normal`
… so empty tracks only collapse gaps with autofit
… then another value (`height` for `empty-cells` or `collapse` for consistency for `visibility`) that makes a track with no items in it or crossing it collapse
… there's other proposals which would make it collapse only if the sizing function is guaranteed to be zero
… or collapsing when the item spans
… but that adds a fair amount of complexity, and the simple solution already covers the vast majority of use cases
… for other variants we could consider other keywords in the future
… so I'd go with the simplest way
fantasai: I think this value makes sense
… some of the other behaviors are probably also valuable
… so I think the name should maybe be more extensible
… my suggestion is the `grid-collapse` property (`none` / `normal` as initial, `empty-tracks` as the value oriol is proposing)
astearns: `grid-track-collapse` might be better?
emilio: was going to bring up the name as well
… but seems like a good idea
astearns: Is this always going to be grid specific? Flexbox doesn't have this implicit things, but masonry might?
… just asking whether this should be layout agnostic since gaps are more layout-agnostic
fantasai: conceptually it's about collapsing tracks, more than gaps
… re. grid vs. masonry they both use the grid-* track management properties
… if we're not making it grid specific we could do track-collapse, but I think grid- might make it easier to see they play together
… was going to bring up that the default value could maybe be more useful
… maybe if the track is completely empty and there's an intrinsic size it should collapse by default
… not sure about compat tho
astearns: yeah compat is a bit concerning here
oriol: a bit concern about changing the default for web compat
… the doing something different when the track sizing function is just intrinsic
… might be a bit weird. `auto` is intrinsic, but auto tracks stretches to fill, should it still be considered empty?
… this is related to the thing I talked about about whether the track is guaranteed to have a size of zero
… so in general more magic behavior worries me
astearns: so details are going to be fuzzy, but sounds like starting to specify a `grid-track-collapse` prop might be a good idea?
fantasai: if we call it `grid-collapse` we can expand it to `grid-collapse-{rows,columns}`
<kbabbitt> +1 fantasai
fantasai: the `track-` extra typing might be very wordy. Grid is mostly about tracks
PROPOSAL: Start defining a `grid-collapse` property
RESOLUTION: Start defining a `grid-collapse` property
whereas grid-track-collapse-rows is very redundant
github-bot: take up w3c/
[css-align] Clarify how `justify-self` affects automatic size of block-level box
<github-bot> OK, I'll post this discussion to https://
oriol: two implementations of justify-self on block boxes (blink and servo). We interpreted some things that the spec says in different ways
… some things we agree on fantasai disagreed on
… want to clarify this
… two questions:
… first could be the effect of `justify-self` on the auto size of a block level box
… spec says that values other than stretch makes auto size fit-content
… so it applies to grid/flex items and block level items
… both blink and servo did this
… fantasai was interpreting it as this property doesn't affect block level sizing, only in over-constrained cases
<iank_> +1 to Oriol - it makes it more consistent w/ grid/flex
oriol: I kinda prefer the fit-content behavior unconditional
… allows to explain tables
… could be explained as `justify-self: normal` on keywords is `start` rather than `stretch`
… on the other hand means diverging from `<center>` and html `align` attributes since those don't prevent stretching
… I prefer treating block-level boxes as other boxes
… but if fantasai wants to argue for an exception...
fantasai: this also plays into the related issue about the effect of these properties when anon boxes are present
… anon boxes always stretch
… so there's an issue there where if you take the position that this affects fit-content you get inconsistent behavior if you have anon boxes
… I initially thought that this was fixing the alignment of stuff given how long block layout has existed
… guess we could go either way
iank_: IMO this makes the feature useful by default
… so kinda prefer how servo and blink interpret it
emilio: Don't disagree, but was curious about the anonymous box situation
emilio: justify wouldn't apply to the anonymous box, right?
iank_: Concern for top-level anonymous boxes that are generated
iank_: consider our previous behavior a bug, so changed so that anonymous boxes ignore justify and always stretch, but we can talk about that issue separately
emilio: Makes sense to be consistent with block (???) to not introduce other issues
iank_: What do you mean?
emilio: If it doesn't do weird things if you have an anonymous block inside.
emilio: If that's ok, then making it work by default makes sense.
astearns: Do we have consensus? what's the resolution?
oriol: Values other than normal or stretch treat the automatic size as fit-content, just like in flex/grid
astearns: Does everyone agree?
fantasai: I'm ok with it.
fantasai: we should ack that this makes justify-self not work for html centering stuff
<TabAtkins> yeah, we've abandoned doing <center> with this now
PROPOSED: Values of `justify-self` other than normal or stretch treat the automatic size as fit-content, just like in flex/grid
RESOLUTION: Values of `justify-self` other than normal or stretch treat the automatic size as fit-content, just like in flex/grid
oriol: there's another thing about how auto margins behave with this
… in servo we have different interpretations
… there's an example in the issue. If you set `justify-self: right` then the size will be `fit-content`, however if then you add auto margins, then these prevent `justify-self` from forcing fit-content
… in servo justify-self still prevents the stretching even with auto margins, and I think that makes more sense
<fantasai> +1
<oriol> w3c/
iank_: yeah basically, do auto margins disable justify-self or just the alignment part of it
If stretching is disabled for zero margins, then it should definitely be disabled for auto margins
<emilio> +1
fantasai: this goes back to the first issue, where alignment is applied after margins
which are applied after sizing decisions
oriol: right in this case the size of the margin box fills the container
… so you don't see the effect but it's not "not working"
fantasai: if the box is larger than the container the auto margins will not absorb that space
… not sure we want the alignment to take effect in that case
… if you have auto margins you were expecting a particular alignment
… or do you just start-align it
oriol: I think if you have unsafe alignment then why not
… but yeah, not sure
iank_: I think auto margins are safe by default, so I think the defaults are actually the same
fantasai: right but in this case the margin can't absorb the negative space
iank_: but by default it's safe alignment so the default should be fine?
fantasai: not sure it falls out of the definitions
iank_: to be clear I'm fine changing blink here
I think CSS2.1 is written in a way that this wouldn't fall out.
astearns: does the previous resolution apply here?
oriol: probably should be a separate one
… the question that fantasai raised could be for a separate issue. We can resolve for the non-overflowing cases
PROPOSED: alignment values different than stretch cause sizing to be fit-content, regardless of auto margins
PROPOSED: auto margins do not prevent justify-self from imposing fit-content
RESOLUTION: auto margins do not prevent justify-self from imposing fit-content
github-bot: take up w3c/
[css-align] `justify-items` and anonymous block boxes
<github-bot> OK, I'll post this discussion to https://
<oriol> w3c/
oriol: since we resolve justify-self can force fit-content size, if you use justify-items on a block container, a block container with inline level contents, justify-items won't apply
… if you then add a block, you add an anonymous block level box and justify-self applies to it
… so it's very unexpected that adding a block-level sibling changes the alignment
… option 1 would be that anon block boxes would always stretch rather than using justify-items of the parent
… another option would be that justify-items other than initial you'd still wrap stuff
… IMO option 1 is the easiest to implement in servo, also avoids some questions about what to do with percentages and so on
<iank_> +1 Oriol - There is a whole can of worms involved w/ option (2)
oriol: percentages in the block axis skips anon boxes, should we skip them in the inline axis if we consider the other option?
… miriam preferred option 2 since it's more useful for authors (no need to wrap in implicit elements)
miriam: oriol described what I think, alignment is one of the more common things to do and doing it easily makes sense
https://
miriam: but either option feels better than the alternative
fantasai: there's one property that allows you to wrap things, not sure it's implemented
… the behavior you want is not the behavior that would fall off from wrapping in anon boxes
… consider a paragraph with text, block level, then text
… if we wrap each in a box then they'd be independently aligned which I'm not sure is what you want
iank_: pretty against option 2
… quite a large can of worms
… probably big source of confusion for web devs too
… a little concerned about compat too
… so prefer option 1, authors ??? text-align
astearns: we could resolve on updating the spec to option 1 with a note
miriam: ok with that
PROPOSED: Anonymous block boxes always stretch
RESOLUTION: Anonymous block boxes always stretch (go with option 1)