- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 11 Aug 2021 18:39:01 -0400
- To: www-style@w3.org
=========================================
These are the official CSSWG minutes.
Unless you're correcting the minutes,
Please respond by starting a new thread
with an appropriate subject line.
=========================================
CSS Content
-----------
- RESOLVED: Spec content:none as having no effect on elements (Issue
#6503: Implementing content:none on elements is not
web-compatible)
CSS Transforms
--------------
- RESOLVED: Add perspective(none) (Issue #6488: After #6320 there's
no way to get an identity transform for interpolation of
perspective)
Draft Server
------------
- The group is aware of the outages of the drafts server. There's a
proposed solution and work is being done to find time/funding to
implement it.
CSS Grid
--------
- RESOLVED: Clamp automatic minimum size of compressible elements,
and the transferred size suggestion of non-compressible
aspect-ratio elements (Issue #6278: Replaced elements
canvas, img, etc should behave as expected when styled
with relative sizes in grid, transferred size should not
affect them unless specifically asked to)
- RESOLVED: Close no change (Issue #5566: Resolution of percentage
row tracks and gutters with indefinite height)
CSS Display
-----------
- RESOLVED: Accept proposal (Issue #6123: For the Accessibility API
visibility:visible within visibility:hidden is
problematic)
- Proposal:
- Import 'visibility' from CSS2 to css-display-3 (since it is
currently only defined in CSS2).
- Define impact of visibility: hidden similar to display:
contents (shouldn't strip necessary a11y information from
the tree).
- Add a warning to authors that marking a required structural
parent box as invisible while descendants are visible
(e.g. table-row invisible while table-cell is visible)
can be problematic.
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2021Aug/0003.html
Present:
Adam Argyle
Rossen Atanassov
Tab Atkins-Bittner
Tantek Çelik
Emilio Cobos Álvarez
Elika Etemad
Simon Fraser
Megan Gardner
Daniel Holbert
Sanket Joshi
Brad Kemper
Jonathan Kew
Vladimir Levin
Daniel Libby
Rune Lillesveen
Ting-Yu Lin
Peter Linss
Jen Simmons
Alan Stearns
Regrets:
David Baron
Scribe: fantasai
Scribe's scribes: florian, Rossen
Rossen: Any other items?
plinss: Wanted to talk about draft server
CSS Content
===========
Implementing content:none on elements is not web-compatible
-----------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6503
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
fantasai: We should spec it
fantasai: If we need a new keyword, I'd suggest "empty"
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
emilio: also interesting question about interaction with
content-visibility:hidden
<TabAtkins> we can just leave the discussion out of this issue for
now, and open a fresh issue arguing for adding this new
keyword
<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
RESOLVED: spec content:none as having no effect on elements
CSS Transforms
==============
After #6320 there's no way to get an identity transform for
interpolation of perspective
-----------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6488
emilio: I wasn't on last week's call
<astearns> we ran out of time last week to get to a resolution
emilio: Seems fine to add a new value to represent this
emilio: ...
smfr: I'm ok with something like perspective(infinity)
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?
RESOLVED: Add perspective(none)
CSS Sizing
==========
Compressible elements with aspect ratio
---------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6341
Rossen: Is this ready for discussion?
<TabAtkins> ian added the agenda+ ^_^
Draft Server
============
plinss: As many noticed, drafts server has been unreliable lately
<TabAtkins> it is currently down, for example
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
plinss: So looking for anyone to sponsor the work, or to take on the
work for setting up alternatives
<TabAtkins> yup, will look into this
<florian> thanks plinss for running the infrastructure in the first
place
CSS Grid
========
Replaced elements canvas, img, etc should behave as expected when
styled with relative sizes in grid, transferred size should not
affect them unless specifically asked to
-------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6278
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.
<fantasai> https://github.com/w3c/csswg-drafts/issues/6278#issuecomment-863439988
fantasai: Tab and I looked over this
fantasai: Our conclusion is summarized in the issue
fantasai: The author's expectation is reasonable in this case
fantasai: Chrome and firefox used to match that, until chrome fixed
to match the spec
fantasai: [explains example]
fantasai: 1fr has an auto min implied and that's what's causing the
breakage.
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
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 potentially all
els
<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"
<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.
<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)
fantasai: Did everyone follow, or should I explain something again?
iank: I did :)
iank: I'd be concerned about doing this for all elements
iank: If we do, should only do for compressible elements
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
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 transferred
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
scribe: 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
aspect-ratio
iank: If I change my suggestion then it agrees right?
fantasai: [missed]. It'd be more consistent if we only clamp the
transferred size. If we do clamp AMS if you have an
aspect-ratio then it changes behavior
iank: If a replaced element has an intrinsic size I don't think that
we'll want to respect that in this case
iank: If you have width 100%
iank: That'd break the person's initial issue, the intrinsic size was
actually quite large
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
iank: Why not do it for both then?
fantasai: Mainly because it means that aspect-ratio affects sizing in
an axis where it'd otherwise not have any effect
fantasai: I don't have an objection but it's a bit weird
fantasai: if you apply an aspect-ratio to a div where we apply the
content size, then it'd suddenly clamp to zero
Rossen: Can we go back to the previous proposal, to make it apply to
all elements?
Rossen: We can try to constrain later if we have strong reasons to
fantasai: I think we may have problems if we try to apply to all
elements
Rossen: This is something we should be able to figure out quite
quickly
iank: I think we can do the change for compressible and aspect-ratio
elements quite easily. I need to think about non-replaced
elements with aspect-ratio inside an auto-sized thing, dunno
how to implement that yet
Rossen: So, let's start with compressible, would that work?
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 aspect-ratio
elements just the transferred size
Rossen: Not opposed, but it's weird to make special elements more and
more special, specially if the behavior is useful for all
elements
Rossen: so I'd prefer to pursue that if possible
<tantek> +1 agreed with Rossen
<tantek> and with that methodology in general
fantasai: I'm fine with all elements, but if not I prefer the
suggestion above, I think it's the closest
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
iank: When we say all elements we mean all elements with aspect-ratio?
Rossen: we meant all elements
iank: That's a very big change, I don't think that'd be ok
fantasai: I'm also skeptical about that
Rossen: So should we resolve on compressible elements + aspect-ratio?
fantasai: [explains her suggestion again]
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
RESOLVED: 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.
Resolution of percentage row tracks and gutters with indefinite height
----------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5566
[ discussion of whether we have time for this issue ]
Rossen: [ reads mrego's comment ]
<fantasai> https://github.com/w3c/csswg-drafts/issues/5566#issuecomment-886483173
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?
RESOLVED: Close no change
CSS Display
===========
For the Accessibility API visibility:visible within visibility:hidden
is problematic
---------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6123
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: with regards to 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:visible 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
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
<fantasai> proposal is
https://github.com/w3c/csswg-drafts/issues/6123#issuecomment-893890561
[
- Import 'visibility' from CSS2 to css-display-3 (since it is
currently only defined in CSS2).
- Define impact of visibility: hidden similar to display: contents
(shouldn't strip necessary a11y information from the tree).
- Add a warning to authors that marking a required structural
parent box as invisible while descendants are visible (e.g.
table-row invisible while table-cell is visible) can be
problematic.
]
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
RESOLVED: Accept proposal
Received on Wednesday, 11 August 2021 22:40:41 UTC