Each of the points below have lived on a whiteboard in my house for months. I see them each day as I think about how CSS can be extended, and what the best way to design extensions to the web platform are, and I think there's truth inside them that can help you avoid some of the pitfalls others have encountered when trying to extend languages.

1. Don't camp on platform names as you extend

This means as you're trying to add new features to a language, avoid using any syntax that could possibly ever be added to the language you're working with in the future.

Example: Some CSS preprocessors have had issues with min() and max() support in CSS because they invented their own min() and max() functions to do something slightly different. Oops!

2. Don't try to predict the future

This means build what you need today and support what you need to support, but don't try to predict what will be standardized in the future, and doubly extra-don't tell people they're 'writing future syntax today'. The future is hard to predict and sometimes one person's misunderstanding can propagate through to an entire industry.

Example: CSSNext claimed to let you use tomorrow's CSS syntax today, and much of the CSSNext functionality was based on a misunderstanding of a dead specification for @apply. There was a dream spec for something called @apply that was only ever intended for ShadowDOM, and the author realized it was flawed and killed it - but not before it was taken and mistakenly applied to light DOM, and thousands of developers got into the habit of using this dead, never-proposed shadowDOM-only feature in a way that was never intended. Now the entire CSSNext project and all code written with it has been deprecated, and 'postcss-preset-env' now claims to let you use tomorrow's CSS today, this time without @apply. Oops!

3. Prefer HTML/CSS/JS over custom syntaxes

The specifications for what valid HTML is, or what valid CSS is, or what valid JS is are published. You can look them up and build a parser that successfully parses these languages. However many tool makers don't do this. Famously, SCSS struggles with just about every new CSS feature that gets added, and based on the limitations of its design and the features we know are coming down the CSS pipeline, we can expect many more breaking changes to come.

Example: SCSS isn't a superset of CSS but is a CSS-like language that can be parsed into CSS. But it also chokes on perfect valid CSS syntax as well, h1 { font-size: max(10px, 1vw); } is a simple example, and if you say "Hey that's valid, but it's a new feature!" fine, this also breaks it and it's been around for years: @supports (--general-enclosed()) { html { background: lime; } } Oops!

4. Abstract HOW you do, not WHAT you do (aka abstract your process, not your product)

When extending a language, don't abstract the pieces you're working with to the point that it's not obvious what's going on, automate your labour but keep your workflow close to the thing you're actually working on. Let your abstraction carry you effortlessly to the place where you need to do your work for maximum effectiveness, rather than trying to abstract the work away from you.

Example: Some CSS-in-JS systems abstract styling so far they're almost impossible to debug, because what you as the author are typing to conjure up styles on an element and the styles that are being put onto the element have little relation to each other. You're not using the tool to help you make your work easier, you're at the mercy of whatever the tool lets you do. Oops!

1,668 0 6