W3C home > Mailing lists > Public > public-css-archive@w3.org > November 2016

Re: [csswg-drafts] [css-text-4] Allow for paragraph-level line breaking

From: Florian Rivoal via GitHub <sysbot+gh@w3.org>
Date: Thu, 03 Nov 2016 08:27:53 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-258085513-1478161672-sysbot+gh@w3.org>
Right, that's kind of what I have in mind. At the same time, you 
suggestion to use text-wrap is quite reasonable also, as it seems the 
separate property would not do anything when `text-wrap` is `nowrap` 
or `balance`. so we could have a new value along the lines of 
`text-wrap: smart` or `text-wrap: smart-wrap` or `text-wrap: 
contextual-wrap` `text-wrap: paragraph-wrap`...

So, to decided if we need more values to the existing property or a 
new one:
* Which one gives the better fallback behavior when the new 
value/property is not supported, or when additional values are later 
added? Looks the same to me, in both case, you can use the cascade to 
provide your favorite fallback, and if you don't it falls back onto 
the default greedy approach

* Any compat constraint? I don't think so.

* Does the decision to wrap or not and the way to wrap look like 
separate decisions, that you may want to cascade separately? Maybe: 
you could decide to switch a the whole page to smart wrapping for any 
element that wraps, and pick between wrap and nowrap at a fine grained
 level. that would push for separate properties, but not that 
strongly, since text-wrap is inherited. You can still do `:root { 
text-wrap: smart;}` and selectively apply nowrap where it belongs.

All in all, I think I could go either way, but I now lean a bit more 
towards a value to text-wrap. And given that text-wrap has not been 
implemented anywhere yet I think, we can bikeshed the property name 
and existing values if needed to make everything fit better together.

GitHub Notification of comment by frivoal
Please view or discuss this issue at 
using your GitHub account
Received on Thursday, 3 November 2016 08:27:59 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:41:05 UTC