- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 25 May 2022 17:40:19 -0400
- 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. ========================================= TPAC & Longform Meetings ------------------------ - The deadline for TPAC meeting requests is the end of May. Please send any preferences for meeting days to the private list. - Next week there will be an extended meeting to cover the Selectors topics. - There have been some suggestions to have a hybrid in person/remote session over the summer. If there is interest please reach out to the private list. Anchor Positioning ------------------ - iank introduced the concept of CSS Anchor Positioning to allow positioning elements relative to other elements in the DOM. - There were some initial questions and positive feedback. Discussion will continue on the private github ( https://tabatkins.github.io/specs/css-anchor-position/#target-anchor-element ) until the proposal is formally moved into the working group's scope. Any substantial changes will also be noted in github issue #7282 (Introduce CSS Anchor Positioning). CSS Text Decor -------------- - More examples will be added of the current unexpected behavior mentioned in issue #7251 (Composition of inset shadows). astearns will also do research into if there is already examples we can follow in the Adobe products. - RESOLVED: Leave text-shadow spread details undefined right now, with possibility of specification later after impl experience (Issue #7250: Text shadow spread corners) CSS Text -------- - RESOLVED: No change (Issue #7249: Make U+0000 invisible?) - Bugs will be filed with the browsers to see if they are willing to align to the spec on issue #6542 (text-align: match-parent on the root element with direction: rtl doesn't match browsers). If the browsers have specific reasons to not conform to the spec the group will consider changing the spec. CSS Color 5 & Images 4 ---------------------- - The features listed in issue #7310 (Are these features ready to ship?) are not ready to ship yet, but there is interest in prioritizing them to become ready to ship. ===== FULL MINUTES BELOW ====== Agenda: https://lists.w3.org/Archives/Public/www-style/2022May/0008.html Present: Rossen Atanassov Tab Atkins Bittner David Baron Oriol Brufau Daniel Clark Emilio Cobos Álvarez Elika Etemad Robert Flack Simon Fraser Mason Freed Chris Harrelson Daniel Holbert Brian Kardell Brad Kemper Jonathan Kew Ian Kilpatrick Daniel Libby Peter Linss Alison Maher Ben Mathwig Florian Rivoal Jen Simmons Alan Stearns Miriam Suzanne Scribe: TabAtkins TPAC & Longform Meetings ======================== astearns: Administrivia, need to decide what times we're going to meet for TPAC astearns: Two options on the private list astearns: Have to give the meeting organizers a preference by end of month astearns: If I don't hear strong opinions we'll probably default to our standard, two long days Mon-Tue astearns: If any prefs or other suggestions, please respond on the list astearns: Second, our agenda is getting long again astearns: A bunch of interrelated issues in Selectors 4 that have been tagged astearns: Should probably have a breakout session on those issues, there's enough to fill a meeting astearns: I suggest next week we have the normal time meeting, and also have a Selectors 4 meeting at the European time astearns: If anyone has an objection to two meeting in a day, lmk, otherwise that's the plan <TabAtkins> Sounds good. <TabAtkins> I'm available next week, but *not* the week following, if timing is adjusted. plinss: I'm not available that time next week, and are interested in being present <plinss> you can do the selectors breakout without me... astearns: Third, some people have suggested before TPAC we should have a hybrid longform meeting that would include getting a few people together in person astearns: If anyone's interested in that, we should start a thread on the private list and/or the meeting planning pages on the wiki astearns: Could probably meet somewhere in NA, anyone interested in traveling could meet, but we'd need a venue with very good remote capabilities. astearns: So if there's interest, let's please talk about it. astearns: Any other admin topics, or agenda changes? Anchor Positioning ================== scribe: fantasai Introduce CSS Anchor Positioning -------------------------------- github: https://github.com/w3c/csswg-drafts/issues/7282 iank: Quite a lot of interest in positioning an element relative to another element in the DOM <astearns> explainer: https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/CSSAnchoredPositioning/explainer.md iank: What we're proposing here isn't a new idea, people have had variants of this idea for over 10 years iank: a post on Tab's blog in 2012, etc. <TabAtkins> (the old post: https://www.xanthir.com/blog/b48H0) iank: This is basically an extension to absolute and fixed positioning iank: in that we can set the inset properties, left/right/top/bottom iank: and interpret that relative to another element iank: We've got a prototype of this, and found it to be pretty powerful iank: you can create popups with this, all sorts of things iank: Tab's written up a basic spec for this, with details of how application works, how this modifies the abspos/fixedpos scheme iank: and how also the rectangles propagate iank: Couple of interesting point in that one thing we think is ?? is that when you propagate up the positions of the anchor elements iank: we think it should roughly follow the same propagation as static elements, in that it ignores transforms and ??? iank: So that you can still have composited text and not affect layout (?) iank: I think that's roughly it TabAtkins: There's a limitation on which elements can be targeted with anchor iank: Roughly speaking, abspos/fixedpos happens right at the end of laying out a container, so you already know where all your in-flow children are iank: you get some really nice properties if you restrict it to elements within that containing block subtree iank: [missed] iank: When we get to abspos/fixedpos positioning, you can reference things that we already know where they are iank: The other thing is @position-set iank: When you examine the popup/anchor use-cases, necessary to be able to say "I don't fit in this position, I'd like to try an alternate position" iank: So you might want to be on the right of the anchor, but if there isn't space I"d like to be below, or the left. That's \ what @position-set is for iank: @position-set lets you specify @try blocks setting top/left etc, and if those don't work (cause overflow) we advance to the next @try and use those instead. TabAtkins: Possibility of exponential explosion in layouts when you have chained anchors means we want to impose a strict limit on how many @try blocks can be used Rossen: Generally I'm favorable to the scenario and the overall approach Rossen: Couple of questions not clear to me, if I heard you right, you said that you can anchor yourself to any other element's box iank: In the containing block subtree that's already being positioned iank: abspos/fixedpos has its containing block iank: Anything that has already been positioned within that containing block subtree iank: so you can't reference something further up the DOM <astearns> which is an *ancestor* in the containing block subtree <TabAtkins> See https://tabatkins.github.io/specs/css-anchor-position/#target-anchor-element for details Rossen: This was exactly my question here Rossen: and think it's really important in order to prevent some of the really circular dependencies Rossen: Question is still, is the assumption that such element will not contribute to the overall bounds of the containing block iank: Right, this will only apply to abspos/fixedpos elements iank: So they won't change the containing block size <TabAtkins> (but presumably would change scrollable overflow area) Rossen: This feature you describe is almost exactly the feature we proposed called "position: float" or something like that Rossen: except that you're anchoring to elements, not allowing the rest of the positioning constructs to apply Rossen: My question was answered, you're basically scoping the anchoring to the containing block, which makes a lot of sense Rossen: Only other question is, you can affect scroll bounds for your containing block still, even for those elements? iank: Yes Rossen: So behave like normal abspos iank: Yes iank: You're right that you need to make the scrollbars predictable, but this isn't a new problem Rossen: Not different than if just an abspos Rossen: Last bit, are you scoping only to anchoring, or anchoring plus... can I say anchor me next to the left border + some offset? iank: These anchor queries you can use in a calculation expression iank: so you can do calc(this + this) iank: We had some fun with our happy prototype, where you could do minimum of this anchor's left and this other anchor's left smfr: Is there potential for circular references? iank: We want to avoid exactly that iank: so anchor-positioned things assigned to the same containing block can't reference each other <iank> https://tabatkins.github.io/specs/css-anchor-position/#target-anchor-element iank: Tab's got all the rules written down in the spec TabAtkins: Very certain not a problem <chrishtr> Anchoring can only apply *down* the containing block chain, which makes it clear that there are no cycles. smfr: Because constrained to something in the containing block, if authors want a global ability they'd have to anchor ...? iank: Have to use fixedpos or something like that TabAtkins: No need to reparent, because fixedpos containing block is the ICB smfr: ... iank: But then there's things where you want it to work more locally iank: There's also a proposal which is related to adjusting the scroll position iank: but that's separate from this dholbert: I was wondering, seems like it's ID-based right now, I wonder if that could be ... how do you imagine using this if you want to have multiple in a single page? TabAtkins: Where are you seeing this? dholbert: Looking at explainer TabAtkins: Ah, MS explainer is earlier draft TabAtkins: look at this spec TabAtkins: We use the anchor-name property, look for the first thing in tree space with that name <astearns> ah, I only read the explainer - not the spec yet :) dholbert: Okay iank: We've got some flexibility in how we do that iank: I personally like anchor-name solution iank: requirement is reference things within this containing block subtree fantasai: Whatever scoping rules we use here we should be consistent with scroll animations, which has a similar named attachment method <fantasai> (and vice versa, they're both early proposals so we switch to whatever's the best method for both) astearns: Suggest to read the spec and fiddle with details in the spec iank: If anyone wants to play with the prototype lmk TabAtkins: We anticipate asking for ED soon-ish, not just yet TabAtkins: so keep informed astearns: I assume there'll be some discussion in your personal repo for awhile, but if significant changes or questions raised, might be good to update the issue we have on introducing this astearns: so people can follow along without following your repo TabAtkins: Happy to track issues in both repos TabAtkins: and move issues later fantasai: Why not move it now? TabAtkins: No particular reason fantasai: better to move now then, your private repo isn't backed up by W3C astearns: Let's give people time to review <TabAtkins> The scoping rules for anchor-name are just "the subtree that is allowed to contribute an anchor due to the positioning rules", which may or may not match up with what scroll animations exactly want CSS Text Decor 4 ================ Composition of inset shadows ---------------------------- github: https://github.com/w3c/csswg-drafts/issues/7251 fantasai: I wanted to ask what we should do with inset shadows - what's their stacking order wrt stroke? fantasai: Expectation is probably that it's between fill and stroke fantasai: But then are we compositing the text decorations with their text before shadowing? If so we can't layer shadows between fantasai: You'd have to shadow each letter and decoration independently to do that smfr: Issue says Chrome and Firefox have somewhat surprising behavior, so [...missed] fantasai: Sebastian said "from author's perspective, expect inset between fill and stroke", but outsets should be below both, so that would require them to be treated differently. fantasai: If you have a semi-transparent shadow on text with spread/ blur, don't think you'd expect it to be darker where letters are near each other - you'd want them to be shadowed as a whole. That requires compositing text *then* shadowing. fantasai: We might not have an answer today, just wanted thoughts on it. astearns: If we don't have opinions from the surprising-behavior browsers, do we know who to ask? Is there a Blink engineer we could talk about? emilio: What's webkit behavior? fantasai: Less interested in current behavior, want to know what we actually want. Changing now isn't going to be a compat question, as we don't have inset shadows yet, and the behavior changes are subtle for outsets anyway (but real) fantasai: So question is what authors want, what's possible to implement, and what's the intersection of those two. astearns: So I suggest we come up with that definition so impls have something to chew on astearns: I think you have the outline of possibilities, but not yet a firm decision on what authors would prefer fantasai: Right, it's just me and sebastian smfr: Is there prior art in InDesign or similar? astearns: I could go take a look astearns: This is not anything I've looked at before tho, not sure if Photoshop/etc behavior is necessarily what we want. I'll take an action to go look. fantasai: Might be interesting to ask people on those teams, who have probably thought about it smfr: I'd like to see some more artistic examples rendered with Chrome and Firefox in the issue, to show the bad behavior more clearly astearns: So let's take back to the issue and get more clarity on what we want to specify here. astearns: And I'll take an action to see if I can divine any intent from my company's tooling Text shadow spread corners -------------------------- github: https://github.com/w3c/csswg-drafts/issues/7250 smfr: Issue here is that when you specify spread on a text shadow, the only way UA can implement is by stroking a line with a wider width and shadowing the result. smfr: That has implications for corners and miters smfr: So we need impl experience, need to implement spread on text shadow and see if there are any problems, not sure if there are right now. astearns: I remember we specified increasing the padding of shapes to avoid these kind of spikes astearns: Do you think having a similar algo for shadows might make sense? smfr: Would have to see what that algo is smfr: Concern is that the font might be the one to specify the miter limit, but I don't think it does smfr: If you have a path, maybe the UA can decide the miter limit when drawing the path. Just want confirmation that it's implementable. astearns: Anyone with opinions, or people we shoudl tag? <TabAtkins> Without examples of what's up, no opinion here since I don't have enough context. fantasai: I'm happy to leave it undefined, just want to know what to put in the spec. astearns: Lacking opinions, think we should leave it undefined smfr: Might be okay to specify you get rounded corners. If we find it's impossible we can come back to it fantasai: Might be opinions on better ways to do it, looking at miter-limit prop or whatever. fantasai: Think I specced it as rounded corners because, at the time, seemed easiest to implement. <astearns> shape-margin solution: https://drafts.csswg.org/css-shapes-1/#shape-margin-property astearns: So maybe see if that's an implementable thing for shadows. smfr: Think it might be a little more complex than that description. Prefer to have it specified the way impls would do it, which is to stroke a path with a wide stroke width and use that edge to shadow astearns: I think there was an issue about shape-margin property too; if there's a better way to specify we can do it in both places astearns: I was trying in that section to be slightly vague to not restrict the particular algo smfr: Briefly playing with it, sometimes in some fonts you'd get a hole due to winding rules. smfr: Reason for impl experience, fonts have weird data. fantasai: So maybe we just make it undefined for now, and can define it with more impl experience smfr: Fine with that. astearns: proposed resolution is to leave it undefined for now, open to specifying it with experience later RESOLVED: Leave text-shadow spread details undefined right now, with possibility of specification later after impl experience CSS Text ======== Make U+0000 invisible? ---------------------- github: https://github.com/w3c/csswg-drafts/issues/7249 fantasai: Do we have Myles and jfkthame on the call? astearns: Have jfkthame, not Myles smfr: Can probably speak for Myles astearns: So we had previous resolution to make all the CC characters visible smfr: We had an issue on one Apple website, the text had U+0000 bytes in it smfr: I'm guessing it's not *that* uncommon to have 0 bytes by mistake, due to server bugs? But we'd probably be okay with no change. astearns: So you're suggesting close no change, and continue to specify they're displayed? smfr: Think that's okay unless we have evidence the problem is more widespread. emilio: I don't recall seeing issues with this in Nightly/Beta and we've had it for a long time jfkthame: Also think we should ship it. Do occasionally see characters show up in Nightly that are invisible elsewhere, but it's rare. jfkthame: And in all cases the users are better served by sites fixing their broken data fantasai: We'd previously discussed doing a coordinated ship of this behavior - that was years ago, guess this didn't happen? florian: Think we prepped coordinating but didn't pull the trigger. florian: Firefox impl'd, Chrome impl'd partially (but leaves it to the font to render), Safari didn't impl. astearns: But I think we can agree to resolve on this issue. astearns: Any objections to no change on rendering of U+0000? RESOLVED: No change astearns: What can we do to coordinate making this part of the spec interoperable? jfkthame: Think we need Blink to fix impl to not depend on the font's rendering. astearns: Do we know if there's a blink issue? jfkthame: There is, don't have it offhand <fantasai> Maybe send that issue link to chrishtr and he can coordinate? <TabAtkins> Yes, chrishtr is the right contact for coordinating this astearns: Suggest we find the issue number and post it here, see if we can get a response from Blink engineers smfr: We might be in a similar situation to Blink where it depends on the font, not sure smfr: But this seems rare enough that I don't think coordinating shipping is necessary, seems hard to do for us in WebKit anyway fantasai: I think we should open a separate issue for the coordination astearns: So we can close this issue with the resolution we got, and continue coordination discussion later on. text-align: match-parent on the root element with direction: rtl doesn't match browsers ---------------------------------------------------------------- github: https://github.com/w3c/csswg-drafts/issues/6542 florian: match-parent on text-align does as the name implies, matches the parent's alignment florian: Different form just inheriting, as the meaning of start and end might have switched if the direction switches. With match-parent it doesn't flip, it definitely matches the parent florian: So the question is what to do on the root. The spec has an answer that I think makes sense, but doesn't have interop. florian: But not sure I'm aware of significant real problems triggered by this, so if we have a sensible behavior in the spec that doesn't cause real issues I think it's okay to leave it as-is and consider non-compliance a bug, but zcorpan didn't see it that way fantasai: zcorpan wanted us to either change the spec to match impls, or get a commitment from browser engines that they want to fix this bug fantasai: My personal take is that this is a very low-priority fix, but it should be considered a bug so when someone is fixing that area of the code they could fix it too. fantasai: Don't think we should require anyone to prioritize fixing it. Super low priority, possibly lowest priority I've ever seen. But don't think we should change the spec, I think the spec is more correct. astearns: Assume there's not bugs filed on this? florian: Not sure. astearns: So part of zcorpan's request is to get bugs filed. I agree with him. fantasai: I can take an action to make sure bugs are filed. astearns: And once bugs are filed, we'll see if we can get evals from impls on the bugs themselves. astearns: But like fantasai said, don't think a timely fix is strictly required for this. fantasai: Well is it okay to close the bug, with the understanding that we have bugs filed and impls plan to fix it at some point? astearns: Right, let's file the bugs and get to the next part emilio: Gecko behavior here is intentional. I'd need to investigate why it's a special case, I didn't write the code. florian: That's relevant, if browsers have specific reasons for differing from the spec it would be good to report so we can see if the spec should reflect that. But if it's just accidental we should know that too, so we can be confident of keeping the current spec. astearns: So next step is writing bugs. CSS Color 5 & Images 4 ====================== Color functions and RCS: Are these features ready to ship? ---------------------------------------------------------- github: https://github.com/w3c/csswg-drafts/issues/7310 jensimmons: These are all part of Interop2022, are they ready to ship? Are specs good enough, or are they unstable? emilio: I'd love to ship some of these, but there's a lot of open questions emilio: I don't think there's any complete impl of these features. emilio: WebKit implements a bunch, but doesn't support currentColor at all. Gecko also has trouble with currentColor. emilio: There's some question about resolution timing that I filed last week. emilio: So don't think things are quite ready to ship yet. jensimmons: So question really is if the spec is gonna significantly change after shipping happens. jensimmons: I think your issue highlights that some things still need to be defined. Maybe we can make this a priority to finish the spec? emilio: Think that would be great. Haven't been working actively, been spending free time on it. emilio: I can tell from Firefox usage - we enabled color-mix() in trunk and it's used extensively, over a thousand uses immediately. emilio: So I think it would be great to prioritize. astearns: So we're at time, please put your thoughts in that issue. astearns: Agree I'd like to see one complete impl before making the decision that it's shippable. fantasai: Sounds like this isn't ready to ship *yet*, but we should try to get it there soon. emilio: What I'd love is to avoid interdependencies on these features. emilio: weinig commented that they'd prefer color-mix() to serialize with new color syntaxes unconditionally; I'm not opposed to that, but it requires us to have new colors to ship color-mix(). Makes me a little sad because it's more work to get this in the hands of authors, but they feel strongly about that. emilio: It'd be great to work out a way to minimize interdependencies so we can ship incrementally. <emilio> thanks for bringing this up jensimmons :) astearns: Please discuss on the list about the meeting next week.
Received on Wednesday, 25 May 2022 21:41:00 UTC