Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I don’t see what benefit the table elements are providing. It’s just convoluting the grid with hidden CSS rules. Why not just use a div for the row and spans for columns? The inline and block behavior of those elements is what defines and distinguishes them. Paired with CSS reset there are no hidden CSS rules affecting their behavior.


Semantics. It's still tabular data and divorced from their custom CSS rules, it would still display as a table.


In addition to the other comments, for those few running old enough browsers that none of the new CSS is recognized, the fallback is basic HTML table layout (because at its core, it is still a HTML table).


Accessibility.


As another user pointed out, there are ARIA roles for this. At this point we are way past being forced to use clumsy elements just for accessibility reasons and the roles are preferred by screen readers.

https://developer.mozilla.org/en-US/docs/Web/Accessibility/A...


In my experience developers are really bad at implementing accessible components from scratch. There are a lot of nuanced edge cases that is easy for a mere human to miss. Like:

* Tabbing order, trapping the tab order (but still allow tabbing to the URL bar)

* Keyboard navigation, and keyboard controls, esc and arrow key behavior etc.

* Submit behavior and change events

And many more. Setting the correct `role` only adds the semantics for assistive technologies and is by no means sufficient to make things accessible.

When you just use `<table>`, `<details>`, `<button>`, <select>, `<dialog>`, etc. you get all accessibility correctly implemented for free.

Sure you can find a library that implements the component. But these are too implemented by mere humans and are likely to miss some of the nuanced edge cases. Also by that point you might as well just use the standard elements.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: