Unexpected number of TD / extend sanity check
Unexpected number of TD / extend sanity check
Hi Allan,
first: thanks for your nice script!
I have a problem with the "old" Unexpected number of TD-issue ;)
I know that datatable will not support row/colspan in tbody, and that it will need a unique th for each column. My table is a plain table with thead / tbody, but the first column of the tbody is a th, not a td. This markup is valid and semantically useful - but it will not work with datatable.
Without any row/colspans allowed, the santity-check expects a matching number of td = row x col, so it doesn't take into account the th.
As far as I understand, datatable would work fine even with th in the tbody section (as only the th in thead are used to trigger actions). Would it be possible to extend datatable / the sanity check in a way that it will test for the correct number of cells (td + th) = row x col so that the script would work with these sort of tables too?
Or do I miss an important point? ...
regards
Jean
first: thanks for your nice script!
I have a problem with the "old" Unexpected number of TD-issue ;)
I know that datatable will not support row/colspan in tbody, and that it will need a unique th for each column. My table is a plain table with thead / tbody, but the first column of the tbody is a th, not a td. This markup is valid and semantically useful - but it will not work with datatable.
Without any row/colspans allowed, the santity-check expects a matching number of td = row x col, so it doesn't take into account the th.
As far as I understand, datatable would work fine even with th in the tbody section (as only the th in thead are used to trigger actions). Would it be possible to extend datatable / the sanity check in a way that it will test for the correct number of cells (td + th) = row x col so that the script would work with these sort of tables too?
Or do I miss an important point? ...
regards
Jean
This discussion has been closed.
Replies
I think you raise an excellent point here - thank you for bringing it up. You are absolutely correct that your HTML is valid and semantically useful, and also that it will not work in DataTables as it stands! The reason I've done it the way it currently is, is basically an optimisation. I must confess I hadn't expected to see TH elements in the TBODY, thus the lack of counting them, and since this is the first time this has been brought to my attention, I'm going to guess it's not a common thing to do. That's not to say that it is not an unreasonable thing to do thought! I suspect that adding support for this actually wouldn't be very difficult, but before I do I'd like to understand the use case, since it will slow things down (admittedly only a very small amount - but I'd rather keep it faster than account for edge usage, where the core code could be locally modified).
The benefit is obvious in that you could have TH elements in the TBODY, but why would you want to do that? What would you gain over (or something to that effect!) given that the TH element is going to be moving around with sorting and popping in and out with filtering, which doesn't seem to quite fit with the meaning of TH.
Regards,
Allan
thanks for the follow up ...
> but why would you want to do that?
;) nothing strange, just trying to write semantic markup.
Many tables have a "real" header and a first (data) column with informations which can be considered as header infos for the row too. There are several ways to express this relation: by using the "headers" or "scope" attribute, or by using the TH tag. Actually, we use a "TH scope=" in most cases.
> What would you gain over
no, adding a class would only add some chrome, but no semantic information. But as mentioned before, "TD headers=" or "TD scope=" could be used for the same purpose instead of the TH ...
So we could change our markup to "TD scope=" ... but I would like the idea that datatable would not make any assumptions which way is used for semantic markup of the tables.
> given that the TH element is going to be moving around with sorting
> [...] which doesn't seem to quite fit with the meaning of TH.
No - as it's meant as a heading for the row data, which is moved around in the very same way, it doesn't bother ...
Please, will you allow me to mention another issue, which is somehow related to the topic?
We are using the column filter feature (very nice!), which has a prerequisite of an empty table row with input fields.
I think about datatable as a sort of enhancement (in the context of Progressive Enhancement, maybe) for plain tables, so the tables should have a valid markup even when no enhancement is used. But in the case of datatable we would end up with a somehow invalid markup (at least in a semantic context) if the script is not running. So in my opinion the creation of the filter row should be moved from the "normal" table creation to a datatable function itself.
Of course I'm able to write a few lines of js/jquery to create the input row dynamically, and most people who use datatable will have no problems either - but I think this should be a core function of your script, instead of relying on a somehow crude table layout. What do you think - or is this forcing too much functions into the core?
tschau
Jean