One other Stab on the Good CSS Pie Chart… Sans JavaScript!

I had beforehand experimented with this sort of “indexing” CSS workaround, for instance, to compensate for the dearth of sibling-index() and sibling-count() features to generate random numbers. I knew this was the precise path and that the remainder would observe logically on the CSS facet.

Spoiler: sibling-index() and sibling-count() have gotten Baseline quickly!

It might appear like duplication since we didn’t add something however quite moved the attributes. Nevertheless, this slight change permits us to handle all labels and values from the mother or father in CSS. What’s finest, we nonetheless maintain all attributes shut collectively. And whilst you could say that this received’t scale as nicely, if we’ve knowledge with tons of entries, then a pie chart is never the only option to indicate it.

Optionally, we might add data-label attributes to the labels simply to pair labels and values visually.

  
  
Apple
  
Banana
  
Orange
  
Strawberry

Now let’s study the CSS. The implementation requires two units of some repetitive however easy CSS guidelines.

Firstly, we’ll must cross down every share to its corresponding slice. To take action, we use Juan’s and get the data-percentage attributes into CSS by means of the upgraded attr() operate. In parallel, we’ll assign them to the corresponding slice utilizing the nth-child() selector.

.pie-chart {
   /* We write one for every slice we predict we'll want */
  --p-100-1: attr(data-percentage-1 sort()); :nth-child(1) { --p-100: var(--p-100-1) }
  --p-100-2: attr(data-percentage-2 sort()); :nth-child(2) { --p-100: var(--p-100-2) }
  --p-100-3: attr(data-percentage-3 sort()); :nth-child(3) { --p-100: var(--p-100-3) }
  --p-100-4: attr(data-percentage-4 sort()); :nth-child(4) { --p-100: var(--p-100-4) }
   /*...*/
}

For that form of repetitive/incremental code, I maintain it as a one-liner with out carriage return. IMHO it’s a really acceptable exception to widespread formatting guidelines because it prevents typos by easing scan-ability of and likewise eases additional iterations (e.g., including help for extra slices). However your mileage could fluctuate.

Let’s look somewhat nearer at what’s happening right here. On the degree of the entire pie, we entry the chances for every slice by means of their index and retailer them in a corresponding CSS variable, so the fourth ingredient will get --p-100-4, the fifth ingredient will get --p-100-5, and so forth:

--p-100-4: attr(data-percentage-4 sort());

Subsequent, we cross every a --p-100 variable that’s native to every slice.

:nth-child(4) {
  --p-100: var(--p-100-4);
}

We now have all these slice values accessible at two ranges:

• On the pie, through listed variables: --p-100-1, --p-100-2, --p-100-3
• On every slice, through the --p-100 variable

Now, we’ll must calculate the corresponding --accum worth, which is the sum of the values of all earlier slices. To take action, we’ll must progressively sum every share after every slice, then assign the worth to the slice utilizing nth-child() once more.

.pie-chart {
  /* ... */
  --accum-1: 0;                                     :nth-child(1) { --accum: var(--accum-1) }
  --accum-2: calc(var(--accum-1) + var(--p-100-1)); :nth-child(2) { --accum: var(--accum-2) }
  --accum-3: calc(var(--accum-2) + var(--p-100-2)); :nth-child(3) { --accum: var(--accum-3) }
  --accum-4: calc(var(--accum-3) + var(--p-100-3)); :nth-child(4) { --accum: var(--accum-4) }
  /*...*/
}

Once more, we first work on the pie degree, the place we compute one devoted variable per slice. The primary slice is a particular case: there isn’t any earlier slice, so the buildup is 0. Whereas in the remainder, the buildup for the slice n is the buildup of the slices earlier than n−1 plus the worth of the slice n−1.

--accum-4: calc(var(--accum-3) + var(--p-100-3));

The fourth ingredient will get --accum-4, the fifth ingredient will get --accum-5, and so forth. Simply as the chances, on the degree of every slice, we assign them to the native variable --accum.

:nth-child(4) {
  --accum: var(--accum-4);
}

As soon as once more, we’ve all these slice accumulation values accessible at two ranges:

• On the pie, through listed variables: --accum-1, --accum-2, --accum-3
• On every slice, through the --accum variable

I hope future native CSS options (maybe @operate?) will forestall us from having to resort to such repetitive code. Within the meantime, this may be simplified with a CSS preprocessor (Sass, Much less).

Whereas forking the unique Pen, some questions popped out in my thoughts — that I didn’t really discover — to maintain the unique code as unchanged as attainable:

• What about utilizing  and  for labels and values?
• What about utilizing a 
   (since charts are sometimes extracted from tables with rows like [label, value])?

  Observe About Accessibility

  In my fork, I dealt with accessibility the identical approach Juan did, however with one slight modification: I used counter-reset / counter() as a substitute of attr() to assign the chances to the content material property. This could work simply nearly as good as attr(), however let’s ensure it's nonetheless screenreader-friendly:

  One other factor I considered altering was the label components inside every 

  . Within the unique article, Juan makes use of a  ingredient, whereas I opted for  as a substitute. Nevertheless, I believe it might be completely acceptable to make use of the  itself. We usually consider them as being bounded inside  components, however the spec says that we might count on to make use of them in contexts “the place phrasing content material is anticipated.” So I couldn't discover any obligation to make use of them solely within the context of kinds.

  Default Colours

  Juan’s article additionally known as upon some enhancements, which I attempted to handle in my fork:

  • data-color might be omitted, and colours are then generated.
  • Colours might be outlined both on the mother or father or on the kids (person’s selection; each are supported).

  This interprets to the subsequent snippet for every slice:

  .pie-chart li {
    --color: attr(data-color sort());
    --bg-color: var(--color, hsl(calc(360deg * sibling-index() / sibling-count()) 90% 40%));
  }

  I avoided utilizing sibling-index() and sibling-count() in the principle half, since they aren’t Baseline (but, however quickly!), however I couldn’t maintain myself again since calculating the colour hue is a lot fancier with them. These features actually enable some magic!

  Nonetheless, right here is my “CSS-only polyfill”; repetitive (but easy) code:

  .pie-chart {
    :has(:nth-child(1)) { --sibling-count: 1 } :nth-child(1) { --sibling-index: 1; }
    :has(:nth-child(2)) { --sibling-count: 2 } :nth-child(2) { --sibling-index: 2; }
    :has(:nth-child(3)) { --sibling-count: 3 } :nth-child(3) { --sibling-index: 3; }
    :has(:nth-child(4)) { --sibling-count: 4 } :nth-child(4) { --sibling-index: 4; }
    /* ... */
  }

  Extra Chart Varieties?

  We now have a typical basis for different chart sorts. As a proof of idea, I carried out a bar chart mode in my fork.

  A Net Element, Maybe?

  In a approach, we have already got an online part right here — one with out JavaScript, utilizing gentle DOM.

  And to me  isn't essentially totally different that both 

   or 

  . I can see worth on this strategy when contemplating progressive enhancement, although.

  For instance, a chart that refreshes mechanically and fetches stay knowledge. However that will require JavaScript — which we're intentionally avoiding as we speak.