In the end, why not directly have the JS reading the class and generating only what's needed? That would be very cool!
I'm still having some doubts about the maintainability (duplication, isolation...) of such styling btw...
I assume he/she means that CSS is cached as an http resource and can be reused in different pages, whereas style attributes are only cached as part of the page; ie using them adds page weight.
I use react inline styles in some situations where it's appropriate. on large tables or SVG (eg. with zillions of styled circles) there will be issues.
if you are sending HTML from a server with inline-styles then you will have much bigger problems with bandwidth.
This is where tachyon and basscss can provide a clean way for the day to day simple styling tasks like "needs more padding here" "make that title bigger there" without writing up stylesheets with repetitive margin, float, etc. for every single view in your app or every page on your website.
I've been looking at this recently. I'd really love to hear more about real-world experience using Tachyons. We're suffering from serious bloat (500KB CSS) on an old project, and are trying to figure out how best to manage CSS so it doesn't bloat over time (at least not as much).
These are valid issues, but one that has a better, actually scalable solution: CSS preprocessors.
You can name your magic numbers/RGB values. You can move your shared behaviour into mixins. You can stop using float for god's sake - it's 2016, we have flexbox now (OK, so that's not related to preprocessors, but it's still true).
Sure, if it's a quick hack or something you're throwing together for personal reasons, use whatever mixture of inline-styles, "visually semantic" classes, and table layout goes fastest for you. But if the point is "scalability" (In the sense of size of team working together), then this halfway point between semantic classes and inline styles is definitely not the right way to achieve it.
Is that still true? I recently joined a company whose primary audience is education, and our numbers say that less than 1% of our customers use browsers that don't support flexbox.
Are public middle schools farther along the tech curve than "enterprise"?
(Legitimately curious. It'd be pretty funny if so.)
I used css-preprocessors (LESS, SASS and various postcss-configurations), but now I'm glad to not have another layer of imports and logic in CSS. Especially in react-driven pages.
I wonder, though, if there could be some workflow where you write and edit with tachyons, (babel-) analyze the code, find commonly used combination and prompt to name them.
EDIT: I also usually work with only two or three people, I guess it's different if there are 20 working on the css.
But especially in teams: don't you consider it extremely valuable that one can change the style of exactly one part somewhere in the page without affecting anything else?
They're making fun of Bootstrap, but having classes that allow you to define margins and padding quickly by adding a class is actually really helpful. Of course that shouldn't be expanded to every possible property.
You can use Foundation + sass processor and not need any of that garbage. My website just has nav, main, sidebar, etc. I define what I want into foundation to be mapped to them and the preprocessor creates my minified CSS.
I really don't know how to take your comment...are you suggesting that precompiling and overriding the functionality native to CSS is easier than just using a handful of classnames?
They're suggesting that Bootstrap-like classes that name and reference a specific visual rendering (e.g., col-md-hidden) are no better than the old ROWSPAN/COLSPAN mess. They've just moved from HTML attributes to being packed into the class attribute.
Then again, semantic markup was a huge pain in the ass before tools like SASS. Now you can actually name and categorize elements semantically in the markup, then decide what that actually means in the pre-processed CSS.
Edit: And it's true: Having recently gone through even a simple bootstrap-to-bootstrap redesign, we pretty much had to comb through every view and remove/replace non-semantic CSS classes. With SASS mixins and semantic markup, it'd have been a CSS-only change.
> Now that we’re writing almost all of our html in modular fashion, I have found mix-n-matching pre-defined css classes works the best. i.e. class=”inline-block bg-bbb text-333 padding-5-15″
>Bootstrap V4 recently introduced spacing utility classes like m-t-1 (which translates to margin-top: 1rem!important), and we thought we'd expand this idea to more classes.
Which is worse; when it's done as satire, or seriously?
To be fair, the top comment here calls out Poe's Law. You can see this best by how "A Modest Proposal" was recieved: the anonymous author was villified and many powerful people were outraged. People were repulsed and offended and everything'd else by it.
One of my favorite Asimov quotes is "It pays to be obvious, especially if you have a reputation for subtlety." It's a damn shame that it's helpful to put blaring giant signs that say SATIRE on it and ruin the joke a bit, but there's just a ton of people out there who just never really got up to speed on detecting it. Many - possibly most! - people really don't look that deeply into things and tend to take stuff at face value (or don't know that there is a deeper meaning to spot), no matter how outlandish.
All that as a mea culpa, as I read the OP's README and thought, "man, that seems like a bit of a mess... under what circumstances would you need to do that?" The answer is NO DO NOT DO THIS but I, lacking experience, kinda didn't get that right off the bat.
> To be fair, the top comment here calls out Poe's Law.
The top comment when I posted was a copypaste of the joke disclaimer. And the top reply to the top comment at the time of this posting is a copypaste of the joke disclaimer.
> Many - possibly most! - people really don't look that deeply into things and tend to take stuff at face value (or don't know that there is a deeper meaning to spot), no matter how outlandish.
If someone can't figure out why generating a CSS class for every (property, value) combination is funny, then I don't think an explanation will help. Maybe it will give those readers an A-ha! moment and a valuable life lesson, but it won't be funny for them.
> All that as a mea culpa, as I read the OP's README and thought, "man, that seems like a bit of a mess... under what circumstances would you need to do that?"
If you got rused then that's great. The joke did what it was supposed to do. What sucks is that people who instinctively click the comments first won't get that experience, because some killjoy had to post "IT'S A JOKE DON'T FALL FOR THIS."
The real joke is how screwed up client side programming is. Here's a library that's an insider/hipster joke but it's only obviously a joke to hipster/insiders.
Javascript is fine. It's the fact that the ecosystem changes every few months and devs post things like "look how ridiculous this old way of doing things is" when the old way was just last year (or 6 months ago) when _it_ was the new hotness.
I have a lot of ideas for small side projects that could be good (or probably not, but at least I wanna try them seriously) and can't get time to implement them, and people who have this time waste it writing universal.css.
Seriously though. What's bad about using, say, tachyons and composing several of its pieces inside more meaningful labels like "sidebar" or "header" or whatever? It's simpler to grasp, and it WILL wind up as one dictionary per node anyway
this is wonderful! finally, a clear, succinct way of writing CSS. This is what I've been waiting for since I wrote my first <font /> tags when I was eight.
This is amazing. I quit a job at a company that did many stupid things, one of which was insist that their home rolled CSS framework did not suck. Said framework was, in all seriousness, exactly this but with shortened, cryptic names. Nightmare.
Ideally, in SMACSS, you could classify all components into their composable parts: a grid width, a title style, a button with a primary style, a button with a secondary style, standard body text, emphasized body text, etc.
But most of the time, designers don't know how to stick with a standardized padding and margin, so I find that without exception, an org requires me to develop "cryptic" representations of margin and padding, such as mr1 (margin right to 1 degree, or 5 px) or pl2 (padding left to 2 degrees, or 10px).
I've also rolled entirely new features without writing a single line of CSS. This is a way to mitigate CSS bloat. I take it you've never actually tried to deal with the problem of CSS bloat, or you'd find either 1) you'd have to hold a gun to designers' heads or 2) do exactly what I just showed you.
I've had a very different experience with designers. I would say that ~95% of them something is a couple pixels off, a slightly different font size, or a shade off in color, it was a mistake.
Usually a quick follow-up question will reveal the mistake and the designer is happy to make the correction.
This is weird, because designers I've worked with hate CSS bloat even more than I do, and love things like consistent spacing and typography. The movement towards styleguides has been one of the biggest things happening in design in the last year or so, which is exactly what you're talking about with not writing CSS.
117 comments
[ 4.5 ms ] story [ 219 ms ] threadhttps://news.ycombinator.com/item?id=11001820
Of course it's a joke. Use semantic CSS class names.
What constitutes self-describing code is wildly different depending on the person. I mean, really?
EDIT: I definitely missed that this is a joke :'(
> Is this a joke? Of course it's a joke.
[1] http://tachyons.io/
Here's the rational: http://mrmrs.io/writing/2016/03/24/scalable-css/
Practical example: I have a form with a header. I look at it and think "there needs to be more space below the header". So I change
to It hot-reloads etc. It took me exactly two keystrokes to change this and I know that the spacing is consistent with all the other spacing in my app.2. the scale also has fractional rem values.
I'd rather change "f5" to "f6" for a smaller font than: "fontSize: 1rem" to "fontSize: 0.875rem".
3. the author of tachyons clearly understand design. If he improves his stylesheet, I benefit.
4. Apparently inline-styles are slower [0], but I don't count that since everything could be extracted.
[0] http://ctheu.com/2015/08/17/react-inline-styles-vs-css-stupi...
5. I thoroughly enjoy using it. :)
http://ctheu.com/2015/08/17/react-inline-styles-vs-css-stupi...
I use react inline styles in some situations where it's appropriate. on large tables or SVG (eg. with zillions of styled circles) there will be issues.
if you are sending HTML from a server with inline-styles then you will have much bigger problems with bandwidth.
This is where tachyon and basscss can provide a clean way for the day to day simple styling tasks like "needs more padding here" "make that title bigger there" without writing up stylesheets with repetitive margin, float, etc. for every single view in your app or every page on your website.
You can name your magic numbers/RGB values. You can move your shared behaviour into mixins. You can stop using float for god's sake - it's 2016, we have flexbox now (OK, so that's not related to preprocessors, but it's still true).
Sure, if it's a quick hack or something you're throwing together for personal reasons, use whatever mixture of inline-styles, "visually semantic" classes, and table layout goes fastest for you. But if the point is "scalability" (In the sense of size of team working together), then this halfway point between semantic classes and inline styles is definitely not the right way to achieve it.
Are public middle schools farther along the tech curve than "enterprise"?
(Legitimately curious. It'd be pretty funny if so.)
Though there's polyfills like flexibility out there, of course.
0. http://caniuse.com/#feat=flexbox
As I understand it, IE10 implements a different, somewhat incompatible version of the flexbox spec. You can see all the changes they made for 11 here: https://msdn.microsoft.com/library/dn265027(v=vs.85).aspx
I wonder, though, if there could be some workflow where you write and edit with tachyons, (babel-) analyze the code, find commonly used combination and prompt to name them.
EDIT: I also usually work with only two or three people, I guess it's different if there are 20 working on the css.
But especially in teams: don't you consider it extremely valuable that one can change the style of exactly one part somewhere in the page without affecting anything else?
Not trolling, I think React is a fine framework.
http://penguindreams.org/blog/jekyll-3-and-foundation-6/
Adding "row-xx" or whatever to your HTML elements is basically going back to the garbage that was in table based html layouts.
Then again, semantic markup was a huge pain in the ass before tools like SASS. Now you can actually name and categorize elements semantically in the markup, then decide what that actually means in the pre-processed CSS.
Edit: And it's true: Having recently gone through even a simple bootstrap-to-bootstrap redesign, we pretty much had to comb through every view and remove/replace non-semantic CSS classes. With SASS mixins and semantic markup, it'd have been a CSS-only change.
> Now that we’re writing almost all of our html in modular fashion, I have found mix-n-matching pre-defined css classes works the best. i.e. class=”inline-block bg-bbb text-333 padding-5-15″
Which is worse; when it's done as satire, or seriously?
See also the latest reprinting of "A Modest Proposal," which kindly has "SATIRE -- DO NOT BELIEVE" in large caps on the front and back covers.
One of my favorite Asimov quotes is "It pays to be obvious, especially if you have a reputation for subtlety." It's a damn shame that it's helpful to put blaring giant signs that say SATIRE on it and ruin the joke a bit, but there's just a ton of people out there who just never really got up to speed on detecting it. Many - possibly most! - people really don't look that deeply into things and tend to take stuff at face value (or don't know that there is a deeper meaning to spot), no matter how outlandish.
All that as a mea culpa, as I read the OP's README and thought, "man, that seems like a bit of a mess... under what circumstances would you need to do that?" The answer is NO DO NOT DO THIS but I, lacking experience, kinda didn't get that right off the bat.
The top comment when I posted was a copypaste of the joke disclaimer. And the top reply to the top comment at the time of this posting is a copypaste of the joke disclaimer.
> Many - possibly most! - people really don't look that deeply into things and tend to take stuff at face value (or don't know that there is a deeper meaning to spot), no matter how outlandish.
If someone can't figure out why generating a CSS class for every (property, value) combination is funny, then I don't think an explanation will help. Maybe it will give those readers an A-ha! moment and a valuable life lesson, but it won't be funny for them.
> All that as a mea culpa, as I read the OP's README and thought, "man, that seems like a bit of a mess... under what circumstances would you need to do that?"
If you got rused then that's great. The joke did what it was supposed to do. What sucks is that people who instinctively click the comments first won't get that experience, because some killjoy had to post "IT'S A JOKE DON'T FALL FOR THIS."
1. Bootstrap is partly for prototypes and quick interfaces where front end best practices don't matter.
2. If you're using a preprocessor, you can include Bootstrap's classes and rename/combine them to something semantic.
3. Something can be a good idea when done in small quantities, and a terrible idea when taken to extremes.
No thanks.
Honestly I thought bootstrap was the only css I would ever need, and this hasn't changed my mind.
I have a lot of ideas for small side projects that could be good (or probably not, but at least I wanna try them seriously) and can't get time to implement them, and people who have this time waste it writing universal.css.
Oh, come on. It probably takes two hours, at most, to create a text generator that prints this whole universal.css file...
"And the HTML tag lived happily ever after."
But most of the time, designers don't know how to stick with a standardized padding and margin, so I find that without exception, an org requires me to develop "cryptic" representations of margin and padding, such as mr1 (margin right to 1 degree, or 5 px) or pl2 (padding left to 2 degrees, or 10px).
I've also rolled entirely new features without writing a single line of CSS. This is a way to mitigate CSS bloat. I take it you've never actually tried to deal with the problem of CSS bloat, or you'd find either 1) you'd have to hold a gun to designers' heads or 2) do exactly what I just showed you.
Usually a quick follow-up question will reveal the mistake and the designer is happy to make the correction.
This has been my best weapon against CSS bloat.
* Components and patterns are standardized, allowing for less process in design reviews and quicker iteration
* Engineers can create component libraries that mirror style guide elements and turn frontend work into something a little closer to 'lego' building