- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 8 Mar 2023 19:29:38 -0500
- To: www-style@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. ========================================= Switching drafts.csswg.org to proxy github.io --------------------------------------------- - RESOLVED: Proxy from drafts.csswg.org to github.io, and have github.io redirect to our server - plinss will set up the proxy server. rachelandrew will work with MDN and TabAtkins will work with WHATWG to get URLs changed. CSS Display ----------- - RESOLVED: Inertness is determined by the base computed style for 'display', resulting in animations to 'none' being considered inert (Issue #8389: Interaction gotchas when delaying the effect of `display: none`) CSS Position ------------ - 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 (Issue #8284: Containing block formed by fragmented inlines) CSSOM & Backgrounds ------------------- - RESOLVED: Move color at the end of the final-bg-layer grammar, to make it serialize as `none` (Issue #8496: Serialization of `background: none`) ===== FULL MEETING MINUTES ====== Agenda: https://lists.w3.org/Archives/Public/www-style/2023Mar/0006.html Present: Rachel Andrew Tab Atkins David Baron Oriol Brufau Tantek Çelik Emilio Cobos Álvarez Yehonatan Daniv Elika Etemad Robert Flack Mason Freed Paul Grenier Chris Harrelson Daniel Holbert Jonathan Kew Peter Linss Eric Meyer François Remy Alan Stearns Miriam Suzanne Bramus Van Damme Chair: astearns Scribe: fantasai Agenda ====== 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 Switching 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 server 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 <TabAtkins> (I'm still not sure what was causing the out-of-sync thing on the github.io) emilio: I think a lot of MDN is pointing to github.io now, which is unfortunate 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 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 <chrishtr> +1 to temporary switch and see how it goes <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 enough <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 <tantek> florian is saying what I would say :) florian: We should try to make some 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 people 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) fantasai: Very strong +1 to florian fantasai: It's possible to proxy some but not all urls? <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 fantasai: We could proxy the urls for the drafts only, but leave the server handle other documents that the github backend doesn't do fantasai: That would take some load off the server, and would still leave us with the extra functionality 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 people to use correct links plinss: We just need to make sure that doesn't break the proxy <TabAtkins> Thinking we'll do the redirect in a script in the ED header boilerplate; we can just check what URL is actually there. RESOLVED: Proxy from drafts.csswg.org to github.io, and have github.io redirect to our server ACTION plinss to set up proxy ACTION rachelandrew to update MDN ACTION TabAtkins to push updates to WHATWG CSS Display =========== Interaction gotchas when delaying the effect of `display: none` --------------------------------------------------------------- github: https://github.com/w3c/csswg-drafts/issues/8389#issuecomment-1458713903 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, could 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 would 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 flackr: but this would be for doing the right thing in the simple cases <PaulG> +1 (from APA) <TabAtkins> +1 from me <masonf> +1 <fantasai> +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: https://github.com/w3c/csswg-drafts/issues/8389#issuecomment-1419970151 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] 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 emilio: This inert, we don't want it to be overridden by anything inside the subtree <oriol> Blink also uses that approach 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 fantasai: For visibility: hidden you can flip back to visible, but visibility: collapse into a flex item doesn't allow you to do that fantasai: so visibility has that behavior as well astearns: Ready to resolve? 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? RESOLVED: 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 ============ scribe: emilio Containing block formed by fragmented inlines --------------------------------------------- github: https://github.com/w3c/csswg-drafts/issues/8284 <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%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 [fantasai describes test-case] fantasai: firefox and chrome disagree fantasai: So... on a single line the abspos cb is the line's bounds fantasai: When it spans multiple lines we could use join the top-left of the first fragment and the bottom-right of the last fantasai: but if the last line is to the left of the first it creates a negative area fantasai: chrome / webkit collapse the width to zero fantasai: firefox does [missing] fantasai: There are pros and cons to both approaches fantasai: 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://bugzilla.mozilla.org/show_bug.cgi?id=489100 and maybe also the somewhat-related https://bugzilla.mozilla.org/show_bug.cgi?id=489207 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 TabAtkins: Allows cb to be as tall as the whole multi-line text box TabAtkins: and also as wide as the whole text TabAtkins: If there's text going further on later lines it'd be good to include that on the box left TabAtkins: so top-left to top-left of first fragment (matches webkit + blink + ff) TabAtkins: bottom matching blink/webkit TabAtkins: 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 <fantasai> Tab's proposal seems reasonable to me... dbaron: This is something I thought about a good bit about a decade ago dbaron: Two things I wanna point out dbaron: One is that it's worth being reasonably careful about directionality dbaron: I think we all do this based on the direction prop of the inline dbaron: iirc chrome didn't handle rtl well but edge did <iank> we've fixed stuff dbaron: Related issue issue is: how do auto-offsets behave for absposes inside inlines dbaron: 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 iank: One thing to note is the start and end is complicated, because the IFC can have different direction to the inline CB iank: 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 iank: When you say linebox we don't quite want that iank: you probably want the max IFC inline edge coordinate iank: because you can have multiple fragments in one line iank: 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 TabAtkins: even 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 iank: but it is different iank: 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 astearns: I think it'd make sense to also take the smallest start edge iank: I doubt that'd be compatible iank: 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 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 dbaron: but might also be more about the auto behavior fantasai: Wanted to talk about about what we pin the right edge to fantasai: end of the first line's last fragment? fantasai: rightmost of all of the lineboxes? fantasai: rightmost of all the fragments? <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: 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 iank: 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 of 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 astearns: The case of putting a caret at the beginning of the line is the thing we can't change astearns: 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 TabAtkins: 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 iank: True <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). <TabAtkins> I think those are the two use-cases we can reasonably 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 astearns: we're defining some reasonable behavior for this edge case where a lot of cases we could get the abspos cb further up astearns: firefox's behavior seems simpler to spec and doesn't run into fragmentation issues iank: we have a solution for fragmentation <TabAtkins> +1 iank: but somewhat hard iank: probably don't have time on this call to consider it iank: I think we should consider at least all of the lines' block edges fantasai: Proposal is 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) <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) <emilio> proposal for dholbert's question is using the fragments themselves <dholbert> thanks! <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) RESOLVED: Try out the proposal above, spec the fragmentation behavior <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 <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 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 <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 <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) CSSOM & Backgrounds =================== Serialization of `background: none` ----------------------------------- github: https://github.com/w3c/csswg-drafts/issues/8496 TabAtkins: Question is how does `background: none` serialize. Using shortest serialization and grammar is unclear TabAtkins: because if you only specify one layer it matches final-background-layer and image-layer TabAtkins: and since color is the first in the final-background-layer safari they serialize transparent TabAtkins: other browsers serialize none TabAtkins: Proposal is to move color to the end of final-bg-layer TabAtkins: which makes it serialize as none fantasai: I think it's great because it moves color to the end fantasai: 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 RESOLVED: Move color at the end of the final-bg-layer grammar, to make it serialize as `none`
Received on Thursday, 9 March 2023 00:30:21 UTC