Yahoo reinvented inline styles through classes | Hacker News Reader

Yahoo reinvented inline styles through classes

imgur.com

151 pointstroels47 comments

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:

  *[style*="text-align:justify"]{ 
       text-align: left !important;
  }

> 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

    .P(20px) {
      font-size: 10px; // 20px in base 5 is 10px in base 10
    }

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

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?

Thats what happens when you have a Turing complete styling DSL

Reply on news.ycombinator.com