I came across a strange one today, which actually wasted a lot of my time, as I first thought it was some module that I upgraded on Drupal or some code change. In fact, it is related to Google Chrome's browser update.
Currently Google Chrome's latest version is 44.0.2403.89. The previous version I was running was 43.0.2357.132. Tables on my site were displaying just fine. And actually, after hours of troubleshooting, I thought to just check the website with Safari and sure enough things were displaying as they always have. Then I checked Firefox, also no problem and displayed as it had. So it seems Google has changed something in Chrome to cause tables to break. Any idea what's going on and how I can fix it, or is this a bug with the latest Chrome version?
Here is a sample of the table being broken by Chrome:
http://www.yoninja.com/jp/browse/results/taxonomy%3A74
See how the middle column's table flows under the right side bar. If you check this page with the previous version of Chrome (43.0.2357.132), it displays just fine. Also displays perfect in Safari and Firefox's latest version. What gives?!?
* UPDATE *
So I have temporarily fixed it by using Drupal's View Theming and modifying the views-view-table--(viewname).tpl.php file and editing the column width of the column which holds the long text. Even specifying the table width, whether with a percentage or a specific width in pixels, doesn't work in the latest Google Chrome.
<table class="<?php print $class; ?>"<?php print $attributes; ?> style="width:770px;">
<table class="<?php print $class; ?>"<?php print $attributes; ?> style="width:100%;">
Neither of these work, specifying 100% doesn't change a thing. Specifying the width in pixels actually does change the width of the table but not the by the width you specify. Strange! Why would Google's update change the behavior of something that has already been working previously?
Anyway, the only way I have been able to get things working is by specifying the width of the column as mentioned below in one of the answers. However, I still feel this is unnecessary and it seems every other browser is still displaying tables properly. So the question is, will Google fix this?
Is there anyone I can get this working without having to specify the table width. I use this view in various pages, and I don't want to have to worry about specifying the width.
This has indeed been reported as a bug.
https://code.google.com/p/chromium/issues/detail?can=2&start=0&num=100&q=&colspec=ID%20Pri%20M%20Stars%20ReleaseBlock%20Cr%20Status%20Owner%20Summary%20OS%20Modified&groupby=&sort=&id=512872
This bug seems to apply to tables who's width has been specified but rely on automatic width calculations on individual table divisions with larger amounts of text in them. It miscalculates the width table divisions which contain larger amounts of texts. Affected rows now extend beyond the edge of the table visually breaking column alignment.
Until a valid update to Chrome fixes this, you can apply my earlier posted work around.
You'll need to manually specify the width of table divisions which contain large amounts of text in them (not the table itself). This will override the invalid calculation and prevent your table row from expanding beyond the width of the table.
I've tested this with an inline width specifier on table divisions with large amounts of text in them.
<table>
<tr>
<td>
some stuff
</td>
<td width='30%'>
some other large text field whose width isn't calculated properly
</td>
</tr>
</table>
I too have experienced this issue. It does indeed seem to be an update from 43 to 44 that changed the layout behavior. My site used the automatic layout to re-size the width which no longer works well. The fix for our site was to set one of the larger text fields width with an inline width element on the table division.
Your mileage may vary.
<table>
<tr>
<td>
some stuff
</td>
<td width='30%'>
some other large text field whose width isn't calculated properly
</td>
</tr>
</table>
After the Chrome 44.0.2403.89 update pages containing an html table with a style of width:100% (or using bootstrap table classes) no longer honor the 100% width if ANY of the columns contains a "long" string (even if the string includes spaces). This is new behavior and I've confirmed it is directly related to the 44 update. Hopefully if enough people post it will get fixed.
I am having the same issue which broke our page layout.
However, I actually am using a fixed width CSS property on the table.
The width of the table is visibly larger than the width specified. (I.E., it overflows.)
Querying the width of the table with JS returns the CSS width set, not the real width.
Related
I have some tables with print-reapeating thead and many rows. Sometimes a new table starts at the very bottom line of a page, when printing.
I want to force the table to do a page break, if the space left on the page is less than, say 10 cm.
I tried to put an (invisible) overlapping div before that table:
<div style="position:relative;">
<div style="position:abolute; top:0px; width:32px; height:10cm; overflow:visible; page-break-inside: avoid;"> </div>
</div>
<table goes here...>
But it's not working. (FF and IE11)
Is there any way to do that? (I'm trying to print a book, and the table is a new chapter).
I believe this is a bug in Chrome.
The code below demonstrates the best method I've found for multi-page table printing. It has the following features:
column headers repeat on each page
if a page break occurs near the top of the table, it will not leave behind an orphaned set of column headers (a problem which isn't limited to just Chrome)
page breaks occur only between rows
no need to worry about paper size or how many rows will fit-- the browser handles everything automatically
cell borders are always fully closed
the above 3 features apply whether or not the table has headers
works in Chrome!
... and the following known limitations:
doesn't support s (tfeet?)
only supports 1 (which is apparently the most you're allowed to have anyway).
only supports top-aligned
any CSS size values that affect height (including border-width and line-height) must be in px
table cannot (easily) be changed dynamically after the js has run
column widths cannot be set by applying width values to individual table cells; you should either let cell content automatically determine column width, or use s to set specific widths, if needed
I put two tables side by side: the left one (1px) only has a thead with 10cm height, the other contains the contents to print.
That sort of works.
I used float:left; for both tables, so they are side-by-side, but IE11 puts underneath.
Any better idea or an improvment of this approach?
I am looking for a way to resize a tables contents using CSS to make sure the contents all show up when printing but yet still keep the text from wrapping for any individual cell. In this example,
<table class="datatables" id="table1">
<tr>
<td style="white-space:nowrap;">This is a table with a bunch of data that stretches off the page when printed.</td>
<td style="white-space:nowrap;">I want it to print on one line, not wrap but also be sized small enough to fit on a printed page.</td>
<td style="white-space:nowrap;">It currently cuts off most of this last column.</td>
</tr>
</table>
The last td is mostly cut off when printing but all these display as I intended on one line. For example purposes I put the style inline but would be using style sheets. My ideal solution would automatically resize the font to fit still on one line per row without wrapping. Any thoughts would be appreciated.
Controlling the output of printing is a nearly impossible task. You never know the variables of what printer the user is using, what fonts are available, what settings are set, etc.
I've had this issue before, and the most clean solution for the user was to convert the table to a .pdf, which will render nearly identical across machines and printers. While it may not seem so easy to do from a technical standpoint, there is a pretty straightforward solution: datatables.
Using the "table tools" plugin, you can create a .pdf formatted version of any table with just a few lines of code and the addition of a few extra files. Here's a working demo In a nutshell, provided your table is correctly formatted and not insanely large (make sure to use <thead> tags) then you should just be able to upload the required files, apply the demo code with a change in the selector to match your table, reference the swf file that facilitates creation of the .pdf, and it should work smoothly. Most issues I've seen in setup have to do with incorrect reference to the swf path.
Voila, printable, simple code.
Maybe you can try with
#media print
{
table.datatables {font-size:10px} /*Type the value that you want*/
}
You can check a print settings in your Chrome Browser by using "Find the Scale Fields" in "Print Options" and adjust the page size on your requirements.
This is not a full-proof solution, you need to check it which values will works for you.
Use CSS transform scale property.
In my case my table width was more hence I did this using javascript.
Since my width was too much, I scaled it lower and adjusted the margin and after javascriptwindow.print() I bring it back to the original state.
document.getElementById('your table id').style.transform = ("scale(0.8)");
document.getElementById('your table id').style.margin = ("0 0 0 -15%");
You can also do it using same property in CSS.
#table {
transform: scale(0.8); //Adjust this accrding to your need by printing
margin : 0 0 0 -15%; //Adjust this accrding to your need by printing
}
I really could use some help with some style issue I fail to get solved:
Scenario:
Inside a web application I have a table visualizing a list of entries. Two of the columns can take longer content, which is chopped for display using "overflow:hidden;"and applying a "text-overflow:ellipsis". The content of all table cells is wrapped into spans so that I can apply animations whilst populating the table. All fine.
Now I want to change the tables layout from its former fixed style to a more liquid behaviour.
Before I had fixed width settings for the table columns. For all except two columns I keep the fixed width, even for one of the ellipsis-style-chopped columns. The other one gets a width of 100%, so that the table consumes the whole available container, thus giving a liquid style ("always use whole screen"). The column shows its content plus some whitespace which is used to pad as required.
Desired behaviour:
I expect the table to shrink when the windows size is decreased. This should obviously happen by reducing the width of the column set to 100%, since it is the only one without a fixed length. That part works only as long as the cells content fits in. As soon as the window gets that narrow, that the content does not fit any more a scrollbar is applied by the browser. This is not what I want. Instead I want the ellipsis-style-rules to chop that cells content, so that the table actually gets smaller, maybe up to a min-width.
Test case:
HTML:
<div>
<table>
<tr>
<td class="c1"><span class="ellipsis">Alfreds Futterkiste</span></td>
<td class="c2"><span class="ellipsis">Maria Anders</span></td>
<td class="c3"><span class="ellipsis">Germany</span></td>
</tr>
<tr>
<td class="c1"><span class="ellipsis">Laughing Bacchus Winecellars</span></td>
<td class="c2"><span class="ellipsis">Yoshi Tannamuri</span></td>
<td class="c3"><span class="ellipsis">Canada</span></td>
</tr>
<tr class="alt">
<td class="c1"><span class="ellipsis">Königlich Essen</span></td>
<td class="c2"><span class="ellipsis">Philip Cramer</span></td>
<td class="c3"><span class="ellipsis">Germany</span></td>
</tr>
</table>
</div>
CSS:
table{table-layout:fixed;width:100%;border:solid gray 1px;}
/*table{table-layout:auto;width:100%;border:solid gray 1px;}*/
tr{}
td{}
td.c1{width:100%;}
td.c2{width:6em;}
td.c3{width:4em;}
/* formatting the clipped output */
.ellipsis{display:block;overflow:hidden;white-space:nowrap;text-overflow: ellipsis;width:inherit;}
/* just for the test case */
div{display:block;width:90%;margin:1em;background-color:silver;}
span{padding:2px;width:inherit;}
I prepared a fiddle with that test case for you to play around:
http://jsfiddle.net/UgYFs/3/
When you decrease the windows width (or the width of the left bottom "Result" compartment) you can see how things work. This is the behaviour that I want.
The problem: (thus this question...)
This only works with a "table-layout:fixed;". Makes some sense, however there are reasons that make this option unavailable: in the real application the tables rows are inserted dynamically. This does not work with a fixed layout, at least the optical result is quite different (which also makes sense). So if I like it or not, I think I have to go with a "table-style:table" (the default). You can switch to that in the CSS compartment by uncommenting the second line, thus changing the table-layout. You see that the behaviour changes.
My question:
Is there a way to combine both things:
to get the desired behaviour as described and demonstrated
to fill the table without a fixed layout (maybe switching the layout later) ?
Until now I failed to succeed. But I am just a bloody beginner in all this stylish web stuff...
Right, since no one had an idea I tried a different approach to what I was asking about were. I want to close this question, so I post the outcome, even if it is not a solution to what I asked here...
I succeeded to modify the rest of the app such that the way the table is filed dynamically works even when table-layout: fixed; is set. This allows me to use standard css table rules to keep that single column flexible in width but still limited in length because the whole tables width can be derived from the container now.
I have an HTML table that can be more than 1K rows and a dozen or so columns.
I want the columns to be a fixed size (controllable by the user) and not grow/shrink either vertically or horizontally. So visually the contents of a particular table cell will be on one line and the overflow gets cut off at the end of the cell.
Doing performance analysis in Chrome on a large table the main performance killer is overflow:hidden.
I've tried putting the contents of each cell inside of an input, since that would replicate the same visual behavior, but that has a similar performance impact.
What do people recommend to improve performance?
If necessary I don't have to use a table tag, but would prefer to stick with the table tag if good performance can be achieved.
Update 1: I've included a file that demonstrates the performance issue here. Warning the file is pretty massive (25MB) and will slow down your computer. By default the table does not have overflow set to hidden, and once the table has been loaded (can take a while) the browser performance relatively smoothly.
However, if you edit the file and uncomment lines 12-15 and then open it. You'll see after loading browser around the table is significantly less responsive.
FYI: I have run into this problem on the iPad/iOS causing performance problems with a page that has about a hundred rows in a table with table-layout:fixed.
As soon as a cell, or a div in a cell, gets an attribute that forces it the cell to be drawn individually, it takes about 300ms instead of 100ms to draw (which causes the UI to feel abysmally slow for my situation).
Either of two properties (position:relative or overflow:hidden) caused the problem for me, removing them optimised the speed but caused text overflow if cell text was too wide for the fixed width columns.
The slowdown was happening even after tables were drawn, because I am dynamically popping up an absolute div over the table. When profiling the javascript (using (new Date).getTime()), the slowdown in measured in places in the javascript that have nothing to do with the table.
[edit: added following as part solution]
Put all cell content inside a span element (so can measure offsetWidth of content rather than width of containing block element).
After appending the row into the document, test if each span.offsetWidth is greater than the column width, if so add the "overflow:hidden" to the style (or via a class) of the containing block.
Can skip 1 and 2 above for some columns (if it is known that the cell content will never need clipping).
Caveats:
Measurements only made for iOS5 Safari (I didn't profile any other browser).
Works for us because we dynamically create table rows (processing your example using javascript would be slow?).
Most cells for our data do not overflow (clipping is only required sparsely - only a limited number of cells).
Compromised initial page load (generation of table in page went from 80ms to 800ms).
But sped up dynamic combo popup (340ms down to 130ms) giving much better keyboard responsiveness.
For your situation, might be fast to first using variable width columns, measure offsetWidth of all columns, setting column widths to pixel widths and setting overflow:hidden only on columns where offsetWidth of column is greater than the pixel width you will be using for the column.
You could try using a tiled approach. It is a pretty typical approach to making things like infinitely side-scrollable games efficiently.
Put all of your data into a Javascript array, and then have N + 1 rows in a table that has N rows visible. When you scroll down, the last item would move into view. At the moment that you have scrolled far enough that the first item moves out of view, you shift all of the data up a row and reset the scroll position back to where it started. Done correctly, the shift would be completely transparent to the user. You would only ever be working with N + 1 rows in an N-rows-visible table.
I've done this before, but under very specific UI constraints. I kind of shutter at the thought of making this consistent using the built-in browser scrollbars and such.
first off, the amount of markup required to have a table is much larger than just using divs with clear:both css for a new row. so that's the first performance hit.
also, you are setting the overflow as a class ( ? )
<style type="text/css"> .ovfl { overflow:hidden; }</style>
<td class="ovfl"></td>
As an aside, 1000 rows is a weight to deliver.
With divs you at least have an easier opportunity to throw those out of sight ( beyond the scroll ) into a div with display:none until the visitor scrolls to them.
few skins to cat mostly likely on this job,
Hope had some good thoughts.
Webkit bug 75001 is related to this problem and it covers the work being done to solve it (also see bugzilla dependencies for information).
I'm new on this particular project, and I've been tasked with resolving an issue that's appearing in IE8.
If you check http://funds.ft.com/ETFHomepage.aspx, There's a section called "News". In that section, there's a column called "Most Popular ETFs". This should be the same width as the "Recently Viewed ETFs" column.
For reference, this page is appearing correctly in Firefox. Can somebody please point out what I can do with CSS or (some other means)* to resolve this?
*I know the best way to resolve this issue is to scrap the terrible design and implement it correctly!! :-) -- we're actually doing that right now. It's a big job, so it's taking a long time. In the mean time however, we have to fix the bugs as they appear. Thanks
Update: just to note what I've said to Hristo, "I think the problem is with the table (rather, nested tables) on the left. The table in the center has its width defined by the image, and the table on the right doesn't have an image so it gets crushed"
Well the reason this is happening is because of the url you have under the "Alphaville: Overcoming the Volcker rule, with ETFs" header. Since the url has no whitespace in it, the table tries to give it space. So there are a couple of ways to fix this problem:
Plain text urls aren't very becoming on a webpage (especially when they're not in anchor tags so you can click on them.) Could you update the content so that you don't have a raw url in your content?
If you must be able to handle long lines of text with no whitespace then you need to figure out how to change the layout of the page so it forces the text to either wrap or clip to fit the container. Try playing around with putting "table-layout: fixed" on your tables to force the column widths to be sized based on the table's specifications only (instead of content). Firefox seems to be wrapping on dashes and slashes in the url whereas IE only wants to wrap on the dashes in the url.
I would say your layout is fine, and you just need to fix the content generation so it doesn't include any long plain text urls (option 1 above)
EDIT: If you do decide to go with option 2 above, then look into the css rule "word-break: break-all". It is IE only and it forces the text to break as soon as it reaches the end of the container. Not good for words, but it works for url's. So you couldn't apply this to the whole news table, but you could to just the cell that contains the url.