Does anyone have experience with rendering nested HTML tables? I am attempting to render 30 - 40 rows that each have 5 tables in them. This renders very slowly in Internet Explorer 7 and 8. Is there a trick I can use to speed my table rendering up? Is there a different element I can use other than tables?
if you are working with a nested structure that bad, I would guess that there are ways that it could be refactored to not be as complex, and your performance gain is going to be great by doing so.
However, we would need to see exactly what you are doing to give a valid answer.
30-40 tables is a lot of code to render. You should definitely switch to CSS layouts.
Setting explicit height and width on every element in the tables will improve browser layout performance.
For internet explorer, see http://msdn.microsoft.com/en-us/library/ms531161(VS.85).aspx
Setting the property to fixed significantly improves table rendering speed, particularly for longer tables.
Setting row height further improves rendering speed, again enabling the browser's parser to begin rendering the row without examining the content of each cell in the row to determine row height.
Tables are good for grids of information. For most other applications use a styled unordered list UL.
Add:
table
{
table-layout: fixed;
}
Be aware: some text may flow out of the table cells now.
Related
When learning CSS and making responsive column layouts, I was taught the flexbox method (but also the fact that you should avoid using it too much). Recently, I watched a newer video from teamtreehouse that uses columns, column-counts and so on, to make a responsive column design. Which one is better to use, or is there a third option that is the best?
Edit: Sorry, apparently it's an older video. The reason I'm asking is because it wasn't on my web design track so I wasn't sure whether it was relevant anymore.
Most modern page layouts are moving away from floated columns and migrating to flexboxes. You'll find that even bootstrap 4 are going to be basing their layouts on flexbox.
The main advantage of using flexbox I find is vertical alignment, which is revolutionary. Because before that was one of the biggest pains developers had to face. You can also re-order dom elements which is pretty cool. There's also flex basis, which allows you to have a div with a fixed dimension, and allow other divs to occupy the remainder of the width/height. The possibilities are endless!
TL;DR Flexbox makes your life hella easier. Only if supporting older browsers isn't an issue.
I came across the column-count in our codebase, and was surprised by it, after 6 years of being a frontend dev, I hadn't heard of it. So I dove into it a little bit and also found this thread. To answer the original question above:
When to use column-count
When you are using a lot of text or for instance checkboxes, and you want to order them into columns, column-count is a good option. It basically creates the columned layout of a news paper article for you. So you give the number of columns and the browser will calculate the height. The drawback here is that you often times don't want multiple columns on smaller devices, so you would have to put it within a media query. If you want to know more about it, read this article: https://www.smashingmagazine.com/2019/01/css-multiple-column-layout-multicol/
When better not to use column-count
If you want to have more control over your columns and rows, for instance where certain content should go within the column, use flexbox or grid. Also when you don't want columns to have the same width, you are better of with flexbox or grid.
Note that CSS grid is not the same as the old floated columns. It sounds like teamtreehouse used CSS grids.
The CSS grid is a 2d system (rows and columns) while flexbox is 1d (either rows or columns). So they can be used in conjunction, css grids for the page layout and flexbox for the internal detail layout. See :
https://tutorialzine.com/2017/03/css-grid-vs-flexbox
You might want to take a look at Boostrap if you are already comfortable with CSS and want a responsive design. It's easy to pickup. I find it saves me alot of time and effort rather than coding your own CSS for every project.
When working with css you need to constantly think what browsers you want to support, and then choose which features to use. For that there's a handy website http://caniuse.com/
For example in your case you can see that ie8 doesn't support columns http://caniuse.com/#search=columns and neither it supports flexbox http://caniuse.com/#search=flexbox so if you want to support ie 8 I suggest you would use the tipical floated column approach. There's many grid systems out there but I'd go with as suggested above. http://getbootstrap.com/
I have a really big performance issue with Internet Explorer (8 and 9) and large data tables.
When I loaded a few hundred items, the browser (not only Internet Explorer, but also Chrome and Firefox) starts lagging a lot. At first I thought it was because of JavaScript, but later I realized that it was CSS's fault. I found out that with display:none the browser does not render elements, so I made tweaks and started grouping elements in elements and hiding them when they are not visible in viewport like this:
<tbody style="display:none"></tbody>
<tbody></tbody>
Performance did really improve in Chrome and Firefox, but not in Internet Explorer. Internet Explorer seems to still be rendering or trying to recalculate styles for those hidden elements. It looks like display:none makes no difference on Internet Explorer. If I could make not rendering work I believe performance should improve, but I don't know how...
Also the reason why browsers starts lagging with large data table is because each row has about 50 elements inside which are also heavily styled with CSS.
I don't know what else to try to fix this in Internet Explorer...
Any ideas?
P.S.: table-layout is set to fixed
Rendering speed also depends on the way you create elements to the DOM, even though the script itself would be executed fast.
By my (Internet Explorer) experience document.write() is the fastest way to create large tables. It can be over 100 times faster than appendChild(document.createElement()). Also insertRow() & insertCell() are remarkable faster than creating and appending each row and cell. innerHTML seems to be the slowest method to add content (though in this case it can be used to create cell content only, not the table itself).
Unfortunately these differences between performance are not necessarily cross-browser, one browser is doing the same job faster with some other method than another browser...
What can you do then? Try to "split" your table into several smaller tables. You said that table-layout: fixed is set; do you also use COL and/or COLGROUP tags and widths for those? Without them setting table-layout is pretty much useless. Or you could use lazy loading; just load a small part of the table, and when needed, load more.
"Example": I've created an Internet Explorer application, which currently shows 379 tables having six rows with eight cells each. To create and render those tables takes less than 2 seconds (in Internet Explorer 9). However, (I just tested) if I'll create all 2274 rows to a single table, rendering will take about 15 seconds. I assume that splitting the large table to smaller parts would speed up rendering in other browsers too.
Having used display:none on elements that aren't being viewed myself, I can assure you that it is a massive performance gain, even in IE.
The problem you have here is that the browser is constantly having to recalculate column sizes, especiallywhen you change display properties.
To fix, try adding table-layout:fixed to your table's styles. This will effectively disable dynamic column widths and make for more consistent viewing when elements change. You may need to specify widths for your first row, however. This should result in an astronomical performance gain in all browsers.
In order to fix the redrawing issue, use a document fragment. Children appended to the document fragment are not rendered and will not cause the issues you see. You can then insert the fragment itself into the table:
var docFrag = document.createDocumentFragment();
// The following is pseudo code, but you get the picture
for (var i = 0; i < largeCount; i++) {
var row = createRow();
docFrag.appendChild(row);
}
// Append the fragment to the table (or even tbody)
var tbl = document.getElementById('myTbl');
tbl.appendChild(docFrag);
The document fragment itself does not render as anything, it is basically a container element that acts as a placeholder and disappears after you insert it into something.
EDIT: Further information can be found here.
It is actually an issue for all the Internet Explorer browsers without Internet Explorer 11. In general (for all other browsers) 'display:none' means that everything in it shouldn't be really processed from the browser on load, but Internet Explorer does that for some reason.
The only solution is to keep it out of the DOM and render part of the table.
I had the same problem. I initially had one table with 1000 records which was crashing most browsers (Firefox was the only one processing it). And even if it processed the initial DOM, the table was giving that slow dragging sensation (really annoying). So it was kind of unusable.
Then I divided it into smaller tables (200 records) with select drop-down and display:none from the start. This actually completely fixed the issue with the slow page dragging for all browsers. The only problem remained the slow (it takes about 2000 ms) initial load in Internet Explorer 10, 9, 8.
The only way to fix that unfortunately is to specifically exclude the tables from the DOM before load.
I can't see the example code, but you could remove the hidden elements from the DOM.
So instead of just setting display:none, detach them with removeChild() and store them in some object until you need to show them and then insert them at the appropriate place.
I've been using those properties, especially display: table-cell, a lot lately. It's well supported in modern browsers and it has a lot of benefits for some grids and for aligning content very easily, without the need of tricky markups. But in the last few days I have seen people talking about this, as it were a bad practice/approach using those attributes, like in this answer.
Pros (that come to my mind right now):
adds no semantics to the HTML-markup
well supported in modern browsers
helpful for aligning content
helpful for grid systems (most likely in combination of aligning content)
Cons
if you just use display: table-cell; the missing parts (row and table) are added automatically
So I don't really get, why it should be bad using those for layout.
I guess this question gets closed (I could understand that), but maybe somebody has a decent answer – even a positive towards their usage.
Quote from the linked answer:
Don't forget that table-cell is not the correct usage. You don't want
images to be trated as table cells, since table cells should only
contain table data. Just raising a caution flag. Stick to the
semantics.
I won't make this long: CSS simply has nothing to do with semantics.
I like to set display and positions as need be, though any large elements I almost always set to position: relative; so I can handle their children much easier.
As for display:table-cell - it's only changing how it's laid out. Instead of coding a full on table, if you just need a neat little 4x4 grid, why NOT use it? It's very simple, very clean, and is a very very simple alternative to coding a big (messy) table.
My advice is that "if it ain't broke, don't fix it". display: only changes the way items are... displayed ~ go figure!
I use as many display:'s as need be, like a menu might be :inline-block; for media queries or :block for full articles, or :table-cell for a nice simple even 2 column bit on a section of a sidebar/article.
one positive: provides table-layout without using table elements. one negative: affects some user agents negatively: http://www.456bereastreet.com/archive/201110/using_displaytable_has_semantic_effects_in_some_screen_readers/ this is one of those "it all depends..." question.
I have the following Table example here: http://jsfiddle.net/Lu9y3/
Which is based on the Telerik example here: http://demos.telerik.com/aspnet-mvc/Grid/Paging?theme=vista which is a UI component I am using in an app I am building.
As you can see they use two separate tables to achieve the fixed header and scrollable content. BUT the headers and columns in both tables still line up correctly.
Even if I REMOVE the style from the <col> in the Telerik examples using Web Inspector the columns will still line up... And they are NOT using jQuery to adjust the width. So how come they have their columns lining up and mine do not?
How are they doing this?
The reason you are having issues is because you are using two separate tables. Tables adjust column width to the longest unbroken content. The way Telerik does it, they have four columns and have set the widths explicitly in all but the third column. This allows the third column to expand and fill the remaining space.
Using table-layout:fixed will help but it will make all your columns evenly spaced regardless of content. I recommend setting the width of each column, or better yet make a class for each width and reuse that on the appropriate columns.
Lined up sample
I don't use classes in my example but I think you get the idea. I used overflow:hidden on th and td to make sure that longer content doesn't display over the other cells of the table. I also think the visual effect of the table works better with fewer columns seven or eight columns might be a bit overkill, but that's my personal opinion.
Using table-layout: fixed; makes the table line up ;)
I'm using Google Chrome, and when I open up the editor (F12) to Telerik's site and change the settings, they start not lining up. I've done some research, and according to W3.org on <col>, it looks like there is no way to globally name a <col> that you can use in multiple talbes (sadly).
Also, in Telerik's example, it appears that the <col> definitions specify a width in the tag itself (likely manually placed via some JS). I think this is the only way to do it other than setting specific CSS rules, but that may not work as well as a more dynamic solution.
Best of luck!
Is it possible to have a css newspaper-column layout arranged such a way that, any number of columns can be added and they will be continuously added to the right of the existing columns.
My thought is like this: I would just add a new div and a new column will be added to the right and so on.
If yes, how?
Here I found a 4-column newspaper layout. But column-heights are not same. I need a way so that, no matter how long the text is, they would be stipulated to a certain height.
Is it possible in CSS?
I think your needs are best served using an existing CSS framework, rather than coding it yourself from scratch, since it is really tricky business plus apallingly hard to get to work across all browsers (since some of them are not standards compliant)
Anyhow, for newspaper columns, I think there's one out there that fits the bill, 960 Grid System. It comes with 12 & 16 column "grids", with the gutters and paddings all worked out, and so long as the number of columns you intend to use is a factor of 12 or 16, it can handle it.
CSS3 provides a way of turning any HTML node's content into any number of columns. There are properties for controlling the number of columns as well as their width, relative height ("fill," or how the content is divided across the existing columns), gutter between columns, "rule" (dividing line or border), etc.
As a starting point, see the w3schools.com CSS3 Multiple Columns reference page.
However, as usual, IE alone among widely used browsers does not support the column- CSS3 properties.
One cross-browser solution is the Columnizer jQuery Plugin.
With pure CSS, it's very hard to assign several divs the same height unless that height is static. You can use ugly hacks but that will only get you so far.
For real columns, use tables, that's what they are for. Tables are valid HTML constructs, it's just that you shouldn't use them as your only layout tool. But when tables work, use tables.
you can set the height of the column using CSS, but adding a column automatically its a programming stuff using other web programming languages.