So, I am using Twitter Bootstrap, I have a table which has a new row appended every time. However intermittently when I append a new tr, borders on the side of the page don't update correctly. See the three border lines on the left. Is this a height issue?
Browser: Chrome Version 32.0.1700.77
Ok, just for some closure here.
The method I was using of appending items to the DOM is unwieldy especially in the backbone setting I was working in. I can't tell you why exactly this was happening other than it was outside of my control.
The correct thing to do here was to rerender the view once the data had changed.
I know this answer doesn't directly address the question but it was indeed the answer to my problem.
Related
I wanted my ag-grid to be scrolled back to its original position after refresh which is not happening so I researched and found this ensureColumnVisible in grid api. Please help me finding the solution to it.
Event handler to be used for this ensureColumnVisible
This page shows all of their available events. I guess I would suggest the RowDataUpdatedEvent, based off your brief description?
The client has updated data for the grid by either a) setting new Row Data or b) Applying a Row Transaction.
Providing more detail always helps in providing a better answer; any details of things you've already tried, existing code snippets, etc. would help pinpoint more precisely what you want.
My site has these interactive tables that are inert until activated by an instructor when they are testing students. The backend is controlled by a vendor and I am the lowly web developer who cleans up their mess on the frontend so things look presentable. I've managed to change several tables indirectly through CSS and JS, but I can't apply anything to the HTML directly to the table since it's generated when the page loads. This particular table is perplexing,it will not shrink down to 720px. I tried everything from adddClass, nth-child, fixed sizes, etc. My last attempt was to write a function that set attributes to td's. It worked and it'll show on the developer tools but the actual table didn't shrink at all. I've been up 24+ hours so I might just be tired and not aware of simple mistakes. Anyways here's my demo. Thank you very much any help is very appreciated.
I just found this: Why is my table cell width wrong in Chrome?
Tables have a property called table-layout which is by default set to auto. It allows the table to be flexible and gives it the ability to distribute column widths on the fly. Setting my rogue table this way:
table-layout: fixed; width: 100%
made it behave and honor the widths I had assigned to it. Here's more details on table-layout
Demo
EDIT: I forgot to mention that this only happens in Chrome, but in Firefox and to a certain extent IE (it's a little off, but that's what you'd expect from a half-baked piece of work), are ok.
I've posted a couple of Google Charts accessibility questions already; here's one more. Thank you in advance for your help.
Google Charts tables are surprisingly easy to make accessible to blind users, but I'm running into a perplexing problem. I'm making a website that uses standard Google category filters to produce a data table. I've added ARIA-live=polite and ARIA-atomic=true attributes to the table to signal screen readers to read out the entire table when it changes. This works perfectly most of the time; when a control is changed, after reading out the control behavior the screen readers will immediately start reading the new table.
Unfortunately, changes in class attributes trigger ARIA-live. For Google Charts tables also tagged with ARIA-atomic, this means that row hover behavior will trigger a reading of the entire table, because hovering over a row changes the row class. And if you move the mouse pointer over more than one row, it'll read out the entire table once for every row over which you pass.
EDIT: see NOTE below to clarify this paragraph. I've tried addressing this by tweaking the table's cssClassNames options, but the results are frankly maddening. Even when changing the tableRow and hoverTableRow options to the same class, the table will only apply that class when hovering, changing the class to " " when not hovering.
I've tried convincing my co-workers that users of screen readers won't be using mice, but I've been asked to find a solution anyway. Guh.
Does anyone understand how this row hover behavior works, exactly? Is the problem as inscrutable as I'm making it out to be, or am I missing something? Does anyone have any ideas for a workaround?
NOTE: Ryan B has a good workaround idea (see comment below), and that's exactly the kind of solution I'll propose if my co-workers insist that the current setup doesn't meet their standards. Thank you Ryan.
Still, in the hope that the problem is with my explanation, I'll clarify: when you hover over a row in a Google charts table, the background color changes. The Google Viz script manages this by listening for hover events over table rows. On hover, the script changes the row class name from something like "tr-goo-viz-table-row" to "tr-goo-viz-table-row-over", both of which are in the Google Viz CSS and only include styles of background colors (white and light grey, respectively).
In the HTML table call one can set the cssClassName option for hoverTableRow to "tr-goo-viz-table-row" (or set both tableRow and hoverTableRow to any class that only sets the background color) and visually, the hover behavior stops. But in an odd quirk, the script insists on differentiating the class names on hover even if you're telling it to keep the class names the same. Depending on the implementation the script will produce a doubled class name ("tr-goo-viz-table-row tr-goo-viz-table-row") for hover rows, or an empty class name ("") for non-hover rows, and either way that'll still trigger ARIA-live even though no style change is implemented and hovering has no visual effect.
Since I don't understand the implementation of this behavior, I'm hoping someone who understands it better than I do might know of a way to stop the hover-triggered class name changes altogether - killing the listener, etc. Something like adding "pointer-events:none" in the row CSS for example...except pointer-events wasn't supported in IE before IE11 and the people using this website will mostly be using IE9.
I've been using jsfiddle.net to try and prototype a scheduler where the items to be scheduled are dragged and dropped into it. I've gotten dragging and dropping from an "unassigned" list and onto the schedule table working. I've also gotten the ability to remove from the schedule table working. What I'm having a difficult time wrapping my head around is moving an item in the table to another part of the table.
The fiddle is located here. I'd appreciate any suggestions on getting internal drag and drop to work. I've been working on this all day and I'm starting to get blurry vision. Oh, and by all means if you think what I'm doing can be done better, please make the change, just let me know what version the fiddle is up to.
UPDATE
As per #SMathew and #darksky I've rebuilt the whole fiddle where I'm not directly shifting the table cells around, but instead their content.
I know you guys recommended using divs and/or spans, but I want to use the structure of the table, especially the rowspan to designate the height of the cell in 30 minute increments. It does work a lot better now, with the only bug being moving cells (or moreso their contents) around because I have to restore cells affected by the rowspan at the source site and remove the cells that will conflict with the rowspan at the target site.
The updated fiddle can be found here.
UPDATE 2 (FINAL)
So, I went back to the drawing board again, and after 64 fiddles, I finally got it to do what I want. In the end, the trick to get everything to work fine without manipulating the structure of the table. All I had to do was set cells that are in the way of a rowspan to display: hidden.
Anyway, for anyone whose interested, the new fiddle is here. I did discover that Chrome has some issues handling the API. I've noted them in the fiddle (along with a partial rant).
The problem is that you are trying to make the td elements draggable. When you remove/insert td elements from a table like that, you have to create a bunch of empty cells to balance it out. I would suggest keep the table intact and wrap draggable elements in a div or span tag. This way the table structure never changes. Your code will also be much simpler and efficient.
It looks like my problems never end with this site. I'm using jQuery to pull posts tagged "_featured" into the sidebar on a Tumblr blog. I have it calling the title of the text post along with the image included in it. Unfortunately, no matter what I try, this breaks the equal height columns on any page where the content column isn't longer than the sidebars.
I've tried different methods of achieving equal columns (I'm currently using The Equal Heights jQuery Plugin since I'm already using jQuery on the site. I've also tried the padding/negative margin trick and good ol' Faux Equal Columns using a background image. I figured it would be easy to solve it by using the jQuery plugin and wrapping the function call in a $(window).load(function(), but it's still hit or miss (mostly miss right now for some reason).
If anyone has any suggestions, please, save my computer from being thrown. The obvious solution that I'm thinking might work would be to have the JS calling the featured posts to also include the image size, but I'm not sure how I would do that.
The JS calling the featured posts can be viewed here and the site itself is at escapebadmusic.com.
Thanks again, everyone. I think I say this just about every time I post a question, but the help here has saved me a lot of time and frustration. It's always appreciated.
Try running EqualHeights after dom has finished changing.
(to be more specific - you should run EqualHeights after doc.ready, and after you add your image, or changed anything in the dom that affects heights)