Poes law meets css: "Poe's law is an Internet adage which states that, without a clear indicator of the author's intent, parodies of extreme views will be mistaken by some readers or viewers for sincere expressions of the parodied views.[1][2][3]
"
https://en.wikipedia.org/wiki/Poe%27s_law
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.
>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?
Absolutely brilliant! Because of its universal nature and compositional design, one only has to download this CSS page once from the primary CDN and it can be used for everything everywhere. One could even argue this should be a standard browser component.
> 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″
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.
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."
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?
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 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'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).
People who don't understand the concept of atomic CSS usually joke about it, but has no idea about the benefits. The new Twitter mobile site is fast as hell and use this concept. Semantic class names makes no sense when you think about it.
It's sad that my first reaction was "Looks like bootstrap." I would like a few more colors. Maybe you could add pantone support, that would make this super useful esp. for mobile!
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'm getting scared to see that on front page, I'm the kind of guy which could have enough luck to randomly fall into a project where someone used it for real.
"Dude, I just found the coolest CSS framework, take a look. This is going to solve ALL of our problems!"
I've had this happen a few times with other developers I thought were pretty sharp. The best example is when someone found Dogescript (https://dogescript.com/) and was convinced it was the next big thing. The best part was I didn't have the heart to tell him the truth.
How can someone take Dogescript seriously?! That is so retarded, even a guy witch is not into programmation and hang out on 9gag sometimes can tell it's a troll!:O
I think we should judge a technique in regard to the problems it solves and the ones it creates, not in regard to our understanding of the said technique.
No, it is not the same as using "inline styles" (just think about it). Yes, it reduces CSS scope and bloat in styles sheets. Yes, it breaks the Separation of Concern principle. No, it does not create bloat in the markup. Yes, it forces you to style via markup rather than via a style sheet, etc.
Like with any other technique, choosing to use "Atomic CSS" in a project should be considered in relation to the problems authors have to solve. CSS is a complex matter, there is no one size-fit-all solution and there are not that many solutions either so I think we should think twice before disregarding a tool, any tool.
PS: Yes, I know universal.css is a joke but it is mocking a real/serious approach to big CSS problems.
Utility classes I dislike (mixins plx) and the idea of using important with them is not a design decision I would want to pick up.
I guess my bigger problem is that Harry sells himself as an expert, stands up on stage telling people this is how they should be doing things... and here I am, no book, no stage and my specificity level gets trumped by Harry amongst certain members of my team (despite my years of qualified awesomeness across large scale, popular, public domain sites)
I read that post earlier and it seemed fine. If you add a .bold class to an element, why would you want it to sometimes not be bold?
Utility classes don't belong everywhere but I think it's going a bit far to discredit the man for proposing this. His work on ITCSS in particular shows he's well versed in the language. I find this system far more sane than other proposals.
Why bother with class 'bold' when you could use inline styles? (I jest)
I come from an older thinking that your HTML should not have any classes that imply visual style, and that classes/id's should be semantic to the content and structure of the HTML.
CSSZen garden is a good example of this.
Nowadays I personally love semantic markup, stylistic mixins, and a CSS file linking the two together following BEM patterns.
I think legitimate times when this falls apart, is when I watch the designers I work with now, work in HTML & CSS - they need to quickly move things around, so doing this all from markup gives them a big speed increase, up until a point that is. We get involved now early after initial client direction sign-off to make their markup and CSS more robust before they carry on like a pig in poo.
> If you add a .bold class to an element, why would you want it to sometimes not be bold?
The problem is having a class called .bold, and then baking it into your HTML. I feel like many people arguing this have never undertaken a full-scale visual redesign on a large site. The designer comes in, and all the sudden everything marked .bold ends up meaning "lightweight italicized text". This presentational/semantic cycle repeats every 6 years or so, but I'm not sure where it's heading.
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.
I pretty much completely disagree with the implicit critique here. The codebase I work on now has largely transitioned from "semantic" CSS (classnames based on feature) to CSS with classnames that describe what they do, visually, and the latter has made writing frontend code dramatically more straightforward - it's gone from something I dread and try to pass off to a specialist to something I can do easily. A night-and-day improvement.
I mean, nobody actually advocates translating every single possible style attribute into its own CSS class. But what's wrong with padding and margin utility classes that use a consistent set of widths? Is doing calculations on "1x" and "2x" when you want elements to line up really worse than doing calculations on pixel or em values in your CSS just because it's "unsemantic"?
Let's take the examples from the "maintainable CSS" book that's linked:
Ask yourself, in which case can you read the code and tell roughly how it's going to render? In which case do you think you'll be able to re-use the classes on other pages? If you wanted to make another, visually consistent page that shows, say, seller search results instead of product ones, in which case do you think you'll be able to figure out which styles need to change more quickly?
Here's the backend equivalent:
# "bad"
def cheapest_products_with_min_rating(rating)
products.
select { |p| p.rating >= rating }.
sort_by { |p| p.price }.
first(10)
end
# "good"
def products_for_category_landing_page(rating)
allowed = []
for p in products
if p.rating >= rating
allowed << p
end
end
# pretend I've implemented quicksort here
result = []
for p in sorted
break if result.length >= 10
result << p
end
result
end
Ugh, that first example - using all these "unsemantic" components like "sort" and "select"! How do I know when I look at the implementation of any of them, or the function itself, what the intent is? What business problem is being solved?
The second example - so nice and "semantic". If we want to change what products show up on the category landing page, it will be easy!
...
In real life, nobody writes backend code like that. Why should we tolerate it in the frontend?
I'm with you. I'm not sure why semantic purists need to spread the idea that utility classes are bad. 1 class name for every property is stupid of course, but layout classes (yes, used with semantic HTML elements) are a great help if used with discipline.
After all, who are we writing code for?
- The end user? He can't care less about the class names.
- Search engines? They can surely identify relevant content. Semantic classes help, but they don't rule out utilities.
- Ourselves? I can read utility/semantic classes well especially that I've written. Also not a case against utilities.
I've been working on an app that relies on parsing CSS styles for like 6 months - full time. This almost gave me a heart attack until I realized it was a joke.
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
It's really funny because I'm working on a real project which uses a CSS which is really like universal.css, and we are thinking of going responsive. Luckily at least this is a joke.
I sympathize with the other commenters with my same problem.
Can someone kindly explain how I'm supposed to feel about this? I'm on mobile ATM and my feelings are somewhat restrained by available processing power.
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 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.
