notecss
TcsS - Typed Cascade Style Sheets
Why hasn't this been made yet? CSS has all the type information needed to create a comparable experience to TypeScript.
@argyleink vanilla-extract is probably the closest thing, but like, it's not CSS at that point. it's TS.
someone needs to make a superset of CSS (like SCSS) with types and autocomplete, especially for things like gradients and shadows.
it could also be built into CSS maybe. i've also asked for this multiple times in surveys. the closest thing we might have is `@property` but that's only for custom properties
Mayank :verified:
@argyleink ...because "it's not a programming language" ... ?
ppk 🇪🇺
@argyleink Preface: I haven't read your article yet.
Would something like typed CSS solve a commonly had issue?
jerry
I think @jon_neal made this for VSCode at some point. Unsure what the status was, but it looked awesome. Isn't all the needed data available in npmjs.com/package/@webre… This feels like something that could be generated from existing data.romainmenke
Lots of thoughts/questions here. While this would help a lot, to provide a comparable experience to typescript would mean a lot more than linting declarations. What about referencing selectors across file boundaries? Understanding where in the cascade each stylesheet is loaded?@chancethedev@mas.to
CSS can be loaded in so many ways, how could a type system understand that a given variable is defined or not?
Seems like you could pull a semi-strong-ish type checker off if it enforced cascade layers, but without them it would still feel pretty brittle trying to figure out which selectors are safe to use in a given context. And that’s always the bigger challenge IMO!
That's what styled-ppx is capable of. When it gets more mature, probably time to make it work in TS?David Sancho
@argyleink I’m kind of shocked that it never occurred to me to wonder about this. I suspect that back in the day I simply internalised browsers’ *application* of CSS as a black box that one reasons about indirectly?
Oliver
@argyleink If there was ever a moment that was ripe for such an intervention, this is certainly it!
What would be the mechanism for such a check do you think? What would a validator query against?
@argyleink That would certainly be a spicy way to hold vendors to account for their implementations 😀
@argyleink More seriously, that actually makes perfect sense: you can literally type-check syntax & values
@argyleink please no. We are *just* getting to where CSS has absorbed enough from SCSS that we can finally get rid of pre-processors.
Half of the measure of progress of core web tech is being able to finally bin the bullshit stack required to compile “how we write it” into “what we wrote”.
Hard pass.
Matt Wilcox
Oooo if anyone is interested in collabing on this, I've done a good deal of work in the CSSTOM (CSS Typed Object Model) and even own a handful of domains in the space 😅 So down 👏🏼Brandon McConnell 🇺🇦✊
If only my name was Tom, I could make a whole brand around this. Hey there, I'm CSS Tom 🙋🏻♂️ Although, maybe that can be the mascot 👀
That is something I am thinking a lot about lately! CSS deserves much more love from us! The same way as TypeScript changed JS, Typed CSS can change CSS! @hi__mayank made a great first step towards better CSS tooling already!Szymon Pajka
僕もTypescriptの流れで型重視のCSSを作る人が出てきそうと思ったことあるけど、大体の人がCSSを適当に書いてるから... nerdy.dev/tcss久保 知己
@argyleink I think it's a pretty difficult lift when you get into details. Do we need to know the unique syntax of 700+ properties? How do we keep that up to date? Do we track browser support? Are we only checking value types, or also valid values? Both 'grid' and 'gord' are the same 'ident' type, but only one is a value for display.
And after solving all that, you're still limited to parse-time errors, unless you implement DOM & cascade. At which point you have a full browser… with dev tools.
Miriam Suzanne
@argyleink Pre-processors & linters do some of these things that don't require maintaining a database of all possible properties/values. And it might be reasonable to write a Sass library with validation wrappers for CSS functions. Sass core does that with eg CSS color functions. But that all falls apart once custom properties/currentColor get the cascade involved.
PostCSS might be able to validate custom prop syntax against against `@property`? Again, that only gets you part way.
Totally agree. Typed CSS could help with repetitive classes and suggest naming conventions based on a file's rendered structure.Shashi Lo
@mia @argyleink all I really want now is stroke-linecap: gord
Adam Kuhn
@cobra_winfrey @argyleink If we slip it into a spec, will anyone notice?
Aye, I did write a VSCode extension that strictly typed CSS files, and more specifically supported JSDoc style comments to provide typing to custom property definitions. As @chancethedev has mentioned, it can feel a little tedious across files and when context is not knowable.Jonathan Neal
Like most of my stuff the last few years, it was too spread out among too many other priorities, where I feel like I never finished any single thing. Until I release a lightweight CSS parser, I still feel like I owe the web that before I do other stuff. I can turn over the code.
If anyone wants it, even. Just hit me up, and we’ll schedule something during the week or whenever at the person’s convenience to demo and pass it over. I’m here to serve, and truly sorry I haven’t done as well or as much lately. I want to do better.
@alvaromontoro @jerryD @argyleink Yeah, there are very few issues where you'd need to add custom typing to CSS. Only if you want to add extra restrictions for a design system, like to only use your declared variables for colours or something.
For most cases, the issue is that the tools people are using to edit CSS aren't giving feedback about errors. However, the in-browser Dev tools are starting to add that. And maybe that's where it needs to stay, so it can stay up to date?
Amelia Bellamy-Royds
@argyleink I dislike this idea a lot tbh. CSS needn’t try to appeal to „Programmers“, it’s beauty is that it appeals to other demographics. It should remain this beacon. CSS shouldn’t be more programmer friendly.
Thomas Michael Semmler
I guess we don't need a new extension/name for this. If CSS is already typed editors could just add built-in validation to standard .css file.Mattia Astorino
Have you heard of @stylableio? We're very much into type systems, and think the experience around CSS and components should be safe, predictable and composable.Tom Raviv
It should be! CSS (the language) can be separated from css styles (the api) just like html isn't the same as dom. All we're defining are style objects, and TypeScript is a great language for that.Joshua Koudys
I suppose it’s quite a challenge given how variable and flexible certain CSS properties are. Take a look at the “background” alone. There’s close to no rule of order in which it’s compound values may be listed.Artem Zakharchenko
This really sounds like an IDE plugin more than a language superset. Aren’t supersets meant to bring value by introducing extra functionality (e.g. variables in Less and Sass)? Here, the point seems to be the intellisense. IDE is the best surface for that.
Please dont creat a new syntax when you can just simply write a linter on the existing syntax. In fact, the linter might have already exist.River
I guess one of the new functionalities would be declaring types for variables (custom properties) if the TypeScript analogy goes far enough. Made-up syntax: --primary: <Color> blue; --primary: 4em; /* type error */Fatih Aygün
@argyleink Is there something like JS doc for CSS?
Florian Geierstanger
@AmeliaBR would the `color()` function cover the color case?
Alvaro Montoro
Well I can contribute on the naming and framing of things, but that's not due yet other than the domain for the file-extension. For sure .tcss, so .scss now has another superset to use 4 characters with to share, using first-letter. A simple rule of ancestoryJustgu.us
I will honestly admit that I am more interested in how to do this Tweet Timeline on my own blog in the future than typed CSS, but knowing the source it can only mean a good thing for designers 🤟
@argyleink NO! BAD!
🍄🌈🎮💻🚲🥓🎃💀🏴🛻🇺🇸
Idk if I understand the idea. Would this mean like if I pass an errant value to a calc function for example, tcss would yell at me?Myles
Haha, I’ve been thinking about this idea for some time, talked about this with a friend today and asked @jjenzz if they explored this for Stitches. And now I see this tweet 🤯Dmitry Belyaev
Also in my version - you can use variables with js-like syntax which get typed but now I think - why can’t that be just a regular css syntax even for variables, except for maybe some dx.
A lot of people answering to this usually ask about current css in js solutions but what we really need is to keep writing css and use a lot of its native features without over complicated syntax, type safety and a way to write utilities
I’d expect the build to break if something is wrong. The IDE layer alone wouldn’t be enough for it to scale imo. Maybe a powerful CSS linter? Not sure about the current state of CSS linters.Aarón García
True. Sounds like a more complex toolchain setup. Basically, a transpiler + IDE experience, just like TypeScript. Let's call it StyleScript. Well, not the best abbreviation.
Ah I dunno man. Leave CSS alone and let it do it’s job silently. Frameworks like chakra make it phenomenally easy to use minimal, logical CSS and also keep everything clean and tidy without muddying too many waters. Extra files for CSS WITH types is too much for me.J
You don't need TS for this. CSS has its own definition syntax to define CSS syntax :) There are some options you can try: - stylelint-csstree-validator (github.com/csstree/stylel…) - csstree-validator (github.com/csstree/valida…) - VSCode extension (marketplace.visualstudio.com/items?itemName…)Roman Dvornov
Complex properties are not a big deal. @csstree has a support for CSS definition syntax and able to match against it. You can play with it on the page built with CSSTree: csstree.github.io/docs/syntax/#P… Btw, there are a stylelint plugin and a vscode plugin built using the same approach
IDE plugins are something personal, it's too hard to enforce everyone on a project to use the same IDE & extensions set. I prefer a linter, which is running on CI disregarding what you use locally. I can to suggest a stylelint plugin for the problem github.com/csstree/stylel…
The problem is not about a CSS parsing actually, but about a support for CSS definition syntax. @csstree has such a support as well as a validator package, and there are a stylelint rule and a VSCode extension. Just curious, are you aware about it? twitter.com/rdvornov/statu…
While evaluating the value of a property sounds great, there's so many possibilities for a single line of CSS. I'm not saying it's impossible but would require some ressources to process few code lines, what about dozens?Chanfi Attoumani
That said, based on declared property, possible value formats might be reduced but the complexity will stay. And what about browser support? Should it natively supported or require "compilation" step?
But definitely a YES if a tool could say: hey, this declaration here is useless/incorrect/redundant...
The VSCode extension doesn't seem to have support for some modern things. How are new units, keywords, functions added to it?
Stylelint's no-unknown rules catch some: stylelint.io/user-guide/rul… We're discussing adding @rdvornov's plugin as a built-in rule for stylelint@15.0.0 (due out soon). The rule will catch unknown property & value pairs: github.com/stylelint/styl… We plan to add more validation rulesStylelint
Curious to hear more about your experience with it. If you are just using the main css package, its essentially a typed preprocessor🛶🧁🍨 𝐌𝐢𝐜𝐡𝐚𝐞𝐥 𝐓𝐚𝐫𝐚𝐧𝐭𝐨
これが早く来て欲しい。 nerdy.dev/tcssみよ