Re: [csswg-drafts] [css-text] What does the `white-space-collapse` apply to when white-space trimming/positioning (#9724)

The CSS Working Group just discussed ``[css-text] What does the `white-space-collapse` apply to when white-space trimming/positioning``.

<details><summary>The full IRC log of that discussion</summary>
&lt;emilio> andreubotella: we have hanging and conditionally-hanging glyphs<br>
&lt;emilio> ... you can only hang at the end of a line<br>
&lt;emilio> ... and you can have unconditional hanging spaces before hanging spaces<br>
&lt;emilio> ... in which case if you grow the size of the line box there'd be a point where you reach the end of the conditionally hanging spaces and then all the spaces hang<br>
&lt;emilio> ... I have a demo in the issue<br>
&lt;emilio> andreubotella: [screenshares https://github.com/w3c/csswg-drafts/issues/9724#issuecomment-1867809865]<br>
&lt;emilio> ... question is are we fine with that behavior?<br>
&lt;emilio> florian: this can happen with different white-space-collapse at the end of the line<br>
&lt;emilio> ... can't think of when this would happen in real content<br>
&lt;emilio> ... another alternative would be that unconditionally-hanging followed by conditionally-hanging spaces all behave as conditionally-hanging<br>
&lt;emilio> ... I don't think this matters in practice<br>
&lt;emilio> ... the demo makes it the more obvious interpretation of the spec<br>
&lt;emilio> ... I think we could do that<br>
&lt;emilio> q+<br>
&lt;emilio> ack bramus<br>
&lt;astearns> I think I prefer the proposal to propagating conditionality<br>
&lt;emilio> andreubotella: the reason this would be rare in practice is that in order to have unconditional hanging spaces _before_ conditional you need to have combination of these values and characters such as ideographic spaces<br>
&lt;emilio> florian: right, just a mix of ideographic and regular spaces won't cause this, you also need different white-space-collapse values<br>
&lt;TabAtkins> emilio: Unless this really matters for some use-case, I think this is fine<br>
&lt;TabAtkins> emilio: I'd be a bit skeptical of introducing this kind of "how you hang depends on how things after you hang" that Florian mentioned<br>
&lt;TabAtkins> emilio: so unless taht behavior is really important for some realistic use-case, I thinkw hat you suggest is fine<br>
&lt;astearns> ack emilio<br>
&lt;astearns> ack fantasai<br>
&lt;emilio> fantasai: I feel the second definition florian gave seemed simpler?<br>
&lt;emilio> fantasai: so I lean towards that<br>
&lt;emilio> ... but I agree it doesn't really matter in practice, so whatever is more straight-forward<br>
&lt;emilio> andreubotella: yeah I guess whether you hang at all depends on what's after or how you hang seems fine<br>
&lt;emilio> florian: what's harder to implement<br>
&lt;emilio> andreubotella: don't know off the top of my head<br>
&lt;emilio> fantasai: can ask internally<br>
&lt;emilio> ... agree to whatever is simpler<br>
&lt;emilio> astearns: So we can resolve either with whatever is simpler or with no change<br>
&lt;emilio> fantasai: can we put option a and option b together and just ask for impl feedback?<br>
&lt;emilio> florian: last comment in the issue does contain that but can clarify<br>
&lt;emilio> fantasai: let's get those options together and poll at the end of the F2F<br>
</details>


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


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 22 January 2025 18:00:21 UTC