Another project, which also uses the idea of atomic CSS classes is Styletron [0].
Perhaps their "introductory blog post" [1] better explains the "why".
All in all this has some interesting performance benefits.
It may look insane, but as long as you don't have to manually make and use these atomic classes this is not such a bad idea.
I think the things such as atomic CSS, CSS-in-JS, CSS Modules, styled-components, inline styles, etc. are all symptoms of something being seriously wrong with CSS and at the same time attempts to fix these problems. They are pushing in the positive direction.
I recommend checking out [2] if somebody is interested in these topics. That's where I found out about Styletron.
I have a desktop publishing background and I'd say that CSS is way less convenient than the common desktop publishing styling model. In desktop publishing you assign styles to certain classes of page elements (paragraphs, character runs, graphics, tables, etc.) and you can base a style on another style, that's all. There's no element-element inheritance, only style-to-style inheritance. This is not ideal, I think, but you never get any surprises that are so common in CSS.
If I were to design a better styling model, I'd take that desktop-publishing model and added multiple inheritance (something you can model in XSL-FO with XSLT attribute templates) and maybe tried to have pattern-based rules, but not hierarchical as in CSS. What you normally need is to be able to specify that "add that much space between a table and a paragraph", "remove first line indent if the paragraph comes after a picture", "do not add space if the paragraph is at the top of the page", and so on. All this seems to be based on a particular arrangement of sibling elements, not of parent-child relationship. The only exception I can think of are tables, but they seem to be special anyway.
Yeah, they showcase how much better it is than using inline styles (which it is, of course) but I don't see "the headache of managing stylesheets" problem this supposedly solves. Not sure who the target audience is for this one.
It's funny how they say "The lower specificity of classes also allows for easier overrides" -- that's true, but what on earth would I want to override a class called "P(20px)" to do instead? :)
Size. Using styles like this lead to a small decrease in page size, which over time on a very high traffic site leads to a notable bandwidth savings.
... or at least, that was the argument. In practice, most teams didn't adopt it unless mandated from above; because it sucks to use, has an infinitesimal decrease in individual page load time, and the bandwidth savings certainly don't outweigh the lost developer time.
But hey, all you gotta do is convince some VP that your niche approach is the right one, and you'll get some adoption in a large company like Yahoo.
Where have you heard that argument? That is absolutely bonkers. Why didn't they just use css as intended and collect all these inline styles into generic classes? Or turn on gzip-compression?
I worked in an org at Yahoo that required all development to use Atomic, and that was essentially the reasoning as presented. The Atomic authors put a lot of effort [1] put into proving the size point, enough that it was pretty difficult to argue with. The stylistic issues were sort of swept aside; less size == faster page loads == more revenue.
If you believe the size argument, and care more about short term revenue over developer productivity or happiness, it makes sense, I guess.
I recently botched a badly written site with loads of inline styles in to something responsive, you can override inline styles. It's not pretty, but it works:
*[style*="text-align:justify"]{
text-align: left !important;
}
Someone already posted styletron which to me is a lot better, but anywho the point of it is to minify your CSS a lot more. If you have something like `margin: 10px` in several different places, it will refactor it out into a new class and apply it to all of those elements. In a big project, it saves a lot of space and you end up with a pretty small CSS file.
Admittedly, I have no idea how well this performs with code splitting though. I like the fact that with code splitting, each page will just load the assets that it needs for that page to render and function.
> Atomizer is a tool for creating Atomic CSS. Generate an Atomic stylesheet dynamically from the Atomic classes you're actually using in your project (no unused styles!), or predeclare styles in configuration - it's up to you. Atomizer is not opinionated, brings no CSS of its own, and integrates nicely with your favorite task runner.
We use a combination of Atomics and BEM in our project.
Atomics offers single level specificity thus providing a strategy to combat the specificity problem that plagues many projects.
They are single purpose and infinitely composable, which complements very well with component oriented architecture that's popular today.
They are localized to single DOM node. When combined with its single purpose nature offers fewer surprises when making changes to your style sheet. For example, when you add a margin 15 Atomics to a DOM node, it is very hard to accidentally add another margin 15 somewhere else. Versus if you add a label class, it is much easier to accidentally add another label class and cause unintended consequences.
this, pretty much. it's as declarative and surprise-free as you can get in CSS and it works super well when abstracted into components.
I know it isn't the easiest to read and it seems counterintuitive at first, but in practice you can easily encapsulate long chains of inline classes into helper classes thus giving most projects a sort of sane middle ground.
The, code is much more readable then the same written with inline styles.
Citing their website:
Most approaches to styling inside components rely on inline styles, which are limiting. Atomic CSS, like inline styles, offers single-purpose units of style, but applied via classes. This allows for the use of handy things such as media queries, contextual styling and pseudo-classes. The lower specificity of classes also allows for easier overrides. And the short, predictable classnames are highly reusable and compress well.
For everyone reading these comments, I want to say that this kind of pull request is hurtful and unwarranted.
You've essentially sent an alert to someone ( or a group of people ) saying that you believe their work has no value. This kind of behavior could have real-world consequences. You could be pushing someone to not work on open-source again, or make them feel worse about working on a project they might be required to contribute to as part of their job.
How would you feel if someone started vandalizing your own github projects gvx? Would it make you feel good? Would you consider it funny?
This is ridiculous. If someone tells you your project is bollocks and you decide to quit the open source world altogether, maybe that world was better off without you.
You're allowed to be a jerk, but when doing so you shouldn't be surprised if people call you a jerk (or use a nicer phrase like "this kind of pull request is hurtful and unwarranted").
Constructive criticism is good, but the linked PR is not that. It's akin to a content-less drive-by HN comment like "you suck". You're free to post it (until you get banned), but it's not adding anything and you should expect downvotes.
To be more specific, they're using the https://acss.io framework which they came up with 2015.
That site is a bit light on the "Why?".
Another project, which also uses the idea of atomic CSS classes is Styletron [0]. Perhaps their "introductory blog post" [1] better explains the "why".
All in all this has some interesting performance benefits.
It may look insane, but as long as you don't have to manually make and use these atomic classes this is not such a bad idea.
I think the things such as atomic CSS, CSS-in-JS, CSS Modules, styled-components, inline styles, etc. are all symptoms of something being seriously wrong with CSS and at the same time attempts to fix these problems. They are pushing in the positive direction.
I recommend checking out [2] if somebody is interested in these topics. That's where I found out about Styletron.
Cheers.
[0] https://github.com/rtsao/styletron [1] https://ryantsao.com/blog/virtual-css-with-styletron [2] https://medium.com/seek-blog/a-unified-styling-language-d0c2...
I have a desktop publishing background and I'd say that CSS is way less convenient than the common desktop publishing styling model. In desktop publishing you assign styles to certain classes of page elements (paragraphs, character runs, graphics, tables, etc.) and you can base a style on another style, that's all. There's no element-element inheritance, only style-to-style inheritance. This is not ideal, I think, but you never get any surprises that are so common in CSS.
If I were to design a better styling model, I'd take that desktop-publishing model and added multiple inheritance (something you can model in XSL-FO with XSLT attribute templates) and maybe tried to have pattern-based rules, but not hierarchical as in CSS. What you normally need is to be able to specify that "add that much space between a table and a paragraph", "remove first line indent if the paragraph comes after a picture", "do not add space if the paragraph is at the top of the page", and so on. All this seems to be based on a particular arrangement of sibling elements, not of parent-child relationship. The only exception I can think of are tables, but they seem to be special anyway.
Yeah, they showcase how much better it is than using inline styles (which it is, of course) but I don't see "the headache of managing stylesheets" problem this supposedly solves. Not sure who the target audience is for this one.
It's funny how they say "The lower specificity of classes also allows for easier overrides" -- that's true, but what on earth would I want to override a class called "P(20px)" to do instead? :)
Size. Using styles like this lead to a small decrease in page size, which over time on a very high traffic site leads to a notable bandwidth savings.
... or at least, that was the argument. In practice, most teams didn't adopt it unless mandated from above; because it sucks to use, has an infinitesimal decrease in individual page load time, and the bandwidth savings certainly don't outweigh the lost developer time.
But hey, all you gotta do is convince some VP that your niche approach is the right one, and you'll get some adoption in a large company like Yahoo.
Where have you heard that argument? That is absolutely bonkers. Why didn't they just use css as intended and collect all these inline styles into generic classes? Or turn on gzip-compression?
I worked in an org at Yahoo that required all development to use Atomic, and that was essentially the reasoning as presented. The Atomic authors put a lot of effort [1] put into proving the size point, enough that it was pretty difficult to argue with. The stylistic issues were sort of swept aside; less size == faster page loads == more revenue.
If you believe the size argument, and care more about short term revenue over developer productivity or happiness, it makes sense, I guess.
[1] https://acss.io/frequently-asked-questions.html#what-are-the...
> Why didn't they just use css as intended
Too many engineers and not enough actual problems.
I recently botched a badly written site with loads of inline styles in to something responsive, you can override inline styles. It's not pretty, but it works:
> but what on earth would I want to override a class called "P(20px)" to do instead? :)
lol maybe you might want to express the sizes in another base /s
Someone already posted styletron which to me is a lot better, but anywho the point of it is to minify your CSS a lot more. If you have something like `margin: 10px` in several different places, it will refactor it out into a new class and apply it to all of those elements. In a big project, it saves a lot of space and you end up with a pretty small CSS file.
Admittedly, I have no idea how well this performs with code splitting though. I like the fact that with code splitting, each page will just load the assets that it needs for that page to render and function.
There is some genuinely cool stuff in there. It's nice to see Yahoo is still thinking about and not afraid to change how we build layout.
> Atomizer is a tool for creating Atomic CSS. Generate an Atomic stylesheet dynamically from the Atomic classes you're actually using in your project (no unused styles!), or predeclare styles in configuration - it's up to you. Atomizer is not opinionated, brings no CSS of its own, and integrates nicely with your favorite task runner.
We use a combination of Atomics and BEM in our project.
Atomics offers single level specificity thus providing a strategy to combat the specificity problem that plagues many projects.
They are single purpose and infinitely composable, which complements very well with component oriented architecture that's popular today.
They are localized to single DOM node. When combined with its single purpose nature offers fewer surprises when making changes to your style sheet. For example, when you add a margin 15 Atomics to a DOM node, it is very hard to accidentally add another margin 15 somewhere else. Versus if you add a label class, it is much easier to accidentally add another label class and cause unintended consequences.
this, pretty much. it's as declarative and surprise-free as you can get in CSS and it works super well when abstracted into components.
I know it isn't the easiest to read and it seems counterintuitive at first, but in practice you can easily encapsulate long chains of inline classes into helper classes thus giving most projects a sort of sane middle ground.
I don't know if this quite counts as the inner-platform effect [1], but it seems similar at least.
[1] http://thedailywtf.com/articles/The_Inner-Platform_Effect
Yeah, that seems accurate to me.
Stuff like this makes me wonder about the sanity of web development. They always seem to be looking for ways to abuse features for other purposes.
Most of it is learned from the environment. A lot of browsers which all implement standards in their own _fun_ ways across dozens of display types.
All of this is using a system that was effectively designed to share and display research papers 20 years ago.
Then you add the competition to _up_ everyone else. Sure you don't have to be the best, but you need to have flare.
The, code is much more readable then the same written with inline styles.
Citing their website:
Most approaches to styling inside components rely on inline styles, which are limiting. Atomic CSS, like inline styles, offers single-purpose units of style, but applied via classes. This allows for the use of handy things such as media queries, contextual styling and pseudo-classes. The lower specificity of classes also allows for easier overrides. And the short, predictable classnames are highly reusable and compress well.
Well that's one way to avoid using Content-Security-Policy with "unsafe-inline" (assuming someone cares about CSP?)
It's open source: https://acss.io
I hope they'll accept my pull request: https://github.com/acss-io/atomizer/pull/302
For everyone reading these comments, I want to say that this kind of pull request is hurtful and unwarranted.
You've essentially sent an alert to someone ( or a group of people ) saying that you believe their work has no value. This kind of behavior could have real-world consequences. You could be pushing someone to not work on open-source again, or make them feel worse about working on a project they might be required to contribute to as part of their job.
How would you feel if someone started vandalizing your own github projects gvx? Would it make you feel good? Would you consider it funny?
It was intended as an innocent tongue-in-cheek joke, not to insult or vandalise. In that, I've failed completely. I can see that now.
I'm closing the pull request with an apology.
I'm glad this is being called out. Thank you.
First day on the internet?
This is ridiculous. If someone tells you your project is bollocks and you decide to quit the open source world altogether, maybe that world was better off without you.
So because some people might take criticism personally we shouldn't be allowed to express criticism?
You're allowed to be a jerk, but when doing so you shouldn't be surprised if people call you a jerk (or use a nicer phrase like "this kind of pull request is hurtful and unwarranted").
Constructive criticism is good, but the linked PR is not that. It's akin to a content-less drive-by HN comment like "you suck". You're free to post it (until you get banned), but it's not adding anything and you should expect downvotes.
I agree with you and I'm not saying "delete your fucking project" is constructive criticism.
But, if an internet stranger says "delete your fucking project" and you take that personally there's no one to blame for your suffering than yourself.
Also, _Marak_'s paternalistic comment would make sense with a group of 10 year olds, but we are all adults here.
If you don't want to be treated like a 10 year old then don't act like one.
I'm sorry, could you explain what part of what I said was infantile?
This kind of criticism has 0 value. It basically says "you suck!". OP needs to grow up.
I asked a question because I want to start a debate, which is quite different.
I'm going to go a bit farther and say: correct, for non-constructive criticism, on HN, you shouldn't be allowed to express it.
The community values here don't support or endorse non-constructive criticism, and I am OK in saying that simply shouldn't be allowed.
There are other venues for that stuff, this isn't one of them.
Why would you do this?
You're an awful person.
You could at least ensure the CI tests still pass. :P
No need for tests to pass if they don't exist ¯\_(ツ)_/¯
Need to provide tests to make sure that the original problem doesn’t crop up again ;-)
Tachyons (http://tachyons.io) is another CSS framework that works the same way, more or less.
What a trainwreck.
It's so easy to end up doing this u_u;
All I can say is tht front-end is going crazy these days. Might give up soon.
Just the web, don't give up, switch platform ;)
Or, I don't know, don't use frameworks one doesn't like?
this is hilariously sad... absolutely awful.. no wonder their company is a disaster.
Thats what happens when you have a Turing complete styling DSL