Eliminate external CSS

[curran]

Currently Chiasm visualization plugins require that some CSS be loaded on the containing page. Ideally, the entire visualization appearance should be configurable from within the Chiasm configuration, and not depend on external CSS. As an example, see this dashboard demo http://bl.ocks.org/curran/4ce2ee825811f1c32125#axes.css

The required CSS relates mostly to axes. Resolving this issue involves moving that static CSS into dynamically added CSS that is configured from the Chiasm JSON configuration. This would enable any page to include Chiasm visualizations via JavaScript only, and not require the addition of any CSS link to the containing HTML source.

[Hypercubed]

Maybe have a look at https://github.com/css-modules...

[curran]

Thank you for the link. It seems like CSS modules require an ES6 build step (with JSPM, WebPack, or Browserify) based on what I see in https://github.com/css-modules/css-modules . Reading through this led me to discover this interesting post CSS Modules - Welcome to the Future - 2015-08-19, which points back to Christopher Chedeau’s “CSS in JS” talk from NationJS in November, 2014. This is basically the same idea I had, which is to have JS/D3 set inline styles based on parameters from the Chiasm configuration.

Here's an example I made to test out the idea - Axis Styles via JavaScript.

[Hypercubed]

One benefit of inlining styles is that the svg is complete. I had to go though pains in in https://github.com/Hypercubed/angular-downloadsvg-directive to make sure css styles are copied to the svg before download.

You might also consider name spacing your css classes so that they don't interfere with other page elements (or otherwise limiting your d3.select). The css modules technique is to add the file path. So .axis could become . _index_html__axis. You could prefix the plugin name: ._chiasm_barChart__axis.

[micahstubbs]

👍

[Hypercubed]

In my opinion (which does have a tendency to change) is that styles should be inline (explicitly stated in the plugin/d3 code) only when the style depends (or may depend) on the data. For example if the points on a scatter plot can vary their fill color by data value, that should be inline (even then maybe should default to css if no style is give). Otherwise CSS is much more powerful.

My list of drawbacks to inline styles:

1. They cannot be overridden using CSS.
2. You cannot use pseudo selectors (for example .dot:hover { border-width: 2px; }).
3. You need to provide a hook in your model-js/plugin for each style you want to make customizable (including on-hover styles).

The advantage of using inline styles:

1. Avoids collision (I think can be solved with name spacing using the css-modules-like technique).
2. Saving the SVG (I'm working on a solution for that).