Wanted: IE9 table cell ghost, alive and without JS - datatable

The IE9 layout engine has issues with tables. Whitespace seems at the root of it.
If you've seen the infamous ghost cell you know what I'm talking about, if you haven't, consider yourself lucky and don't worry about it.
Anyways, I'd really like an HTML only sample to test "fixes" on.
I know I've seen it before in odd circumstances several layout tables deep, but I can no longer get the ghost cell to come up when I need it to.
What I need is a consistent ghost cell without invoking JS.
I've found several JS related ones, and there are plenty discussion on those when it comes to sorting.
This is a great sample:
http://www.ncf.ca/ncf/support/ie9_issue/index.html
Some discussions:
http://social.msdn.microsoft.com/Forums/en-US/iewebdevelopment/thread/28d78780-c95c-4c35-9695-237ebb912d90
http://datatables.net/forums/discussion/5481/bug-ghost-columns-when-generating-large-tables/p1
http://datatables.net/forums/discussion/8248/datatable-in-ie-9-bug-with-large-tables/p1

I managed to clean up the html quite well and still keep the issue. I replaced all the javascript with equivalent spaces & newlines, and could remove most of the elements attributes without affecting the ghost-cell.
It seems like IE has a buffer problem since removing single spaces or newlines in a "safe area" cause the ghost cell to disappear, while removing entire attributes does not affect the rendering.
I see that you have unclosed tags, but I also managed to remove them altogether (replacing with spaces) without removing the ghost cell.
Result being I have a javascript-free html with ghost-cell. See result here: http://compscicon.no/ghostcell.htm

Related

Draw2d: Containing RectangleFigure will sometimes cuts off text when zoomed. (Pictures included)

In my program I have a bunch of RectangleFigures where each figure holds text. The text is held in a TextFlow which is held by FlowPage to allow word wrapping. RectangleFigure then uses getPrefferedSize() to make itself just big enough to hold it's text (using a fixed width).
These RectangleFigures are held by a ScalableLayeredPane. The problem rises when I try to zoom by calling setScale(). Most of the time it works fine but occasionally the ends of the text will be cut off. If I zoom again the figure will correct itself. I should also say that I have tested my program using Figure instead of RectangleFigure with the same result.
Has anyone dealt with this bug before and can shed some light on why this is happening and/or know of any workarounds?
I havn't included any code because this is a rather large program and relevant chunks of code are spread out. But if you would like to see the code let me know and I will try piecing it together.
I was holding the text inside a Figure and that was the Figure I was calling getPrefferedSize() on. But I then put that Figure(lets call it textFigure) inside a second Figure(called containerFigure). I was essentially doing the equivalent of containerFigure.setSize(textFigure.getPrefferedSize()).
You're probably wondering why I was doing that. Well originally I planned on having containerFigure hold multiple things instead of just textFigure. I ended up coding it differently but forgot about the unnecessary extra layer.
So even though containerFigure was technically the size it needed to be scaling caused problems. But when I removed containerFigure and started placing textFigure directly on the screen this bug was fixed.
This is a fairly specific error on my part so I don't know how much help this will be to others. To make it more broad if you're having some kind of sizing issue just check to see how the size of parent Figures are being set. Using sizes from child Figures might be incorrect and/or causing problems.

Nokogiri strategy for identifying largest text on a page?

I'm doing a comparison of a bunch of landing pages in the wild. I'm trying to pull out the main header and the call to action, but of course the HTML formatting of the pages varies wildly.
I started looking for H1, H2, etc. assuming that the header tags correspond to primacy, but this is often not the case. Rendered font-size* might be a better indicator, however this seems messy and wouldn't handle cases where images with alt tags are used.
What's a good strategy to identify the main heading of 100 wild landing pages using Nokogiri?
*Also- is there a clever selector for rendered font-size?
You can't do it unless you have an AI running that can determine the most semantically important section of a document.
You can't count on the tags, such as headers or meta-tags, because those can be missing entirely.
You can't count on location in the source because CSS can move things anywhere.
And, even if you think you've got it nailed by looking at the CSS, the JavaScript can rip that reality from you because it can override everything, relying on the fact it takes a human's eyes and brain to make sense of the final rendered page.
So, basically, you're going to be mostly shooting in the dark unless you have code that can understand the content of the page and determine how often a word occurs, along with its synonyms and their root words, and then determine their placement on the page after CSS and JavaScript have been run.
It's really a tough task that a lot of big companies are spending a lot of money on.

Trouble with selection.datum()

I am following this example of a difference chart. I've added buttons on my page that make ajax calls to fetch new datasets, and then I redraw the difference charts. There are several difference charts on my page.
Upon redrawing, the rendering of the above/below areas becomes corrupted: x-values have both above and below areas rendered. I'm fairly certain it's not a back-end problem, because the initial load produces a correct chart; changing a parameter messes up the redrawn chart; and going back to the default parameters and redrawing the original chart also produces a corrupted chart. In fact, I can partially make out what's happening: the original time series is present on the new graph. It's almost as if there are three series being graphed.
I think it has to do with .datum. I don't fully understand how it works, since it differs from the standard enter/update/exit methods associated with .data. I've read the documentation, but am still confused. Some possibilities:
The original data is hanging around (even though I clean out the container with $('#chart').html(''))
The .append(g) is adding groups without removing the earlier ones.
The svg.append("clipPath").attr("id", "clip-below") is causing problems, since multiple nodes have the same id (even though again, I'm not sure how this could happen since I remove the nodes before the redraw).
I feel like I'm missing a lot of fundamentals here, even though I've spent a decent amount of time trying to understand the library. Can anyone see anything obvious, or point out some good resources for me to look at?
UPDATE: This has to do with there being two charts on the page. I noticed this when I opened the inspector and closed it. The areas of the bottom chart (the difference chart) had screwed up, and I noticed the new line that it was using to separate the above-area from the below-area looked a lot like one of the lines from the top chart.
Does anybody have experience with dependency issues/namespace collisions when drawing two charts on the same page?
The problem was, the id's for the clipping paths were the same.
I would still like some more resources concerning .datum.

Splitting Ruby strings into pages

I've been thinking about this problem for a while, and not quite sure the best way to go about it.
In a rails app I have books, which have many chapters, which have many sections. Chapters are basically just containers for sections, though may contain strings of text themselves. The sections hold most of the book text.
I'm planning to build an HTML 5 ebook reader that works in a mobile browser, and I don't want the user to have to scroll down -- I want the text to break at the end of the page.
I'd assumed using split might be the way to go, but I'm not sure there's a way to break at regular intervals? Would a javascript option work better here?
I'd looked at this: Dividing text article to smaller parts with paging in Ruby on Rails but can't feasibly insert manual break marks in the text, some of which are 90,000+ words.
Any ideas would be appreciated.
I think the main problem here is that the page length will depend on the device (and possibly the text size, if that is feature of your app). You should probably send large chunks that are sure to be at least say 5 pages long, at a time and then let the javascript do the paging. Rails has no access, nor should it, to the size of the display.
Text requires very little data, you shouldn't worry about transmitting more than you need or keeping too much in memory.
You may use blank line("\n" or "") as the separator.
I'd send enough of the page content down to easily fill a page and more, then use javascript on the client slide to remove sentences from the page until the scroll-bar disappears.
Resize.js is something similar I wrote a while ago. I wanted to enlarge/reduce the font size used on a screen until the screen was just full (for a dashboard monitor).. Yours would be similar, but instead of changing the font size, you are trimming off sentences.
Let me know if you can't see how to adapt this code.
Note: I would also make the javascript note the amount of text it ends up displaying, and pass that to the server in the 'next page' request, so the server knows where to start the next page from.

Best way to fit a lot of stuff onto one page

I have created a webpage, but my boss came back saying that the page is too busy. I was just wanting some ideas of how to split up the page e.g. Accordian, tabs etc. What tactics have you implemented to break up a page into different sections?
You already named 2 of the most popular ones: accordions and tabs. The other one you're missing is "rotators".
Here's an example of one: http://www.zurb.com/playground/jquery_image_slider_plugin (also happens to be a good jQuery plugin).
Keep in mind that you can also reduce clutter by using more vertical space and embracing scrolling. Not everything has to be above the fold.

Resources