Tachyons – A CSS Toolkit
tachyons.io
tachyons.io
It's strange, I never saw the point of it, however I saw the value in tailwind almost straight away.
I think that might be the difference in examples. The tachyon examples always look uninspiring.
Give me a web dev framework with view encapsulation / scoped styles and you can almost get rid of class attributes in your markup all together, especially if you build a component library that your higher level components can consume.
The ridiculous class strings get particularly hilarious when anything beyond basic CSS is used. Want CSS variables? Now it's even less readable!
For what it's worth, I enjoyed Basscss more than Tailwind, although I mostly just stick to CSS Modules + CSS variables these days.
> Team is doing OK with the current boring tech stack
> Senior Dev who is chronically on Twitter: "Hey guys, we should adopt this new library, React-TailsbyQL-babelfu by so-and-so Node though-leader because it makes this one very specific pattern easier! Look at how slick the docs look!"
> Team: "But we already swapped that part of our stack a year ago, and that one pattern would only help in a few specific parts of the codebase."
> Senior Dev makes argument to Product Manager
> Product Manager agrees because it'll look good to the rest of the company
> We complete migration to new shiny new tool; 30 transient dependencies and 4 config files added
> Senior Dev and Product Manager boast to other teams about the successful migration and cherry-pick LOC reduction in certain modules, omitting the added configs and complexity elsewhere; other Product Managers are impressed
> Meanwhile the app now performs worse; weird bugs creep up because details are now obfuscated by the new library; new devs now have to learn the codebase + the way this library dictates things must be done
> Devs start paying for courses by the author of said library using continuing education funds because the docs for the library are insufficient
> Author of library deprecates library; moves on to new library that does almost the exact same thing, and starts evangelizing it on Twitter
> Senior Dev comes back "Hey guys, check out this new library..."
You can tell I'm not bitter.
I'm going to come up with a trendy library or framework and name it Fool.
"A fool with Fool is still a fool." lol
Tailwind probably looks better, but I'm primarily using Tachyons for common spacing stuff and if I need better looking colors, I'll copy what Tailwind has or define my own. I can still write CSS, I'm not trying to stuff everything into classes generated by some configuration tool or whatever.
There was a push to build tutorials for whatever using Tailwinds (Build a blog with Hotwire, or something), those were there fastest tab closes ever performed on my lifetime. Those tutorials are useless, they have so much added nonsense that will not stand the test of time that might as well not exist at all.
Personally? Not a fan. Wish it would have stuck to utility classes.
The latest and newest i did https://github.com/meerita/fcss
just drop into your react app, in this order:
root.css normalizer.css generics.css (all css classes) sm.css (mobile classes) md.css (mid desktop/iPad) lg.css (standard desktop) xl.css (large desktop) xxl for large large desktops
The usage is easy, lets build a grid:
<div className='display--grid gap--8'>...</div>
Those are from the generics.css, but if you need 2 cols in mobile and 4 in desktop you can do it
<div className='display--grid gap--8 sm-template-columns--2 md-template-columns--4'>...</div>
The structure of every class is made using the css language, contrary to tailwind has its own syntax. it takes huge amount of time and mental effort to get it. With FCSS you learn the pattern and you can advance it or extend it.
Having said that we switched to Tailwind for a very specific reason: customisability. see: https://github.com/dwyl/learn-tailwind#what-about-tachyons
Still Tachyons is a perfectly valid and lightweight utility class based CSS library.
I'm working on a css style copying project on the side (DivMagic https://divmagic.com/) and I might add Tachyons as an option there
What makes this 'functional'? Is it related to functional programming? Or is it used as a synonym for 'usable'?
- .sans-serif {
- font-family: -apple-system, BlinkMacSystemFont,
- 'avenir next', avenir,
- helvetica, 'helvetica neue',
- ubuntu,
- roboto, noto,
- 'segoe ui', arial,
- sans-serif;
- }
+ .sans-serif { font-family: sans-serif; }
The idea of user configurability is nice but most users have no idea how to do that or that it’s even possible, and browsers bury these settings increasingly more deeply which doesn’t help matters either.
I think just going with sans-serif is the better choice.
No need to baby users. In the context of Hacker News, a lot of the websites built here are demo sites/documentation where the audience is definitely technical enough to not need this.
In the case of libre, Free Sans is a clone of Helvetica (as is Nimbus) & they are usable if a user decides to set them as their preferred font (or a fallback in fontconfig).
I've never had a designer ask for 17 fallback options before selecting a generic (like this font stack).
Perhaps there is room for new preferred-sans-serif-font, preferred-serif-font and preferred-mono-font aliases that we can shove at the top of font stacks like this and are set by the user if they wish (defaulting to nothing if they don't). That way people with a strong preference get listened to if they set this, so you can have other fonts installed for compatibility with documents written by others you collaborate with without them overriding your preference which is otherwise further down the list. Though that might be impractical: you need to convince browsers to implement the setting and designers to add it to the top of their stacks. The browser makers are not always fast to implement things until there is demand and there might not be demand because no one tries to use it while browsers don't support it. That and many designers may think “let the user pick the typeface, eeewwwwww!” & similarly browsers those packaging browsers for their OS might implement it wrong (putting something in those settings by default instead of them being blank unless specified). It could be described as an accessibility issue to get more traction, allowing users with certain vision issues to specify typefaces (and maybe other properties like minimum sizes & weights) that improve readability for those with their condition.
I actually don’t mind something designed with purpose & has a reasonable font stack to match it, but this stack isn’t that.
Using a system font stack isn't about “a typeface that is a bit Grotesk” and more about trying to integrate with the look of the users OS. Including a @font-face will not achieve that version of “just so” unless you want to mimic one OS for everyone.
-apple-system will give San Francisco on Apple systems. BlinkMacSystemFont will do the same in Chrome. Roboto is the Android default font. And so on. Since most people don’t typically have the default system font for other platforms installed, a rule like this will typically give the same font that is used everywhere else in the platform.
Web browsers don’t typically use the standard font for the platform for backwards compatibility reasons, which is why system-ui was created. Older browsers don’t support system-ui, so tools like PostCSS will often replace it with a stack like this in an attempt to get the same behaviour in older browsers.
This basically boils down to somebody saying “let’s use the standard font for the platform the user is using”.
Exactly. This is what system-ui should be but some browsers instead default to something else, perhaps in a misguided effort to make their UA look consistent between platforms, to many use a font-list like the above to try enforce what system-ui should be. Unfortunately it falls apart if the user has fonts for other systems installed (perhaps for compatibility with others they collaborate with on documents, or to be able to view HTML more exactly as those users will see it) and those users get someone else's system font instead because it is ahead of thiers in the list.
My website, my design. my fonts. Period.
Their device, their preferences, their fonts. Period.
However pretty much every website specifies which font to use. If you want your own font, you aren’t going to get it by complaining about one particular CSS framework. There’s a way of overriding fonts in every browser; find that and you’ll get what you want.
A few minor things still to iron out but it’s the way to go. I also maintain a version with darkmode support based on v1 :)
Feature wise it has grid, css variables and a full color palette.
The grid system is still using floats instead of flex/grid.
You can see this when trying to trying to use querySelector with responsive:property-[arbitrary] classes (I think, or it might be a different pattern of which I'd have to go back and check) and other cases where the JS engine will throw an error for trying to use a class Tailwind encourages you to write.
ident [-]?{nmstart}{nmchar}*
nmstart [_a-z]|{nonascii}|{escape}
nonascii [^\0-\177]
unicode \\[0-9a-f]{1,6}(\r\n|[ \n\r\t\f])?
escape {unicode}|\\[^\n\r\f0-9a-f]
nmchar [_a-z0-9-]|{nonascii}|{escape}
document.querySelector('.[&_a]:underline')
It is, but in the same way “I received an error” is not an incorrect error report it just lacks specificity.
I think what CSSer was asking (though the question itself was not worded as precisely as it could be) is: can you give examples of the invalid identifiers that it encourages?
There is also the matter of separation of concerns, not wanting to add classes specifically for particular bits of code where possible to avoid it, but given the sea of classes generated by frameworks these days I'm not sure that is an ideal which is much followed ATM.
I think you touched on an objective subject, however, if you were alluding to performance. Classes are generally free and cheap. I’d be very interested in evidence to the contrary if anyone could share.
My last, somewhat random, thought is that it does indeed seem that who likes TW and who doesn’t does seem to depend a lot on the stack they’re thinking of when they mull over its (de)merits.
It isn't as much about performance (the small amount of extra network transfer is likely to be brought close to zero if compression is used, the extra CPU load might be measurable on low-spec devices but on top of all the junk already in sites using heavy frameworks this is not going to make/break anything) as maintainability. You have something extra to make sure is set everywhere it needs to be.
When I started using it, if I needed a card or a list I could go to the components section and pick one, copy-paste it and then change it to my liking. When I tried the same in tailwind I was faced with a paywall and automatically lost all interest.
more info on this PR https://github.com/tachyons-css/tachyons/pull/705
<b>bold</b>
<div class=“b”>bold</b>
Things like this make me think CSS needs namespaces though, just the other day I found out there was more than one library in an application I am working on that declares properties of “.dropdown” which could be a problem.
More generally you really ought to be able to pull some HTML out of page A and transcode it into page B and that means copying the styles and a lack of namespaces for id(s) and class(es) gets in the way of that. In principle you could have syntactic macros for HTML or frameworks that work on the DOM more imaginatively than React does but you run headlong into the “macro hygiene” problem.
See this example where semantic HTML tags aren't going to help much with the styling or getting the information hierarchy right: https://twitter.com/steveschoger/status/997125312411570176/p...
Of course in this example, semantic HTML makes sense. How do you compose styles? Do you have a semantic element for every CSS property and every combination of every CSS property? Utility frameworks are used for much more than making text bold. The idea is to write as little CSS as possible, which reduces CSS bloat, collisions, specificity hell etc.
> More generally you really ought to be able to pull some HTML out of page A and transcode it into page B and that means copying the styles and a lack of namespaces for id(s) and class(es) gets in the way of that.
That is quite literally what tools such as tachyons/tailwind solve.
> or frameworks that work on the DOM more imaginatively than React does
I don’t really know what this means. But if you’re using React, you can leverage CSS Modules or one of the many CSS-in-JS frameworks. Both of these approaches solve your issue with namespacing.
An alternate approach is to work entirely at the DOM level, a bit of a manifesto for that
https://ontology2.com/the-book/html5-the-official-document-l...
To take the common case, your "master template" could be an HTML page with a few "slots" in, say <div> elements with a certain id or class. The main content for a page is another HTML page, both of these are parsed to the DOM, the <body> of the donor page is extracted, grafted into the slot of the host page.
More generally we can write functions that act on the DOM just as someone can write code that works on the AST of a programming language.
One capability that ought to be possible is transclusion, in fact the "Real Semantics" system that was being designed at that time was a system for annotating documents and extracting knowledge from them and the first step of that is that a document is "fixated" an embedded in an another document, pinned down the way an entomologist pins down a butterfly.
This is on the edge of possibility: cut-and-pasting an arbitrary fragment of HTML out of somebody else's document and also rewriting id and class names and relevant CSS styles such that the the donor HTML looks the same way it did in the host HTML. (Or better yet, the CSS is manipulated so as to maintain the intent of the donor document in a way consistent with the host document)
Anyhow, one major barrier to this is that DOM parsing is pretty slow, a simple system based on DOM parsing can be two orders of magnitude slower than string templates. (No wonder ASP.NET compiles templates ahead of time)
Another one is ubiquitous Javascript; from my viewpoint a static document that can be "pinned down" is dramatically more valuable than a changable document in that I can easily repurpose the static document. (In literary criticism is is notable that a document is "dead" and can't fight back against a hostile or inventive reader, say Derrida or Badiou.) You certainly can snapshot the DOM of a dynamic document the way that Google can index React-based sites, but it sure is a hassle.