What is the single fastest method for table row hover css change?
I've tried jQuery (onmouseover/out) and CSS with tr:hover, but once I make my page fullscreen (1920x1200) the performance on my grid is getting just sluggish enough to give the entire page a feel of being sub-par. That's on a grid with 25 rows, and some spans and divs per row. I've tried IE and Google Chrome.
Is there another, faster method? What is generally considered the fastest method across browsers for doing hover CSS changes?
Using CSS is the fastest. I've done some testing, and it's about ten times faster than using Javascript.
You might want to try making the grid with simple div elements instead of using a table. In a table the size of all cells depend on other cells, so every change means a lot of recalculating even if the result is the same size as before.
Related
I have a table with thousands upon thousands of rows with 4 cells in each.
https://streamable.com/pywk9
You can see above my table is very big (no idea if its showing very well the laggy scrolling).
I understand this is because the browser has to actually render everything and with large datasets it could take time.
Is there a way WITHOUT pagination to make it more bearable?
Perhaps some way to render content ONLY shown in browsers view like a certain angularJS component (without needing angularjs)
A table that size is useful to nobody, you say you don't want to paginate but why? Pagination is a usability feature for a reason. Just implement pagination and searching. A grid with more than a few thousand rows is not going to be useful to anyone.
If you really need to have the table that big and scrollable then the technique used is to remove the item that are not in view out of the DOM. As you scroll you create DOM objects for the items as they come into view and remove them as they move out of view. This way there are not thousands of DOM objects the browser has to deal with.
This question at face value is a duplicate of: Divs vs tables for tabular data
BUT I don't think there is a good explanation of WHY someone will ignore what we agree on as standard practice.
It is 2017, tables were inappropriately used for layouting so people say don't use tables, but the exception we know is for visualizing tabular data!
Why is react-table made with divs instead of table/tr/td/th ? https://github.com/react-tools/react-table Certainly some, if not all, 43 contributors know that it shouldn't be divs.
Finally, isn't there an accessibility argument to be made in favor of using the right definition for the job? Wouldn't a screen reader understand that something is a table b/c it uses the term?
Nowadays, tabular data can be formatted nicely with divs and flex box css model. Not 100% as with table, but very close. Additionally, table elements (especially tr) can be styled with css to achieve responsive behavior for mobiles and tablets. At least in most modern web browsers.
So I'd use tables when you need to keep 'rubber' columns (proportionally stretching table heading and table body columns) and use divs when you can make columns with already known width and when semantics is not that important.
I have a big HTML table (~10K rows, 4 columns, text only) dumped from a database. I'm experiencing poor performance when opening it in Chrome/Firefox.
I do not have direct access to database, so it is impossible to load page by page. All data is static HTML.
Does pagination with some jQuery plugin help improve performance in this case? Any other suggestions?
When applicable, setting table-layout: fixed helps in reducing rendering time a lot. The slowness is mostly caused by the fact that in the default table layout method, the browser has to parse and process the entire table, calculating width requirements for all cells, before it can render any part of the table.
Fixed layout tells the browser to set column widths according to the first row (paying attention to any CSS that may apply to it). This may, of course, result in a mess, if the widths are not suitable for other rows. For a data table where rows are generally very similar, the widths can probably be set suitably.
This does not change the issue that very few people, if any, are going to read all the 10,000 rows. People will probably be looking for some specific data there. It might be better to set up a search form that lets the user get just what he wants.
I had a similar problem and made a jQuery plugin:
https://github.com/lperrin/infinitable
To use it, you can load all your data with Ajax call, turn it into a huge array, and pass it to the plugin.
It basically hides cells that are not visibles, while making it easy to sort or filter cells. There are other solutions to achieve that, but this one has no dependencies besides jQuery.
The project contains a demo with a table containing 100,000 elements.
Pagination would most certainly solve this problem. You could also try initially setting the table style to display: none. Although the pagination should likely take effect before the browser attempts to render the table.
You could also store the table in a separate html file, do an ajax call to the document, and implement live scrolling. Although, this depends on how you expect the user to explore the data. If jumping to a particular rage like 100-199 is useful, a paginated table would be ideal.
I've developed a module at my work in JQuery, it is basically a table with the following functionality
Cell level Edit
Row level edit
Drop n drop rows to change position
Show/hide columns
Column resize
every thing works fine on latest browsers like, FF9.0, IE9 and Chrome, but in older browsers like IE8 and FF3.6 as the number of rows in the table increases the performance of the page reduces significantly.
I've tried many optimization from jQuery and DOM manipulation but still no effect on the performance. Any idea if I'm missing something or some tip to make the performance better i.e. to an acceptable level.
I haven't use any plugin, everything is my custom implementation. The javascript file is quite huge and I'm looking for some general good practices and tips.
There are two major ways to improve performance with large html pages - reduce the number of page reflows and reduce the number of handlers.
1. Reduce the number of page reflows
Every time you make a change to the DOM, it needs to redraw itself. This is a reflow. Keep these to a minimum by creating a string or DOM fragment with all your DOM manipulations, then inserting that into your page. This will trigger only one reflow. For example, if you're adding a table, create the whole table with text in it as should be, then insert that in a single operation.
JQuery allows you to create a DOM fragment like this:
var table = $('<table></table');
You can manipulate your fragment in the standard ways:
var line = $('<tr><td>Some Data</td></tr>');
line.css('color','red');
table.append(line);
Then when the fragment is complete, add it to the DOM in a single step:
$('body').append(table);
you will trigger only one reflow and the process will be orders of magnitude faster.
2. Reduce the number of handlers
If you have a lot of controls on each row, that's a lot of handlers. Instead create only one handler and attach it to the document root, then when it gets called inspect the target attribute to discover what to do. In JQuery you can use the new "on" handlers to do this, or else use the old "live" style handlers.
for example:
$('table td').on('click', function() {
//do work here
});
Only one handler will be created which will handle all of the td click events.
Do both of these and you should see dramatically improved performance.
The bad news is, there's not really much you can do as it mostly depends on the javascript engine used in the browser.
If it's an option for you try Google's Chromeframe for IE8, but on a public website that's most likely not a very nice solution. But it can be in a corporate environment when users can easily update software.
You could also try to render the table on-the-fly:
Ao you got your table and you got an array with information in javascript (or pullable via ajax), plus you got informations about where you are in the table (row) and how long the table is (maxrows).
Then create a table that's only as big as the viewport, maybe a little bit bigger. Everything above and below the viewport is handled by a big <div> or anything that is streched to the height of remaining rows or rows before the topmost in-viewport row.
That way only a very limited number of dom-nodes is present at any time. It could possibly improve performance.
When the user scrolls remove table cells that are no longer in viewport (and add their height to the respective whitespace block of that side) and add table cells that freshly came into viewport (removing the height from the whitespace on that side).
Having a big html table with many rows that does not fit on the screen, do you know how to focus on a given row with javascript/jquery avoiding the need to scroll down?
Look up the "scrollIntoView" function. It's supported on most elements by (I think) all the browsers.
What I do, when I want to make a table (or something like a table) behave that way, I make sure that the target table row has a special class, or maybe an "id" value. Then I can find the row with Javascript and call "scrollIntoView()". The only thing you have to watch out for is that sometimes IE gets confused and screws up layout around the table, but if you're careful with how you set up scrollable elements it usually can be made to work.