- From: SelenIT via GitHub <sysbot+gh@w3.org>
- Date: Fri, 09 Jun 2017 15:37:00 +0000
- To: public-css-archive@w3.org
> then we could have syntactical equivalences Yes, they would be _functionally_ equivalent, but the clear and intuitive _naming rule_ "for any X, `inline-X` becomes `inline X`, just replace hyphen with space" would still break, it would feel "unnatural" and it would perpetually confuse developers (especially beginners). Having `block` as an internal display value could restore this naming consistency and fix the blockification issue at the same time (but possibly introduce some parsing difficuilties, although I don't see big problem here). I don't like the `flow-abracadabra` values because they seem to me contradicting the Priority of Constituencies principle ([from HTML](https://www.w3.org/TR/html-design-principles/#priority-of-constituencies), but IMO it's applicable to CSS development as well). This name splitting effectively makes some technical things easier for the spec writers, but otherwise these names doesn't have much meaning for the average CSS author. I have an impression that even the "flow" concept itself is not very intuitive for many of them, people tend to think of inlines and blocks as of two clearly distinct layout modes. And it would be not easy to explain somebody who just started studying CSS why under the same circumstances `inline-table` becomes `table`, `inline-grid` becomes `grid`, but `inline-block` suddenly becomes some _mumbo jumbo_ which, after some _magic_ applied, still effectively converts to `block`. This "magical" step clearly feels a redundant entity to me. The `flow-root` value has at least a practical meaning per se, it solves a real problem that many CSS authors often face. Unfortunately I can't say the same about the new proposals. -- GitHub Notification of comment by SelenIT Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1496#issuecomment-307422922 using your GitHub account
Received on Friday, 9 June 2017 15:37:06 UTC