For some time (since at least Splunk 6.3), SimpleXML has supported using the <style>
element to include CSS settings directly in a SimpleXML dashboard. It commonly appears in a hidden element like the following
<row depends="hiddenCSS">
<html>
<style>
/* insert CSS here */
</style>
</html>
</row>
This does not seem to be documented in the SimpleXML reference: http://docs.splunk.com/Documentation/Splunk/latest/Viz/PanelreferenceforSimplifiedXML#html
From my own testing, I know that using CSS selectors, e.g., [id^="panel_custom"]
, is not supported using this method. However, directly specifying CSS classes and IDs seems to work fine.
Does Splunk consider this an officially supported use of SimpleXML?
If so, are there any other side-effects or limitations that users should be aware of?
So, here is the explanation from Splunk.
It is supported in the general case because the <style>
tag is a legitimate HTML entity; however, it is a potential mechanism to do malicious things. There is no guarantee it will be supported in future versions, and the web.conf configuration file even has a way of disabling it. Here are the details from web.conf for dashboard_html_allow_inline_styles
dashboard_html_allow_inline_styles = <bool>
* If this setting is set to false styles attributes from inline HTML elements
* in dashboards will be removed to prevent potential attacks.
* Default is true
So, for quick wins and little things it is probably OK, but maintained projects and apps probably should not use it.
So, here is the explanation from Splunk.
It is supported in the general case because the <style>
tag is a legitimate HTML entity; however, it is a potential mechanism to do malicious things. There is no guarantee it will be supported in future versions, and the web.conf configuration file even has a way of disabling it. Here are the details from web.conf for dashboard_html_allow_inline_styles
dashboard_html_allow_inline_styles = <bool>
* If this setting is set to false styles attributes from inline HTML elements
* in dashboards will be removed to prevent potential attacks.
* Default is true
So, for quick wins and little things it is probably OK, but maintained projects and apps probably should not use it.
Hi,
Not sure if this is an answer, but I can share my experience as an app developer.
Within the Nmon app I use a lot of CSS customization to make user interfaces more user friendly, better look and feel or to answer to specific needs.
Most of the time I will rely on CSS and JS external files, for quick win this can be as well inline CSS for basic stuff. (font size etc of a specific panel HTML content)
The app is widely used and maintened since more than 2 years and a half, during that time I have seen many main Splunk releases and maintenance releases.
By experience I would say that CSS customization is not an issue in most cases, for obvious reasons it makes more sense to store CSS codes in external files and make the relevant use of classes, etc.
And yes it is required for advanced technical stuff such as auto selection on IDs, etc. It is much cleaner and logical not to store this code into a dashboard in any case. (And your code becomes recyclable)
Whatever you use inline or files, the issues we can face against Splunk evolution will rely on the stuff you are doing and if Splunk updates classes and so on, or make important changes.
However I would say that Splunk has a great and efficient level of interoperability between versions (hey that's Splunk ;-), very rare have been the cases that I needed to do major updates to comply with new versions behaviors.
Just a personal experience and opinion.
Guilhem
Thanks as usual Guilhem. You always have great input.
Kind of hoping a Splunk employee can chime in saying if this is an official feature or not.