- From: Daniel Glazman <daniel.glazman@disruptive-innovations.com>
- Date: Wed, 9 Mar 2016 09:10:14 +0100
- To: www-style@w3.org
On 09/03/2016 02:09, Tab Atkins Jr. wrote: > "Why not" isn't a good reason to add things to a language. Additions > should have a strong justification behind them. Aliasing should only > be done when the name is *manifestly* wrong or confusing; imo, it > should only be done when we're *deprecating* the previous name as a > mistake. I don't think deprecating is an option at all. But, to reuse your own words and strong emphasis, we *manifestly* did not do things right when we chose list-* names and your proposal is to stick with it. We already have aliases for many property values (angles, color names, positions, etc.) because they increase human readability of the specified value and then maintenance of the stylesheet. In full theory, they're bloat and not needed. In practice, they improve CSS's industrial stability. That's the same here. > Aliasing because "sometimes it's more like this" just invites *more* > confusion, as people now have *two* names to refer to everything. > This gets *way* worse when there's a whole connected set of names > being aliased - it's really confusing if you can set "display: > block-with-marker; list-style-position: inside; marker-type: square;" > *and have it actually work together*. No. Here, the aliasing would be explicitely made to decrease the confusion, and possibly decorelate in the future list-item and has-a marker behaviours if we need it. And I'm pretty sure we'll need it at some point. </Daniel>
Received on Wednesday, 9 March 2016 08:10:41 UTC