- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 28 Sep 2022 19:40:06 -0400
- To: www-style@w3.org
- Cc: public-aria@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 Flexbox & Grid
------------------
- RESOLVED: Draft reading-order (minus source value) into
css-display-4 ED (Issue #7387: Providing authors with a
method of opting into following the visual order, rather
than logical order)
CSS Flexbox
-----------
- RESOLVED: Flex baselines take flex ordering into account so first/
last use roughly *physical* directions (Issue #7776: Flex
container baselines with reverse direction)
- Issue #7774 (Flex container baselines with "flex-wrap:
wrap-reverse" present) requires clarifying edits that you should
be using writing-mode order.
CSS Sizing
----------
- RESOLVED: Last remembered size uses the "stitch together in block
axis" bounding box (Issue #7598: Last remembered size
when fragmented?)
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2022Sep/0016.html
Present:
Rachel Andrew
Jake Archibald
Rossen Atanassov
Tab Atkins
David Baron
Oriol Brufau
James Craig
Yehonatan Daniv
Elika Etemad
Robert Flack
Bryan Garaventa
Chris Harrelson
Brad Kemper
Jonathan Kew
Ian Kilpatrick
Peter Linss
James Nurthen
Florian Rivoal
Khushal Sagar
Alan Stearns
Miriam Suzanne
Regrets:
Daniel Holbert
Chair: Rossen
Scribe: jcraig
<RRSAgent> logging to https://www.w3.org/2022/09/28-css-irc
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
<chrishtr> Welcome ARIA!
rachelandrew: Several requests over the years
rachelandrew: css says stick with document order... works in most
cases
rachelandrew: but with grid in particular, can be a disconnected from
the sighted focus or AT, screen reader...
rachelandrew: My initial proposal, can the author opt in to "visual"
order instead of Dom/source
rachelandrew: fantasai proposed a more refined order
<fantasai> my proposal Rachel mentions is here:
https://github.com/w3c/csswg-drafts/issues/7387#issuecomment-1217193918
<fantasai> rachel's use case analysis is here:
https://github.com/w3c/csswg-drafts/issues/7387#issuecomment-1248754496
rachelandrew: so we need a way to define reading order if not logical
in the DOM
scribe: fantasai
scribe's scribe: jcraig
chrishtr: Specific proposal from fantasai on August 16th (see above)
chrishtr: candidate for resolution
chrishtr: affects focus order and reading order simultaneously
jamesn: Just want to confirm it's for grid/flex, not abspos etc?
rachelandrew: Yes, you can get disconnected order in abspos
rachelandrew: but I don't see people building entire layouts using
abspos
rachelandrew: things like grid-auto-flow: dense are cases where the
won't know where things are
rachelandrew: so scoping down
<TabAtkins> They are reordering, *and* we have a reliable way of
knowing the order they're producing (as opposed to abspos/
floats).
jamesn: Support scoping down, just wanted to confirm
iank: Question, in flexbox there's various mechanisms to switch the
order
iank: e.g. flex-wrap: reverse
iank: would this affect that as well?
rachelandrew: I think so, should behave similar way as when you have
one of the grid values that allows reordering
iank: if logically it looks like you're following the different order
iank: but worth coming up with use cases to check
<TabAtkins> Yes, I think they'd also reorder per the reading order of
the writing mode on the element, I'd think.
* fantasai disagrees actually
Rossen: fantasai, can you give an overview of the proposal?
Rossen: particularly effects on flex/grid and also on abspos
Rossen: if mostly reviewing, don't need thorough minuting
<fantasai> https://github.com/w3c/csswg-drafts/issues/7387#issuecomment-1217193918
fantasai: Reviewing this proposal to add a reading order property
with values: source (DOM), auto, default, would follow
rendering order but not in cases that authors could not
predict. final value: an integer that affects keyboard order
fantasai: Could also use it differently than the order property....
or use reading order in layout mode... so abspos elements
reading order could be modified by the order value.
fantasai: IMO author predictable layout methods should not be covered
by auto... maybe a different keyword, but not by default
fantasai: e.g. if you're reversing the order, that doesn't mean there
is no order,. should follow the layout.
Rossen: How does this impact reading order vs focus management
fantasai: Randomizing layout models indicate that the underlying
order of the items doesn't matter, so in this case we want
the UA to make the reading order match the visual order.
fantasai: but if it's not randomizing, the source potentially has
meaningful order and we should preserve that unless
specifically overridden by the author
fantasai: reading order vs focus management... different ways to
manipulate the default.... linear forwards or backwards
fantasai: linear order is an artifact of the @@@ order
fantasai: there should not be a disconnect between the order we
choose for the reading order and the focus order
Rossen: suppose I have items with tabindex, I swap the visual order,
what happens
fantasai: interaction with tabindex needs defining... explicit
tabindex should be respected
<chrishtr> +1 to tabindex taking precedence
iank: Property does 2 things, work at different levels
iank: e.g. reading-order, works at the container level
iank: I think it's a mistake to also bundle the 'integer' variant on
top of that
iank: it seems to me that it operates on the item instead
iank: so if we want the integer variant, that should likely be a
separate property
fantasai: Think of the value similar to z-index: auto versus integer
iank: Would then need to set on every item?
fantasai: I see that's an unsolved issue... integer versus auto can't
be resolved at the element level
fantasai: Could drop the source value unless someone really wants it
fantasai: Could be useful as separate properties in case you want to
define them independently
iank: Are valid use cases for source order
iank: core use cases for column-reverse is chat bubbles that
propagate upwards
iank: but you're saying that doesn't affect it ...
iank: I think I'll need to see all the interactions written down
iank: before I can evaluate it as a whole
iank: lots of subtle interactions here
jcraig: I agree lots of subtleties in the layout examples
jcraig: Some of the other subtleties mentioned last night are what's
supposed to happen to either a keyboard user's focus or an AT
user's focus, such as screenreader
jcraig: not detectable
jcraig: What happens when the order changes on the fly?
jcraig: Use cases were based on dynamic interaction of values of
these orders might change
jcraig: What happens to the users keyboard focus or AT focus, when
metaphorical rug gets pulled out?
jcraig: If JS interaction, author should maybe call .focus() after UI
modification
jcraig: but in this case, not a CSS method for doing this
jcraig: do we expect this to be primary rendering layout in CSS and
then need to follow up with focus method afterwards?
jcraig: or other interactions?
jcraig: can change
fantasai: Focus should stay on the same element. But its relative
order to other elements around it
fantasai: Only have a problem if you remove the element you're on
jcraig: Afraid there's some unpredictable cases, e.g. you tab through
and get stuck in a loop
jcraig: so interactions where we might not be able to rely on it
jcraig: could maybe get a good default
jcraig: when that happens, maybe call focus()
jcraig: I'm just worried about a layout method that changes
reading/kb/AT order not tied to a JS call (e.g. focus()) that
would not to be used to correct it
rachelandrew: In terms of having all of the likely combinations that
might want to assess, would it be helpful for me to do?
rachelandrew: Discussed with Chrome DevRel
rachelandrew: would it be helpful to come up with the different
combinations of things are that people could see this
being used for?
jcraig: that would be great
chrishtr: I suggest possible resolution, in general this is a good
idea, need to work out the details, so go work it up in a
draft spec
jcraig: happy to work on the list with rachelandrew
jcraig: and try to throw in as many AT challenges as I can
fantasai: Suggest drafting into css-display-4
fantasai: (which doesn't yet exist)
<chrishtr> display-4 SGTM
fantasai: then we can work on details, evaluate, and decide if we
like it
Rossen: Opinions from others?
BGaraventa: I do agree with what you've been talking about, just read
through the bug, and there are some things I'm not
familiar enough that I can't provide info on, but like
idea of moving this
BGaraventa: One scenario is that basically curious how it works with
ARIA widgets, e.g. listbox that has options
BGaraventa: style various list items, once you add aria roles to it
[missed]
BGaraventa: I'd be happy to be part of future discussion if that's
helpful
Rossen: Thanks, helpful
Rossen: Anything else on this topic?
Rossen: We have concrete direction
Rossen: Talked about this in 2015, glad to see we've got a direction
here
RESOLVED: Draft reading-order (minus source value) into
css-display-4 ED
<rachelandrew> thanks all, I'll start a list and ping people to
contribute
Rossen: Ok, back to our regularly scheduled CSS topics. ARIA folks
are welcome to stay or leave
CSS Nesting
===========
FPWD of css-nesting-1
---------------------
chrishtr: Apparently already in FPWD
CSS Flexbox
===========
Scribe: TabAtkins
Flex container baselines with reverse direction
-----------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7776
iank: At TPAC we did a bunch of baseline stuff
iank: Today, if we have flex-direction:*-reverse, we will take the
first baseline from the first in DOM order, the "logical" first
iank: this is interoperable across all browsers
iank: The spec doesn't say this, I believe it says to take
flex-direction into account, which means browsers are all wrong
today
iank: We're willing to make this change, I don't have strong opinions
fantasai: I think the spec change makes sense, if you ask for
last-baseline you want the baseline at the bottom, not the
top
fantasai: So I think that makes the most sense
iank: It'll likely be compatible
iank: One possible case is people doing column-reverse and having
overflow propagate things upwards, so the "first" thing will be
way up in the overflow area and get clamped to the block-start
edge
fantasai: They're probably not asking for baseline alignment in these
cases, so probably fine?
iank: Yup, just a subtle side effect, I'm fine with it
<TabAtkins> I'm fine with this.
RESOLVED: flex baselines take flex ordering into account so first/
last use roughly *physical* directions
Flex container baselines with "flex-wrap: wrap-reverse" present
---------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7774
iank: Similar to the last, but I don't think this is in the spec
currently
iank: You can have flex: row wrap-reverse, so the lines are inverted
iank: Currently impls will take the last baseline from the visually
last line
fantasai: I think this is basically the same as the previous, and the
spec says "startmost" or "endmost", so that's already in
spec
TabAtkins: startmost and endmost have strict meanings
<fantasai> https://github.com/w3c/csswg-drafts/issues/995
fantasai: Actually I think it's somewhat unclear, "start" is a little
ambiguous with "flex-start" in Flexbox
fantasai: So we should do some clarifying edits
fantasai: But yeah, if we're accounting for flex-direction we should
absolutely do flex-wrap as well
fantasai: they're together
fantasai: So we should make sure the spec is clear about this
fantasai: Might have forgotten to clarify that it was a flex vs
writing mode
fantasai: I think it's clear that you do both of them with the same
set of directions, the spec just isn't entirely clear that
you should be using writing-mode order rather than flex
order
<fantasai> "RESOLVED: take the visually first line when considering
baseline alignment in flexboxes"
<fantasai> from the issue
<TabAtkins> (I disagree and think it's correct as is, but am fine
with making it more explicit)
CSS Sizing
==========
Last remembered size when fragmented?
-------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7598
oriol: Continuing discussion
oriol: What size to record as last remembered size when there's
multiple fragments?
oriol: In discussion, preferred behavior was taking all frags into
account, but we weren't sure if that was possible
oriol: The ResizeObserver API supposedly only returned the first
fragment size
oriol: but in Blink, while a single size is exposed, it's not the
first fragment size as the spec says; instead it's the sum of
the block sizes of the fragments
oriol: So perhaps by accident, the last remembered size is behaving
as we desired in blink already
oriol: So I implemented a way in RO to track size per fragments, not
enabled yet but used by last remembered size
oriol: So impls have this behavior we thought was better in
discussion, so I think we can resolve on this
oriol: Precisely, the last remembered block size will be the sum of
the fragment block sizes, while last remembered inline size is
the max of the fragment inline sizes
(As if pasting all the fragments together block-wise, then
taking bounding box)
<iank> that sounds good to me - its a long standing issue that we
aren't taking the max.
Rossen: I'm assuming that, without knowing current impl, what we used
to have in Edge especially for variable-size frags was we
used bounding box of all fragments as the size
Rossen: What I'm hearing is matching that
TabAtkins: No, that's not right
TabAtkins: The summary that I put in is right, it's as if you too all
the fragments, pasted them together, and then took the
bounding box
TabAtkins: not take the bounding box as they exist on the page
Rossen: That's what I meant to say
oriol: [missed, something about columns]
iank: This sounds good to me
iank: Note that we need to ignore repeated things like table headers
fantasai: Do we?
Rossen: And box-decoration?
iank: Repeated table headers, for example, if you take the stitched
size...
iank: the table header won't vary between the fragmentainers
iank: So if you have a repeated frag you just want to take the first
iank: It's an edge case tho
Rossen: What about border-decoration:repeat?
Rossen: Are you ignoring the borders along the slices?
<bradk> box-decoration: clone
oriol: Re: decos, we're remembering content size, so it's not
including the borders
oriol: Re: tables, the last remembered size is only used when the
element has size containment, and I think tables can't have
size containment so it doesn't matter in practice
Rossen: Stepping back, proposal sounds good. Think there will be some
details as we implement.
Rossen: But I think the path forward sounds good
Rossen: Thoughts or objections?
RESOLVED: Last remembered size uses the "stitch together in block
axis" bounding box
fantasai: We've had interesting conversations about ResizeObserver
fantasai: Many inconsistencies between planned and implemented
fantasai: Who's working on this?
TabAtkins: ResizeObserver has new editors
oriol: I can try to drive something to make the spec handle different
fragments, like what I implemented in Firefox
oriol: But there are unclear details
fantasai: We also have a previous discussion, maybe from A Coruna,
about this?
oriol: I think we have a resolution that API should extend to expose
fragments, it's just not clear how to do so in some cases
fantasai: Think we discussed an array of fragments, we just didn't do
that in first version because it shipped before review
oriol: Yes, impl currently returns an array that has 1 item, in FF
it's the first...
Rossen: Wait is this part of the topic?
fantasai: My point is just that we're basing decisions on
ResizeObserver but ResizeObserver is shaky, and we haven't
followed up on resolutions we made for ResizeObserver.
oriol: emilio
oriol: is the new editor
oriol: I added some RO issues to the agenda, hopefully we can handle
those
oriol: I can try to change the spec to handle fragments
<fantasai> Having the first item in the array be the sum of all
fragments makes *no sense*
<fantasai> Either it's not an array and it's the sum of all
fragments, or its an array of multiple items each
representing a fragment
Rossen: Ok, please do that and raise issues if there are any new
questions
Received on Wednesday, 28 September 2022 23:40:46 UTC