16:58:26 <RRSAgent> RRSAgent has joined #css
16:58:31 <RRSAgent> logging to https://www.w3.org/2023/03/08-css-irc
16:58:31 <Zakim> RRSAgent, make logs Public
16:58:32 <Zakim> Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
17:00:27 <ydaniv> ydaniv has joined #css
17:00:27 <flackr> flackr has joined #css
17:00:27 <gtalbot> gtalbot has left #css
17:00:29 <gtalbot> gtalbot has joined #css
17:00:29 <khush> khush has joined #css
17:00:29 <rachelandrew> present+
17:00:42 <gtalbot> gtalbot has left #css
17:00:46 <gtalbot> gtalbot has joined #css
17:01:13 <fremy> fremy has joined #css
17:01:23 <plinss> present+
17:01:24 <jfkthame> jfkthame has joined #css
17:01:44 <gtalbot> gtalbot has left #css
17:01:44 <ydaniv> present+
17:01:48 <fremy> present+
17:01:49 <gtalbot> gtalbot has joined #css
17:01:57 <PaulG> PaulG has joined #css
17:02:04 <PaulG> present+
17:02:23 <masonf> masonf has joined #css
17:02:27 <masonf> present+
17:02:47 <oriol> oriol has joined #css
17:03:08 <emilio> present+
17:03:30 <fantasai> scribenick: fantasai
17:03:44 <chrishtr> present+
17:03:48 <bramus> present+
17:04:00 <fantasai> astearns: changes or edits to agenda?
17:04:19 <fantasai> astearns: We will have longer meetings, and more of them next week and the week after
17:04:28 <dbaron> Present+
17:04:29 <flackr> present+
17:04:30 <fantasai> astearns: I will set up calendar invites, but either way
17:04:42 <fantasai> astearns: we have next monday at 7am Pacific and wed at 8am Pacific, both for 2 hours
17:04:47 <fantasai> astearns: same thing the following week
17:04:50 <oriol> present+
17:04:52 <fantasai> astearns: trying to burn down a bunch of the agenda
17:05:22 <fantasai> Topic: Switcihng drafts.csswg.org to proxy github.io
17:05:30 <miriam> present+
17:05:41 <fantasai> astearns: Chris brought this up, github.io seems to be more reliable even with recent work on the servier
17:05:45 <fantasai> astearns: I think it might be time.
17:05:59 <fantasai> chrishtr: This would make it alias the github domain?
17:06:03 <fantasai> astearns: Just for our editor's drafts
17:06:06 <tantek> tantek has joined #css
17:06:11 <TabAtkins> present+
17:06:12 <fantasai> chrishtr: So if you got drafts.csswg.org, it would go to github.io?
17:06:15 <fantasai> astearns: yes
17:06:20 <fantasai> chrishtr: I agree
17:06:23 <fantasai> astearns: building in both places
17:06:33 <fantasai> astearns: but we don't control the infrastructure around github.io
17:06:47 <fantasai> astearns: but it seems to be reasonably reliable, but we get out of the business of hosting our own
17:06:50 <dholbert> present+
17:06:56 <emilio> q+
17:06:57 <florian> q+
17:06:59 <fantasai> plinss: There's still value in having our own infrastructure
17:07:10 <fantasai> plinss: it will get fixed, just not quite there yet
17:07:19 <fantasai> plinss: if we want to switch temporarily, that's fine
17:07:28 <fantasai> plinss: if we want to switch permanently, not my call
17:07:43 <fantasai> plinss: We're also running fxtf and houdini stuff
17:07:51 <fantasai> plinss: and GitHub isn't perfectly reliable, was out of sync for awhile, too
17:07:55 <astearns> ack emilio
17:08:08 <fantasai> emilio: I think a lot of MDN is pointing to github.io now, which is unfortunate
17:08:09 <TabAtkins> (I'm still not sure what was causing the out-of-sync thing on the github.io)
17:08:19 <fantasai> emilio: we should preserve our own URL, even if proxying github.io under the hood
17:08:42 <fantasai> astearns: It's a problem, if MDN and WHATWG are pointing to github.io, proxy server doesn't help much
17:08:54 <fantasai> emilio: GitHub does allow custom domains, can we configure a way that points ...
17:08:57 <tantek> present+
17:09:03 <fantasai> emilio: I guess that would lose functionality from current drafts server
17:09:07 <fantasai> emilio: but point DNS at github?
17:09:17 <fantasai> TabAtkins: That doesn't help problem of hard-linking to github.io
17:09:30 <fantasai> TabAtkins: but if we're quick about it, MDN and WHATWG are changeable
17:09:43 <fantasai> TabAtkins: if they both switch to using our own URL because it's proxying github.io
17:09:44 <tantek> +1 TabAtkins
17:09:45 <fantasai> TabAtkins: [audio cut]
17:09:52 <JonDavis> JonDavis has joined #css
17:09:57 <fantasai> emilio: This is a problem because our server is unreliable, so should be able to change MDN etc if we fix that
17:10:02 <astearns> ack florian
17:10:05 <fantasai> florian: Answering peter's question from earlier
17:10:10 <chrishtr> +1 to temporary switch and see how it goes
17:10:11 <fantasai> florian: I think we should make the switch [audio cut]
17:10:26 <fantasai> florian: Once peter is done fixing the whole thing, we may be able to evaluate what's the better thing to server our URLs
17:10:27 <tantek> +1 to temporary switch with intention to switch back to our own infra
17:10:36 <fantasai> florian: but currently the market is telling us that what we have is not good enoug
17:10:38 <chrishtr> we could also have a different url that goes to the existing server for those who need it
17:10:38 <tantek> important thing is to maintain linking to our URLs
17:10:47 <fantasai> florian: and they're switching away from our URLs, which that's the most important thing because we control them
17:10:50 <fantasai> florian: we should switch
17:11:02 <fantasai> florian: we should try to make sokme trickery to switch from github.io to our own if possible
17:11:08 <emilio> +1
17:11:09 <TabAtkins> We can def do some redirect trickery.
17:11:11 <tantek> +1
17:11:15 <fantasai> florian: but make sure our own URLs are reliable enough that ppl don't refuse to link to them
17:11:19 <tantek> +1
17:11:22 <astearns> ack fantasai
17:11:26 <dholbert> Can't we make both sets of URLs work, with the redirect/proxying being transparent under the hood? (Maybe what Florian was alluding to)
17:11:28 <fantasai> very strong +1 to florian
17:11:29 <emilio> fantasai: very strong +1 to florian
17:11:46 <emilio> fantasai: it's possible to proxy some but not all urls?
17:11:46 <florian> fantasai: strong +1 to florian. Wanted to ask if it is possible to proxy some urls only?
17:12:08 <dbaron> +1 to temporarily making drafts.csswg.org (and hopefully also fxtf.org and css-houdini.org) use the github.io infrastructure while preserving the csswg.org etc. URLs
17:12:12 <florian> fantasai: we could proxy the urls for the drafts only, but leave the server handle other documents that the github backend doesn't do
17:12:31 <florian> fantasai: that would take some load off the server, and would still leave us with the extra functionality
17:12:48 <florian> fantasai: but yes, we need something that's reliable enough that people are willing to link to it
17:13:02 <boris> boris has joined #css
17:13:13 <fantasai> astearns: So we can proxy to github.io, and then ask MDN and WHATWG to use our own URLs
17:13:29 <fantasai> astearns: and if draft server is fixed, we can return to it, and otherwise maintain the proxy
17:13:42 <fantasai> plinss: Ideal would be to have the github stuff have a redirect back to our URLs, if it's served correctly
17:13:58 <fantasai> TabAtkins: we can put a hard redirect so if you hit the actual github.io URL we redirect to the drafts URL
17:14:10 <fantasai> plinss: That'll help encourage ppl to use correct links
17:14:19 <fantasai> plinss: we just need to make sure that doesn't break the proxy
17:14:40 <fantasai> RESOLVED: Proxy from drafts.csswg.org to github.io, and have github.io redirect to our server
17:14:40 <TabAtkins> Thinking we'll do the redirect in a script in the ED header boilerplate; we can just check what URL is actually there.
17:14:53 <fantasai> ACTION plinss to set up proxy
17:14:55 <rachelandrew> I can speak to mdn
17:15:10 <fantasai> ACTION rachelandrew to update MDN
17:15:23 <fantasai> ACTION TabAtkins to push updates to WHATWG
17:15:50 <emeyer> emeyer has joined #css
17:15:53 <github-bot> Topic: [css-display] Interaction gotchas when delaying the effect of `display: none`
17:15:55 <emeyer> present+
17:16:12 <fantasai> flackr: Using display to animate from block to none
17:16:27 <fantasai> flackr: this has effect that during animation, the element can still be interacted with and is in the a11y tree
17:16:39 <fantasai> flackr: it has problems with e.g. form submission, coudl accidentally submit twice because animating out
17:16:57 <fantasai> flackr: proposed resolution is that we look at the base value of the display property, i.e. the value before animation is apply
17:17:02 <fantasai> flackr: when animating to none, base value woudl be none
17:17:11 <fantasai> flackr: use that to determine whether the element should be in the a11y tree
17:17:28 <fantasai> flackr: and also effectively make it inert while it's none
17:17:42 <fantasai> flackr: longer-term, we might want to have inert be a CSS property, and this would be part of auto behavior for inert
17:17:49 <PaulG> +1 (from APA_
17:17:50 <TabAtkins> +1 frome me
17:17:50 <fantasai> flackr: but this would be for doing the right thing in the simple cases
17:17:53 <masonf> +1
17:18:08 <fantasai> +1 to "make it work like expected without author fussing"
17:18:11 <bramus> +1
17:18:24 <emilio> +1 as long as there are tests for this
17:18:39 <fantasai> flackr: [re-explains proposal]
17:19:09 <fantasai> Rossen: There was some work that was already happening around inert, curious if your proposal has any tracking with that work
17:19:10 <emilio> q+
17:19:41 <fantasai> Rossen: I'm sure inert as CSS property was considered and debated at some point in the past, I'm not sure where we ended up, but would be good to have a tracking issue or at least track that discussion
17:19:54 <chrishtr> Link to prior discussion: https://github.com/w3c/csswg-drafts/issues/8389#issuecomment-1419970151
17:20:17 <gtalbot> gtalbot has left #css
17:20:22 <gtalbot> gtalbot has joined #css
17:20:24 <fantasai> chrishtr: Link to pros and cons
17:20:35 <jfkthame> present+
17:20:39 <fantasai> chrishtr: my understanding from previous discussion was that no one had strong opinions, and the door was open to adding it in the future
17:20:45 <fantasai> Rossen: that answers my question
17:21:03 <fantasai> chrishtr: We can do this thing for now, so by default it does the right thing
17:21:13 <fantasai> chrishtr: and if there's significant developer need, we can add 'inert' in the future without too much trouble
17:21:20 <astearns> ack emilio
17:21:20 <fantasai> flackr: yes, this is designed to be forwards-compatible with that
17:21:34 <fantasai> emilio: I was thinking about this, inert has this feature where some elements that escape inert-ness
17:21:42 <fantasai> emilio: e.g. modal dialog that's now 'display: none', that will not be inert
17:21:51 <fantasai> emilio: but 'display: none' would prevent modal dialog from showing
17:21:59 <flackr> qq+
17:22:09 <fantasai> emilio: this looks almost like inert, but with that thing where we may not want subtrees to escape inertness?
17:22:19 <fantasai> chrishtr: if you have [scenario]
17:22:24 <astearns> ack flackr
17:22:24 <Zakim> flackr, you wanted to react to emilio
17:22:34 <fantasai> flackr: the auto behavior is based on the computed base style of 'display', which even for the descendant would be 'none'
17:22:39 <fantasai> emilio: not really, display is not inherited
17:22:50 <fantasai> flackr: but it's within an element with a computed base display style of 'none'
17:23:01 <TabAtkins> display may not be inherited, but display-none-ness *basically* is
17:23:11 <masonf> modal dialog inside a display:none subtree is already display:none.
17:23:16 <fantasai> emilio: the way inert is implemented, at least in WebKit and Gecko, basically it's an internal inherited bit in the computed style representation
17:23:22 <fantasai> emilio: there are things that can flip that for a subtree
17:23:33 <fantasai> emilio: when you have fullscreen element, everything is inert except fullscreen element subtree
17:23:35 <oriol> Blink also uses that approach
17:23:43 <fantasai> emilio: this inert, we don't want it to be overridden by anything inside the subtree
17:23:56 <fantasai> flackr: even if overridden, this proposal would fix the common cases
17:24:12 <fantasai> flackr: but if we did allow overriding, you would have these edge cases where the things animating to 'display: none' would not include modal dialog
17:24:24 <fantasai> emilio: this proposal helps a lot for ?? cases
17:24:33 <fantasai> emilio: just an edge case that might be better to explicitly point out?
17:24:49 <fantasai> emilio: "inert, but actually force inertness for the entire subtree"
17:25:02 <fantasai> flackr: sounds like something we could consider if we add a CSS property for inertness
17:25:11 <fantasai> flackr: I think there are use cases for opting subtree
17:25:26 <fantasai> emilio: if we add inert, it would be similar to visibility, can set it differently inside a subtree
17:25:37 <fantasai> emilio: might have use cases for inert unable to flip within the subtree
17:25:56 <fantasai> emilio: probably the spec should call out this edge case, and define the behavior explicitly
17:26:05 <astearns> ack fantasai
17:26:07 <fantasai> emilio: if you have fullscreen element inside, define that behavior
17:26:48 <emilio> fantasai: for visibility: hidden you can flip back to visible, but visibility: collapse into a flex item doesn't allow you to do that
17:27:01 <fantasai> astearns: ready to resolve?
17:27:02 <emilio> ... so visibility has that behavior as well
17:27:09 <fantasai> s/.../fantasai:/
17:27:24 <gtalbot> gtalbot has left #css
17:27:31 <gtalbot> gtalbot has joined #css
17:27:31 <fantasai> flackr: inertness is determined by the base computed style for 'display', resulting in animations to 'none' being considered inert
17:27:40 <fantasai> astearns: can make that claim generally, not just during animations?
17:27:46 <fantasai> flackr: base computed style is all styles before animations
17:28:03 <fantasai> astearns: any other comments or concerns?
17:28:12 <fantasai> RESOLVED: inertness is determined by the base computed style for 'display', resulting in animations to 'none' being considered inert
17:28:33 <fantasai> astearns: +1 to having tests for this
17:28:54 <github-bot> Topic: [css-position-3] Containing block formed by fragmented inlines
17:29:02 <emilio> scribenick: emilio
17:29:27 <fantasai> https://www.software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cp%3E%3Cdiv%20style%3D%22background%3A%20gray%3B%20width%3A%20100px%3B%20height%3A%201em%3B%20display%3A%20inline-block%22%3E%3C%2Fdiv%3E%3Cspan%20style%3D%22position%3A%20relative%3B%20border%3A%20solid%20blue%22%3E%3Cspan%20style%3D%22position%3A%20absolute%3B%20inset%3A%200%3B%20border%3A%20orange%20solid%22%3E%3C%2Fspan
17:29:33 <fantasai> %3Efirst%20and%3Cbr%3Esecond%20line%20that%27s%20very%20long%20and%3Cbr%3Ethird%3C%2Fspan%3E%0A%3Cp%3E%3Cspan%20style%3D%22position%3A%20relative%3B%20border%3A%20solid%20blue%22%3E%3Cspan%20style%3D%22position%3A%20absolute%3B%20inset%3A%200%3B%20border%3A%20orange%20solid%22%3E%3C%2Fspan%3Efirst%20and%3Cbr%3Esecond%20line%20that%27s%20very%20long%20and%3Cbr%3Ethird%3C%2Fspan%3E
17:29:37 <emilio> fantasai: what do we do when the absolute positioned box is an inline but it spans multiple lines
17:30:06 <emilio> [describes test-case]
17:30:12 <emilio> ... firefox and chrome disagree
17:30:36 <emilio> ... so... on a single line the abspos cb is the line's bounds
17:31:18 <emilio> ... when it spans multiple lines we could use join the top-left of the first fragment and the bottom-right of the last
17:31:49 <emilio> ... but if the last line is to the left of the first it creates a negative area
17:31:56 <emilio> ... chrome / webkit collapse the width to zero
17:32:02 <emilio> ... firefox does [missing]
17:32:09 <castastrophe> castastrophe has joined #css
17:32:12 <emilio> ... there are pros and cons to both approaches
17:32:43 <emilio> ... the four things we think we can do are in the bullet list in the last comment
17:32:46 <fantasai> Use the first line's fragments only (so the entire containing block is contained by its generating box).
17:32:51 <fantasai> Anchor at the start/start corner of the first line box and extend to the end/end corner of the last line box, but clamp the inline size at zero (so the end/end corner might not overlap with a fragment).
17:32:53 <fantasai> Anchor at the start/start corner of the first line box and extend to the end/end corner of the last line box, and allow inversions (so the corners are pinned to actual fragment corners, but the containing block might end up between fragments).
17:32:57 <fantasai> Anchor at the start/start corner of the first line box and extend to the end/end corner of either the last line box (if that's endward of the start line) or of the first line box (otherwise).
17:33:09 <dbaron> There's some old discussion of this in https://bugzilla.mozilla.org/show_bug.cgi?id=489100 and maybe also the somewhat-related https://bugzilla.mozilla.org/show_bug.cgi?id=489207
17:33:56 <emilio> TabAtkins: my preferred behavior is to anchor the top left of top left of the first fragment, anchor bottom to the bottom of the last fragment, and anchor right to the right-edge of either the whole fragment, or line box edge if there are multiple
17:34:06 <emilio> ... allows cb to be as tall as the whole multi-line text box
17:34:17 <emilio> ... and also as wide as the whole text
17:34:36 <emilio> ... if there's text going further on later lines it'd be good to include that on the box left
17:34:51 <dino7> dino7 has joined #css
17:34:58 <emilio> ... so top-left to top-left of first fragment (matches webkit + blink + ff)
17:35:04 <iank_> q+
17:35:10 <emilio> ... bottom matching blink/webkit
17:35:49 <emilio> ... and right edge to the right edge of line box (if multi-line) or end of fragment if it's single-fragment
17:36:04 <astearns> ack dbaron
17:36:08 <fantasai> ... rather than whereever the first fragment happened to break
17:36:17 <emilio> dbaron: this is something I thought about a good bit about a decade ago
17:36:23 <fantasai> Tab's proposal seems reasonable to me...
17:36:23 <emilio> ... two things I wanna point out
17:36:35 <emilio> ... one is that it's worth being reasonably careful about directionality
17:36:55 <emilio> ... I think we all do this based on the direction prop of the inline
17:36:56 <iank_> we've fixed stuff
17:37:05 <emilio> ... iirc chrome didn't handle rtl well but edge did
17:37:28 <emilio> ... related issue issue is: how do auto-offsets behave for absposes inside inlines
17:37:39 <emilio> ... maybe it's not that related but there are a few interesting aspects to it
17:37:44 <astearns> ack iank_
17:37:49 <astearns> q+
17:37:57 <emilio> iank_: worth retesting Chrome because we've fixed a lot of these
17:38:26 <emilio> ... one thing to note is the start and end is complicated, because the IFC can have different direction to the inline CB
17:38:33 <emilio> ... I _believe_ we use the direction of the IFC
17:38:42 <TabAtkins> Yeah, I'd think the IFC is probably the most coherent thing to take the directions from?
17:38:52 <emilio> ... we don't necessarily want to do that but it makes sense given all the edge cases
17:39:01 <emilio> ... when you say linebox we don't quite want that
17:39:15 <emilio> ... you probably want the max IFC inline edge coordinate
17:39:21 <argyle> argyle has joined #css
17:39:24 <emilio> ... because you can have multiple fragments in one line
17:39:32 <emilio> ... and those might not go at the end of the line box
17:39:56 <emilio> TabAtkins: if the inline starts at the left edge of the text area and it covers multiple lines the CB should fill the box
17:40:05 <emilio> ... even if if the actual text bounds is slightly narrower
17:40:27 <emilio> iank_: you can have the situation where the span won't go all the way to the inline edge but there may be some text there
17:40:30 <emilio> ... but it is different
17:40:42 <emilio> ... I think tab's proposal seems fine
17:41:05 <emilio> astearns: I don't like something about tab's proposal, which is the difference for the determination for the start and end edge
17:41:22 <emilio> ... I think it'd make sense to also take the smallest start edge
17:41:38 <emilio> iank_: I doubt that'd be compatible
17:41:57 <emilio> ... that's interoperable now, it's used to do something like a caret at the start of an inline
17:42:03 <emilio> TabAtkins: that's why
17:42:27 <emilio> astearns: It's just a weird result where the orange box covers half of the paragraph in fantasai's
17:42:31 <astearns> ack dbaron
17:42:32 <emilio> ... test-case
17:42:35 <astearns> ack astearns
17:42:43 <emilio> TabAtkins: yeah, but it's very interoperable behavior, so I think we're stuck with that
17:42:52 <iank_> there is :)
17:43:05 <emilio> dbaron: Are there complications here when the inline is split across columns/pages?
17:43:16 <emilio> iank_: there are, I can talk about what edge did here, but that's a long tangent
17:43:32 <emilio> TabAtkins: so we do ???
17:43:40 <astearns> ack dbaron
17:43:53 <TabAtkins> s/???/still anchor the top-left of the CB to the top-left of the first fragment there?/
17:44:01 <emilio> dbaron: I think the issue of splitting over columns / pages is one of the reasons this never got fixed in Gecko
17:44:07 <astearns> ack fantasai
17:44:07 <Zakim> fantasai, you wanted to discuss this right-edge criteria
17:44:10 <emilio> ... but might also be more about the auto behavior
17:44:22 <astearns> q+
17:44:23 <emilio> fantasai: Wanted to talk about about what we pin the right edge to
17:44:39 <emilio> ... end of the first line's last fragment?
17:44:47 <emilio> ... rightmost of all of the lineboxes?
17:44:49 <TabAtkins> My instinct is that if there's a column/etc break, we put the bottom edge to the end of the last fragment in that fragmentainer, analogous to the right-edge behavior.
17:44:53 <emilio> ... rightmost of all the fragments?
17:45:05 <emilio> ... line boxes have different edges with floats
17:45:07 <iank_> From my perspective right most of either the line-boxes or the fragments
17:45:27 <emilio> ... do we want to consider all of the lines? Or just the first?
17:45:37 <emilio> iank_: pretty strong bias towards all of the lines
17:46:11 <emilio> ... covers the case where all of the lines might not line up
17:46:26 <TabAtkins> Ah, I see what you mean by "probably don't want lineboxes" then, yeah
17:46:34 <TabAtkins> right edge fo the IFC or whatever, instead, yeah
17:46:52 <TabAtkins> +1 to rightmost/bottommost of all fragments
17:46:52 <emilio> fantasai: my proposal would be to use the rightmost edge of all of the fragments of the inline box
17:47:11 <emilio> astearns: hard time coming with a use case for doing much more than what FF is doing
17:47:45 <emilio> ... the case of putting a caret at the beginning of the line is the thing we can't change
17:48:08 <emilio> ... what use case is there for having an abspos thing going over some weird section of a fragmented inline?
17:48:30 <emilio> TabAtkins: there's no use case for doing both of the horizontal/vertical bounds we're defining
17:48:36 <emilio> ... but each individually make sense
17:49:01 <emilio> iank_: someone willing to cover all of the lines
17:49:12 <emilio> fantasai: that's only useful if the span is the first thing in the line
17:49:19 <TabAtkins> 1) Putting something at the start of the text (requires top/left to be the top left of the first fragment). 2) Have something as tall as the text (background, or overlay, etc).
17:49:20 <emilio> iank_: true
17:49:28 <TabAtkins> I think those are the two use-cases we can reasoanbly address with a single-box solution.
17:49:42 <emilio> astearns: I worry that we're coming up with this thing that isn't really motivated by use cases
17:50:31 <emilio> ... we're defining some reasonable behavior for this edge case where a lot of cases we could get the abspos cb further up
17:50:51 <emilio> ... firefox's behavior seems simpler to spec and doesn't run into fragmentation issues
17:50:54 <TabAtkins> +1
17:50:59 <emilio> iank_: we have a solution for fragmentation
17:51:02 <TabAtkins> (+1 to Ian, that is)
17:51:02 <emilio> ... but somewhat hard
17:51:13 <emilio> ... probably don't have time on this call to consider it
17:51:44 <emilio> ... I think we should consider at least all of the lines' block edges
17:51:52 <iank_> (i've got to run 👋)
17:52:05 <gtalbot> gtalbot has left #css
17:52:19 <gtalbot> gtalbot has joined #css
17:52:25 <hober> hober has joined #css
17:52:33 <emilio> fantasai: proposal is that that in LTR-tb the top-left corner is the top-left corner of the top-left-most fragment of the first line, and the bottom and right edges are bottommost and rightmost edges of all the fragments
17:53:15 <dholbert> bottom right of all-of-the-fragments, or all-of-the-line-boxes-that-contain-fragments? (if there's a <br> that prevents the fragments from hitting the end of the line)
17:53:24 <emilio> RESOLVED: Try out the proposal above, spec the fragmentation behavior
17:53:28 <TabAtkins> (afaict, the use-cases I listed are already satisfied by Chrome/WebKit's behavior, since neither of them depend on the right side. But I do think a zero-width box should be avoided if we can.)
17:53:30 <dbaron> (also need to be clear whether that LTR-tb is for the IFC or the inline)
17:54:13 <fantasai> analogously for other writing modes, anchoring on the same writing mode as the painting of borders
17:55:06 <emilio> fantasai: I think you want the writing-mode of the inline element, e.g. if you want a flag at the start of the span
17:55:19 <emilio> emilio: iank_ was arguing for writing-mode of the IFC
17:55:40 <dholbert> (my question relates to a distinction that Tab was making early on; we should be clear whether we're talking about line boxes vs. fragments for bottom-right corner.  Sorry, my audio seems to be broken)
17:55:58 <emilio> proposal for dholbert's question is using the fragments themselves
17:56:12 <dholbert> thanks!
17:56:15 <emeyer> I have an uneasy feeling about the proposed solution, but I’m not sure I understand it properly..
17:56:33 <fantasai> Using fragments, because if you have short lines of text you want the edges of those inlines, not the far right of the screen
17:57:37 <emilio> RESOLVED: in LTR-tb the top-left corner is the top-left corner of the top-left-most fragment of the first line, and the bottom and right edges are bottommost and rightmost edges of all the fragments. Directionality comes from the inline
17:57:50 <fantasai> see testcase on borders: https://www.software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cp%3EThis%20%3Cspan%20dir%3Drtl%20style%3D%22border%3A%20solid%22%3Etest%3Cbr%3Eborder%3C%2Fspan%3E%3C%2Fp%3ERESOL
17:57:54 <TabAtkins> emeyer, top/left/bottom edge all match Chrome's current behavior, right edge is the rightmost of *all* fragments (rather than just the first, like what FF currently does, or the last-but-clamped, like Chrome currently does)
17:58:06 <emilio> github-bot: topic https://github.com/w3c/csswg-drafts/issues/8496
17:58:06 <github-bot> Topic: [css-om][css-backgrounds] Serialization of `background: none`
17:58:06 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/8496.
17:58:41 <emilio> TabAtkins: question is how does `background: none` serialize. Using shortest serialization and grammar is unclear
17:59:08 <emilio> ... because if you only specify one layer it matches final-background-layer and image-layer
17:59:49 <emilio> ... and since color is the first in the final-background-layer safari they serialize transparent
18:00:02 <emilio> ... other browsers serialize none
18:00:14 <emilio> ... proposal is to move color to the end of final-bg-layer
18:00:28 <emilio> ... which makes it serialize as none
18:00:39 <emilio> fantasai: I think it's great because it moves color to the end
18:00:47 <emilio> ... which makes sense because it's at the bottom
18:01:02 <emilio> RESOLVED: Move color at the end of the final-bg-layer grammar, to make it serialize as `none`
18:01:07 <emilio> topic: end
18:01:40 <fantasai> i/RESOLVED/... but that would be a change to how a color + image serializes, and I'm not sure that's Web-compatible/
18:03:55 <astearns> zakim, end meeting
18:03:55 <Zakim> As of this point the attendees have been rachelandrew, plinss, ydaniv, fremy, PaulG, masonf, emilio, chrishtr, bramus, dbaron, flackr, oriol, miriam, TabAtkins, dholbert, tantek,
18:03:58 <Zakim> ... emeyer, jfkthame
18:03:58 <Zakim> RRSAgent, please draft minutes v2
18:03:59 <RRSAgent> I have made the request to generate https://www.w3.org/2023/03/08-css-minutes.html Zakim
18:04:06 <Zakim> I am happy to have been of service, astearns; please remember to excuse RRSAgent.  Goodbye
18:04:06 <Zakim> Zakim has left #css
18:05:02 <gtalbot> gtalbot has left #css
20:32:56 <TC> TC has joined #css