I have a user generated report page that is sometimes printed off, but it has a bizarre bug one internet explorer. The page is set as tables within a series of divs that appear on the website at all the same sizes and formats, however when printing with IE each page "shrinks" a little more. It may be that the margins are growing, but the relative font size and proportions of the table seem accurate in that they shrink with the pages. I have tried disabling the shrink to fit option, but that did not help. Has anyone run into a similar bug? I have been searching for a while but most of the related problems' fixes have not helped.
looked in to your page, what i think that is causing the shrinking of the page is the extra space at the end of the page.
According to
http://www.w3schools.com/html/html_images.asp
Always specify the width and height of an image. If width and height are not specified, the page will flicker while the image loads.
Personally I have tried testing it and never noticed it happening. Anyone seen it before and know why it happens?
w3schools is not known for their accurate information, and historically was so bad that http://w3fools.com was created to explain just how bad the information was.
The "flicker" that w3schools is referring to is probably the content shifting that happens when an image changes sizes after it loads. Browsers have generally optimized this shifting to mostly go away, but it can still occur depending on how images are loaded and styles are handled.
The main point being to use [width] and [height] attributes to inform the browser of what size the content is expected to be to make correct rendering as fast as possible.
On one of my websites a post received a big amount of comments (1188 to be precise). As a result the length of this page is quite long (1,100,000 characters).
Despite being that large, the page used to display fine. Last week I launched a new design in HTML5, and now the browsers are cutting half-way through the comments, so that some of them don't get displayed (I am not 100% sure the re-design is the cause of the problem).
The weird thing is that the HTML source looks fine (all the comments are there) but the visualization on the browser cuts the page.
You can see it here: http://www.dailywritingtips.com/50-incorrect-pronunciations-that-you-should-avoid/
Any clue regarding the possible reason?
This is the problem bro. You are setting max-height: 100000px to every element. Your body's height is more than 100000px so it restricts it to 100000px only. Remove this line from your CSS and things should work.
I have a site with a header div and an iframe used to display a map in the rest of the page, resizing to the maximum space it can under the header div.
I can get the method working on Firefox and Chome, but the iframe won't fill the div on IE9. Anyone know what the issue is? Rather than post html, here's a few links to the problem page and the old page I'm re-designing that does work in the same way in IE9.
New problem page (doesn't resize div in IE9):
http://permitmap.paydirt.co.nz/devtest/permitmap.html
Old page using the same technique that does work in IE9:
http://permitmap.paydirt.co.nz/
It might be my abuse of Twitter's Bootstrap? I use bootstrap it as it's meant to be used on normal content pages, but this page is a one-off that needs to display a map in as much of the page as possible while still following the styling for the header as the rest of the site.
And my use of tables for layout is also bad practice I know, but it's the only method I've found to achieve the desired effect with the iframe (believe me, I've tried a lot of ideas out that don't use tables!).
Thanks in advance any CSS / HTML gurus out there that can help!
How much time is lost making IE behave like other browsers!? Microsoft must cost the planet an incredible amount in lost man hours and extra expense supporting IE.
Ah, just noticed I had to solve this issue with the original page.
Removing the DOCTYPE element from the top of the page resolves the issue in IE9!
I came to know that, if we dont give width and height attr. in image tag there will be a performance isssue.
I have a div element for which i'm setting width and height in percentages. Also the same div is having a background image of fixed size say 140px * 140px.
Here, will there be a perfromance issuse?.
markup example:
<div style="width:50%;background:url('imgofsize140*140') no-repeat"> </div>
Thanks
This isn't a one-size-fit-all case - Therefore we have to look at it case by case.
There are a lot of variables that we must keep in mind - User's internet connection speed, image size, computer capabilities, etc.
I found a few questions on SO that are somewhat relevant to this question. I will include them as I see it beneficial. I am NOT claiming to be absolutely correct.
BGIMG vs IMG
Performance Argument
AFAIK, browsers cache images the same whether they're in a DIV or an
IMG. In any case, I think this one of those cases where specific
performance is defined as an implementation detail internal to each
rendering engine (and possibly the browsers built around them). As
such, it's both out of our control as designers/developers and subject
to change from browser to browser and version to version. In other
words, I wouldn't spend too much time worrying about it.
Context
Technical differences yes, most notably you can set the width/height
of an IMG tag and it will stretch the image, which can be useful in
some situations.
The main thing you've got to keep in mind though is the context of the
image within the HTML document. If the image is content, say an image
in a gallery, I'd use a IMG tag. If it is just part of the interface I
might use a div instead.
- By Paul
And the response to that is just as important.
That said, you bring up an excellent point about the semantic
difference: an IMG is usually the better choice when the image is a
material part of the page's content, while a CSS technique is usually
preferred when the image is just decorative or for formatting.
This is not performance related directly - More about semantics and accessibility. By - Mr. W.
Then one more for Performance OFF of SO which I feel is directly related to your question.
Page Load Test
The version with background images actually gave me a “Document
Complete” after .0225 seconds – while the fully loaded page load time
was roughly the same as the inline image version. Could using all
background images speed up firing of $.document(ready)? It turns out
background-images are only downloaded after the element (containing
div, span etc) is available. This prevents blocking from all the round
trips required to get images.
results: inline image test page
results: background image test page
I wouldn't think there would be a performance issue in the same way as not specifying height and width on a img tag, since that forces the browser to repaint the whole page and that's where the performance issue is.
http://code.google.com/speed/page-speed/docs/rendering.html#SpecifyImageDimensions
tl;dr
You will not get a performance penalty (which is really small in the other case as well).
Some more details:
You shouldn't care (unless you work for Google) about the performance "penalty" you'd get from not specifing a width & height, but more about the layout flickering you might get.
Not specifing a width and height will make the browser display an initial box, as it doesn't know beforehand how much space the image will take, and after the image is loaded it will do a reflow - which means it will have to recalculate the layout of some elements which will be affected by the size change. But, this is actually going to happen very fast (and you're probably triggering reflows in lots of other places).
There is no reflow necessary for the background image.
I don't think this will effect perfomance.
If you combine your background images into one image and position it as and when you need to that will help speed up performance as you're only loading the one image rather than multiple images.
The background image will be displayed as 140x140 unless the div width has smaller size than 140px.
You might also want to check the result in older browsers such as InternetExplorer 6-7-8 just to ensure if there is any other performance issue.
Depends on the browser. I learned today that Chrome currently redraws the canvas as you scroll with an absolute position bg image. Firefox handles it just fine. This should be fixed in a future Chrome release.
On the contrary, specifying the img height and will cause the performance issue.
Because by specifying them, you tell the browser to resize the img first, then render the image. For example, storing thumbnail image is much better than resize the image on the fly.
If your image is already the specified size you want their is no need to specify the Height and Width in the attributes. Also, there will be no performance issue in using the background image.