I get some funny markup. If I use āView Sourceā in Firefox, the markup seems ok (the table row is inside the turbo frame). However, when using the web inspector, I see that the turbo frames actually appear above the table:
Browsers re-organize the HTML they are given into a DOM that follows their interpretation of the rules of layout. Since Turbo uses a made-up tag that does not adhere to the rules of what tags may be children of a tag, that made-up tag gets sorted out of the hierarchy. You will find that you can put a around the entire , and that will not get re-organized, but just like if you tried to put a
inside the
, anything that cannot (legally) be a child of the will be moved within the DOM. All browsers do this, not just Firefox. All browsers are free to interpret what the correct re-organization scheme is, though, so you may see some put the foreign tags after the table rather than before it.
Is the solution you coded working for your purposes, philosophical purity of markup aside?
Or is the updated content being rendered above your table when Turbo re-builds the page?
Ugh, sorry, this got all stripped out because I replied by e-mail. Hereās what I wrote, without angle brackets and capitalized to give it the same meaning:
Browsers re-organize the HTML they are given into a DOM that follows their interpretation of the rules of layout. Since Turbo uses a made-up TURBO-FRAME tag that does not adhere to the rules of what tags may be children of a TBODY tag, that made-up tag gets sorted out of the hierarchy. You will find that you can put a TURBO-FRAME around the entire TABLE, and that will not get re-organized, but just like if you tried to put a DIV inside the TBODY, anything that cannot (legally) be a child of the TBODY will be moved elsewhere within the DOM. All browsers do this, not just Firefox. All browsers are free to interpret what the correct re-organization scheme is, though, so you may see some put the foreign tags after the table rather than before it.
Is the solution you coded working for your purposes, philosophical purity of markup aside?
Or is the updated content being rendered above your table when Turbo re-builds the page?
Hey @walterdavis, thank you very much for your answer, it does make things clearer for me. The problem for me is that in this case Turbo does not work at all. What Iām trying to do is that when clicking on edit, I get the edit form of the given recorded rendered in place of the row. However, as the edit button is in this case outside of the turbo frame, this does not work. Right now, Iāve fallen back to not using a table, but divs. Once again, thank you for your answer.
I had the same issue. Indeed table elements are very strict and can only accept a set of element.
The solution I decided to go with and that I suggest is to stop using tables and use div instead, you can then use CSS to style it just like a table with display: table, display: table-row, display: table-cell etc.
If you use a utility CSS framework like tailwind itās very simple.
Iāll second @Intrepidd - stop using HTML Table and start using CSS Table. Just had my own tour of the trenches over this issue - I did a small post on the issue - feel free to comment if Iām totally in the woods! Tailwind, Hotwire, more
@vincentlee certainly has a point - if āturbo-chargingā HTML Tables was/is the only issue to deal with but IMHO we also have to finally start making ātablesā responsive - perhaps peruse my second installment on the topic
I did some research and played with this a bit last week. Itās not impossible for Turbo to make this work, but I think it would take support from the core team.
I had the same problem and played around for hours until even REALIZING the problem why my <td> tags were stripped. Although it makes sense from a rendering perspective, this behaviour is totally unexpected when trying turbo for the first time.
I hope you will consider @leehericks suggestion about using Customized built-in elements. Tables are really important, not just for screen readers. There are many nice javascript frameworks for tables, such as Data Tables that make tables work really well, but do not work with divs.
I just ran into this. But my solution was to just move the <turbo-frame> to wrap <table> instead.
To answer the OPās question directly: just move the <turbo-frame> to wrap the whole table instead of a row, this is necessary due to HTML rules of layout.
If we think about it, the <turbo-frame> does not have to be right beside the loop, inside <tbody>. We could wrap the whole page in a <turbo-frame> and things would still work, but that is inefficient.
In my view, <turbo-stream> is not absolutely necessary here. Just sharing.
I work in an area where HUGE tables are just part of daily life. They necessitate progressive loading. My existing solution is to immediately display a modest number of rows, then load some more via a partial that calls itself until I run out of data. Hereās an example:
Loading the whole table via a single Turbo Frame wonāt help. I suppose I could load the initial 100 rows and do a single replacement of the entire 14,000 row table when itās done loading but that could be a 5 second delay where currently there is functionally none.
Every example of Turbo Stream Iāve seen seems to be used for synchronizing state. Could I instead use it to blast row after row in order from within the initial index action? Iād love to avoid making 15 distinct server requests to load a table.