- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 18 Jul 2024 18:31:57 -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. ========================================= CSS Containment & Conditional ----------------------------- - RESOLVED: Publish new WD of Conditional 5 (Issue #10433: Reorganizing the Containment specs) CSS UI ------ - RESOLVED: When the caret is past the end of a line, attempt to show the caret even if it overflow, with any necessary clipping behavior we end up needing to be specified later. (Issue #10289: caret-shape: block/underscore and overflow) CSS Text -------- - RESOLVED: Specify the -webkit-* values for text-align in the Compat spec (Issue #10388: Specify HTML alignment as text-align: -webkit-{left,right,center}) CSS Conditional --------------- - RESOLVED: Use `named-feature()` as the function name (Issue #9875: Choose names for keyword-based feature queries in @supports and names for initial set of queries) - RESOLVED: Call the keyword `align-content-on-display-block` (Issue #9875) CSS Font Loading ---------------- - RESOLVED: Delete FontFaceSet constructor from the spec (Issue #10390: Remove the FontFaceSet constructor?) CSS Images ---------- - RESOLVED: Move the missing position fixup to computed value time (Issue #10374: Gradient interpolation doesn't specify how to handle positionless stops at computed-value time) CSS Selectors ------------- - The group wasn't ready to close issue #3080 (Do we need :focus-visible-within?) yet, but agreed to remove it from call agendas until there is more discussion in the issue as to if the use case can be covered by shadow dom or not. CSSOM View ---------- - RESOLVED: Add .width and .height as doubles to the layout viewport interface (Issue #5260: No way to access the viewport size without losing precision) ===== FULL MEETING MINUTES ====== Agenda: https://lists.w3.org/Archives/Public/www-style/2024Jul/0005.html Present: Tab Atkins Kevin Babbitt David Baron Stephen Chenney Keith Cirkel Emilio Cobos Álvarez Robert Flack Paul Grenier Chris Harrelson Daniel Holbert Jonathan Kew Ian Kilpatrick Roman Komarov Chris Lilley Alan Stearns Brandon Stewart Miriam Suzanne Regrets: Rachel Andrew Yehonatan Daniv Elika Etemad Noam Rosenthal Khushal Sagar Lea Verou Chair: astearns Scribe: TabAtkins Scribe's scribe: emilio CSS Containment & Conditional ============================= Reorganizing the Containment specs ---------------------------------- github: https://github.com/w3c/csswg-drafts/issues/10433#issuecomment-2231498564 miriam: We resolved earlier to move CQ out of containment and into conditional miriam: That has meant, so far, that what has happened is CQ were removed from Contain and repubbed, but Conditional hasn't been repubbed yet. miriam: So CQ doesn't exist outside of ED right now, which seems wrong miriam: Seems we should publish Conditional miriam: I don't know what else has happened in Conditional 5, dunno if I'm the right person to comment on if we can do that right away ChrisL: I've gone through the changes on Conditional, doc is ready to be published <ChrisL> +1 astearns: Proposed resolution to publish new WD of CSS Conditional 5 astearns: Objections? RESOLVED: Publish new WD of Conditional 5 astearns: There was some discussion about whether we do Conditional 3 as a retired draft astearns: I think its current state (just a parking doc that says "go look at Conditional 5") is fine. We can worry about it later. astearns: Any concerns with no action? ChrisL: Not a concern, but unsure about consequences if we retire and then want to repub with something in it. Should know, but I don't. I think "no action" is fine. astearns: Yeah, expect a discontinued draft being re-continued hasn't happened before. astearns: So let's leave Contain 3 as it is. <fantasai> The reason we introduced Discontinued Draft was to have an IPR-safe place to park the draft. <fantasai> FWIW CSS UI ====== caret-shape: block/underscore and overflow ------------------------------------------ github: https://github.com/w3c/csswg-drafts/issues/10289 schenney: This is the only significant issue blocking Igalia implementing the feature schenney: If you have a fixed-size container, and you're editing, and you have a block or underscore caret-shape schenney: What happens when it gets to the end of the line and there's no space to draw the caret? schenney: Spec isn't clear, I did some investigation but it's not clear what's happening. schenney: My argument is for not drawing, or drawing what you can <TabAtkins> (+1 for drawing clipped; making a new line is wrong) kizu: Firefox draws regardless and possibly clips kizu: You can see that with overflow:clip on a parent kizu: I think I like this better, if it's on the edge of a container and it's clipped by overflow, the user can't see the caret. kizu: Easier if it still shows. Still *possible* to be invisible, but not common. kizu: I think in general if we can draw the caret, perhaps on the border of the content, we should. Also agree that wrapping isn't a good idea. astearns: So not really option 4 in the issue, but a new option? Treat the caret as overflow regardless of overflow on the container? kizu: No, more like focus-ring in Firefox. It's drawn over everything (but inside of browser chrome). astearns: With chair hat off, I'm also in favor of not clipping the cursor. If you clip it it might not look like a cursor even if partially drawn. schenney: I'm coming around to thinking that is the best option. Anything creating a new line is definitely a bad idea. emilio: Clarifying firefox - it doesn't skip clipping arbitrarily, it's just drawn by the containing block of the element. So it'll skip *some* clipping but not all. emilio: I implemented this to be compatible with some Chromium quirks. emilio: I can dig up some history, but yeah, it's not just "don't clip the caret" schenney: So one option is we can try implementing with not clipping, and see what happens. I suspect it's problematic, because clip is applied to the container. schenney: But that does seem like the best way to resolve this in the short term. emilio: I suspect it interacts badly with scrolling and such if you scroll off the editable element entirely. <flackr> +1 emilio: That's why I landed on that compromise in FF <PaulG> (APA interest here) I agree not clipping (or limited clipping) sounds better. emilio: I'd be suspicious with "not clip at all" even being compatible. Don't think it's most desirable either. kizu: Just tested in codepen, FF is interesting. kizu: Still seeing it painting outside of a contain:paint kizu: [another case] <kizu> I tested in CodePen: https://codepen.io/kizu/pen/oNrbYPP — Firefox's behavior is interested, where when there is overflow: auto, the cursor is visible on the edge, as if it was “sticky” astearns: Perhaps have a resolution to attempt to show the caret in full, in the case this issue talks about, but leave open exactly what the clipping behavior is until Steven has time to work things out? schenney: Yes, sounds reasonable to resolve on that and leave the issue open for details. astearns: Proposed: when the caret is past the end of a line, attempt to show the caret even if it overflow, with any necessary clipping behavior we end up needing to be specified later. astearns: Objections? RESOLVED: When the caret is past the end of a line, attempt to show the caret even if it overflow, with any necessary clipping behavior we end up needing to be specified later. CSS Text ======== Specify HTML alignment as text-align: -webkit-{left,right,center} ----------------------------------------------------------------- github: https://github.com/w3c/csswg-drafts/issues/10388 emilio: Websites try to depend on this -webkit value being exposed emilio: Right now nobody implements the justify-items:legacy stuff emilio: My original idea was to just spec reality here, which is a bit underwhelming emilio: but I'm okay trying to implement justify-items emilio: But we'll probably need to keep the -webkit value for compat emilio: So we should probably choose to spec -webkit-left/right/ center either in Alignment or Compat (probably Compat), and let browsers implement Alignment eventually TabAtkins: So your proposal is we spec the -webkit in Compat, and have HTML refer to those, and later see if we can compat-wise fix to Alignment? emilio: Yes. We can possibly have HTML refer to Alignment. TabAtkins: I don't think HTML would take a patch for features that aren't implemented yet. emilio: Yeah, possibly. astearns: So two steps. First, add -webkit value to text-align because we have to, not because we want to. emilio: Yes, because widely depended on astearns: But then a little unclear what the second step is astearns: Oriol talks about using justify-items:legacy opting into those values, but I thought the point was sites depending on the values without using justify-items emilio: Right, you have to support the text-align values anyway. emilio: So my preference is to keep them both defined, and then start with having HTML referring to the text-align values, and later switch to justify-items once implemented dbaron: This sounds reasonable to me dbaron: Given that everyone does the same thing, and it's not completely clear what the space of changes we can make compatibly *is*, it seems reasonable to spec what we currently have, maybe with a note about what we want to change it to in the future. dbaron: This legacy thing is defined in a way that's supposed to deal with this issue, but it's not clear, for example, how much pages depend on this actually working via text-align dbaron: Because for example you can override this inherited behavior by setting another value on text-align. We need to see if that's something that's ok to break. dbaron: So I'm supportive of moving closer to reality. iank: dbaron just said what I was gonna astearns: so proposed resolution is: specify the -webkit value for text-align, with a note about what we'd like to do in the future emilio: I think we should specify them without a note, and have HTML take the note about the intended migration dbaron: Sounds fine. TabAtkins: Specify in Text or in Compat? astearns: Compat sounds slightly easier to quarantine emilio: Sounds fine, don't mind either way RESOLVED: Specify the -webkit-* values for text-align in the Compat spec. astearns: Who's doing the HTML patch? emilio: I can. CSS Conditional =============== Choose names for keyword-based feature queries in @supports and names for initial set of queries --------------------------------------------------------------------- github: https://github.com/w3c/csswg-drafts/issues/9875 dbaron: About six months ago we had a discussion about adding a mechanism for one-off things in @supports that don't have an existing structure to fit in dbaron: To solve some known problems that would otherwise be complicated to deal with. dbaron: We resolved to do it, but not on what to call the things dbaron: I opened an issue about naming, it has not had much discussion, but I have proposed names in the issue dbaron: There was a bunch of disagreement about naming the last time we discussed it dbaron: It seems like the sort of thing that might be easier in an issue but nobody was commenting, so telecon it is dbaron: Proposal is to call the query function `feature()` dbaron: And calling the feature for css alignment on blocks as `align-content-on-display-block` dbaron: I'm okay with resolving today or taking it back to the issue, as long as someone actually comments in the issue astearns: The bit that's possibly not changeable is... dbaron: It just might be less useful because the thing we want to detect has already been shipping for a while. So might not be useful/accurate. astearns: I agree with the commenter that feature() isn't great, think named-feature() is slightly better. But don't have a strong opinion. <kizu> +1 astearns: But since this isn't meant to be a very used feature, I think a longer name is fine dbaron: Fine with named-feature() <TabAtkins> No opinion from me; lean slightly toward just feature(). keyword seems fine miriam: I think this is useful, having it matters more to me than bikeshedding it. Happy with these proposed names schenney: I'm in favor of named-feature(), makes it clear you're looking for a special name astearns: We can resolve on named-feature() and see if anyone complains afterward astearns: proposed resolution is to use named-feature() RESOLVED: Use `named-feature()` as the function name astearns: Do you want a resolution on the keyword too? dbaron: We should resolve on the name, then figure out if we still want it astearns: Proposed resolution: call the keyword `align-content-on-display-block` RESOLVED: Call the keyword `align-content-on-display-block` CSS Font Loading ================ Remove the FontFaceSet constructor? ----------------------------------- github: https://github.com/w3c/csswg-drafts/issues/10390 TabAtkins: So we have a crbug tracking the missing FontFaceSet constructor TabAtkins: but there's not a lot of reasons to have it TabAtkins: I agree, at the time I wrote the spec I was of the thought that magic interfaces were a smell TabAtkins: so I put it in on the assumption that it could be useful TabAtkins: but the only useful thing is calling .check() TabAtkins: so fine with removing it, a one-liner in the spec emilio: Agree with Tab, and also WebKit's the one that wanted to remove it at the time foolip filed the issue. It actually caused trouble for them emilio: So it's unanimous agreement. RESOLVED: Delete FontFaceSet constructor from the spec CSS Images ========== Gradient interpolation doesn't specify how to handle positionless stops at computed-value time ----------------------------------------------------------------- github: https://github.com/w3c/csswg-drafts/issues/10374 TabAtkins: Right now images defines fixup steps to supply default positions and shift stops that are mis-ordered TabAtkins: The second one requires layout-time information TabAtkins: so that step has to happen at used value time TabAtkins: for simplicity at the time I put all the fixups over there TabAtkins: But that means that stops without a position don't have a position at computed value time when interpolating TabAtkins: And there's no reason for doing that, can be done at computed-value time TabAtkins: Proposal is to split the fix-up between computed-value and used-value time fixup TabAtkins: where computed fixup would assign positions TabAtkins: and used would reorder fixups <ChrisL> q+ to wonder what the syntax is for the interpolated value ChrisL: What do you actually get? TabAtkins: Just calc()s TabAtkins: Just evenly spacing the missing values astearns: So proposal is moving the missing position fixup to computed value time emilio: My concern is - to be clear, I think every browser does this at used-value time right now emilio: This changes the computed value serialization in a somewhat non-trivial way, hope this isn't an issue emilio: this is potentially a concern TabAtkins: I haven't done a test to see if browsers currently interpolate missing positions or not TabAtkins: I think the gradient interpolation text doesn't take that into account TabAtkins: The serialization one is a meaningful change, we can fix that if it becomes a problem emilio: At that point you could just change the interpolation algorithm right? TabAtkins: Yeah that'd probably be better ChrisL: If we're fixing this this, I think a one-stop gradient would go to a 50% rather than 0 or 100% TabAtkins: Happy to take that up but let's do this resolution first <ChrisL> OK, the other issue is #10092 <ChrisL> https://github.com/w3c/csswg-drafts/issues/10092#issuecomment-2230892477 RESOLVED: Move the missing position fixup to computed value time emilio: Does this _need_ to happen at computed value time? Could be done at parse time right? TabAtkins: Yeah, but we usually don't do this at parse time emilio: Yeah just wanted to clarify whether it could be done or I was missing anything ChrisL: Just wanted to make sure we didn't stomp on the other resolution TabAtkins: Yeah it doesn't matter very much CSS Selectors ============= Do we need :focus-visible-within? --------------------------------- github: https://github.com/w3c/csswg-drafts/issues/3080 astearns: Brian added a comment just asking to close the issue (and open a different one about shadow dom) dbaron: I think we should punt, people missing probably have strong opinions astearns: Would be great if those strong opinions were written in to the issue emilio: I know focus does propagate out from shadow trees emilio: :has() mostly covers this, just not when shadow dom is involved emilio: And for that, :focus works, but :focus-visible... probably not? emilio: I think moving it out of the shadow tree would cause undesired outlines emilio: So main question is if people are having to work around this with JS we probably want something like this, but... emilio: I don't see a way of making it work with shadow dom emilio: Slightly against closing because there's a use-case that seems valid, and don't see how it can be addressed without this astearns: So punt on this today. Keep the agenda tag on it? or solicit opinions first? astearns: Slightly inclined to take the tag off dbaron: I think taking it off is fine, though I think I'm in the opposite camp of Brian (I think we should add it) CSSOM View ========== No way to access the viewport size without losing precision ----------------------------------------------------------- github: https://github.com/w3c/csswg-drafts/issues/5260 emilio: We've discussed in the past, making innerWidth and innerHeight not round is not compatible, it breaks things emilio: but we recently decided to add an object to the Window that represents the layout viewport (mainly for segments stuff) emilio: But it sounds like a good place to expose the full double-precision viewport dimensions emilio: So they'll do the same as innerHeight/Width, but without the weird rounding <flackr> +1 emilio: Proposal is to add ... unsure if we decided it to be window.viewport or window.layoutViewport, but whatever, add .width and .height astearns: Idle thought that maybe this should have a slightly different name to indicate it shouldn't be rounded, but nevermind, that sounds awful emilio: Before we had this new object, best proposal I could come up with was .innerWidthDouble or .innerWidthUnrounded emilio: but those are bad emilio: MDN and the spec could have a note about the difference flackr: Another bad alternative would be to have a gBCR() api on one of these objects, those also return doubles emilio: Right, but top and left would be 0 always flackr: You *could* imagine them being the scroll position... astearns: That sounds worse emilio: There's other issues to expose the other layout viewport things (small/big/etc) emilio: But I think .width and .height should do the right thing. emilio: And consider other names for the small/large viewport sizes astearns: Anyone remember if it's .viewport or .layoutViewport? emilio: I think we punted on the name in the previous call astearns: So proposal is to add .width and .height as doubles to the layout viewport interface RESOLVED: Add .width and .height as doubles to the layout viewport interface TabAtkins: When we have these box sizes, I'm always confused about whether they have scrollbars or not, do we need variants to account for that? emilio: I think right now the way to do that is document.scrollingElement.scrollWidth, or clientWidth emilio: Which I agree isn't great emilio: I'm also not sure if those round or not off the top of my head emilio: but gBCR() gets around it emilio: We should have a separate issue TabAtkins: Agreed
Received on Thursday, 18 July 2024 22:32:31 UTC