CSS custom property support for column widths

[tiwe-ppi]

Description

Our application supports different themes for different customers. To achieve this, we use CSS custom properties to define column widths, with each theme having its own set of values. So basically this:

{
    columns: [
        { width: "var(--foo-bar)", /* ... */ }
    ],
    // ...
}

This approach worked well with DataTables 1.11.5. However, after upgrading to DataTables 2.2.2, it no longer functions as expected. I suspect this issue arises because regular expressions are now used to parse the width values, likely for optimization or parsing reasons.

Workaround

We have devised a workaround by pre-computing the pixel values for column widths in JavaScript before initializing the table. While this is a feasible solution, it adds extra complexity to our code.

Request

Is there a possibility to officially support the use of CSS custom properties for column widths in future versions of DataTables?
I think this would be a nice feature for datatables but as we have a functioning workaround we can live without it.

Thank you for considering this suggestion.

[AllanJard]

Interesting one! I've never come across that use case before, so yup, I'm not too surprised something has changed to break it I'm afraid.

In 2.x the way column widths are calculated did change a lot, in part due to the complex header support. For this reason there is now this function which will take the given columns and calculate their width. I've just been looking at it and it would be possible to add:

		else if (definedWidth.match(/^var\(/)) {
			// CSS variables, but only works for a single column
			return definedWidth;
		}

into the if chain, but it would only work for non-colspan'ed elements.

It also still wouldn't be propagated to the table itself. What happens is that DataTables constructs a "worst case" table from the longest strings in each column, assigns the defined widths (i.e. your variable) and then reads back the column widths that the browser actually renders this as. The reason for this is that it allows for mistakes such as column widths not adding up to 100% table width, or content overflowing, etc etc (table column widths are a dark art that I don't fully understand!). Those read back widths are what is used by DataTables for the main table - so it will always get a pixel value in 2.x, even if a width is specified in another unit.

It isn't perfect, but its the best I've got so far.

Long way of saying, it is something I could look at putting in, but it might not do exactly what you are expecting. It might be worth adding that condition into a local copy of DataTables (do it just before the else in that block) and see if it does what you need. Then let me know and I can consider adding it in and what any other implications might be.

[tiwe-ppi]

I think if it is limited to a single column it doesn't really make sense. In that case I would say don't worry about it and better not support it at all.

I think what could be done is do the definedWidth.match(/^var\(/) check and evaluate the value in pixels and use that for the computation. One way to do this could be something like this: https://codepen.io/timw-ppi/pen/wBvRxEK?editors=1111

I think evaluating the custom property always requires a connected HTML element which is not ideal. Our current workaround is this:

1. Before DataTables gets initialized we insert an invisible element (<div>) into the table container.
2. We set visibility: hidden and position: absolute on that element
3. We iterate over the columns, check for those whose widths start with var(-- do invisibleElement.style.setProperty("width", column.width)
4. Set column.width = invisibleElement.getBoundingClientRect().width

I don't see a different solution. Maybe this could be simplified with jQuery.

I think it would be cool if DataTables supports this somehow but as I said we already have our workaround so no pressure at all!

[AllanJard]

Yup that could work although it will slow things down a little (read the size back will force a reflow) and the CSS selector would need to be general enough the it would apply to the element used for sizing as well (th { var: ...} wouldn't work for example).

Let's leave this open and see if anyone else comments to indicate that it is something they could use as well. It is a neat idea and I do like using CSS variables where possible.

Thinking about it, a workaround would be to assign the CSS variable to a class name, and use columns.className, rather than columns.width. That would address the issues above.