- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 17 Aug 2022 19:53:00 -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 Contain
-----------
- RESOLVED: Publish new WD of css-contain-3
CSS Flexbox & Grid
------------------
- RESOLVED: The WG not accept ‘visual-order' as a switch, but
continue working on other methods of order that will aid
various technologies (Issue #7387: Providing authors with
a method of opting into following the visual order,
rather than logical order)
CSS Sizing
----------
- RESOLVED: When laying out an element, if contain-intrinsic-size is
not auto, remove last-remembered-size immediately (Issue
#6220: Clarify spec about when elements are allowed to
not have a last remembered size)
- RESOLVED: Last remembered size is the logical size, not the
physical size (Issue #7564: Is last remembered size
logical or physical?)
- RESOLVED: No change to specified behavior (Issue #7206: Are
intrinsic sizing keywords definite with size containment?)
Resize-Observer
---------------
- RESOLVED: When first observing an element with ResizeObserver,
lastReportedSize gets initialized with a -1 x -1 size
(Issue #3664: The initial size of ResizeObservation)
CSS Viewport & Device Adapt
---------------------------
- RESOLVED: Rename css-device-adapt css-viewport; Emilio will become
editor and figure out the details of renaming/updating
(Issue #7590: Really create a css-viewport spec)
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2022Aug/0001.html
Present:
Adam Argyle
Rossen Atanassov
Tab Atkins
David Baron
Oriol Brufau
Emilio Cobos Álvarez
Elika Etemad
Robert Flack
Simon Fraser
Mason Freed
Megan Gardner
Chris Harrelson
Daniel Holbert
Brian Kardell
Brad Kemper
Jonathan Kew
Vladimir Levin
Daniel Libby
Peter Linss
Alison Maher
Eric Meyer
François Remy
Jen Simmons
Miriam Suzanne
Regrets:
Chris Lilley
Bramus Van Damme
Lea Verou
Scribe: emeyer
Rossen: Any new agenda items?
(silence)
Rossen: Reminding everyone about TPAC FTF and a joint call with the
APA, I believe Tuesday
astearns: Meeting with APA on Thursday at 10:30am and i18n Group on
Friday, time TBD
<Rossen> https://wiki.csswg.org/planning/tpac-2022
Rossen: Please add yourself as in-person or remote on the planning
link, particularly your time zone and preferences for agenda
topics
CSS Contain
===========
Publish a new WD
----------------
miriam: This is republishing of the working draft, it was last
published in December 2021 and there have been significant
number of changes since then
miriam: Several changes to syntax, including shorthand rearrangement;
changing how default container works; changes around how we
find a container; automatically narrowing by type; deferred
state queries to another level; clarified workings around
Shadow DOM
miriam: Some syntax, we'd accidentally required parentheses, which is
no longer the case
Rossen: I think we definitely have to republish. Any additional
opinions or objections?
<fantasai> +1 to republishing
<fantasai> Publish Early And Often
<astearns> Thanks for the detailed change log in
https://drafts.csswg.org/css-contain-3/#changes-2021-12
RESOLVED: Publish new WD of css-contain-3
CSS Flexbox & Grid
==================
Providing authors with a method of opting into following the visual
order, rather than logical order
-------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7387
TabAtkins: In Rachel's post, she points out with Grid and flexbox,
visual order can be divergent from source order
TabAtkins: That's literally the feature. But it's easy for the two
orders to diverge, such as styling a grid differently
based on media queries.
TabAtkins: Suggestion is to have a way for authors to indicate to the
browser that it should present elements to the
accessibility tree in source or visual order
TabAtkins: Example, in masonry layout, the visual order is guaranteed
to get shuffled
TabAtkins: We'll need to address how this impacts focus navigation;
lot of details to get worked out
TabAtkins: Core idea is: can we give CSS authors to have a way to opt
into different accessibility ordering?
<fantasai> https://github.com/w3c/csswg-drafts/issues/7387#issuecomment-1160991881
fantasai: I have a lot of concerns, as did posters in the thread
fantasai: One is that having focus order differ from screen reader
order is a real problem
fantasai: There are a bunch of other considerations like: some
examples should have source order changed, not be addressed
via this sort of mechanism
<fantasai> https://github.com/w3c/csswg-drafts/issues/7387#issuecomment-1217193918
fantasai: I think we should consider that focus and screen reader
order should always match
fantasai: There are clear use cases for disconnecting layout order
and screen reader order, because visual-perception order is
not the same as layout order
fantasai: There are examples in the thread where you don't want to
follow the box order
fantasai: There are a lot of cases where people are using ‘order' as
a convenience and we don't want to encourage that
fantasai: It's important to note that each hierarchical level of a
page can have different needs for ordering. We should have
something that can do fine-tuned adjustments on specific
cases, not be a document blanket
fantasai: We should put pressure on the DOM side to provide an API
for letting people rearrange DOM order, something simple
<fantasai> https://github.com/w3c/csswg-drafts/issues/7387#issuecomment-1217193918
fantasai: We should also add some ability to change reading order
in CSS
fantasai: We'll want the ability to force source order, there should
also be the ability for the author to specify exact reading
order
<fantasai> reading-order: source | auto | <integer>
<fantasai> order: <'box-order'> [ <'reading-order'> |
reading-matches-box-order ]?
<fantasai> box-order: <integer> /* current order property */
<fantasai> reading-order: source | auto | <integer>
fantasai: This is my proposal. Open to others, but I think
`focus-order: visual` as proposed earlier would be harmful
<fantasai> We have box-sizing, and box-decoration-break, border-box/
content-box, etc. So we've already established the idea of
CSS boxes
Rossen: Huge plus-one on all that
Rossen: Very long-standing issue. I strongly believe calling this
‘visual-order' will create misperceptions
Rossen: As we are thinking through this, there's an intersection of
how to handle focus, how to handle search, screen reader
order; if these are in mismatch, they cause confusion
emilio: The proposals seem fine but I think there's a lot more
complexity than it seems
emilio: focus order is already not following the accessibility tree
order
emilio: At the very least, we should figure out what tree we want to
sort on; we might want focus order to be flat-tree order
miriam: My main concern as an author is where it happens
automatically, like in ‘grid-flow: dense'
miriam: Will ‘auto' solve those sorts of things?
fantasai: Yes. I'm open to which value should be the default.
Rossen: Sounds like there's a set of good proposals that Elika
summarized, but don't feel like we're ready to resolve on any
of them
Rossen: Do you want to discount any of these now, Elika?
fantasai: I'm against having a switch that just says “use the visual
order” because I think it would be misunderstood and
mis-used and allow people to stop thinking about source
versus reading order to the detriment of getting it right
Rossen: So we can resolve on this and continue to work on the details
of how this will work
RESOLVED: The WG not accept ‘visual-order' as a switch, but continue
working on other methods of order that will aid various
technologies
CSS Sizing
==========
Clarify spec about when elements are allowed to not have a last
remembered size
---------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6220
oriol: Followup on FTF discussion
oriol: If an element is not generating a box, if the intrinsic size
isn't auto, the last remembered size will be forgotten
oriol: You can take a look at my comment in the issue
<TabAtkins> "second comment from the end" this one:
https://github.com/w3c/csswg-drafts/issues/6220#issuecomment-1212633016
oriol: When we are laying out an element, it's a good time to observe
or not observe an element, but I have to observe an element to
see if I should forget last remembered size and then
un-observe it
oriol: Makes more sense to say with contain-intrinsic-size stops
being auto, we should immediately remove last remembered size
oriol: Some were arguing against that, argument is that it's not well
defined what should happen
oriol: I don't see a big problem and would prefer to switch to a more
consistent behavior
<emilio> +1 to oriol, the undefinedness of flushing layout/style info
is https://github.com/w3c/csswg-drafts/issues/5115 and very
long-standing
TabAtkins: No opinions, I need to talk about this more with Ian to
see what's what
emilio: We have a long-standing bug about this, I think the
contain-intrinsic-size is probably not the place to draw the
line
emilio: I think I agree with oriol, we should do this whenever we
style the document and can re-evaluate whether elements need
last remembered size
Rossen: What's the one-line resolution?
oriol: When laying out an element, if contain-intrinsic-size is not
auto, remove last remembered size immediately
TabAtkins: No objections now, but want to preserve right to object
later
Vladimir: Does this interact badly with container queries?
oriol: Not sure, to be honest. Will have to think about that.
emilio: The remembered size doesn't affect styling, but does affect
layout. I think you need size containment to cause this
emilio: I don't think it's a problem but worth thinking about a bit
more
Rossen: Doesn't sound like a strong pushback, and we can bring this
back if we have issues down the line
RESOLVED: When laying out an element, if contain-intrinsic-size is
not auto, remove last-remembered-size immediately
Is last remembered size logical or physical?
--------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7564
oriol: Spec says when contain-intrinsic-size is auto, then we record
current size, but doesn't say how this is done and we stored
height and width or block and inline size?
oriol: I propose to store a logical size; Blink is already doing
this, and I'm doing the same in Firefox
oriol: Approach seems better because observers are triggered on
logical size change, not physical size
TabAtkins: This seems wild to me, I definitely imagine physical size
when I wrote this, but given resizeobserver depends on
logical size, let's do it
RESOLVED: Last remembered size is the logical size, not the physical
size
Are intrinsic sizing keywords definite with size containment?
-------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7206
oriol: Normally, when we have an element with height: auto, if
there's a descendant that's a percentage, it gets set to auto
oriol: In a case where a container has size containment and doesn't
depend on descendants, what should happen?
oriol: Implementations treat this as cyclic
oriol: auto height container should resolve to zero, and percentages
of content should be zero
oriol: if container is height: 100px, descendants at 50% are 50px
TabAtkins: We don't currently treat a no-contents element being
non-cyclic, so I don't see how contain: size would change
that
TabAtkins: I support what implementations are doing
oriol: If there are no content, can you tell whether the height is
considered to be definite or not?
TabAtkins: Nothing we've written makes the assumption that that's the
case
TabAtkins: You have to perform layout to know the size, even if
nothing is actually laid out
emilio: I think I agree with Tab; it's easy to back-compute the size
on a block container, but in other places it might not be
emilio: Complex cases tend not to be very interoperable
emilio: It's not obvious to me you can define the sizes of element
without performing layout on the elements
emilio: I'd rather not make this more complicated
Rossen: Agreed.
Rossen: proposed path forward is to resolve as no change; objections?
oriol: I would like the specifications clarified, even if it's just a
note or example
oriol: I don't think the behavior we want to resolve on is clear form
the current specification
oriol: Adding something that clarifies that this case is still cyclic
would be preferred
<emilio> +1 to clarify, do we define this block-axis back-computation
of percentages properly somewhere?
Rossen: Please add a comment on the issue with proposed addition text
RESOLVED: no change to specified behavior
Resize-Observer
===============
The initial size of ResizeObservation
-------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3664
emilio: FTF resolved that zero was not a special size for contain
intrinsic size
emilio: The resolution seems to include resizeObserver, but in chats
with Oriol it evolved that wasn't clear
emilio: Worth clarifying
TabAtkins: The resolution was not intended to apply to resizeObserver
but I'm fine with it applying
TabAtkins: Consistency with things like contain-intrinsic-size has me
leaning to fire immediately and have an undefined size in
resizeObserver
Rossen: Any objections to the proposed resolution?
<emilio> When observing an element with ResizeObserver,
lastReportedSize gets initialized with a -1x-1 size
RESOLVED: When first observing an element with ResizeObserver,
lastReportedSize gets initialized with a -1 x -1 size
CSS Viewport & Device Adapt
===========================
Really create a css-viewport spec
---------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7590
emilio: We resolved on this when removing @viewport, but it never
happened
emilio: Now that we're trying to define interactions between various
orders, I was talking with Bramus and we don't have a great
place to put this sort of thing
emilio: A viewport spec seems like a natural place to do it
fantasai: I was thinking that reusing css-device-adapt makes a lot of
sense to me
emilio: Should we just rename css-device-adapt to css-viewport?
fantasai: I would just run with what we have, but we can rename it,
that's fine.
emilio: I think css-viewport is a more findable name
<smfr> +1
* fantasai defers to the editors on the naming :)
Rossen: proposal is to name viewport spec css-viewport and let go of
css-device-adapt
<bradk> +1 to css-viewport
fantasai: We could take everything we don't want out of
css-device-adapt, rename it, and continue with that
Rossen: I don't have a strong preference on how we start the new one,
whether we rename an old spec or start a new one
fantasai: or we could kill css-device-adapt and start a new spec
called css-viewport
smfr: Do we think this would ever become viewport-plus-other-stuff?
fantasai: Depends if we want the continuity, or having a dead-end spec
Rossen: I don't want to force a resolution but it sounded like we
were getting ready to resolve on css-viewport
smfr: I'm fine with viewport, just worried about the future
Rossen: We can keep this one viewport-specific
<smfr> if we put `touch-action` in a CSS spec it might to into
device-adapt
RESOLVED: rename css-device-adapt css-viewport; Emilio will become
editor and figure out the details of renaming/updating
Received on Wednesday, 17 August 2022 23:53:40 UTC