15:53:12 <RRSAgent> RRSAgent has joined #css
15:53:12 <RRSAgent> logging to https://www.w3.org/2022/09/28-css-irc
15:53:14 <Zakim> inviting RRSAgent
15:53:14 <Zakim> RRSAgent, make logs Public
15:53:15 <Zakim> Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
15:53:31 <oriol> oriol has joined #css
15:55:28 <vmpstr> vmpstr has joined #css
15:55:34 <gtalbot> gtalbot has joined #css
15:56:37 <gtalbot> gtalbot has left #css
15:57:30 <flackr> flackr has joined #css
16:00:11 <khush> khush has joined #css
16:00:17 <khush> present+
16:00:43 <flackr> present+
16:01:08 <Rossen_> present+
16:01:13 <jfkthame> jfkthame has joined #css
16:01:18 <JakeA> present+
16:01:25 <jcraig> present+
16:01:49 <florian> present+
16:01:52 <jamesn> present+
16:02:48 <bradk> bradk has joined #css
16:02:52 <ydaniv> ydaniv has joined #css
16:03:00 <ydaniv> present+
16:03:54 <jfkthame> present+
16:04:42 <jondavis> jondavis has joined #css
16:04:51 <rachelandrew> present+
16:04:54 <jcraig> scribe: jcraig
16:04:58 <plinss> present+
16:05:09 <chrishtr> present+
16:05:15 <oriol> present+
16:05:15 <TabAtkins> present+
16:05:23 <chrishtr> Welcome ARIA!
16:05:30 <jcraig> topic: opt-in focus and at-order https://github.com/w3c/csswg-drafts/issues/7387
16:05:32 <Rossen_> Topic: [css-flexbox][css-grid] Providing authors with a method of opting into following the visual order, rather than logical order
16:05:35 <bradk> present+
16:05:37 <miriam> present+
16:05:44 <Rossen_> github: https://github.com/w3c/csswg-drafts/issues/7387
16:05:55 <BGaraventa> BGaraventa has joined #css
16:06:22 <jcraig> rachelandrew: several requests over the years
16:06:26 <TylerWilcock> TylerWilcock has joined #css
16:06:38 <jcraig> css says stick with document order... works in most cases
16:07:04 <jcraig> but with grid in particular, can be a disconnected from the sighted focus or AT, screen reader...
16:07:06 <dbaron> Present+
16:07:34 <jcraig> my initial proposal, can the author opt in to "visual" order instead of Dom/source
16:07:36 <jondavis_> jondavis_ has joined #css
16:08:06 <fantasai> my proposal Rachel mentions is here: https://github.com/w3c/csswg-drafts/issues/7387#issuecomment-1217193918
16:08:21 <jcraig> fantasai proposed a more refined order @@@elika help?@@@
16:08:37 <fantasai> rachel's use case analysis is here: https://github.com/w3c/csswg-drafts/issues/7387#issuecomment-1248754496
16:08:40 <Rossen_> q?
16:08:41 <jcraig> so we need a way to define reading order if not logical in the DOM
16:08:42 <fantasai> scribenick: fantasai
16:08:52 <jamesn> q+
16:08:52 <fantasai> chrishtr: Specific proposal from fantasai on August 16th (see above)
16:08:59 <fantasai> ... candidate for resolution
16:09:05 <fantasai> ... affects focus order and reading order simultaneously
16:09:07 <dlibby> dlibby has joined #css
16:09:23 <chrishtr> https://github.com/w3c/csswg-drafts/issues/7387#issuecomment-1217193918
16:09:40 <chrishtr> (oops, sorry dup of what fantasai said above)
16:09:44 <fantasai> ???: Just want to confirm it's for grid/flex, not abspos etc?
16:09:51 <astearns> s/???/jamesn/
16:09:54 <fantasai> rachelandrew: Yes, you can get disconnected order in abspos
16:09:59 <Rossen_> ack jamesn
16:10:05 <fantasai> ... but I don't see people building entire layouts using abspos
16:10:15 <jcraig> s/???: /jamesn: /
16:10:16 <fantasai> ... things like grid-auto-flow: dense are cases where the won't know where things are
16:10:20 <fantasai> ... so scoping down
16:10:24 <TabAtkins> They are reordering, *and* we have a reliable way of knowing the order they're producing (as opposed to abspos/floats).
16:10:26 <fantasai> jamesn: support scoping down, just wanted to confirm
16:10:34 <iank_> q?
16:10:51 <fantasai> iank_: Question, in flexbox there's various mechanisms to switch the order
16:11:01 <fantasai> ... e.g. flex-wrap: reverse
16:11:05 <fantasai> ... would this affect that as well?
16:11:21 <fantasai> rachelandrew: I think so, should behave similar way as when you have one of the grid values that allows reordering
16:11:29 <fantasai> ... if logically it looks like you're following the different order
16:11:36 <TabAtkins> Yes, I think they'd also reorder per the reading order of the writing mode on the element, I'd think.
16:11:36 <fantasai> ... but worth coming up with use cases to check
16:12:01 <fantasai> Rossen_: fantasai, can you give an overview of the proposal?
16:12:09 <fantasai> ... particularly effects on flex/grid and also on abspos
16:12:20 <fantasai> ... if mostly reviewing, don't need thorough minuting
16:12:33 <fantasai> https://github.com/w3c/csswg-drafts/issues/7387#issuecomment-1217193918
16:13:18 <Rossen_> q+
16:13:22 <Rossen_> ack fantasai
16:14:08 <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
16:14:18 <iank_> q+
16:15:06 <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.
16:15:49 <jcraig> IMO author unpredictable layout methods should not be covered by auto... maybe a different keyword, but not by default
16:15:57 <jamesn> q+
16:16:17 <jamesn> q-
16:16:38 <fantasai> s/unpredictable/predictable/
16:16:59 <jcraig> e.g. if you're reversing the order, that doesn't mean there is no order,. should follow the layout.
16:17:23 <jcraig> q+
16:17:26 <jamesn> q+ to clarify which would be the default (I had previously presumed source)?
16:18:24 <jcraig> ack me
16:19:10 <jcraig> Rossen_: how does this impact reading order vs focus management
16:19:15 <jcraig> ack Rossen_
16:19:24 <fantasai> 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.
16:19:47 <fantasai> ... but if it's not randomizing, the source potentially has meaningful order and we should preserve that unless specifically overridden by the author
16:19:55 <bradk> bradk has joined #css
16:20:14 <aaronlev_> aaronlev_ has joined #css
16:20:22 <jcraig> fantasai: reading order vs focus management... different ways to manipulate the default.... linear forwards or backwards
16:20:42 <jcraig> linear order is an artifact of the @@@ order
16:21:08 <jcraig> there should not be a disconnect between the order we choose for the reading order and the focus order
16:21:36 <fantasai> Rossen_: suppose I have items with tabindex, I swap the visual order, what happens
16:22:02 <chrishtr> +1 to tabindex taking precedence
16:22:10 <jcraig> fantasai: interaction with tabindex needs defining... explicit tabindex should be respected
16:22:14 <jamesn> q-
16:22:16 <Rossen_> ack iank_
16:22:27 <fantasai> iank_: Property does 2 things, work at different levels
16:22:34 <fantasai> iank_: e.g. reading-order, works at the container level
16:22:45 <fantasai> iank_: I think it's a mistake to also bundle the 'integer' variant on top of that
16:22:51 <fantasai> iank_: it seems to me that it operates on the item instead
16:22:59 <fantasai> iank_: so if we want the integer variant, that should likely be a separate property
16:23:06 <bradk> bradk has joined #css
16:23:21 <jcraig> fantasai: think of the value similar to z-index: auto versus integer
16:23:46 <jcraig> iank_: would then need to set on every item?
16:24:23 <jcraig> fantasai: I see that as an unsolved issue... integer versus auto can't be resolved at the element level
16:24:37 <fantasai> s/see that as/see, that's
16:25:08 <jcraig> fantasai: could drop the source value unless someone really wants it
16:25:12 <Rossen_> q?
16:25:32 <jcraig> could be useful as separate properties in case you want to define them independently
16:26:18 <fantasai> iank_: are valid use cases for source order
16:26:29 <fantasai> ... core use cases for column-reverse is chat bubbles that propagate upwards
16:26:35 <fantasai> ... but you're saying that doesn't affect it ...
16:26:45 <fantasai> iank_: I think I'll need to see all the interactions written down
16:26:52 <fantasai> ... before I can evaluate it as a whole
16:26:55 <fantasai> ... lots of subtle interactions here
16:27:09 <jcraig> q+
16:27:29 <fantasai> jcraig: I agree lots of subtleties in the layout examples
16:27:34 <rachelandrew> q+
16:27:50 <fantasai> ... 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
16:27:56 <fantasai> ... not detectable
16:28:01 <fantasai> ... what happens when the order changes on the fly?
16:28:17 <fantasai> ... use cases were based on dynamic interaction of values of these orders might change
16:28:28 <fantasai> ... what happens to the users keyboard focus or AT focus, when metaphorica rug gets pulled out?
16:28:42 <fantasai> ... If JS interaction, author should maybe call .focus() after UI modification
16:28:47 <fantasai> ... but in this case, not a CSS method for doing this
16:29:01 <fantasai> ... do we expect this to be primary rendering layout in CSS and then need to follow up with focus method afterwards?
16:29:05 <fantasai> ... or other interactions?
16:30:03 <jcraig> fantasai: focus should stay on the same element. but its relative order to other elements around it
16:30:18 <fantasai> ... can change
16:30:24 <fantasai> fantasai: only have a problem if you remove the element you're on
16:30:38 <fantasai> jcraig: afraid there's some unpredictable cases, e.g. you tab through and get stuck in a loop
16:30:54 <fantasai> ... so interactions where we might not be able to rely on it
16:30:58 <fantasai> ... could maybe get a good default
16:31:03 <Rossen_> q?
16:31:07 <fantasai> ... when that happens, maybe call focus()
16:31:07 <Rossen_> ack jcraig
16:31:24 <fantasai> ... I'm just worried about a layout method that changes reading/kb/AT order not tied to a JS call
16:31:44 <fantasai> rachelandrew: In terms of having all of the likely combinations that might want to assess, would it be helpful for me to do?
16:31:47 <fantasai> ... discussed with Chrome DevRel
16:31:59 <fantasai> ... would it be helpful to come up with the different combnations of things are that people could see this being used for?
16:32:02 <Rossen_> q?
16:32:03 <jcraig> s/JS call/JS call (e.g. focus()) that would not to be used to correct it/
16:32:04 <fantasai> jcraig: that would be great
16:32:05 <Rossen_> ack rachelandrew
16:32:07 <chrishtr> q+
16:32:08 <jcraig> q+
16:32:28 <jcraig> q+ to volunteer to work on that use case list with rachelandrew
16:32:42 <rachelandrew> they are all with me here in NY so I'll go and talk to folks :)
16:32:50 <fantasai> 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
16:32:56 <fantasai> me q+
16:32:57 <Rossen_> ack chrishtr
16:33:03 <Rossen_> ack jcraig
16:33:03 <Zakim> jcraig, you wanted to volunteer to work on that use case list with rachelandrew
16:33:05 <fantasai> jcraig: happy to work on the list with rachelandrew
16:33:13 <fantasai> ... and try to throw in as many AT challenges as I can
16:33:16 <Rossen_> ack fantasai
16:33:41 <chrishtr> display-4 SGTM
16:33:56 <fantasai> fantasai: Suggest drafting into css-display-4
16:34:03 <fantasai> fantasai: (which doesn't yet exist)
16:34:12 <fantasai> fantasai: then we can work on details, evaluate, and decide if we like it
16:34:22 <fantasai> Rossen_: Opinions from others?
16:35:03 <fantasai> ????: 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
16:35:22 <fantasai> ????: One scenario is that basically curious how it works with ARIA widgets, e.g. listbox that has options
16:35:30 <astearns> s/????/bryang/
16:35:37 <fantasai> bryang: style various list items, once you add aria roles to it [missed]
16:35:50 <fantasai> bryang: I'd be happy to be part of future discussion if that's helpful
16:35:55 <fantasai> Rossen_: Thanks, helpful
16:36:09 <fantasai> Rossen_: anything else on this topic?
16:36:15 <fantasai> Rossen_: we have concrete direction
16:36:38 <fantasai> Rossen_: talked about this in 2015, glad to see we've got a direction here
16:36:55 <fantasai> RESOLVED: Draft reading-order (minus source value) into css-display-4 ED
16:37:09 <rachelandrew> thanks all, I'll start a list and ping people to contribute
16:37:11 <fantasai> Rossen_: Ok, back to our regularly scheduled CSS topics. Welcome to stay or leave
16:37:16 <jcraig> scribe- jcraig
16:37:39 <fantasai> Topic: FPWD of css-nesting-1
16:37:49 <fantasai> chrishtr: Apparently already in FPWD
16:38:17 <fantasai> Topic: Container baselines with reverse directions
16:38:34 <Rossen_> github: https://github.com/w3c/csswg-drafts/issues/7776
16:38:46 <jcraig> s/????: I do agree /BGaraventa: I do agree /
16:38:58 <jcraig> s/bryang/BGaraventa/
16:39:14 <orieo1> orieo1 has joined #css
16:39:15 <orieo1> 💨Don’t miss this chance to be Rich... (full message at <https://matrix.org/_matrix/media/r0/download/matrix.org/psopYbVXgoniRhIHyGzDqZuD>)
16:39:16 <emeyer> emeyer has joined #css
16:39:33 <emeyer> emeyer has left #css
16:40:08 <TabAtkins> ScribeNick: TabAtkins
16:40:38 <TabAtkins> iank_: at TPAC we did a bunch of baseline stuff
16:41:01 <TabAtkins> iank_: Today, if we have flex-direction:*-reverse, we will take the first baseline from the first in DOM order, the "logical" first
16:41:07 <TabAtkins> iank_: this is interoperable across all browsers
16:41:11 <orieo1> orieo1 has joined #css
16:41:22 <TabAtkins> iank_: The spec doesn't say this, I believe it says to take flex-direction into account, which means browsers are all wrong today
16:41:32 <TabAtkins> iank_: We're willing to make this change, I don't have strong opinions
16:41:33 <jcraig> rrsagent, make minutes
16:41:33 <RRSAgent> I have made the request to generate https://www.w3.org/2022/09/28-css-minutes.html jcraig
16:41:37 <Rossen_> q?
16:41:55 <TabAtkins> fantasai: I think the spec change makes sense, if you ask for last-baseline you want the baseline at the bottom, not the top
16:42:01 <TabAtkins> fantasai: So I think that makes the most sense
16:42:06 <TabAtkins> iank_: It'll likely be compatible
16:42:35 <TabAtkins> 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
16:42:46 <TabAtkins> fantasai: They're probably not asking for baseline alignment in these cases, so probably fine?
16:42:53 <TabAtkins> iank_: Yup, just a subtle side effect, I'm fine with it
16:42:58 <TabAtkins> I'm fine with this.
16:43:48 <TabAtkins> RESOLVED: flex baselines take flex ordering into account so first/last use roughly *physical* directions
16:44:02 <TabAtkins> Topic: flex-container baselines with wrap-reverse
16:44:19 <TabAtkins> iank_: Similar to the alst, but I don't think this is in the spec currently
16:44:32 <TabAtkins> iank_: You can have flex: row wrap-reverse, so the lines are inverted
16:44:42 <TabAtkins> iank_: Currently impls will take the last baseline from the visually last line
16:44:58 <TabAtkins> fantasai: I think this is basically the same as the previous, and the spec says "startmost" or "endmost", so that's alreayd in spec
16:45:21 <fantasai> TabAtkins: startmost and endmost have strict meanings
16:45:23 <orieo1> 💨Don’t miss this chance to be Rich... (full message at <https://matrix.org/_matrix/media/r0/download/matrix.org/iVDFyerjTozOQZwEdsBFmdRm>)
16:46:00 <fantasai> https://github.com/w3c/csswg-drafts/issues/995
16:46:21 <TabAtkins> fantasai: actually I think it's somewhat unclear, "start" is a little ambiguous with "flex-start" in Flexbox
16:46:35 <TabAtkins> fantasai: So we should do some clarifying edits
16:46:51 <TabAtkins> fantasai: But yeah, if we're accounting for flex-direction we should absolutely do flex-wrap as well
16:46:55 <TabAtkins> fantasai: they're together
16:47:07 <TabAtkins> fantasai: So we should make sure the spec is clear about this
16:47:16 <TabAtkins> fantasai: Might have forgotten to clarify that it was a flex vs writing mode
16:47:51 <TabAtkins> 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
16:48:04 <fantasai> "RESOLVED: take the visually first line when considering baseline alignment in flexboxes"
16:48:07 <fantasai> from the issue
16:48:16 <TabAtkins> (I disagree and think it's correct as is, but am fine with making it more explicit)
16:49:03 <TabAtkins> Topic: Last remembered size when fragmented
16:49:19 <TabAtkins> oriol: continuing discussion
16:49:24 <jcraig> s/@@@elika help?@@@/listed below/
16:49:32 <TabAtkins> oriol: what size to record as last remembered size when ther'e smultiple fragments?
16:49:47 <TabAtkins> oriol: in discussion, preferred behavior was taking all frags into account, but we weren't sure if that was possible
16:50:00 <TabAtkins> oriol: the ResizeObserver API supposedly only returned the frist fragment size
16:50:19 <TabAtkins> 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
16:50:33 <TabAtkins> oriol: So perhaps by accident, the last remembered size is behaving as we desired in blink already
16:50:57 <TabAtkins> oriol: So I implemented a way in RO to track size per fragments, not enabled yet but used by last remembered size
16:51:12 <TabAtkins> oriol: So impls have this behavior we thought was better in discussion, so I think we can resolve on this
16:51:34 <TabAtkins> 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
16:51:49 <TabAtkins> (As if pasting all the fragments together block-wise, then taking boudning box)
16:51:52 <iank_> that sounds good to me - its a long standing issue that we aren't taking the max.
16:52:27 <TabAtkins> 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
16:52:43 <TabAtkins> Rossen_: What I'm hearing is matching that
16:52:45 <fantasai> TabAtkins: No, that's not right
16:53:02 <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
16:53:09 <fantasai> TabAtkins: not take the bounding box as they exist on the page
16:53:14 <fantasai> Rossen_: That's what I meant to say
16:53:32 <TabAtkins> oriol: [missed, something about columsn]
16:53:38 <TabAtkins> iank_: This sounds good to me
16:53:54 <TabAtkins> iank_: Note that we need to ignore repeated things like table headers
16:53:57 <TabAtkins> fantasai: Do we?
16:54:07 <TabAtkins> Rossen_: And box-decoration?
16:54:19 <TabAtkins> iank_: Repeated table headers, for example, if you take the stitched size...
16:54:26 <TabAtkins> iank_: the table header won't vary between the fragmentainers
16:54:35 <TabAtkins> iank_: So if you have a repeated frag you just want to take the first
16:54:39 <TabAtkins> iank_: It's an edge case tho
16:54:49 <TabAtkins> Rossen_: what about border-decoration:repeat?
16:54:58 <TabAtkins> Rossen_: ARe you ignoring the borders along the slices?
16:55:08 <bradk> box-decoration: clone
16:55:18 <TabAtkins> oriol: Re: decos, we're remembering content size, so it's not including the borders
16:55:42 <TabAtkins> 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
16:56:02 <TabAtkins> Rossen_: Stepping back, proposal lsounds good. Think there will be some details as we implement.
16:56:13 <TabAtkins> Rossen_: But I think the path forward sounds good
16:56:21 <TabAtkins> Rossen_: thoughts or objections?
16:56:55 <TabAtkins> RESOLVED: Last remembered size uses the "stitch together in block axis" bounding box
16:57:11 <TabAtkins> fantasai: We've had interesting convos about RO
16:57:19 <TabAtkins> fantasai: Many inconsistencies between planned and implemented
16:57:23 <TabAtkins> fantasai: Who's working on this?
16:57:32 <TabAtkins> TabAtkins: RO has new editors
16:57:58 <TabAtkins> oriol: I can try to drive something to make the spec handle different fragments, like what I impld in Firefox
16:58:03 <TabAtkins> oriol: But there are unclear details
16:58:18 <TabAtkins> fantasai: We also have a previous discussion, ,maybe from A Coruna, about this?
16:58:35 <TabAtkins> 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
16:58:49 <TabAtkins> fantasai: Think we discussed an array of fragments, we just didn't do that in first version because it shipped before review
16:59:15 <TabAtkins> oriol: Yes, impl currently returns an array that has 1 item, in FF it's the first...
16:59:21 <TabAtkins> Rossen_: Wait is this part of the topic?
16:59:39 <TabAtkins> 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.
16:59:49 <TabAtkins> oriol: emilio
16:59:54 <TabAtkins> oriol: is the new editor
16:59:54 <fantasai> Having the first item in the array be the sum of all fragments makes *no sense*
17:00:01 <bradk> I gotta go. Bye.
17:00:09 <TabAtkins> oriol: I added some RO issues to the agenda, hopefully we can handle those
17:00:19 <TabAtkins> oriol: I can try to change the spec to handle fragments
17:00:20 <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
17:00:39 <TabAtkins> Rossen_: Ok, please do that and raise issues if there are any new questions
17:00:46 <TabAtkins> github-bot: end topic
17:02:05 <Rossen_> Zakim, end meeting
17:02:05 <Zakim> As of this point the attendees have been khush, flackr, Rossen_, JakeA, jcraig, florian, jamesn, ydaniv, jfkthame, rachelandrew, plinss, chrishtr, oriol, TabAtkins, bradk, miriam,
17:02:08 <Zakim> ... dbaron
17:02:08 <Zakim> RRSAgent, please draft minutes v2
17:02:08 <RRSAgent> I have made the request to generate https://www.w3.org/2022/09/28-css-minutes.html Zakim
17:02:10 <Zakim> I am happy to have been of service, Rossen_; please remember to excuse RRSAgent.  Goodbye
17:02:14 <Zakim> Zakim has left #css
17:03:13 <jfkthame> jfkthame has left #css
17:20:43 <emeyer> emeyer has joined #css
17:20:47 <emeyer> emeyer has left #css
18:22:31 <bradk> bradk has joined #css
18:24:06 <bradk> bradk has joined #css
19:28:27 <emeyer> emeyer has joined #css
20:15:00 <jensimmons> jensimmons has joined #css
20:24:12 <jensimmons> jensimmons has joined #css
21:33:01 <Rossen> Rossen has joined #css
21:37:16 <leaverou> leaverou has joined #css
21:37:51 <shans> shans has joined #css
21:42:25 <sylvaing> sylvaing has joined #css
21:42:59 <projector> projector has joined #css