Meeting minutes
<chrishtr> Welcome ARIA!
opt-in focus and at-order https://github.com/w3c/csswg-drafts/issues/7387
[css-flexbox][css-grid] Providing authors with a method of opting into following the visual order, rather than logical order
<Rossen_> github: https://
rachelandrew: several requests over the years
css says stick with document order... works in most cases
but with grid in particular, can be a disconnected from the sighted focus or AT, screen reader...
my initial proposal, can the author opt in to "visual" order instead of Dom/source
<fantasai> my proposal Rachel mentions is here: https://
fantasai proposed a more refined order listed below
<fantasai> rachel's use case analysis is here: https://
so we need a way to define reading order if not logical in the DOM
chrishtr: Specific proposal from fantasai on August 16th (see above)
… candidate for resolution
… affects focus order and reading order simultaneously
<chrishtr> https://
<chrishtr> (oops, sorry dup of what fantasai said above)
jamesn: Just want to confirm it's for grid/flex, not abspos etc?
rachelandrew: Yes, you can get disconnected order in abspos
… but I don't see people building entire layouts using abspos
<jcraig> s/???: /jamesn: /
rachelandrew: things like grid-auto-flow: dense are cases where the won't know where things are
… 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
… e.g. flex-wrap: reverse
… 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
… if logically it looks like you're following the different order
<TabAtkins> Yes, I think they'd also reorder per the reading order of the writing mode on the element, I'd think.
rachelandrew: but worth coming up with use cases to check
Rossen_: fantasai, can you give an overview of the proposal?
… particularly effects on flex/grid and also on abspos
… if mostly reviewing, don't need thorough minuting
https://
<jcraig> 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
<jcraig> 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.
<jcraig> IMO author predictable layout methods should not be covered by auto... maybe a different keyword, but not by default
<jcraig> e.g. if you're reversing the order, that doesn't mean there is no order,. should follow the layout.
<jcraig> 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.
… but if it's not randomizing, the source potentially has meaningful order and we should preserve that unless specifically overridden by the author
<jcraig> fantasai: reading order vs focus management... different ways to manipulate the default.... linear forwards or backwards
<jcraig> linear order is an artifact of the @@@ order
<jcraig> 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
<chrishtr> +1 to tabindex taking precedence
<jcraig> fantasai: interaction with tabindex needs defining... explicit tabindex should be respected
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
<jcraig> fantasai: think of the value similar to z-index: auto versus integer
<jcraig> iank_: would then need to set on every item?
<jcraig> fantasai: I see, that's an unsolved issue... integer versus auto can't be resolved at the element level
<jcraig> fantasai: could drop the source value unless someone really wants it
<jcraig> could be useful as separate properties in case you want to define them independently
iank_: are valid use cases for source order
… core use cases for column-reverse is chat bubbles that propagate upwards
… but you're saying that doesn't affect it ...
iank_: I think I'll need to see all the interactions written down
… before I can evaluate it as a whole
… lots of subtle interactions here
jcraig: I agree lots of subtleties in the layout examples
… 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
… not detectable
… what happens when the order changes on the fly?
… use cases were based on dynamic interaction of values of these orders might change
… what happens to the users keyboard focus or AT focus, when metaphorica rug gets pulled out?
… If JS interaction, author should maybe call .focus() after UI modification
… but in this case, not a CSS method for doing this
… do we expect this to be primary rendering layout in CSS and then need to follow up with focus method afterwards?
… or other interactions?
<jcraig> fantasai: focus should stay on the same element. but its relative order to other elements around it
jcraig: can change
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
… so interactions where we might not be able to rely on it
… could maybe get a good default
… when that happens, maybe call focus()
… 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?
… discussed with Chrome DevRel
… would it be helpful to come up with the different combnations of things are that people could see this being used for?
jcraig: that would be great
<rachelandrew> they are all with me here in NY so I'll go and talk to folks :)
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
me q+
<Zakim> jcraig, you wanted to volunteer to work on that use case list with rachelandrew
jcraig: happy to work on the list with rachelandrew
… and try to throw in as many AT challenges as I can
<chrishtr> display-4 SGTM
fantasai: Suggest drafting into css-display-4
fantasai: (which doesn't yet exist)
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
bryang: One scenario is that basically curious how it works with ARIA widgets, e.g. listbox that has options
bryang: 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
RESOLUTION: 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. Welcome to stay or leave
FPWD of css-nesting-1
chrishtr: Apparently already in FPWD
Container baselines with reverse directions
<Rossen_> github: https://
<orieo1> 💨Don’t miss this chance to be Rich... (full message at <https://
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 propogate 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
I'm fine with this.
RESOLUTION: flex baselines take flex ordering into account so first/last use roughly *physical* directions
flex-container baselines with wrap-reverse
iank_: Similar to the alst, 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 alreayd in spec
<fantasai> TabAtkins: startmost and endmost have strict meanings
<orieo1> 💨Don’t miss this chance to be Rich... (full message at <https://
<fantasai> https://
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
(I disagree and think it's correct as is, but am fine with making it more explicit)
Last remembered size when fragmented
oriol: continuing discussion
oriol: what size to record as last remembered size when ther'e smultiple 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 frist 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 boudning 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 boudning box of all fragments as the size
Rossen_: What I'm hearing is matching that
<fantasai> TabAtkins: No, that's not right
<fantasai> 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
<fantasai> TabAtkins: not take the bounding box as they exist on the page
<fantasai> Rossen_: That's what I meant to say
oriol: [missed, something about columsn]
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 lsounds good. Think there will be some details as we implement.
Rossen_: But I think the path forward sounds good
Rossen_: thoughts or objections?
RESOLUTION: Last remembered size uses the "stitch together in block axis" bounding box
fantasai: We've had interesting convos about RO
fantasai: Many inconsistencies between planned and implemented
fantasai: Who's working on this?
TabAtkins: RO has new editors
oriol: I can try to drive something to make the spec handle different fragments, like what I impld 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 shoudl 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 RO but RO is shaky, and we haven't followed up on resolutions we made for RO.
oriol: emilio
oriol: is the new editor
<fantasai> Having the first item in the array be the sum of all fragments makes *no sense*
<bradk> I gotta go. Bye.
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> 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
github-bot: end topic