schenney-chromium
commented
3 months ago As a reference point, chrome currently clips the caret when it hits the end of a run in a fixed width content editable div with horizontal text, then puts the next entered character on the next line. Or maybe it is painting it under the focus ring.
Firefox paints the caret on top of the focus ring.
But neither start a new line if the caret doesn't fit.
<!DOCTYPE html>
<html>
<head>
<style>
div {
width: 200px;
}
</style>
</head>
<body>
<div contenteditable="true">
This is a long horizontal string
</div>
</body>But if you remove the focus ring and set the padding to zero, the behavior changes in both browsers. As far as I can tell by messing with widths etc, both Chrome and Firefox consider the cursor part of the word and start a new line by breaking the line and starting a new one with the last word and the caret.
<!DOCTYPE html>
<html>
<head>
<style>
div {
width: 200px;
padding: 0px;
border: 1px solid black;
outline: none;
}
</style>
</head>
<body>
<div contenteditable="true">
This is a long horizontal string
</div>
</body>
</html>In the example above, it is possible to set the width so that the caret is rendered at the end of the line very close to the border. Then, reducing the width by one (the width of the caret) creates a new line with the last word and the caret. I can't find any code in chromium that would cause this, so it may be that effectively the cursor is currently shown at "width - 1" of the shaped text string. Such behavior would result in clipping of a block or underline cursor.
css-meeting-bot
The spec for caret-shape sensibly says that a caret at the end of a text run should paint to the right (in ltr, left in rtl) where the next character in a run would appear. But what should happen if there is no space to put the caret in the container at that location?
Options include: 1) Clip the caret. 2) Start a new line and put the caret on that line. 3) Paint the caret as close as possible to the edge, even if it overlaps the last character in the run. 4) Treat the caret as overflow and apply the overflow rules for the container.
Terminal programs on Mac and Linux, the things I can easily check, both exhibit behavior (2). There is no existing browser implementation other than maybe Opera (according to canIuse).
Igalia is considering a chromium implementation and this is a question that immediately comes to mind as a blocker.