Type auto-detected as 'html' rather than 'string' when column contains an empty value

themightystephen

Link to test case: https://jsfiddle.net/0pzgtqn9/14/
Debugger code (debug.datatables.net): N/A
Error messages shown: No errors, but potentially wrong behaviour
Description of problem:
As the question title says and the test case shows, in a scenario where the data for a column contains an empty string (whether via ajax or hard-coded in the HTML), DataTables type auto-detection logic computes that column's type as being 'html' rather than 'string', even if there is no HTML present.

This behaviour can be seen in the following Chrome debugger/breakpoint screenshot if you look at the value of d:

There is a condition in the logic here that checks _empty( d ), which seems to be responsible for this odd behaviour. Perhaps there is a logical reason behind it but it seems that if the value is empty, we shouldn't assume the type is HTML.

The jsfiddle test case linked above shows this behaviour happening if you check the jsfiddle console. For my case, this issue was discovered through the use of the diacritics-neutralise plugin, which overrides and relies on the behaviour of string type-based filter (jQuery.fn.DataTable.ext.type.search.string). This plugin stopped working as expected due to columns containing empty values being (incorrectly) detected as 'html' rather than 'string', leading to the diacritics plugin type-based filter not kicking in (since it overrides on the 'string' type, not the 'html' type).

NOTE: I am aware one can manually specify the column type in the DataTables configuration for a table, but ideally the auto-detection should get it right out the box. If necessary I can resort to using manual types but I'm trying to avoid where possible.

allan

but ideally the auto-detection should get it right out the box

Yes. It has occurred to me on a number of occasions to remove the ability to manually set type in fact, as I've seen that causing all sorts of problems that the auto type detection wouldn't cause.

In this case, I agree, it probably is undesired behaviour, but also I don't think it is going to result in any issues, with the exception of replacing the default string search. But with that replaced, I'd say it might be a good idea to replace the HTML search as as well.

I'll look into this for the next release - thanks!

Allan

allan

Its a good six months late I'm afraid, but I've finally got this done. The change is here and will be in the next release.

Regards,
Allan