I'm implementing a dgrid in my dojo application, and for some reason the grid seems to ignore the white-space:nowrap; property assignment when applied to .dgrid-cell class. My goal is to make the cell widths of the dgrid never reduce to lower than the content within the cell headings. But actual behaviour is, if there are too many cells in the row to fit in their entirity, they all get reduced in width equally.
I've tried the following declaration, with varying specificity and !important etc:
th.dgrid-cell {
white-space:nowrap;
}
I even tried to apply it to all cells as follows:
.dgrid-cell {
white-space:nowrap;
}
But the property just seems to be ignored. Any suggestions on how I can achieve this please?
white-space: nowrap should work just fine.
However, it's not feasible to get dgrid to automatically determine column widths based on cell contents due to the way it is designed (as well as generally any other dynamic data grid component including dojox grid and gridx, if I'm not mistaken).
dgrid renders each row in its own table, which makes features like virtual scrolling (i.e. OnDemandGrid) possible and also avoids the heavy rendering overhead normally incurred by large tables with many rows and columns which need to compute widths based on all of its content. As a result, however, it's not possible to have dgrid's columns automatically sized based on content.
If you're primarily concerned with ensuring widths based on header contents, hopefully that's reasonable enough to implement based on their expected contents. You can also use text-overflow: ellipsis (as I've done in the fiddle I linked above) to more gracefully indicate overflow when it does happen.
Related
Use case
I want to detect if html tables get too wide, and if so, I want to flip the table header cells to become vertical (e.g. with writing-mode: vertical-lr;).
I want to update this on resize: If the viewport gets bigger, the text in the cells might become horizontal again.
The flip condition is whether the original table with horizontal labels would be wider than its container.
Question
How do I determine the width a table would have with horizontal labels, without changing the table itself?
Thoughts
My current idea would be to make an invisible copy of the table with horizontal labels, and use it as a "sensor". But I am afraid this will pollute the DOM and cause side effects somewhere. Also I would need to keep this copy updated all the time.
Is there a "best practice" or a known pattern to solve this problem?
It is actually quite simple:
We can change the css on the table during the script run. Once we query a property like element.width, this will cause a reflow during the script execution, but it won't cause a repaint. So this means we can do the test without the need for a cloned DOM element, and without visible changes.
See https://developers.google.com/speed/docs/insights/browser-reflow
I'm working with the DataTables library, and I'm using the autoWidth option to have DataTables set column widths automatically, as well as the Scroller plugin to fix headers and page data from the server.
This combination looks beautiful when my table has a large number of columns, but when it has just a few columns, the autoWidth setting makes them cartoonishly large.
Here's an example:
http://live.datatables.net/rizuvaza/2/edit
What I'd like is for the table to be only as wide as necessary for its content, and no wider. Sometimes this will mean that the content is too wide for the viewport and must be horizontally scrolled, and sometimes this will mean that the content is narrower than the viewport, in which case I don't want it to consume the whole horizontal space.
I've found a couple of approaches that work if I'm willing to hard-code a maximum width for the table, but doing so relies on me writing code to estimate the width of the columns myself. Obviously this is dependent on a wide variety of difficult measurements (font size, content width, etc) that I'd really rather leave up to DataTables.
Is there some way to configure DataTables, or use wrapping DOM elements and styles, such that it will always draw a table using only the width necessary?
Well - dont know if that it was you are looking for - but if you set
#example {
display: block;
}
and run a columns().adjust() right after initialisation
var table = $('#example')
.DataTable()
.columns()
.adjust()
.draw();
then the columns will be shrinked to the absolute minimum size.
demo -> http://jsfiddle.net/j5h9ob12/1/
Update, edited titles in the fiddle to emphasize the point.
I have to render up to 1500 row using jquery plugin Datatables and twitter bootstrap css. In each row, there is a table that can contain up to 50 row.
Using chrome developper tools profiler and testing, the rendering is a real problem. For example, i have for 250 items displayed 219861 selector match for .table th, .table td.
How can i optimize this ?
I retrieve twitter bootstrap from bootstrapcdn
I am a framework developer and I can share some of things I have faced and remember at this moment
When writing table inside table layout, don't use
'box-sizing:border-box'
Instead use 'content-box', otherwise it will create gaps between rows, not columns if you have specified or not specified borders. No style will help you to remove that.. This is very important while implementing nested table layout
Even if you are using DIV with table layout, take care 'max-width' does not work properly in some mozilla versions, for that you may have to maintain a "wrapper" DIV that is occupying the 100% width and 100% height of cell.
Maintain block lever wrappers inside cells and apply skins to it if it is table, because hover and focus will not apply properly.. Example: half filled hover skin observed in some modern browsers as well.
And while embedding those many elements dynamically instead of creating elements on fly and appending, prepare HTML string and append it, it does perform very well.. I have observed this. But modifying html renderer might look dirty, but all we need is performance
These are some things I remember at this point of time. If I am wrong somewhere please correct me..
Suggestion If you are targeting mobile browsers as well, then go for table layout until unless you have good expertise in dealing with div layout. Floats does not work properly in some mobile devices. And tables scaled properly with media Queries in mobiles as well.
I recently had a similar situation with waaaay too much table data and had to solve it with pagination. The HTML has to pull all that info and build that massive table before it will even start to render it, thus the horrible slowness.
Finally i will limit maximum number of rows displayed to 200. No "display all the stuff" allowed.
I will try to optimize css too. Seems that there is a lot of definition of bootstrap css i don't use.
I'm writing some code that wraps various content into columns of text (and images, videos, etc). The code works fine, but due to the algorithm I'm using it's rather slow, specifically this general logic:
add something (text for this example) to a column
check to see if column.scrollHeight > column.offsetHeight (this requires a DOM reflow)
if yes, start to binary split the text until it's shorter
Basically my issue is that I'm adding an unknown amount of text to a column, so after each chunk of text I check the column's scroll height which requires the browser to actively reflow the DOM in order to give me the correct scrollHeight. So I have 50-100 or more reflows in order to properly lay everything out.
Any general ideas on how to avoid most of these?
You could render the content multiple times. Since the first time would cache it, this should be fairly fast. The reason for the multiple rendering would be as follows.
Render the original content in a hidden area
Check to see what the column width is compared to content
Overlay the content over the column, but beneath the page. This
will cut off part of the content that is overflowing. You can accomplish with
z-indexing or with overflow: hidden;
Based on what the check from step 2 was, overlay a copy of the content with
the calculated offset in the next column in the same fashion, hiding the
extra content.
Keep track of the rendered content versus total content so you can tell how many
columns you need to do this to if there are multiple columns.
Maybe this is the same thing Travis J is suggesting, but I'm not sure, I don't quite understand his solution.
You could render everything first, on a single column, then loop through the elements top-down to know when to split, based on your desired column height versus each element's offsetTop plus height. When you find an element to break at, cache its position and go on. At the end you should have an array with the list of elements to break at, so you can actually split the content in columns.
Does this make any sense to you?
I'm creating an app which allows the user to manipulate a table structure by adding and removing columns and rows, setting column widths and cell colspans, and inserting elements into table cells. While testing, I came across a scenario in which Firefox 4 and Internet Explorer 8 render the table in the way I expect it to be rendered and Google Chrome 11 doesn't. I'm using table-layout: auto and I am aware that CSS does not specify a rendering algorithm to be used in this case (http://www.w3.org/TR/CSS21/tables.html, section 17.5.2.2). Nonetheless, I'd like to have consistent views in the three mentioned browsers, if possible.
Here's a very simple scenario to illustrate the different rendering (try it in Chrome and Firefox/IE to see the difference): http://jsbin.com/ayuja4/3
Even though the table is wide enough to contain the blue div (because the first column is set to 200 px and the second column, although having a width of 100 px, must expand to 300 px to contain the green div), in Chrome the first column is widened beyond its 200 px. This results in extra, unnecessary space in the last row, which is precisely what I'm trying to avoid.
Any ideas to make this table look the same in Chrome as it does in Firefox and Internet Explorer? I don't need a pure HTML/CSS approach - manipulating the table with JavaScript is a valid option, if it solves my problem. I'm already considering using fixed table layout, but this will result in extra effort to handle elements that are wider than columns, so it's a last resort.
If you make the divs inside the table display as cells with table div {display:table-cell;} you'll get the same results. Also, the way you're going about it now is leaving a 1px gap because the 500px element doesn't get the 1px border calculated into it.
I actually took a second look at it, and if you use min-width instead of width it'll work that way too.