6 ms·

It seems standard that all of these JS table libraries are rendering using <div> elements instead of a <table> element. Why? This really irks me. As far as I ca

It seems standard that all of these JS table libraries are rendering using <div> elements instead of a <table> element. Why? This really irks me. As far as I can tell, all of the features could be implemented using the correct HTML element rather than using <div> to mimic a table.

djaychela 8y ago
I'm certainly not an expert (beginning Python programmer who knows very little about Javascript), but I thought it was because divs can be responsive and tables can't be, but I'm prepared to be corrected on that.
- EMRZ 8y ago
  I work as a developer in a trade marketing company, our platform have dashboards with different type of charts for our clients to measure different metrics of their business. The front end requests to the backend each chart on the current dashboad, then the backend, depending of the type of chart, gets the data from the database and passes it to the front who renders it, it could be a pie chart, a bar chart, a table, etc. We hade 2 or 3 different types of table charts, al using different js based solutions, one of them using bootstrap, i don't remeber the others. The javascript solutions had responsiveness issues, when you changed the size of the window, or used something that is not Chrome, column headers messed everything up. One day i decided to end that and added a new type of chart, it expected one table resultset from the db, and once in the front it rendered a traditional <table> with it's content. We have no more problems with table charts. It works in every browser and every screen resolution. It was possible to fix the current js tables of course, but is it realy necessary? We have been using tables since forever, and they are just to correct way to display table data on the web. Thats it, it just works.
- JangoSteve 8y ago
  There are many ways to make HTML tables responsive: https://css-tricks.com/responsive-data-tables/ https://css-tricks.com/responsive-data-tables/
warpech 8y ago
Author of another library, Handsontable, here. We actually use <table>, but there are many things that are easier with <div>: - With <div>, you have complete control over the positioning of the cells. With <table>, you delegate the layout to the browser engine. - <table> has lots of semantic meaning, which makes it slower to render than a <div>, because the browser engine needs to make a sense of it. - There are differences in how <table>s are rendered in various browsers. This is especially a problem with old browsers such as IE6. - It is trickier to implement things like floating headers, virtual scrolling with <table> Still, Handsontable uses <table> because you can overcome these problems if you're motivated enough. The biggest benefit is that <table> gives you enhanced semantics, which are good for Accessibility, SEO or any other form of code processing.
- BjoernKW 8y ago
  In addition to that, using <table> gives you out-of-the-box Excel file export because .xlsx files (which are basically zipped XML files) support HTML tables.
- twanvl 8y ago
  Could use use <table> for the semantics but set display:block to get <div> style layout?
  - olifolkerd 8y ago
    the problem is it isnt just the table element, it is the thead,tbody,td,th elements as well Complex interactive tables need a great number of elements to make them run and these wont conform to the standards of using a table (you cant just put a div inside a tbody element) but that is exactly what you would need to to to get a table with a virtual DOM to work correctly. There are a lot of different styling tweaks that would need to be overriden for each element, some of which arnt consistent across each browser. Also people have a tendency to put styles on the generic table tab to style tables across the site. if Tabulator was to then be used on the page, it could have any number of unknown CSS properties set on it, so would essentially have to look at overriding all possible style properties. where as no one generically styles divs or spans and they come with very little built in styling making them the ideal choice for a library that wants to keeps its functionality isolated from the rest of the site
lunchables 8y ago
I've worked with datatables quite a bit and it uses standard table tags: https://datatables.net/ https://datatables.net/
- noir_lord 8y ago
  That's what I use at work, I just wrapped it with Vue and did some moderately horrible stuff internally to allow reactive rendering (and by moderately I mean horribly). Performance is solid, it's easy to work with for ~90% of the times I use it and there are other ways to handle that last 10%. I probably wouldn't have used datatables on greenfield but the legacy (in every sense) project I inherited already used it so I went with it anyway.
olifolkerd 8y ago
Let me preface my answer by saying im the chap that built Tabulator This is because the <table> element introduces a lot of design constraints. There is a lot of inhernt styling that would have to be overridden if a table element was to be used. it could also mess with the standard behaviour of other table elements that have been generically styled. Importantly when you start building interactive complex tables there are 100's of different types of elements needed to make the table function correctly that a standard HTML element simple isn't designed to handle, event making the header and the body scroll separately requirements more elements that a standard table can handle and it would invalid HTML to use the tags inside the table that would be needed to achieve it. Especially when you move into the world of the virtual DOM a standard table element simply wont cut it With the inclusion of aria tags there are no accessibility issues as screen readers treat them just as any other tables.
- Rumudiez 8y ago
  For others; your last point is the most important. Semantic HTML gets you pretty far but there will always be an unhandled case. This is a fine use case of ARIA as long as it’s met with sincere concern for accessibility testing.
- ohitsdom 8y ago
  Appreciate the details. I've done some minor JS-based table controls while using <table>, but I wasn't dealing with thousands of rows so didn't need the virtual DOM. Sounds like that's the biggest obstacle. Nice work on the project!
- damntrecky 8y ago
  For the nested markup and styling it sounds like a perfect fit for creating a web component no? The virtual DOM, while very impressive, isn't necessary as well. Really depends on what problem you are solving there and what level of support you need for browsers. What problem are you solving? Many entries? Minimal cell mutation control?
  - olifolkerd 8y ago
    For Tabulator the virtual DOM is essential. if you try and load 10,000 rows into a table either the browser will slow down and become almost unusable or crash entirely. For large data sets it makes the table work regardless of the number of rows
kgwxd 8y ago
Try it, it doesn't take long to figure out there's no good way to do even basic features without fighting very hard against the built-in behavior of tables. Also, for even just 1000 rows, all browsers still suck at redrawing if any little thing changes, I believe it's because the entire layout of the table has to be recalculated no matter how small the change is.
- olifolkerd 8y ago
  Spot on!, Tabulator uses a virtual DOM to get round the limit on the number of rows, and that simple isn't achievable in a standard table element
JangoSteve 8y ago
A library I built called Dynatable doesn't do that! It uses semantic, standard table elements for all serializing and rendering of tabular data. We've since rewritten Dynatable to use vanilla JS and are in the process of renaming it to simply Dynatable instead of jQuery Dynatable. https://github.com/alfajango/jquery-dynatable https://github.com/alfajango/jquery-dynatable https://www.dynatable.com/ https://www.dynatable.com/

djaychela 8y ago

I'm certainly not an expert (beginning Python programmer who knows very little about Javascript), but I thought it was because divs can be responsive and tables can't be, but I'm prepared to be corrected on that.

EMRZ 8y ago
I work as a developer in a trade marketing company, our platform have dashboards with different type of charts for our clients to measure different metrics of their business. The front end requests to the backend each chart on the current dashboad, then the backend, depending of the type of chart, gets the data from the database and passes it to the front who renders it, it could be a pie chart, a bar chart, a table, etc. We hade 2 or 3 different types of table charts, al using different js based solutions, one of them using bootstrap, i don't remeber the others. The javascript solutions had responsiveness issues, when you changed the size of the window, or used something that is not Chrome, column headers messed everything up. One day i decided to end that and added a new type of chart, it expected one table resultset from the db, and once in the front it rendered a traditional <table> with it's content. We have no more problems with table charts. It works in every browser and every screen resolution. It was possible to fix the current js tables of course, but is it realy necessary? We have been using tables since forever, and they are just to correct way to display table data on the web. Thats it, it just works.
JangoSteve 8y ago
There are many ways to make HTML tables responsive: https://css-tricks.com/responsive-data-tables/ https://css-tricks.com/responsive-data-tables/

warpech 8y ago

Author of another library, Handsontable, here. We actually use <table>, but there are many things that are easier with <div>: - With <div>, you have complete control over the positioning of the cells. With <table>, you delegate the layout to the browser engine. - <table> has lots of semantic meaning, which makes it slower to render than a <div>, because the browser engine needs to make a sense of it. - There are differences in how <table>s are rendered in various browsers. This is especially a problem with old browsers such as IE6. - It is trickier to implement things like floating headers, virtual scrolling with <table> Still, Handsontable uses <table> because you can overcome these problems if you're motivated enough. The biggest benefit is that <table> gives you enhanced semantics, which are good for Accessibility, SEO or any other form of code processing.

BjoernKW 8y ago
In addition to that, using <table> gives you out-of-the-box Excel file export because .xlsx files (which are basically zipped XML files) support HTML tables.
twanvl 8y ago
Could use use <table> for the semantics but set display:block to get <div> style layout?
- olifolkerd 8y ago
  the problem is it isnt just the table element, it is the thead,tbody,td,th elements as well Complex interactive tables need a great number of elements to make them run and these wont conform to the standards of using a table (you cant just put a div inside a tbody element) but that is exactly what you would need to to to get a table with a virtual DOM to work correctly. There are a lot of different styling tweaks that would need to be overriden for each element, some of which arnt consistent across each browser. Also people have a tendency to put styles on the generic table tab to style tables across the site. if Tabulator was to then be used on the page, it could have any number of unknown CSS properties set on it, so would essentially have to look at overriding all possible style properties. where as no one generically styles divs or spans and they come with very little built in styling making them the ideal choice for a library that wants to keeps its functionality isolated from the rest of the site

lunchables 8y ago

I've worked with datatables quite a bit and it uses standard table tags: https://datatables.net/ https://datatables.net/

noir_lord 8y ago
That's what I use at work, I just wrapped it with Vue and did some moderately horrible stuff internally to allow reactive rendering (and by moderately I mean horribly). Performance is solid, it's easy to work with for ~90% of the times I use it and there are other ways to handle that last 10%. I probably wouldn't have used datatables on greenfield but the legacy (in every sense) project I inherited already used it so I went with it anyway.

olifolkerd 8y ago

Let me preface my answer by saying im the chap that built Tabulator This is because the <table> element introduces a lot of design constraints. There is a lot of inhernt styling that would have to be overridden if a table element was to be used. it could also mess with the standard behaviour of other table elements that have been generically styled. Importantly when you start building interactive complex tables there are 100's of different types of elements needed to make the table function correctly that a standard HTML element simple isn't designed to handle, event making the header and the body scroll separately requirements more elements that a standard table can handle and it would invalid HTML to use the tags inside the table that would be needed to achieve it. Especially when you move into the world of the virtual DOM a standard table element simply wont cut it With the inclusion of aria tags there are no accessibility issues as screen readers treat them just as any other tables.

Rumudiez 8y ago
For others; your last point is the most important. Semantic HTML gets you pretty far but there will always be an unhandled case. This is a fine use case of ARIA as long as it’s met with sincere concern for accessibility testing.
ohitsdom 8y ago
Appreciate the details. I've done some minor JS-based table controls while using <table>, but I wasn't dealing with thousands of rows so didn't need the virtual DOM. Sounds like that's the biggest obstacle. Nice work on the project!
damntrecky 8y ago
For the nested markup and styling it sounds like a perfect fit for creating a web component no? The virtual DOM, while very impressive, isn't necessary as well. Really depends on what problem you are solving there and what level of support you need for browsers. What problem are you solving? Many entries? Minimal cell mutation control?
- olifolkerd 8y ago
  For Tabulator the virtual DOM is essential. if you try and load 10,000 rows into a table either the browser will slow down and become almost unusable or crash entirely. For large data sets it makes the table work regardless of the number of rows

kgwxd 8y ago

Try it, it doesn't take long to figure out there's no good way to do even basic features without fighting very hard against the built-in behavior of tables. Also, for even just 1000 rows, all browsers still suck at redrawing if any little thing changes, I believe it's because the entire layout of the table has to be recalculated no matter how small the change is.

olifolkerd 8y ago
Spot on!, Tabulator uses a virtual DOM to get round the limit on the number of rows, and that simple isn't achievable in a standard table element

JangoSteve 8y ago

A library I built called Dynatable doesn't do that! It uses semantic, standard table elements for all serializing and rendering of tabular data. We've since rewritten Dynatable to use vanilla JS and are in the process of renaming it to simply Dynatable instead of jQuery Dynatable. https://github.com/alfajango/jquery-dynatable https://github.com/alfajango/jquery-dynatable https://www.dynatable.com/ https://www.dynatable.com/