IE8 not recalculating size of div on insertion of content - javascript

So, now in this page (it's a dev page), http://www.antarctic-design.co.uk/oboe when the content is loaded (dynamically from JSON source), IE doesn't recalculate the size. Do you know how to force it to do so?

with
.information_block { height: auto; }
you should solve (or at least it works injecting that style using development tools [F12])

Related

Workaround for iframe/mousewheel bug in Safari 6.1/7.0

I've found a bug affecting Safari 6.1 and 7.0 (it is fine in Safari 5.1 and 6.0). I've reported it to Apple.
The test case is here: http://tremby.net/dump/iframe-safari/
The code is very simple. The parent page just has an iframe, and the iframe has a listener for the mousewheel event which fires an alert. The iframe's contents are smaller than the iframe itself (more on that later).
If you refresh this page by clicking in the location bar and pressing enter, the mousewheel events in the iframe will not fire (you see no alerts). But if you refresh with the refresh button they will.
What I need is a workaround to this.
One we have already found is to make the iframe's contents overflow the iframe's bounds. Mousewheel events now fire, but it's not acceptable to have a scrollbar and the contents moving. (Never mind why the choice of using an iframe at all -- that's not up to me.)
Any ideas?
Unbelievably this feature is still present in Safari 8.
I found great workaround here: https://bugs.webkit.org/show_bug.cgi?id=124139
Simply add onmousewheel="" attribute to the iframe tag.
<iframe src="..." onmousewheel=""></iframe>
I found a workaround which is acceptable in my use case.
Adding the following CSS to the iframe contents makes the events show up.
html, body {
width: 100%;
padding: 0;
margin: 0;
}
body {
padding-right: 1px;
overflow-x: hidden;
}
No scrollbar is shown since the content-box box sizing model is used by default and the width is 100%, which means the pixel of padding is overflowing off the right edge, which is hidden.
Example is at http://tremby.net/dump/iframe-safari-workaround/

Height is not being set on an InfusionSoft form

We've got an InfusionSoft form on a page (on a WordPress site) that is coming from the InfusionSoft javascript.
<script type="text/javascript" src="https://uu145.infusionsoft.com/app/form/iframe/9ad1af7469e553f569dde3d29b09d319"></script>
on this page:
http://www.heartofbusiness.com/foundations-one-clients-money-mini-series/
Some of our users are reporting that the form only partially shows (it's all there in the iframe, but the viewable area is about half the height of the form). Mostly in Chrome & Firefox on macs. Safari doesn't seem to ever have the problem, but it's not consistent as I'm able to see the form properly in both Chrome and Firefox on my mac.
Any thoughts as to why the height wouldn't be set properly?
Edit: I did some more digging on your webform and it looks like the issue presents itself in Internet Explorer. To fix the issue you can set a manual height on two elements.
First set the div infFormDiv_0 to height of 360.
Second set the height of the iframe to 360 as well.
CSS:
#infFormDiv_0 {
height: 360px;
}
#infFormIframe_0 {
height: 360px;
}
Original Answer:
It is hard to determine the issue if I can't see it myself. The form works fine in the multiple browsers I checked.
I would suggest you change from the javascript form to the HTML form anyways. This would most likely prevent the form from cutting off in the cuture.
Go to the forms details page and click Get the code and select the HTML unstyled version to get the HTML code you will need. Then style the form using CSS to get the look you want.

Html/JS/PHP two pages using the same files look different (only in chrome)

On one of my fake domains I've been working on a menu for fun. The menu works as expected here:
-Removed-
However, that page doesn't use any PHP.
-Removed-
This page does use PHP to fill the links in the menu from a database full of fake links. The problem is that it works as expected in IE9 but chrome for some reason adds a left:40px to the div that holds the links the first time you load the page. Afterwords, the script looks and acts as it is supposed to. I validated the html and CSS as XHTML 1.0 Strict and CSS3. I have not been able to test this in Firefox or opera because this computer cannot have those browsers installed.
The only difference HTML wise is that in the php version, the links are actually tagged as links were as the homepage version, they are simply text. The CSS does contain styles for the element in the .LinkDiv class that sets margins and padding to 0px.
If anyone is able to shine some light on this issue, that would be great.
I added:
.LinkDiv {
height: 100px;
width: 175px;
display: none;
position: relative;
left: 0; /* This */
background-color: rgb(217,217,217);
}
and constantly hit refresh, sometimes in chrome it loaded correctly, others it loaded with the div 40px to the left.
add this to you css file
.LinkDiv:nth-child(1){left:0 !important;}

How do I identify source of element.style injected by js?

I am updating a wordpress website for a client so am unfamiliar with the structure of the whole site.
On the blog page (http://shoreditchradio.co.uk/blog/) , posts are displayed in a wrapper #blogleft, which is defined in the css file as follows:
#blogleft {
float: left;
width: 580px;
}
however via the inspector I can see that the width is being over-ridden to be 100%
element.style {
width: 100%;
}
My question is - what is the easiest way to determine where this is being injected from? As far as I know it can only be from a javascript file somewhere in the site.
I have been poking around in the inspector for some time now. Is there a simple way to identify the source of an injected inline style like this? Any help much appreciated!
That width:100%; is hard coded on the HTML, you can see this by checking the style attribute on the div tag in the HTML.
The easiest way for CSS and HTML debugging is by using the developer tools/web inspector tools (integrated in firefox and chrome or by plugin such as Firebug). The element.style CSS selector means it is hard coded on the selected element.
"hard coded", in this case, means it is directly injected through the HTML. Through the developer tools/web inspector tools you should be able to determine the origin of the CSS in question.
If you want to troubleshoot "injected stylesheet" in Chrome
Open develop console -> Network
Filter it something '.css'
Look for extensions domains that load some CSS files
Find the extension in your extensions list by filtering domain (like on the pic "hcndlme...")
Try to disable the extension and reload the page

Printing pages on different Browsers

I'm encountering a lot of problems with printing on a rather huge website we are working on.
The problem is there are issues in FF, IE etc... that appear only when printing.
The workflow is like this: I click a print button on the page, a popup opens with different template and styles and the window.print command is triggered.
MY POSSIBLE SOLUTION:
When the popup opens, I will render the entire DOM in a canvas element and then put it back in page as a png file, and then trigger the print action.
Is this a feasible solution?
You can approach this in two ways:
Browser extension
Writing an extension for the browser(s) (at least Chrome and FireFox) will allow you to grab the current content as a bitmap you can use with canvas.
This is probably the fastest option as the screen snapshot is created internally. Though, I am not sure if the browser snapshots client window or the full document so this need to be determined.
Simulate the DOM tree
There are libraries such as html2canvas and canvas2image that simulates the DOM tree and tries to render an approximate representation of the web page.
There a couple of things to notice with this:
It's relatively slow
You may run into cross-origin restrictions in relation to images (work around is to use an image proxy)
You cannot get content of "foreign objects" (Flash, Java etc.)
It is not 100% accurate (if this matters)
When you have a snapshot one way or the other the other things should be straight forward. Just remember that users have different printers, drivers and resolutions and you may not be able to produce identical results cross-over as you are also dependent on the browser's own print implementation.
provide special css for print view:
<link rel="stylesheet" type="text/css" media="print" href="print.css" />
in which for everything you dont want to print use something like:
#qqq, .#aaa, #header, ...., ...., .banner{
display: none;
height: 0;
width: 0;
}
so you leave only content you want to see printed. In this case visitor or you dont need to use special print popup version. Just click print.
example: http://viliusle.github.io/miniPaint/ - only canvas will be printed.

Categories