Re: [csswg-drafts] [css-text-3] Hanging spaces can't be scrollable overflow (#4297)

The CSS Working Group just discussed `Hanging spaces cannot be scrollable overflow`.

<details><summary>The full IRC log of that discussion</summary>
&lt;emilio> Topic: Hanging spaces cannot be scrollable overflow<br>
&lt;emilio> Github: https://github.com/w3c/csswg-drafts/issues/4297<br>
&lt;emilio> florian: fantasai points out that if we treat hanging spaces as scrollable overflow there's a bunch of cases where we got scrollbars where we don't want<br>
&lt;emilio> ... but on editable stuff you want to create scrollable overflow<br>
&lt;emilio> ... blink and webkit agree with me, gecko always treats it as ink overflow, edge always layout overflow<br>
&lt;emilio> ... proposed resolution is treat hanging spaces as ink overflow in general but layout overflow in editable context<br>
&lt;emilio> fremy: how did you test for editable context<br>
&lt;emilio> ... you may be testing a different `white-space` due to UA rules<br>
&lt;heycam> emilio: it feels weird to special case layout based on editable context, whatever that is<br>
&lt;heycam> Rossen: why?<br>
&lt;heycam> emilio: there's no good reason for the layout engine to know the editable state of the DOM<br>
&lt;heycam> ... in Gecko this all works via UA sheets<br>
&lt;heycam> ... we change a bunch of stuff when something becomes editable, but it's explained through CSS properties<br>
&lt;heycam> ... specifying something like this seems quite awkward<br>
&lt;heycam> florian: make it specific to contenteditable only, and not other kinds of editable, would be weird<br>
&lt;heycam> ... but if it's all kinds of editable, and good old fashioned textarea, ....<br>
&lt;leaverou_> But it can be detected with CSS selectors<br>
&lt;heycam> emilio: if you do that, I would prefer to have some kind of CSS value that causes this effect<br>
&lt;heycam> ... and specify in HTML or whever that contenteditable and textarea input have this in the UA sheet<br>
&lt;heycam> florian: if you are editing the content, you never want to not reach the content<br>
&lt;heycam> ... if you are trying to edit/delete them, if the cursor moves where you can't see it, that's not desirable<br>
&lt;heycam> emilio: then the UA sheet can have an !important rule<br>
&lt;heycam> florian: if we define this how is it magical?<br>
&lt;heycam> emilio: what if it's something slotted into a contenteditable element?<br>
&lt;heycam> fantasai: the main thing that's happening here, if spaces are overflowing in the document, you don't want to create scrollbars for them<br>
&lt;heycam> ... when you're editing text, it's nice to be able to see the text<br>
&lt;heycam> ... I don't think authors care. don't think adding a CSS property, increasing the number of things authors could learn, is a benefit here<br>
&lt;heycam> emilio: sure<br>
&lt;heycam> fantasai: it makes sense to allow the UA to make it scrollable overflow when that piece of text is editable<br>
&lt;heycam> ... how you got to that state, doesn't really matter<br>
&lt;heycam> emilio: why only when it's editable, and not selectable?<br>
&lt;heycam> ... the caret movement is pretty much the same<br>
&lt;heycam> ... don't know why those owuld be different<br>
&lt;heycam> fantasai: the characters are still there, you can select if you go frmo one line to the next<br>
&lt;heycam> ... but there's a higher priority on not introducing scrollbars<br>
&lt;heycam> emilio: can we confirm Chrome is doing what you claim it is?<br>
&lt;heycam> florian: Elika pointed out, if this is awkward to do on the C++ thing, you can have the dedicated CSS value, and make it !Important, and not accessible to users<br>
&lt;heycam> emilio: I know how to implement it, just doing want it defined in a magical way<br>
&lt;heycam> -- end --<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4297#issuecomment-532131869 using your GitHub account

Received on Tuesday, 17 September 2019 09:05:10 UTC