So I have to choose between a several Meg download vs using JavaScript to render styles?

No thanks.

Honestly I thought bootstrap was the only css I would ever need, and this hasn't changed my mind.

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:

  <!-- bad [sic] -->
  <div class="red pull-left">
  <div class="grid row">
  <div class="col-xs-4">

  <!-- good [sic] -->
  <div class="header">
  <div class="basket">
  <div class="product">
  <div class="searchResults">

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'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.

See https://news.ycombinator.com/item?id=11737510

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.

I know this is meant as a joke, but having used BassCSS[0] in a production webapp, I believe it really is a valid approach to CSS.

To each their own, I guess.

[0] http://www.basscss.com/

go on and just waste more time on this by reading the comments

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.

Does this compile with vanillajs?

I've done this before. The performance on IE, firefox, safari and mobile is complete shit yet suprisingly good in Chrome.

cornflowerblue was a nice touch.

(Sorry about that, but we can’t show files that are this big right now.)

Uh oh

For about 15 seconds I was horrified. Time to go to bed.

> Of course it's a joke.

whew, had me going there

Obviously, it's just a joke.

Sign me up.

These frameworks get everywhere.

Cool

> Where is the documentation? > You don't need documentation.

What constitutes self-describing code is wildly different depending on the person. I mean, really?

EDIT: I definitely missed that this is a joke :'(

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...

People really waste their time on these jokes.

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.

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 add to this, the addition of a style guide is helpful on two fronts.

* 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

It should be. But... https://vimeo.com/147806338

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.

In all seriousness, what advantages do you see over writing inline styles?

  className="mt0"

  className="mt1"

    style="margin-top: 1rem;"

    style="margin-top: 2rem;"

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).

1. way less clutter and repeating, my whole style is in one line per tag.

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. :)

sure, I searched for tests just before I posted my comment.

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.

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.

The sticking point for enterprise-y things remains IE, since it only supports flexbox (buggily) as of IE11.

Though there's polyfills like flexibility out there, of course.

For what it’s worth my project is about 2.5% no flexbox, which is too high to move over really.

Yes, schools use chromebooks