Hacker News new | past | comments | ask | show | jobs | submit login

Ah, yet another CSS extension that adds variables and mixins. At some point, shouldn't some of these projects come together, and say "we ought to standardize this?" I realize that the CSS working group is against adding variables and mixins to the standard, but given that there are now at least three prominent (and incompatible) implementations (Less/Sass/Google Closure), it seems like it's time to fork the standard (like the WHATWG did), standardize something, and then see if you can roll that back up to the W3C (or ignore the W3C if you can't get them to accept it).



Unless it's the standards group that's going to standardize it (which like you say is unlikely), what exactly is the advantage of the projects getting together to "standardize"? It may seem good to the average end developer, simply because there's fewer deliberation to be made, but I suspect the "competition" is probably a net positive for everyone.

The way most of these things go is that over time, either one of the projects becomes the de facto "best one," and the other projects eventually fade away, or two or more projects make some significantly different choices and thus branch off in multiple directions, each with its own community of contributors and users.


I think at this point we really don't need more of these CSS supersets but more comprehensive CSS frameworks like Compass and web framework integration with these CSS frameworks, i.e middlewares and asset management tools. I for once would love to see Compass ported to Less.


Well, yes, that's my point. We don't need more CSS supersets, we need fewer; one standard one, that is called "CSS" (or "CSS4" or whatever). That, then, can be the target for frameworks like Compass, instead of them targeting CSS 2.1/3 or targeting only a single CSS superset like Less, Sass, or now Closure.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: