Re: [csswg-drafts] [css-text][css-sizing] When to/not to include preserved trailing spaces (#3440)

The CSS Working Group just discussed `When to/not to include preserved trailing spaces`, and agreed to the following:

* `RESOLVED: preserved spaces from pre-wrap hang when they occur before a soft wrap, but would not hang when at the end of block or forced break`

<details><summary>The full IRC log of that discussion</summary>
&lt;heycam> Topic: When to/not to include preserved trailing spaces<br>
&lt;heycam> github: https://github.com/w3c/csswg-drafts/issues/3440<br>
&lt;heycam> fantasai: some discussion back and forth about how to handle preserved whitespace at the end of a line<br>
&lt;heycam> ... most recent resolution is that it hangs if it doesn't fit in the line box<br>
&lt;heycam> ... koji came back to say that doesn't make sense if you have a paragraph that is white-spcae:pre-wrap<br>
&lt;heycam> ... since then you will end up not justifying fully with the last visible letter to the edge of the container<br>
&lt;heycam> ... because if that white space happened to fit, it would be within the container, otherwise you wouldn't get a flush edge<br>
&lt;heycam> ... the discussion is now: should we say it's force hang instead?<br>
&lt;heycam> ... or do something else?<br>
&lt;heycam> florian: koji raised this only in the case of justification?<br>
&lt;heycam> ... on other alignments browsers were aligned, and you're not trying to change that?<br>
&lt;heycam> koji: for justification including trailing spaces it's clearly wrong<br>
&lt;heycam> ... for right and center, I'm neutral<br>
&lt;heycam> ... in those cases I can see both sides of the argumnet<br>
&lt;heycam> florian: I'm trying to understand the use cases better<br>
&lt;heycam> ... because I'm a little bit confused about whether it's in general OK, or already broken, to try to use pre-wrap on body text, paragraphs<br>
&lt;heycam> ... if you have source code that is pre, and you want to switch to pre-wrap to avoid overflow, that's fine<br>
&lt;heycam> ... if you apply pre-wrap to body text, there are some odd things that happne<br>
&lt;fantasai> I think this is why actually I made the comment in https://github.com/w3c/csswg-drafts/issues/3440#issuecomment-458783789<br>
&lt;heycam> ... links in the text are underlined, if your linked phrase have spaces, you'll have a hanging underlined space at the end<br>
&lt;heycam> ... so it's a bit strange, but I'm not sure<br>
&lt;heycam> ... don't know if we should try to support that more, in which case what you say about justificaiton is right<br>
&lt;heycam> ... or decide we don't really care about this, and not optimize for it<br>
&lt;heycam> ... maybe people want to use double space after a period?  that also feels into the category of not needing to try to support it<br>
&lt;heycam> ... so these are kind of at the edge<br>
&lt;heycam> ... of reasonable use of the properties<br>
&lt;heycam> fantasai: format=flowed plain text email is essentially pre-wrap text<br>
&lt;heycam> florian: but you don't rejustify it<br>
&lt;Rossen> q?<br>
&lt;heycam> ... if you try to preserve the format of the email, you don't go to justify it, since your alignments made with spaces will be broken by the justification<br>
&lt;heycam> fantasai: as far as trailing spaces underlined go, you can use text-decoration-skip<br>
&lt;heycam> ... I think it's a bit weird for something to hang for some operations but not others<br>
&lt;heycam> ... it might make more sense to say that if there is a soft break after a space, then that space force hangs<br>
&lt;heycam> ... for alignment, justification, everything<br>
&lt;heycam> ... but if there's a hard break, then that space does not hang<br>
&lt;heycam> ... for the use case of pre-wrap on an entire para, you're not going ot be ended it with a period, a space, a line break<br>
&lt;heycam> ... but for a line of text that happens to end with a space, then that would work<br>
&lt;heycam> florian: if we do force hang in that situation, what does it do for the max content size?  include the size of not?<br>
&lt;heycam> fantasai: max size is always unwrapped, so you include the spaces<br>
&lt;heycam> florian: what about space at the end of the paragraph?<br>
&lt;heycam> fantasai: then there's a force break right after it<br>
&lt;heycam> florian: ok<br>
&lt;heycam> fantasai: let's say you have a word a space a word another space, end of the block<br>
&lt;heycam> ... then you wrap in the middle of that<br>
&lt;heycam> ... so you have word space soft-break word space end of block<br>
&lt;heycam> ... if you were to right align that text, the space that is at the end of the block would not hang<br>
&lt;heycam> ... it's at the end of the bloc<br>
&lt;heycam> ... the space that is wrapped does hang<br>
&lt;heycam> ... when you left align you won't notice<br>
&lt;heycam> ... when you right align or justify you will see the first line's space hang<br>
&lt;heycam> ... generally you want spaces to disappear the end of line -- we can distinguish between these cases by whether there's a soft wrap there or not<br>
&lt;heycam> koji: I think that makes sense<br>
&lt;heycam> ... if other browsers are willing to match, I think we can try to match<br>
&lt;heycam> ... is Gecko happy with it?  I think xidorn wanted to include trailing spaces<br>
&lt;heycam> ... for right and center<br>
&lt;heycam> heycam: we can resolve and ping xidorn to get his opinion<br>
&lt;heycam> RESOLVED: preserved spaces from pre-wrap hang when they occur before a soft wrap, but would not hang when at the end of block or forced break<br>
&lt;heycam> florian: currently we say that spaces hang when they go beyond the edge of the block, browsers are allowed to discard them<br>
&lt;heycam> ... we key that off the fact they hang<br>
&lt;heycam> ... are we still allowed to drop the last spaces before the forced break, or also not allowed to do that<br>
&lt;heycam> fantasai: let's discuss that another day<br>
</details>


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

Received on Thursday, 28 February 2019 01:41:56 UTC