Meeting minutes
astearns: changes or edits to agenda?
astearns: We will have longer meetings, and more of them next week and the week after
astearns: I will set up calendar invites, but either way
astearns: we have next monday at 7am Pacific and wed at 8am Pacific, both for 2 hours
astearns: same thing the following week
astearns: trying to burn down a bunch of the agenda
Switcihng drafts.csswg.org to proxy github.io
astearns: Chris brought this up, github.io seems to be more reliable even with recent work on the servier
astearns: I think it might be time.
chrishtr: This would make it alias the github domain?
astearns: Just for our editor's drafts
chrishtr: So if you got drafts.csswg.org, it would go to github.io?
astearns: yes
chrishtr: I agree
astearns: building in both places
astearns: but we don't control the infrastructure around github.io
astearns: but it seems to be reasonably reliable, but we get out of the business of hosting our own
plinss: There's still value in having our own infrastructure
plinss: it will get fixed, just not quite there yet
plinss: if we want to switch temporarily, that's fine
plinss: if we want to switch permanently, not my call
plinss: We're also running fxtf and houdini stuff
plinss: and GitHub isn't perfectly reliable, was out of sync for awhile, too
emilio: I think a lot of MDN is pointing to github.io now, which is unfortunate
<TabAtkins> (I'm still not sure what was causing the out-of-sync thing on the github.io)
emilio: we should preserve our own URL, even if proxying github.io under the hood
astearns: It's a problem, if MDN and WHATWG are pointing to github.io, proxy server doesn't help much
emilio: GitHub does allow custom domains, can we configure a way that points ...
emilio: I guess that would lose functionality from current drafts server
emilio: but point DNS at github?
TabAtkins: That doesn't help problem of hard-linking to github.io
TabAtkins: but if we're quick about it, MDN and WHATWG are changeable
TabAtkins: if they both switch to using our own URL because it's proxying github.io
<tantek> +1 TabAtkins
TabAtkins: [audio cut]
emilio: This is a problem because our server is unreliable, so should be able to change MDN etc if we fix that
florian: Answering peter's question from earlier
<chrishtr> +1 to temporary switch and see how it goes
florian: I think we should make the switch [audio cut]
florian: Once peter is done fixing the whole thing, we may be able to evaluate what's the better thing to server our URLs
<tantek> +1 to temporary switch with intention to switch back to our own infra
florian: but currently the market is telling us that what we have is not good enoug
<chrishtr> we could also have a different url that goes to the existing server for those who need it
<tantek> important thing is to maintain linking to our URLs
florian: and they're switching away from our URLs, which that's the most important thing because we control them
florian: we should switch
florian: we should try to make sokme trickery to switch from github.io to our own if possible
<emilio> +1
<TabAtkins> We can def do some redirect trickery.
<tantek> +1
florian: but make sure our own URLs are reliable enough that ppl don't refuse to link to them
<tantek> +1
<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)
very strong +1 to florian
<emilio> fantasai: very strong +1 to florian
<emilio> fantasai: it's possible to proxy some but not all urls?
<florian> fantasai: strong +1 to florian. Wanted to ask if it is possible to proxy some urls only?
<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
<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
<florian> fantasai: that would take some load off the server, and would still leave us with the extra functionality
<florian> fantasai: but yes, we need something that's reliable enough that people are willing to link to it
astearns: So we can proxy to github.io, and then ask MDN and WHATWG to use our own URLs
astearns: and if draft server is fixed, we can return to it, and otherwise maintain the proxy
plinss: Ideal would be to have the github stuff have a redirect back to our URLs, if it's served correctly
TabAtkins: we can put a hard redirect so if you hit the actual github.io URL we redirect to the drafts URL
plinss: That'll help encourage ppl to use correct links
plinss: we just need to make sure that doesn't break the proxy
RESOLUTION: Proxy from drafts.csswg.org to github.io, and have github.io redirect to our server
<TabAtkins> Thinking we'll do the redirect in a script in the ED header boilerplate; we can just check what URL is actually there.
ACTION: plinss to set up proxy
<rachelandrew> I can speak to mdn
ACTION: rachelandrew to update MDN
ACTION: TabAtkins to push updates to WHATWG
[css-display] Interaction gotchas when delaying the effect of `display: none`
flackr: Using display to animate from block to none
flackr: this has effect that during animation, the element can still be interacted with and is in the a11y tree
flackr: it has problems with e.g. form submission, coudl accidentally submit twice because animating out
flackr: proposed resolution is that we look at the base value of the display property, i.e. the value before animation is apply
flackr: when animating to none, base value woudl be none
flackr: use that to determine whether the element should be in the a11y tree
flackr: and also effectively make it inert while it's none
flackr: longer-term, we might want to have inert be a CSS property, and this would be part of auto behavior for inert
<PaulG> +1 (from APA_
<TabAtkins> +1 frome me
flackr: but this would be for doing the right thing in the simple cases
<masonf> +1
+1 to "make it work like expected without author fussing"
<bramus> +1
<emilio> +1 as long as there are tests for this
flackr: [re-explains proposal]
Rossen: There was some work that was already happening around inert, curious if your proposal has any tracking with that work
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
<chrishtr> Link to prior discussion: w3c/
chrishtr: Link to pros and cons
chrishtr: my understanding from previous discussion was that no one had strong opinions, and the door was open to adding it in the future
Rossen: that answers my question
chrishtr: We can do this thing for now, so by default it does the right thing
chrishtr: and if there's significant developer need, we can add 'inert' in the future without too much trouble
flackr: yes, this is designed to be forwards-compatible with that
emilio: I was thinking about this, inert has this feature where some elements that escape inert-ness
emilio: e.g. modal dialog that's now 'display: none', that will not be inert
emilio: but 'display: none' would prevent modal dialog from showing
emilio: this looks almost like inert, but with that thing where we may not want subtrees to escape inertness?
chrishtr: if you have [scenario]
<Zakim> flackr, you wanted to react to emilio
flackr: the auto behavior is based on the computed base style of 'display', which even for the descendant would be 'none'
emilio: not really, display is not inherited
flackr: but it's within an element with a computed base display style of 'none'
<TabAtkins> display may not be inherited, but display-none-ness *basically* is
<masonf> modal dialog inside a display:none subtree is already display:none.
emilio: the way inert is implemented, at least in WebKit and Gecko, basically it's an internal inherited bit in the computed style representation
emilio: there are things that can flip that for a subtree
emilio: when you have fullscreen element, everything is inert except fullscreen element subtree
<oriol> Blink also uses that approach
emilio: this inert, we don't want it to be overridden by anything inside the subtree
flackr: even if overridden, this proposal would fix the common cases
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
emilio: this proposal helps a lot for ?? cases
emilio: just an edge case that might be better to explicitly point out?
emilio: "inert, but actually force inertness for the entire subtree"
flackr: sounds like something we could consider if we add a CSS property for inertness
flackr: I think there are use cases for opting subtree
emilio: if we add inert, it would be similar to visibility, can set it differently inside a subtree
emilio: might have use cases for inert unable to flip within the subtree
emilio: probably the spec should call out this edge case, and define the behavior explicitly
emilio: if you have fullscreen element inside, define that behavior
<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
astearns: ready to resolve?
<emilio> fantasai: so visibility has that behavior as well
flackr: inertness is determined by the base computed style for 'display', resulting in animations to 'none' being considered inert
astearns: can make that claim generally, not just during animations?
flackr: base computed style is all styles before animations
astearns: any other comments or concerns?
RESOLUTION: inertness is determined by the base computed style for 'display', resulting in animations to 'none' being considered inert
astearns: +1 to having tests for this
[css-position-3] Containing block formed by fragmented inlines
<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
fantasai: what do we do when the absolute positioned box is an inline but it spans multiple lines
[describes test-case]
… firefox and chrome disagree
… so... on a single line the abspos cb is the line's bounds
… when it spans multiple lines we could use join the top-left of the first fragment and the bottom-right of the last
… but if the last line is to the left of the first it creates a negative area
… chrome / webkit collapse the width to zero
… firefox does [missing]
… there are pros and cons to both approaches
… the four things we think we can do are in the bullet list in the last comment
<fantasai> Use the first line's fragments only (so the entire containing block is contained by its generating box).
<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).
<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).
<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).
<dbaron> There's some old discussion of this in https://
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
… allows cb to be as tall as the whole multi-line text box
… and also as wide as the whole text
… if there's text going further on later lines it'd be good to include that on the box left
… so top-left to top-left of first fragment (matches webkit + blink + ff)
… bottom matching blink/webkit
… and right edge to the right edge of line box (if multi-line) or end of fragment if it's single-fragment
<fantasai> ... rather than whereever the first fragment happened to break
dbaron: this is something I thought about a good bit about a decade ago
<fantasai> Tab's proposal seems reasonable to me...
dbaron: two things I wanna point out
… one is that it's worth being reasonably careful about directionality
… I think we all do this based on the direction prop of the inline
<iank_> we've fixed stuff
dbaron: iirc chrome didn't handle rtl well but edge did
… related issue issue is: how do auto-offsets behave for absposes inside inlines
… maybe it's not that related but there are a few interesting aspects to it
iank_: worth retesting Chrome because we've fixed a lot of these
… one thing to note is the start and end is complicated, because the IFC can have different direction to the inline CB
… I _believe_ we use the direction of the IFC
<TabAtkins> Yeah, I'd think the IFC is probably the most coherent thing to take the directions from?
iank_: we don't necessarily want to do that but it makes sense given all the edge cases
… when you say linebox we don't quite want that
… you probably want the max IFC inline edge coordinate
… because you can have multiple fragments in one line
… and those might not go at the end of the line box
TabAtkins: if the inline starts at the left edge of the text area and it covers multiple lines the CB should fill the box
… even if if the actual text bounds is slightly narrower
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
… but it is different
… I think tab's proposal seems fine
astearns: I don't like something about tab's proposal, which is the difference for the determination for the start and end edge
… I think it'd make sense to also take the smallest start edge
iank_: I doubt that'd be compatible
… that's interoperable now, it's used to do something like a caret at the start of an inline
TabAtkins: that's why
astearns: It's just a weird result where the orange box covers half of the paragraph in fantasai's
… test-case
TabAtkins: yeah, but it's very interoperable behavior, so I think we're stuck with that
<iank_> there is :)
dbaron: Are there complications here when the inline is split across columns/pages?
iank_: there are, I can talk about what edge did here, but that's a long tangent
TabAtkins: so we do still anchor the top-left of the CB to the top-left of the first fragment there?
dbaron: I think the issue of splitting over columns / pages is one of the reasons this never got fixed in Gecko
<Zakim> fantasai, you wanted to discuss this right-edge criteria
dbaron: but might also be more about the auto behavior
fantasai: Wanted to talk about about what we pin the right edge to
… end of the first line's last fragment?
… rightmost of all of the lineboxes?
<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.
fantasai: rightmost of all the fragments?
… line boxes have different edges with floats
<iank_> From my perspective right most of either the line-boxes or the fragments
fantasai: do we want to consider all of the lines? Or just the first?
iank_: pretty strong bias towards all of the lines
… covers the case where all of the lines might not line up
<TabAtkins> Ah, I see what you mean by "probably don't want lineboxes" then, yeah
<TabAtkins> right edge fo the IFC or whatever, instead, yeah
<TabAtkins> +1 to rightmost/bottommost of all fragments
fantasai: my proposal would be to use the rightmost edge of all of the fragments of the inline box
astearns: hard time coming with a use case for doing much more than what FF is doing
… the case of putting a caret at the beginning of the line is the thing we can't change
… what use case is there for having an abspos thing going over some weird section of a fragmented inline?
TabAtkins: there's no use case for doing both of the horizontal/vertical bounds we're defining
… but each individually make sense
iank_: someone willing to cover all of the lines
fantasai: that's only useful if the span is the first thing in the line
<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).
iank_: true
<TabAtkins> I think those are the two use-cases we can reasoanbly address with a single-box solution.
astearns: I worry that we're coming up with this thing that isn't really motivated by use cases
… we're defining some reasonable behavior for this edge case where a lot of cases we could get the abspos cb further up
… firefox's behavior seems simpler to spec and doesn't run into fragmentation issues
<TabAtkins> +1
iank_: we have a solution for fragmentation
<TabAtkins> (+1 to Ian, that is)
iank_: but somewhat hard
… probably don't have time on this call to consider it
… I think we should consider at least all of the lines' block edges
<iank_> (i've got to run 👋)
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
<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)
RESOLUTION: Try out the proposal above, spec the fragmentation behavior
<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.)
<dbaron> (also need to be clear whether that LTR-tb is for the IFC or the inline)
<fantasai> analogously for other writing modes, anchoring on the same writing mode as the painting of borders
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
emilio: iank_ was arguing for writing-mode of the IFC
<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)
proposal for dholbert's question is using the fragments themselves
<dholbert> thanks!
<emeyer> I have an uneasy feeling about the proposed solution, but I’m not sure I understand it properly..
<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
RESOLUTION: 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
<fantasai> see testcase on borders: https://
<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)
github-bot: topic w3c/
[css-om][css-backgrounds] Serialization of `background: none`
<github-bot> OK, I'll post this discussion to https://
TabAtkins: question is how does `background: none` serialize. Using shortest serialization and grammar is unclear
… because if you only specify one layer it matches final-background-layer and image-layer
… and since color is the first in the final-background-layer safari they serialize transparent
… other browsers serialize none
… proposal is to move color to the end of final-bg-layer
… which makes it serialize as none
fantasai: I think it's great because it moves color to the end
… which makes sense because it's at the bottom
<fantasai> ... but that would be a change to how a color + image serializes, and I'm not sure that's Web-compatible
RESOLUTION: Move color at the end of the final-bg-layer grammar, to make it serialize as `none`