<chart type="pie"> landed in #1891 with displayValues printing the value, the way it does on every other type, and with each slice's annotation reading North: 41. Neither prints the share, and a pie's whole subject is the share.
This was deliberately left open rather than decided in that PR, because it is one question with two faces and half an answer is worse than none:
- What
displayValues prints on a slice. Today the value. A percentage would need displayValues to stop being a boolean — displayValues="percent" alongside displayValues="value", with displayValues and displayValues="true" still meaning what they mean now — and that change lands on bar, line and scatter too, where a percentage of a total is not always a thing that exists. A second attribute (displayShares, say) avoids that at the cost of two attributes doing one job.
- What a screen reader hears. The annotation is
${category}: ${value}, matching every other type. A reader who cannot see the slices has less access to the proportion than a sighted one, not more, so if anything this is the more important half. North: 41 (21%) is translation-safe — there are no words in it — but it is a second number in every announcement, and it should not be decided separately from the visual one.
Whatever is chosen has to answer:
- Rounding.
1/3 is 33%, 33.3% or 33.33%? A pie of 1 1 1 whose slices are labeled 33% visibly does not add to 100.
- Whether the percentage is readable from
$chart at all. There is no property today reporting a slice's share or the pie's total; $chart.values gives the values and an author can write <sum> over them, so a document can compute a share for prose. A total or shares property would be the smaller, less committal move, and might be enough on its own.
- Whether
bar and line get it too. A stacked bar chart has a per-slot total and the same question; a scatter does not.
The narrow option worth considering first: leave displayValues alone, expose the shares as a property, and revisit slice labels once there is a second type that wants the same thing.
Part of #437.
🤖 Generated with Claude Code
<chart type="pie">landed in #1891 withdisplayValuesprinting the value, the way it does on every other type, and with each slice's annotation readingNorth: 41. Neither prints the share, and a pie's whole subject is the share.This was deliberately left open rather than decided in that PR, because it is one question with two faces and half an answer is worse than none:
displayValuesprints on a slice. Today the value. A percentage would needdisplayValuesto stop being a boolean —displayValues="percent"alongsidedisplayValues="value", withdisplayValuesanddisplayValues="true"still meaning what they mean now — and that change lands onbar,lineandscattertoo, where a percentage of a total is not always a thing that exists. A second attribute (displayShares, say) avoids that at the cost of two attributes doing one job.${category}: ${value}, matching every other type. A reader who cannot see the slices has less access to the proportion than a sighted one, not more, so if anything this is the more important half.North: 41 (21%)is translation-safe — there are no words in it — but it is a second number in every announcement, and it should not be decided separately from the visual one.Whatever is chosen has to answer:
1/3is33%,33.3%or33.33%? A pie of1 1 1whose slices are labeled33%visibly does not add to 100.$chartat all. There is no property today reporting a slice's share or the pie's total;$chart.valuesgives the values and an author can write<sum>over them, so a document can compute a share for prose. Atotalorsharesproperty would be the smaller, less committal move, and might be enough on its own.barandlineget it too. A stacked bar chart has a per-slot total and the same question; a scatter does not.The narrow option worth considering first: leave
displayValuesalone, expose the shares as a property, and revisit slice labels once there is a second type that wants the same thing.Part of #437.
🤖 Generated with Claude Code