Meeting minutes
Rossen_: Any other items?
plinss: wanted to talk about draft server
content:none
<Rossen_> github: https://
emilio: We implemented it, broke tons of sites
emilio: We should at least fix the spec to say that content:none has no effect on non-pseudo elements
emilio: It's a bummer because 'content' does have effects on some elements
emilio: We could add another value to the content property to represent that behavior
Rossen_: how broken?
emilio: content:none suppresses boxes for children of element
emilio: sites were specifying it on a bunch of stuff using e.g. * { content:none; }
emilio: initial value is normal
florian: I wouldn't have expected it to be Web-compatible, has been a no-op for a long time, so mistakenly applied in lots of places
emilio: any objection to change the spec to match reality?
emilio: other question is should we add a new value
<florian> fantasai: we should spec it
<florian> fantasai: if we need a new keyword, I'd suggest "empty"
<florian> fantasai: not too sure what the use cases are though
Rossen_: any other comments?
emilio: not sure we should even add the keyword, we implemented for completeness
<rachelandrew> it would be interesting to see if authors have use cases
bradk: I think there could be some interesting cases for having the box but not its contents
<bradk> That was me
<TabAtkins> we can just leave the discussion out of this issue for now, and open a fresh issue arguing for adding this new keyword
emilio: also interesting question about interaction with content-visibility:hidden
<TabAtkins> no reason to tie it to this discussion
<astearns> +1 to new issue for use cases
bradk: maybe ask authors
<emilio> +1
Rossen_: ok, let's deal with that in a separate issue
Resolution: spec content:none as having no effect on elements
identity transforms
github: https://
emilio: I wasn't on last week's call
emilio: seems fine to add a new value to represent this
emilio: ...
smfr: I'm ok with something like perspective(infinity)
<astearns> we ran out of time last week to get to a resolution
smfr: I do wonder about the lack of units, wonder if it adds complexity to animations and blending
TabAtkins: perspective is normalized to matrix, so shouldn't be a problem
TabAtkins: addition with infinity would swamp whatever value the other side was, so don't have to worry in that case either
Rossen_: sounds like we're going forward with infinity?
astearns: there was also the suggestion of perspective(none)
TabAtkins: smfr brought up that animation-iteration-count uses 'infinite' whereas calc() uses 'infinity', so 'none' would dodge the issue
<jfkthame> +1 to perspective(none)
Rossen_: is everyone ok with none?
Resolution: Add perspective(none)
Compressible elements with aspect ratio
github: https://
Rossen_: is this ready for discussion?
github: none
Draft Server
plinss: As many noticed, drafts server has been unreliable lately
plinss: fundamental issue is it puts a lot of load on database
plinss: when get hit by ton of crawlers
plinss: fix is to make code less reliant on database, serve static files
plinss: unfortunately it's 1-2 weeks of time for me
plinss: which I can't take off from work
plinss: if anyone wants to sponsor it, I can just do it
plinss: server also needs a bunch of other tuning, which is why estimating up to 2 weeks work
plinss: alternatively, look for a different solution
plinss: but that would not have the same features as the draft server, e.g. regenerating to ensure cross-links continue to work
plinss: I would not be doing the alternative work. I would not recommend that.
plinss: my recommendation is to just fix the infrastructure
gsnedders: Alternative where any of us, not just plinss, can do maintenance might be better.
plinss: either way, someone else has to do the work
plinss: doesn't have to be done by me, I'm happy to give access to the current infrastructure
plinss: just I'm the most familiar with it, so can do it the fastest
<TabAtkins> yup, will look into this
plinss: so looking for anyone to sponsor the work, or to take on the work for setting up alternatives
replaced elements percentage-sized within grid areas
github: https://
github: https://
iank_: There's concept of compressible elements, if you put a percentage width in one axis, it will compress to min-size
iank_: Chrome did a bunch of fixes in this area (replaced elements) recently
iank_: that brought our behavior more inline with the spec here
iank_: which applied an automatic minimum size in this case
iank_: web author found this really surprising behavior, filed issue
iank_: Question is do we want to follow the spec, and if not, how do we match the author's expectation?
iank_: Firefox behaves as expected, because there is some behavior around transferred sizes that they still don't do correctly.
https://
<florian> fantasai: tab and I looked over this
<florian> fantasai: our conclusion is summarized in the issue
<florian> fantasai: the author's expectation is reasonable in this case
<florian> fantasai: chrome and firefox used to match that, until chrome fixed to match the spec
<florian> fantasai: [explains example]
[ fantasai insert summary later]
<Rossen_> 1fr has an auto min implied and that's what's causing the breakage.
<Rossen_> fantasai: the auto min size is supposed to be weaker constraint of specified height... and that's what's happening because the % isn't taking affect
<Rossen_> fantasai: the sln we are interested in is to make % resolve against min definite height. resolving against 0 is to clamp the min size. do it for compatible elements and potentionally all els
<Rossen_> fantasai: did everyone follow, or should I explain something again?
<Rossen_> iank_: I did :)
<TabAtkins> Summary: During Grid layout, we first lay out to figure out row heights, then lay out given that height to figure out column widths (then maybe do both of those again). A 1fr item size has an automatic minimum; during the first layout both dimensions are unknown so the auto-min doesn't trigger, but in the second layout there is a height so it *does* trigger, and this ends up giving us the bad behavior where the height is frozen as "large"
iank_: I'd be concerned about doing this for all elements
iank_: if we do, should only do for compressible elements
<TabAtkins> But our intention was always that auto-min be a relatively weak constraint - it shouldn't be taken as gospel in the middle of this algo and have this effect.
Rossen_: what's downside to doing it for all elements?
iank_: Currently, if you've got a non-replaced element with width:100%
iank_: that would change behavior pretty drastically
fantasai: what if we only clamp the transferred size
<TabAtkins> (because of the ordering of row vs height resolution, this behavior doesn't have a bad effect when the space is tall; it only makes the element too-large when the space is wide, which is an annoying discontinuity)
iank_: so only things with aspect ratio ...
iank_: would need to think about that a bit more
Rossen_: can add aspect-ratio to anything, now, right?
fantasai: 2 inputs into auto min size: content size in that axis, and for items with aspect ratio (previously only replaced elements), size trasferred
fantasai: suggestion would be to make transferred size weaker than percentage size
iank_: there's a difference between spec and implementations atm with this stuff
iank_: spec says to resolve lengths against zero, whereas implementations will actually ignore that length
iank_: ignoring that difference, your suggestion and mine are effectively equivalent
fantasai: no, yours was to do it to it for compressible elements
<emilio> fantasai: no, because you are saying to do it only for compressible elements and I'm suggesting to do it for all elements with a-r
<emilio> iank_: if I change my suggestion then it agrees right?
<emilio> fantasai: [missed]. It'd be more consitent if we only clamp the transferred size. If we do clamp AMS if you have an aspect-ratio then it changes behavior
<emilio> iank_: if a replaced element has an intrinsic size I don't think that we'll want to respect that in this case
<emilio> ... if you have width 100%
<emilio> ... that'd break the person's initial issue, the intrinsic size was actually quite large
<emilio> fantasai: in that case I wonder if that should depend on whether they're compressible. Clamp transferred size always, clamp content-based size if it's compressible
<emilio> iank_: why not do it for both then?
<emilio> fantasai: mainly because it means that aspect-ratio affects sizing in an axis where it'd otherwise not have any effect
<emilio> ... I don't have an objection but it's a bit weird
<emilio> ... if you apply an aspect-ratio to a div where we apply the content size, then it'd suddenly clamp to zero
<emilio> Rossen_: can we go back to the previous proposal, to make it apply to all elements?
<emilio> ... we can try to constrain later if we have strong reasons to
<emilio> fantasai: I think we may have problems if we try to apply to all elements
<emilio> Rossen_: this is something we should be able to figure out quite quickly
<emilio> iank_: I think we can do the change for compressible and a-r elements quite easily. I need to think about non-replaced elements with a-r inside an auto-sized thing, dunno how to implement that yet
<TabAtkins> ian, let's do a video chat about this soon
<emilio> Rossen_: so, let's start with compressible, would that work?
<iank_> sure
<emilio> fantasai: I think my preferred suggestion would be all elements, but if we can't we should do it for compressible elements, do it for transferred and content size, and for a-r elements just the transferred size
<emilio> Rossen_: not opposed, but it's weird to make special elements more and more special, specially if the behavior is useful for all elements
<emilio> ... so I'd prefer to pursue that if possible
<tantek> +1 agreed with Rossen_
<tantek> and with that methodology in general
<emilio> fantasai: I'm fine with all elements, but if not I prefer the suggestion above, I think it's the closest
<emilio> Rossen_: can we resolve on all elements and if you come back with strong reasons why it doesn't work we can consider the other suggestion
<emilio> iank_: when we say all elements we mean all elements with a-r?
<emilio> rossen: we meant all elements
<emilio> iank_: That's a very big change, I don't think that'd be ok
<emilio> fantasai: I'm also skeptical about that
<emilio> Rossen_: so should we resolve on compressible elements + aspect-ratio?
<emilio> fantasai: [explains her suggestion again]
<emilio> Rossen_: sounds reasonable, other comments / objections?
proposal: clamp automatic minimum size of compressible elements, and the transferred size suggestion of non-compressible aspect-ratio elements
<tantek> sounds reasonable to limit to those elements
Resolution: clamp automatic minimum size of compressible elements, and the transferred size suggestion of non-compressible aspect-ratio elements
fantasai: Thanks everyone. That was a complicated issue, and I understood it better by talking it through with all of you.
percentage resolution of row tracks and gutters with indefinite height
github: https://
[ discussion of whether we have time for this issue ]
Rossen_: [ reads mrego's comment ]
https://
Rossen_: would be nice to close the issue and move on, if we all already agree
Rossen_: Anyone object to closing the issue with no change?
Resolution: Close no change
visibility: visible and a11y
github: https://
TabAtkins: some a11y folks brought up that the visibility property is tricky
TabAtkins: in particular, visibility:hidden on visibility:visible ancestor
TabAtkins: problem is invisible items gets stripped from a11y tree
TabAtkins: very similar to 'display:contents' a11y bug
TabAtkins: our proposal is to specify impact of 'visibility:hidden' as similar to 'display:contents'
TabAtkins: wrt a11y
TabAtkins: to do that, pull visibility property definition from CSS2 to css-display-3
TabAtkins: and add a warning to authors that in special cases (like tables) can cause problems to have invisible ancestor of visible child
TabAtkins: this proposal got a thumbs up from the original commenter
florian: ...
florian: unlike table cell example, what if these hidden boxes have text content?
florian: do we retain the box but not the text, or what
TabAtkins: text isn't an issue here, because invisible to everyone
TabAtkins: it's the implicit structural relationships that shouldn't get lost
florian: so text shouldn't be in accessibility tree either, just the box structure
TabAtkins: yes
Rossen_: referring to text inside cell made visible?
TabAtkins: no, invisible text
Rossen_: so text inside of other cells
florian: that, or if div with text in it that's hidden, and span that's visible
florian: do we hide all the text outside the span
Rossen_: yes, this is expected behavior and implemented
florian: is it implementable
fantasai: shouldn't be any problem, text has its own boxes in implementations
Rossen_: ...
Rossen_: text for role/description can be taken from hidden areas, but that's a known pattern that works
Rossen_: current implementations already support display of visible text inside of hidden elements
Rossen_: the issue is only when there's structure part of the invisible elements, then want to be able to recreate that
Rossen_: Tab, one question I have is
Rossen_: the use case here is very specific to when a table has visibility:hidden and cell is visibility:visible
Rossen_: is the same behavior here, are we trying to specify same for table which is inside of visibility:hidden?
TabAtkins: I don't believe the issue is specific to that
TabAtkins: applies the same if you visibility:hidden a link, and visibility:vissible some contents of the link
TabAtkins: We don't want that to strip the linkness of the text inside which is still visible
Rossen_: ok, didn't want to make it too specific
fantasai: no, going to make it quite general
proposal is https://
Rossen_: so expected behavior is to provide the structural role of the invisible ancestors of visible elements in the a11y tree
TabAtkins: yes, same as display:contents
Rossen_: anything else?
fantasai: we're pulling visibility propdef from CSS2 to css-display-3 (not defined anywhere else than CSS2 atm)
Rossen_: hearing no objections here
Resolution: accept proposal
Meeting closed.