Comment

Comment by nilliams

Okay, interesting. I perhaps don't understand enough about the syntax to appreciate why those lower-level constructs would be beneficial w.r.t the geo stuff.

On the styling sure, data should often dictate the style in visualisations - the most noddy example people tend to give in JS as the exception to the rule of never 'programatically' (JS) setting styles is the progress bar where the width has to be data-based (as CSS-classes only make sense for discrete increments or 'states'). Of course the same applies for colouring/shading and sizing based on say population data or whatever is being modeled in a visualisation, I get that.

But, in the example on the first page the bars of the histogram are all explicitly coloured gray w/ white text programatically and the bar heights are manually set to '20' (presumably px). What would make more sense is for them to have a default class of say 'hist-bar-default', which is set in CSS to { height: 20px; background: gray; color: white }. If anything it would just make the example simpler as it actually muddles up the code where the widths are being dynamically set. shrug

Edit: btw, you will see that d3.js does this, it applies classes where appropriate rather than setting styles explicitly: http://mbostock.github.com/d3/ex/cartogram.html

parent nilliams 14 years ago

Discussion

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton