Re: [css-pseudo][css-ui] Allow to control selection width related to letter-spacing

On 2 February 2016 at 16:21, Sebastian Zartner <sebastianzartner@gmail.com>
wrote:

> On 2 February 2016 at 15:55, Jonathan Kew <jfkthame@gmail.com> wrote:
>
>> On 2/2/16 14:37, Sebastian Zartner wrote:
>>
>>> Use case: I have an input field, which has a background image visually
>>> putting each character into a box. When the text cursor is moved to the
>>> end of the field, i.e. after number 9, it moves the display of the
>>> numbers to the left, so that they don't fit into the boxes anymore. See
>>> this example:
>>>
>>> data:text/html,<input maxlength="5"
>>> style="box-sizing:content-box;width:17.1ch;border:1px solid
>>> black;background-image:repeating-linear-gradient(to right, transparent,
>>> transparent 1.72ch, gray 1.72ch, gray 1.82ch);padding:0
>>> 0.4ch;font-family:monospace;font-size:6ch;letter-spacing:0.8ch;"
>>> value="0123456789">
>>>
>>> So, what would be needed to get a better UX, could be either:
>>> - define that the letter spacing doesn't affect the last character
>>>
>>
>> FWIW, CSS Text already says[1] that "[l]etter-spacing must not be applied
>> at the beginning or at the end of a line".
>>
>
> Ah, good to know!
> Though I assume completely forbidding letter-spacing at the end of a line
> may also not be desirable, as that will result in the text cursor being at
> a different place than the character when you enter or remove one at the
> end.
>

Reading https://bugzil.la/125390 I realized that this is obviously a
long-standing issue.

As the behavior is obviously discussed controversially, what about
introducing some keywords to the syntax to control the behavior? E.g.
something like this:

    letter-spacing: [ normal | <length> ] [ inside || [ outside |
inline-start | inline-end ] ]?

This should cover all use cases. And according to the currently defined
behavior of "Letter-spacing must not be applied at the beginning or at the
end of a line." the default value would map to inside.

But AFAIK neither Gecko nor Blink currently implements this correctly per
>> spec.
>>
>
> Correct.
>

Btw. also Trident and EdgeHTML don't implement this correctly per spec. at
the moment.

Sebastian