[css-text-3] Hanging spaces can't be scrollable overflow

[fantasai]

We currently define hanging punctuation to be scrollable overflow, but it seems that hanging spaces can't be scrollable overflow, so we will need to define them as ink overflow at least.

Testcase: http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cdiv%20style%3D%22background%3A%20yellow%3B%20overflow%3A%20auto%3B%20width%3A%205.5em%3B%20font%3A%2020px%20Ahem%3B%20white-space%3A%20pre-wrap%22%3Ex%20x%20x%20x%20x

Chrome bug: https://crbug.com/966773

[frivoal]

I wonder if we should make it ink overflow in general, but switch to scrollable overflow when the element is editable. I'm don't like this kind of modal operation in general, but we seem to have conflicting needs here.

[kojiishi]

• Blink/WebKit makes them layout overflow only when contenteditable
• Gecko doesn't make them layout overflow regardless of contenteditable
• Edge makes them layout overflow regardless of contenteditable

[css-meeting-bot]

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

The full IRC log of that discussion

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

[css-meeting-bot]

The CSS Working Group just discussed hanging spaces, and agreed to the following:

• RESOLVED: Hanging spaces are ink overflow by default. UAs may make them scrollable overflow when they think that would be useful.

The full IRC log of that discussion

<TabAtkins> Topic: hanging spaces
<astearns> GITHUB: https://github.com//issues/4297
<TabAtkins> florian: We've discussed this before - should hanging spaces be scrollable or ink overflow?
<TabAtkins> florian: Conclusion last time was use-cases for both. Generally they're invisible and unnoticeable, invisible things triggering overflow is bad, so generally it should be ink overflow.
<TabAtkins> florian: But when text-editing, it's bad to move your caret into spaces and not see where you are, because there's no scrollbar and the caret is off the viewport.
<TabAtkins> florian: So I think when not-editing always ink, when editing always scrolalble.
<TabAtkins> florian: Some people objected that when not editting, selection still has value for scrollable overflow so you can see the bounds of your selection.
<TabAtkins> florian: So one possibility is to make that simple distinction. Another is to make a switch for it.
<TabAtkins> florian: I think we had general consensus that the switch is useful, but some, maybe emilio, were uncomfortable with this.
<TabAtkins> emilio: I still think it's weird, but...
<TabAtkins> florian: I think my preference is an automatic behavior that switches based on edittability.
<TabAtkins> florian: If we later think there are more situations, we can always add a proeprty *then* that defaults to "auto". I suspect we won't need it, but we're not locked out.
<TabAtkins> fantasai: I think we should define it as ink overflow, but UA *may* treat it as scrollable when the content is editable or UA thinks user would otherwise like to see it.
<TabAtkins> fantasai: So on static pages it'll never make scrollbars.
<TabAtkins> fantasai: But there's an allowance to improve usability on interactive.
<TabAtkins> koji: Do you remember what we did for hanging punctuation?
<TabAtkins> florian: Don't remember, but I think this should apply to both.
<TabAtkins> stantonm: I think we defined hanging punctuation as ink overflow, but I could be wrong.
<TabAtkins> jfkthame: It says "scrollable" at the top of the issue...
<fantasai> "A hanging glyph is still enclosed inside its parent inline box, is still counted as part of the scrollable overflow region [CSS-OVERFLOW-3], and still participates in text justification"
<TabAtkins> florian: Turns out the spec currently says hanging-punct is always scrollable, and there's a Chrome bug showing this is bad (too much scrollbars).
<TabAtkins> astearns: We might want to say it's ink overflow all the time, and respond to editting as we get bugs.
<TabAtkins> florian: For hanging punct, you don't have more than one punct sitting there, it doesn't overflow much anyway. But spaces, you can have a bunch.
<TabAtkins> heycam: When you're editting text, and ws is collapsed, you also don't get the cursor thru those.
<TabAtkins> heycam: So why is it important to cursor thru these?
<TabAtkins> florian: You can still see your caret in that case, it's not offscreen and invisible.
<TabAtkins> heycam: Why not just move the caret to the next line when it would overflow?
<TabAtkins> astearns: It breaks selection, you want to be able to select those.
<TabAtkins> heycam: You can select them, just not in the middle of them.
<TabAtkins> florian: So, scrollable-always breaks things.
<TabAtkins> florian: One option is "always ink"
<TabAtkins> florian: Second is "ink by defalt, UAs can determine when it shoudl be scrollable"
<TabAtkins> florian: Third is "ink when not editable, scrollable when editable"
<TabAtkins> fantasai: I like the second
<TabAtkins> florian: Hard to test, but maybe doesn't need to be tested.
<TabAtkins> florian: I can live with that.
<TabAtkins> astearns: So proposal is "hanging spaces are ink overflow by default, UAs can choose to make them scrollable overflow when it's useful"
<TabAtkins> [discussion about hanging punct]
<TabAtkins> stantonm: Are there implications about underlines?
<TabAtkins> stantonm: In our world (Kindle) we want puncts to hang outside the box, overlap is fine
<TabAtkins> fantasai: They'll still do that, yes.
<TabAtkins> astearns: Objections?
<TabAtkins> RESOLVED: Hanging spaces are ink overflow by default. UAs may make them scrollable overflow when they think that would be useful.