- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 17 Jul 2024 16:16:35 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[CSS-UI] caret-shape: block/underscore and overflow`, and agreed to the following: * `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.` <details><summary>The full IRC log of that discussion</summary> <fantasai> The reason we introduced Discontinued Draft was to have an IPR-safe place to park the draft.<br> <fantasai> FWIW<br> <TabAtkins> schenney: This is the only signif issue blocking Igalia implementing the feature<br> <TabAtkins> schenney: If you have a fixed-size container, and you're editing, and you have a block or underscore caret-shape<br> <TabAtkins> schenney: What happens when it gets to the end of the line and there's no space to draw the caret?<br> <TabAtkins> schenney: Spec isn't clear, I did some investigation but it's not clear what's happening.<br> <kizu> q+<br> <TabAtkins> schenney: My argument is for not drawing, or drawing what you can<br> <astearns> ack kizu<br> <TabAtkins> (+1 for drawing clipped; making a new line is wrong)<br> <TabAtkins> kizu: Firefox draws regardless and possibly clips<br> <TabAtkins> kizu: You can see that with overflow:clip on a parent<br> <TabAtkins> 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.<br> <TabAtkins> kizu: Easier if it still shows. Still *possible* to be invisible, but not common.<br> <TabAtkins> kizu: I think in general if we can draw the caret, perhaps on the border of the contnet, we should. Also agree that wrapping isn't a good idea.<br> <TabAtkins> astearns: So not really option 4 in the issue, but a new option? Treat teh caret as overflow regardless of overflow on the container?<br> <TabAtkins> kizu: No, more like focus-ring in Firefox. It's drawn over everything (but inside of browser chrome).<br> <TabAtkins> 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.<br> <TabAtkins> schenney: I'm coming around to thinking that is the best option. Anything creating a new line is def a bad idea.<br> <TabAtkins> 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.<br> <TabAtkins> emilio: I implemented this to be compatible with some Chromium quirks.<br> <TabAtkins> emilio: I can dig up some history, but yeah, it's not just "dont' clip the caret"<br> <TabAtkins> 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.<br> <TabAtkins> schenney: But that does seem like the best way to resolve this in the short term.<br> <TabAtkins> emilio: I suspect it interacts badly with scrolling and such if you scroll off the editable element entirely.<br> <flackr> +1<br> <TabAtkins> emilio: That's why I landed on that compromise in FF<br> <PaulG> (APA interest here) I agree not clipping (or limited clipping) sounds better.<br> <TabAtkins> [emilio's kid interjects with an important point]<br> <TabAtkins> emilio: I'd be suspicious with "not clip at all" even being compatible. Don't think it's most desirable either.<br> <TabAtkins> kizu: Just tested in codepen, FF is interesting.<br> <TabAtkins> kizu: Still seeing it painting outisde of a contain:paint<br> <TabAtkins> kizu: [another case]<br> <TabAtkins> astearns: Perhaps have a reoslution 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?<br> <kizu> I tested in CodePen: https://codepen.io/kizu/pen/oNrbYPP — Firefox' behavior is interested, where when there is overflow: auto, the cursor is visible on the edge, as if it was “sticky”<br> <TabAtkins> schenney: Yes, sounds reasonable to resolve on that and leave the issue open for details.<br> <TabAtkins> 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.<br> <TabAtkins> astearns: objections?<br> <TabAtkins> 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.<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10289#issuecomment-2233698993 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 17 July 2024 16:16:36 UTC