Works fine in firefox but displaying bottom left in ie9
I assume it's either something to do with css in ie9 or the DOCTYPE?
Any help appreciated. The site this is happening on is below.
http://bydezign.co.nz/Products/Chairs/ManoliChair.aspx
Where to begin
Okay lets start with validation
http://validator.w3.org/check?verbose=1&uri=http%3A%2F%2Fbydezign.co.nz%2FProducts%2FChairs%2FManoliChair.aspx
Now a lot of those errors are I think as a result of not adhering to your transistional doctype. I always go xhtml1 BUT you may have your reasons for the transistional (though I can't believe anyone worth their salt nowadays would not use xhtml as it is pretty much the standard.
Sorting your doctype MAY (and probably will) solve your rendering issues but if it doesn't I would look at your use of tables for layout. This is a very big 'no-no'. You should be using divs and css for layout. It will give you much better design capabilities. Tables are not semantically correct to use for layout - they are for displaying tabular data.
Fix these first and see if that solves your issue (99% confident just the doctype and getting it through validation will resolve the issue
Related
According to the HTML5 Boilerplate team (and many other authors, for sure), all JS on a given page should go at the bottom (right before the </body> tag) as far as this is possible, except for Modernizr due to the way it acts during page load.
Given that Google WebFonts Loader works, as far as I can tell, pretty much the same way as Modernizr (by doing #font-face feature-detection and adding classes to the <html> tag), I wonder if the same holds true for this script...
Should this go on the <head> or <body> tag? Does it matter all that much?
Short answer: as much as the pageload speed purists would love to tell you otherwise, the reality is that no, it doesn't actually matter that much. Put it at the top.
The only reason for putting JS includes at the foot of the page is for page loading performance reasons. If putting it at the top does not result in a noticeable performance drop, then it really doesn't matter. Particularly it's just the one or two scripts and you stick to having most of your scripts still at the bottom. The things is: for most sites, the difference it makes is pretty negligible.
I don't really know the answer as it applies specifically to Google Webfonts, as I haven't used that library (yet), but my advice is just stick it at the top with Modernizr, and be done with worrying about it.
My brain is overflow about this issue, so let me share my frustration in order to look for someone having the same experience and, luckily, finding a solution.
The thing is the following:
http://jsfiddle.net/w4d2E/
In chrome, percentages work fine, but when trying the same in Firefox (latest version) the content div is not expanding horizontally and vertically anymore.
I've analyzed every similar question over here, but I can't find any valid answer.
Thanks in advance
P.S.: I've tried to use block display instead of the 'box' one in the 'content' layer, but still having the same behavior.
You're using XUL box layout. I suggest not doing that. -moz-box is NOT CSS flexbox layout, as you seem to think.
The problem here is display: -moz-box for body. If you remove it everything works fine. It appears to be a bug, so I suggest filing a report in the bug tracker.
I'm working on a site with lots of CSS3 transitions (which are hardware accelerated) and high memory objects (for example, an array of 39 objects, each containing the full html source for a typical online news article) and I'm noticing some very choppy/jittery scrolling, which I've been unable to debug.
I've kept these high memory objects out of the DOM, which should prevent them from affecting DOM performance, however, I can't help but think that they are still having a negative effect. I don't have code samples to post because I'm unsure of whether this is even an issue.
Please go to this site (Orange) and click on an article tile. In the reader div that pops up over the page, try scrolling as you normally would. Does it feel choppy/jittery? Do you have any suggestions on how to improve this?
CSS3 transitions, opacity, text and box-shadows and the like are certainly known to impact rendering speeds. In fact, even sites with heavy use of text-shadow alone can cause choppy scrolling on the average computer. Combining this with heavy use of javascript seems like a recipe for choppy web browsing.
edit: The loading animation on the o in orange is pretty awesome!
Yes, that's jittery. A page with a lot of Javascript will do that and frameworks like jQuery won't help at all. I'd recommend recoding as much as you can without using jQuery and passing it through JSLint (http://www.jslint.com/).
Try using Chrome's developer tools too to get an idea of what the bottleneck is.
Try disabling Javascript too and seeing if it's any better. If it isn't, then you know where your problem lies.
This is probably an easy fix, but I'm stumped. Here's the URL: http://urgent.mchenry.edu
First off, underneath the urgent.mchenry.edu text box in the header is an h2 w/ class="caps" and text that says "Official McHenry County College Update". However, it absolutely disappears in IE7. Gone.
I tweaked the ie.css with !important declarations, but still, no go. What gives?
Secondly, in FF, the same h2 has some weird a:hover states, despite the fact that there's NOT an anchor tag in the source code, but FF inserts its own. Use Firebug and see what I'm talking about.
Any help on the above two points would be greatly appreciated. BTW, I'm running XP/FF 3.5 and IE8.
The problem with the hover state is easy to fix - your closing tag on the urgent.mchenry.edu link is <a/> instead of </a>. I suspect this may fix your other issues too.
See here: http://code.google.com/p/ie7-js/
Does anyone have any experience or remarks about this javascript? Is it worth including? Do you recommend it?
I know many people, myself included that are using various IE hacks to get transparent PNG support. THis looks like a little bit more help, and as long as it works, and the size is fairly small, I wouldn't see much against using it.
I've used it before, and my results are mixed. Those scripts cause IE to churn for a bit on page load. Basically, you have to think of it as iterating through Elements and stylesheet rules to apply "fixes" for areas that are deficient in that particular rendering engine. In some cases, depending on how complicated your markup or stylesheets are, that can take a bit of time and you will see the browser hang.
That said, if you can trade off that performance cost, you will save development time as you'll spend less time hacking around IE6 quirks; IE7/IE8 will provide enough missing functionality that you can avoid certain edge cases, can develop using standards better (min-width/min-height, multiple className selectors, etc.), and certain rendering issues will disappear.
However, if you just need 24-bit transparent PNG support, use a tool built for that. Including IE7/IE8.js for PNG support alone is like pounding in a nail with a tank. Use DD_belatedPNG for that.
It works, but its worth keeping in mind that ie7.js and ie8.js do much more than provide transparent PNG support. Even with the transparent PNG support, its worth keeping in mind that transparent background images cannot be tiled (repeated) using background-repeat or positioned using background-position. This hinders any ability to use CSS rollovers using background-position. I've only used it on one site I've done, and now that I'm updating the site I can't remove the ie8.js because if I do the entire website breaks layout in IE. I don't believe I'll be using it in the future, and instead rely on simple CSS hacks or simply allow my sites to "degrade gracefully" in IE6.
I know that there are some tools for fixing the transparent PNG problem which are more flexible than this. For instance, the jQuery plugin ifixpng2 will support background position, which ie7-js doesn't do.
As long as you are aware of exactly what it fixes, I would say go for it. I'm not sure about this lib exactly, but some libs get very expensive if you have a large DOM, as they tend to hook in HTC file base behaviors on EVERY DOM Element. This causes the dreaded "Loading x of y" status bar message to flash constantly on the initial load, and any newly generated DOM content.
well its beautiful and works grate way u can use cs3 features like li:hover. we did lost of project last time using ie8.js and it works great way.