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.
For what it's worth, I enjoyed Basscss more than Tailwind, although I mostly just stick to CSS Modules + CSS variables these days.
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.
- .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.
-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.
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.
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.
The grid system is still using floats instead of flex/grid.
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'?
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.
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.