CSS-only plotting | Hacker News Reader

CSS-only plotting

github.com

102 pointsteddet31 comments

Might as well use inline styling to accomplish the same (without adding tons of CSS):

    <div class="bar-chart">
      <ul>
        <li style="height:99%">99%</li>
        <li style="height:50%">50%</li>
        <li style="height:30%">30%</li>
        <li style="height:90%">90%</li>
        <li style="height:10%">10%</li>
        <li style="height:70%">70%</li>
        <li style="height:30%">30%</li>
        <li style="height:90%">90%</li>
      </ul>
    </div>

yep... been using that technic for years.

Agreed, especially since the inline approach allows more flexibility, like 66%.

I just came here to say the same. You can accomplish the first two chart styles quite easily, though the last might be a bit more involved.

Why do you bring this up? Is this more ideal? I thought writing inline css was an accepted awful thing to do. Or is that just a simplification for new developers? Why do you benefit from doing this?

If you look at the example on Github, it looks exactly the same as the GP with inline styles, except it uses data params.

GP is saying that there is next to no benefit to the approach proposed in this project compared to just using [the ugly and terrible] inline CSS.

      <div class="bar-chart">
          <ul class="container">
              <li data-cp-size="99">99%</li>
              <li data-cp-size="50">50%</li>
              <li data-cp-size="30">30%</li>
              <li data-cp-size="90">90%</li>
              <li data-cp-size="10">10%</li>
              <li data-cp-size="70">70%</li>
              <li data-cp-size="30">30%</li>
              <li data-cp-size="90">90%</li>
          </ul>
      </div>

Inline CSS isn't any more awful than any other meaningless presentational markup.

Why use inline CSS? Because it's simpler and obvious. The proposed hack has no upsides: it isn't any more accessible, isn't any more maintainable, and it isn't any more performant (quite the opposite).

To me it's in the same category as replacing `<font color=red>` with `<span class=red>`, because "font is bad".

The proposed hack has the upside that all of the bar charts on a site are governed by the same CSS.

The CSS is ugly because of the many redundant rules. But if you have x bar charts on y pages, then one ugly CSS file is better than x repeated ugly spots spread out in y HTML files.

tru.

Inline style for bar height doesn't preclude use of external styles for common properties like color, borders, etc.

Also it's very unlikely you'd have many charts with markup written by hand. I'd expect charts to be generated from a template from a proper data source, so change in markup of all charts would still be done in one place.

I think for graphing, its far better then whatever this library is doing.

It's not worse to put inline style on a tag, than bruteforcing all the possibilities in a css.

At least with inline style you can have the precision you want and are not forced to round your value.

Sooo, yeah it's an interesting exercise but I'm not convinced about the usefulness of that project.

This gives up some flexibility. If you want to switch from horizontal to vertical you have to change a lot more code. If you want to introduce a new face style that color codes bars based on height this wouldn't work.

I loved the simplicity, and wanted to know how it was done.

https://github.com/asciimoo/cssplot/blob/master/cssplot.css

  .bar-chart ul li[data-cp-size="0"] {
  height: 0%;
  }
  .bar-chart ul li[data-cp-size="1"] {
  height: 1%;
  }
  .bar-chart ul li[data-cp-size="2"] {
  height: 2%;
  }
  ...

Still find it cool, but a 1200 line CSS may be a bit too much for a practical application.

Just shows what CSS can do but won't use it in production.

Eventually once browser support is there we can reduce this to about 70 lines. By using

.scatterplot ul li[data-cp-y] { bottom: attr(data-cp-y %); }

I really wish browsers supported the second attribute of attr(). None do.

This will be so awesome.

Couldn't this be reduced by, like, a lot by simply using this CSS3 gem?

height: attr(sata-cp-size px);

Someday, but right now the support for using 'attr()' function in properties other than 'content' is very poor.

Correct, attr() for use with anything than the content property is unsupported by most browsers.

(https://developer.mozilla.org/en-US/docs/Web/CSS/attr)

Yes, once we get to the point where we can stop supporting IE <= 9. :)

Converting it to a LESS mixin (or similar) would be interesting, it'd allow you to bring in only the needed styles for the graphs you've used :)

Checking the source code, it actually starts out as LESS

It's very redundant so it gzips to 3kb.

Usually, "CSS-only" articles and repos are either technically impressive, or clever solutions for production environment problems.

Considering attribute selectors have been around for a while, I fail to see a decent use case. Any progress bar or 2-dimensional chart of this kind needs to be generated dynamically, either through the backend or frontend, same thing. In this case, they're inserted as data attribute values. What's the difference with using inline style attributes (left: 10%; width: 90%)? They're generated automatically, so verbosity is not an issue. And you'd save yourself 1200 lines of CSS.

What about flexibility? CSS provides the ability to style each of the 400 options differently, right? Well using a "x24 y78" CSS class would be as simple. But in the end, you only want to give different height/width bottom/left values. The styling remains unchanged.

Writing every possible option of a dynamically generated chart into a static CSS file, just for the sake of "Simplicity" and "No javascript required" seems like an overkill.

On a side note, anything dealing with percentages instead of pixel values is automatically granted the keyword "Responsive".

Neat idea, a little disappointed looking at the source though. A class for every possible datapoint doesn't scale particularly well.

No need for duplicating the value in the attribute and also in the element by including this snippet.

  [data-cp-size]:after { content: attr(data-cp-size) "%"; }

i think what you made is cool. keep making cool stuff.

With the addition of a few CSS transition rules these could be animated really easily.

if only CSS supported for loops and variables..

Reply on news.ycombinator.com