W3C home > Mailing lists > Public > public-css-archive@w3.org > September 2018

Re: [csswg-drafts] [css-overflow] ensure interactions between block-overflow and text-overflow are defined

From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
Date: Wed, 19 Sep 2018 16:58:35 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-422879246-1537376314-sysbot+gh@w3.org>
The CSS Working Group just discussed `block-overflow and text-overflow`, and agreed to the following:

* `RESOLVED: text-overflow affects non-breakable portions of the block-overflow string`

<details><summary>The full IRC log of that discussion</summary>
&lt;astearns> topic: block-overflow and text-overflow<br>
&lt;astearns> github: https://github.com/w3c/csswg-drafts/issues/2882<br>
&lt;emilio> florian: so the issue is about whether their interaction is well-defined. There's only one case where it's not defined.<br>
&lt;emilio> florian: if you have a break opportunity during the line we'll insert the ellipsis after that break opportunity and block-overflow doesn't have  the chance to apply<br>
&lt;emilio> florian: the only case where it's not defined is where the ellipsis is longer than the whole line, right now the spec doesn't define it<br>
&lt;emilio> florian: seems like we don't want the ellipsis to climb the line back up, so for now I think we should go for 'when the ellipsis is longer than the line then it does overflow, and text-overflow must apply'<br>
&lt;emilio> tantek: I think we need an example that we could look up<br>
&lt;emilio> florian: it's something like a very narrow paragraph with a very long block-overflow ellipsis<br>
&lt;emilio> florian: the spec says that if block-overflow ellipsis overflows then it may overflow to the next line, but it's undefined<br>
&lt;emilio> tantek: any implementation experience?<br>
&lt;emilio> tantek: we should construct some examples and experiment, keeping the issue open for now<br>
&lt;emilio> tantek: rather than spec something that is not easy to implement<br>
&lt;dbaron> It seems like "use multiple lines for the block-overflow indicator" is probably the better behavior from a user perspective, but it does seem hard to implement.<br>
&lt;emilio> fantasai: seems fine to leave it open as people implement it<br>
&lt;emilio> florian: so I'd expand on the proposal with examples in the issue<br>
&lt;emilio> florian: I'm ok with that<br>
&lt;emilio> dbaron: [what he wrote above]<br>
&lt;emilio> dbaron: saying that it needs to fit on one line definitely makes implementation easier, but it's not clear how much<br>
&lt;emilio> tantek: I'd prefer to specify the better behavior for the user, and we don't know how much harder it is<br>
&lt;emilio> fantasai: so what we're hearing is that we should the issue open to wait for block ellipsis breaking across multiple lines, but we probably should say that if the block-overflow string still doesn't fit withing the block then text-overflow applies in that case as it would to any other text<br>
&lt;emilio> astearns: I like the idea of working out concrete examples so that people get better idea, but also so that we can put them in the spec<br>
&lt;emilio> florian: does it sound reasonable to resolve on what fantasai said and add examples for the block-ellipsis on multiple lines?<br>
&lt;emilio> fantasai: I think we should resolve that text-overflow applies to the overflow string if there's an unbreakable string on it like it does to the rest<br>
&lt;emilio> fantasai: also that we should put some example in the spec about this interaction, and also on the issue about what happens if the block-overflow string can break<br>
&lt;emilio> fantasai: we could narrow down the behavior as 'either you treat is as unbreakable' or 'treat it as breakable and grab space from previous lines'<br>
&lt;emilio> astearns: so the first bit is to resolve that text-overflow affects overflowing, unbreakable portions of the block-overflow string. objections?<br>
&lt;emilio> RESOLVED: text-overflow affects non-breakable portions of the block-overflow string<br>
&lt;emilio> astearns: probably the examples doesn't need a resolution<br>
&lt;emilio> astearns: we're going to work on those to put them on the spec<br>
&lt;emilio> florian: I'm going to put examples in the spec on what we just resolved, and then in the issue about the wrapping<br>
&lt;emilio> astearns: should that be a different issue?<br>
&lt;emilio> florian: maybe, sounds reasonable<br>
&lt;emilio> astearns: we'll leave it to your discretion<br>
&lt;emilio> florian: should we resolve on the breaking to narrow it down to the two discussed options?<br>
&lt;emilio> astearns: don't care<br>
&lt;emilio> florian: I think I prefer to leave as-is for now<br>
&lt;emilio> florian: then we can narrow if we don't resolve soon<br>
&lt;emilio> astearns: I think that's reasonable, I prefer to resolve soon, the examples would be really helpful<br>

GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2882#issuecomment-422879246 using your GitHub account
Received on Wednesday, 19 September 2018 16:58:37 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 19 September 2018 16:58:37 UTC