Move dynamically added styles into Shadow DOM

It would be good if google-chart support the Table graph.

[pkuvegeta]

+1

[sgomes]

Thanks for the suggestion!

There's now a few graph types that folks have suggested that are part of extra packages, so I'll need to look into what the best strategy is for loading them; whether we should do so preemptively or only once the chart type is defined.

[SmokyBob]

+1

[sgomes]

Thanks for the PR, @SmokyBob! I have a similar implementation in the works, but yours is cleaner, so I'll probably just use that, thanks! However, it's running into the same issue as mine: loading extra CSS.

The table chart type, as well as a few others (such as the org chart type) use native HTML elements instead of SVG to draw the charts. This is all well and good, except that they load extra CSS to style them, and they do so by attaching it to the document head. That does not play well with the shadow DOM, and means the elements end up unstyled.

I see several approaches to solve this problem:

• Leave it up to the user to figure out. Not the best approach, since default styling is something they usually get for free, and it isn't exactly easy for them to get a copy of the dynamically loaded CSS resources to start from.
• Include copies of the extra CSS with google-chart. We'd need to keep a close eye on any Google Visualization API releases to make sure all CSS is always up to date for all chart types. And this is assuming the API isn't doing any sort of clever on-the-fly CSS rule writing.
• Set up an object observer on the document head, and for every dynamically added CSS resource rewrite all added CSS rules to pierce the shadow DOM boundaries. Parsing CSS is a bit of a nightmare, so this seems like a bad idea.
• Set up an object observer on the document head, and copy any dynamically added CSS documents to inside the element's shadow DOM. This would introduce duplication on the order of how many elements there are on the page.

The latter is my currently favoured approach, but I'm not particularly happy with any of these. I'd love to hear what the folks following the issue have to think on this!

[SmokyBob]

Hi @sgomes, glad to help.
I took sometime thinking about what could be a solution that is both functional and the least difficult to manage.
Would be awesome to be able to directly get the styles from the visualization API with something like google.visualization.getStyles() or google.visualization.Table.getStyles() to get the URL and add the import in the shadow DOM from the component without using and observer... but for now observing the head element for changes seems the only viable way.
My2Cents

[SmokyBob]

Tried to set up the observer to get the CSS.
No problem identifying when the CSS element is added to the head, when the browser finish to load the stylesheet.... but I have no Idea how to get the CSS styles themselves to add them in the shadowroot...

Here a gist with the code I've tried
CORS is not supported so the second piece of code doesn't work, the first waits for the link element to be loaded and try to search for one of the classes that are loaded by the API as you can find out in the devtools...

If anyone has any other Ideas, they are more than welcome

[sgomes]

So to add to this, as far as I can tell there's currently no way to implement support for the added styling.

It's easy enough to detect changes, as @SmokyBob mentions, but we then need a way to actually apply them as needed:

• adding a link inside the shadow DOM: this approach does not work, since links are ignored inside the shadow DOM (this was a surprise to me). Polymer's apparent support for <link> tags inside the element template is, I suspect, based on some clever static tricks; in any case, any dynamically inserted <link> tags get promptly ignored.
• adding a style tag with the content: as @SmokyBob mentioned, CORS is not enabled, so we can't make an XHR request to retrieve the styles.

Unless I'm missing something, the only solution for now seems to be to provide the markup, but no styling. Polymer 0.8 may give us a way of solving this, but for now it seems we're stuck :(

[philipwalton]

I think the <google-chart> element should package up some default styling in it's shadow DOM. That would be the "Web Component-y" way of doing things (rather than using global styles with the /deep/or >>> combinators). The default styling could be the same as the current table chart defaults, but I don't see any reason it has to be (it's kinda ugly).

If users want to override the default styles they have a few options:

1. Extend the <google-chart> element and set their own style overrides.
2. Compose the <google-chart> element inside of their own element and use the ::shadow pseudo-element selector to override the default styles.
3. Set the cssClassNames chart option in combination with either 1) or 2) above to start fresh.

I'm happy to submit a PR with these changes as I want to get this working with the <google-analytics-chart> element anyway.

@sgomes what do you think?

[SmokyBob]

@philipwalton IMO adding the default styling, even if a bit old and didn't age well is a good idea and compromise.
Using the current table styling just to keep the element behave the same as the Google Chart API and avoid causing possible confusion in the users that use the google-chart element.

For different, more modern, Material styles we could have something like a materialTable chart type to load the google.Visualization.table package but apply the new style?

[sgomes]

@philipwalton Thanks for helping out! I think it's a reasonable compromise, yes. I'm not thrilled about us keeping static CSS against a library with regular updates, but I still think it's a better approach than just throwing markup at users with no context.
As for what exactly the styling should look like, I don't think it's a big concern, as long as we have something and it's easily overridable (your suggested approach is perfect).

@SmokyBob: I'd rather stay away from calling anything "Material" unless it's based on the spec or has gone through the right reviews, so I think we're better off just having the default styling. Again, it should be pretty easy for users to override styling, either outside of the component by using ::shadow, or by extending it and modifying the styling.

[philipwalton]

Finally got around to working on this. Here's the PR: #34