- From: Florian Rivoal via GitHub <sysbot+gh@w3.org>
- Date: Thu, 03 Nov 2016 08:27:53 +0000
- To: public-css-archive@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
https://github.com/w3c/csswg-drafts/issues/672#issuecomment-258085513
using your GitHub account
Received on Thursday, 3 November 2016 08:27:59 UTC