- Mark as New
- Bookmark Message
- Subscribe to Message
- Mute Message
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi there,
I have a <html> <style> block defined for a table in my dashboard. It is defining a custom column width.
It works when I only have a limited number of columns in my table (See "Table 1" in the example dashboard code below)
However when I add additional columns it stops working (see "Table 2").
I have searched high and low for a solution to this with no luck. Anyone got any ideas?
Here is an example dashboard that demonstrates the issue - the cveID column is the focus.
<form version="1.1" theme="dark" hideFilters="true">
<label>custom table column width not working</label>
<row>
<panel depends="$alwaysHideCSSPanel$">
<html>
<style>
#customWidth1 th[data-sort-key=cveID] {
width: 50% !important;
}
</style>
</html>
</panel>
<panel>
<table id="customWidth1">
<title>Table 1</title>
<search>
<query>
| makeresults
| table _time Hostname instance_id Remediation Description Severity ExploitStatus DaysOpen OldestCVEDays cveID</query>
</search>
</table>
</panel>
</row>
<row>
<panel depends="$alwaysHideCSSPanel$">
<html>
<style>
#customWidth2 th[data-sort-key=cveID] {
width: 50% !important;
}
</style>
</html>
</panel>
<panel>
<table id="customWidth2">
<title>Table 2</title>
<search>
<query>
| makeresults
| table _time Hostname instance_id Remediation Description Severity ExploitStatus DaysOpen OldestCVEDays OpenVulnCount DetectionLogic VendorRef VendorAdvisory Link cveID OldestCVEDate Application Version OldestCVEDate Application Version FirstSeen InstanceName amiName amiID awsOwner awsApplication Account_id AccountName DNSDomain OS IPAddress Team OU Site Environment Location OSGroup OSType</query>
</search>
</table>
</panel>
</row>
</form>
- Mark as New
- Bookmark Message
- Subscribe to Message
- Mute Message
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Understood, but I am getting the same squeezing of the column width even when there is a significant amount of data in the cveID field (e.g. 100+ CVE IDs).
I get the same behaviour if I define the style using px instead of %, and also using td as well/instead of th elements.
I found a workaround - padding out the field name using em space characters 👍
(note I didn't need 50% col width, that was just for the sake of demonstration)
Thanks for the quick response - I take it there is no way to force the style to be applied, overriding the default table rendering behaviour?
- Mark as New
- Bookmark Message
- Subscribe to Message
- Mute Message
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content

Table rendering will attempt to display as much data as it can so blank spaces will get squeezed to allow more columns to be shown, even if the width is set to 50%.
- Mark as New
- Bookmark Message
- Subscribe to Message
- Mute Message
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Understood, but I am getting the same squeezing of the column width even when there is a significant amount of data in the cveID field (e.g. 100+ CVE IDs).
I get the same behaviour if I define the style using px instead of %, and also using td as well/instead of th elements.
I found a workaround - padding out the field name using em space characters 👍
(note I didn't need 50% col width, that was just for the sake of demonstration)
Thanks for the quick response - I take it there is no way to force the style to be applied, overriding the default table rendering behaviour?
- Mark as New
- Bookmark Message
- Subscribe to Message
- Mute Message
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content

I haven't found a way (yet!) - I suspect that it isn't a Splunk issue, more of a browser / HTML rendering issue. I have even tried wide data which is hidden (display = none). Your solution with non-breaking spaces is a good one.
- Mark as New
- Bookmark Message
- Subscribe to Message
- Mute Message
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Cool.
Does my workaround qualify on here as a solution do you think? Temped to mark it as such, but don't want to stray from accepted practice, given I'd be rating my own advice 😂
- Mark as New
- Bookmark Message
- Subscribe to Message
- Mute Message
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content

I think it is reasonable to mark your workaround as the solution.
