I am working on a Wordpress site (a modified 2012 theme) for a client that is rendering incorrectly in IE8. Everything looks great in IE9+, as well as current versions of Chrome, FF, Safari, etc. I have looked around at some of the suggestions posted to fix the problem but I'm not quite sure where mine begins. The whole page is considerably broken. If anyone can provide me with some clues it would be a huge help. Thanks!
My Site
Edit: I'm noticing some of my styles are not being applied, specifically to top-nav and my footer. Others appear to have most if not all styles mostly intact. I've read that media-queries are not supported in IE8, but I don't see how that could be related. I am also reading that only 31 stylesheets can be applied, but I don't believe I am using nearly that many.
I had a project a while back where I have built an intranet and was nearly finished with the strap when I realized that most of the users rely on IE8; it was a shocking experience, can tell you that. That just as a preamble, so I know what your into.
I have wasted a lot of time so to safe yours (maybe), here what I would look for and probably do:
Install IE8 if you haven't already. There's a lot of tools which can help you with that like IE Tester as well as an integration installation from Microsoft directly to switch between versions
Eradicate the current errors first before you start working on the specific IE8 issues (as #markratledge already mentioned)
If you want to have HTML5 elements working as well then I recommend the HTML5.js Enabling Script
You have definitely too many HTTP Referrers (even for modern browsers), in IE8 (especially on a slower machine) it's sometimes deadly (Your page may load fast, however the rendering time is extremely long (+/- 6-20 seconds))
Combine and minify CSS and JScripts
There are a lot of services around the net where you put in your raw data and it compiles you a minified version, or server-side like Minify for PHP5
Move most scripts to the bottom to counterfeit rendering issues in IE8
Make a unique .css only for IE8 or use hacks, if really needed in your main, however you prefer (quick'n'dirty solution though)
IE8 and the X-UA-Compatible situation
How IE8 Determines Document Mode
I'm not too sure, but I think Mootools and jQuery together may create a conflict in older IE's (assumption)
Fix your code errors, in particular the JS call above the doctype. Anything above the doctype throws IE into quirks mode
Especially IE8 will get really hard on you for little mistakes inside the code, I have even seen script-includes not working because of being positioned lower than another in the code (while any other browser doesn't really care). It will take you at least a good bunch of hours to fix/erase all those errors and to make it compatible for IE8< users.
Beware that most clients (at least from my experience) don't (want to) understand browser compatibility issues like this one (It has to work!) or if really needed then make them understand that some features may be jeopardized/incomplete in the specific browser, herein.
There's plenty more you can do, but that depends on the deadline/timespan you have.
Fix your code errors, in particular the JS call above the doctype. Anything above the doctype throws IE into quirks mode
See [Invalid] Markup Validation of delindesign.com excellence - W3C Markup Validator. Scroll down in the validation report to see line numbers and source code. Start fixing the code errors and revalidate.
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
What's the point of valid CSS/HTML?
This is a over-asked question, but I'm going to ask anyway.
How important is site/code validation?
I'm not referring to code errors that would break a site layout, like forgetting to close a tag, or using an unsupported tag. Just general warnings and tag usage errors.
I used to make sure my sites were validated 100%. No questions asked. Lately, I have not taken that approach however, especially with the use of HTML5. I feel that it is more important to make the site function as needed, even if it means putting a <p> tag within a <span> tag. Also, some of the CSS validation rules are pointless I feel. They are more considered with saving every possible byte then code readability.
Does it really matter? Looking for thoughts/concerns/opinions/links to articles. Thanks!
I do it for Peace of Mind.
When code is valid, it's more likely to work with a compliant browser. In theory, just because I test it and it works in various browsers today, does not mean it will work in newer browsers tomorrow. Standards Compliance solves that issue because if it follows the "Standard" today, it will follow the "Standard" tomorrow... of course, assuming that new browsers continue to support the Doctype you've selected to standardize against.
Why Validate - W3C
From W3C itself, here's a "Why Validate?" page that is extremely helpful: http://validator.w3.org/docs/why.html
Some of the main points:
Validation as a debugging tool
Validation as a future-proof quality
check
Validation eases maintenance
Validation helps teach good practices
Validation is a sign of
professionalism
Edit
The biggest reason I think is that when you don't validate, you're catering to broken browsers instead of designing for the browsers that do it right. Chad recently quipped that "if you use a degraded browser you deserve a degraded experience", and I think he's absolutely right. Design perfectly valid markup for standards-compliant browsers, and if absolutely necessary use IE6-specific stylesheets and the like for broken browsers. This way, you don't break the standards-compliancy of the good browsers, but you can "cheat" for the broken browsers.
Edit 2
The best exception, I think, is when you're moving forward instead of backwards. When you move backward, use separate stylesheets that only load for broken browsers - that way the good browsers aren't affected. But when you're moving forward (e.g, using CSS animations with vendor-branded tags, etc) you know that someday those will become standards (well, most of the time).
HTML5 is the culmination of our loose and sloppy HTML periods then overly-anal and pedantic semantic XML compliant xhtml period.
Which led us to an overall "validation is really important, but let's be pragmatic about it."
As stated, valid html is easier to debug, so there's the big plus right there. But there's plenty of room for exceptions as well. As long as you aren't using laziness as an excuse to allow for invalid markup when needed, it's probably a pragmatic decision.
I'm doing css for a website. I send the html and css to a guy, he puts it into ASP.net. The problem is that the transfer didn't end well for my code and it needs some fixing. The problem is that when I look at it in Chrome, or Firefox, or IE8, I get three completely different renderings. I spent a good amount of time trying to fix a drop-down menu that is supposed to appear while hovering over a link. The one he had in place from ASP.net worked in IE, kinda worked in Firefox, and was completely broken in Chrome (I haven't tested Safari or Opera.) Just getting it to look basically the same in firefox and chrome was a struggle. The html source is showing me two completely different pages as well.
Does anyone have experience with this? I know nothing of ASP.net, and it seems like the guy is modifying my layout with a wsyiwyg (I found tables used in random places, which I did not put there.) Faced with this, what is my best option? Is this fixable, or am I in over my head?
Many times WYSIWYG programs don't generate code that results in reliable, consistent renderings. However, there are a few things you can do to check your site's consistency.
You can use a program like Adobe BrowserLab (there's a free trial right now) to automatically render your page in multiple browsers side by side
You can use the w3 Validator to make sure that your code is standards compliant. If your code isn't standards compliant, then you will likely have issues across browsers.
Note that you can force asp.net to generate XHTML Transitional- or Strict-compliant code (if that's the standard you choose to implement) via the web.config file. Use the directive
<xhtmlConformance mode="Transitional"/>
if you want to enable this behavior.
Was your code rendering fine in those browsers before you sent it off to the .NET guy? If so, the programmer is doing something to muck up your work. ASP .NET won't change the way your code renders... it's simply the Windows equivalent of PHP (simply put).
I would suggest (if you haven't already) testing your code before hand-off to verify proper rendering. Take some screenshots, and if after sending your code to this developer things break, you can point out that it was working until he started messing with your markup. If that ends up being the case, at least you know it wasn't you. If it was, then we have more work to do. :)
Can you provide any samples?
The html source is showing me two completely different pages as well.
That sounds like your asp.net guy is doing something wrong there. You can use asp.net to do browser-dependant rendering, but it sounds more like his job is to just make the site render what you gave him, and it's usually better to get your html and css right to begin with.
Is there any problem with using jquery layout plugin (there are several) to layout a page as opposed to using CSS and fixing browser compatibility issues myself?
Another problem is that the page has to fully load and download the javascript, then get rendered. This will slow down the page significantly.
The most obvious problem is that any visitor to the page using a browser with JavaScript turned off will not get the layout. If you're willing to turn away from those people, that may not be a blocking factor for you.
There can also be performance issues, delays on resizing the browser window, that sort of thing.
I'm not saying don't do it; if it's appropriate for your target audience. But look to see if you can avoid it or at least gracefully degrade if JavaScript isn't enabled. (Turn off JavaScript and come here to SO, for instance; still very usable in a read-only way.)
If doing this, continue to be sure to mark up your content in the main page (rather than only adding it dynamically) and use the most semantic markup you can, to improve your search-ability.
When your layout doesn't behave for whatever reason (and that will happen), will you be able to understand the code behind the JQuery plugin to fix it?
Invest in yourself and learn CSS properly, it's not hard, it doesn't take long and it will equip you for the future, don't just rely on plugins. Now I'm not saying never use a plug-in, but this to me seems inappropriate use
I've noticed a lot of sites, SO included, use XHTML as their mark-up language and then fail to adhere to the spec. Just browsing the source for SO there are missing closing tags for paragraphs, invalid elements, etc.
So should tools (and developers) use the XHTML doctype if they are going to produce invalid mark up? And should browsers be more firm in their acceptance of poor mark-up?
And before anyone shouts hypocrite, my blog has one piece of invalid mark-up involving the captha (or it did the last time I checked) which involves styling the noscript tag.
There are many reasons to use valid markup. My favorite is that it allows you to use validation as a form of regression testing, preventing the markup equivalent of "delta rot" from leading to real rendering problems once the errors reach some critical mass. And really, it's just plain sloppy to allow "lazy" errors like typos and mis-nested/unclosed tags to accumulate. Valid markup is one way to identify passionate programmers.
There's also the issue of debugging: valid markup also gives you a stable baseline from which to work on the inevitable cross-browser compatibility woes. No web developer who values his time should begin debugging browser compatibility problems without first ensuring that the markup is at least syntactically valid—and any other invalid markup should have a good reason for being there.
(Incidentally, stackoverflow.com fails both these tests, and suggestions to fix the problems were declined.)
All of that said, to answer your specific question, it's probably not worthwhile to use one of the XHTML doctypes unless you plan to produce valid (or at least well-formed) markup. XHTML's primary advantages are derived from the fact that XHTML is XML, allowing it to be processed and transformed by tools and technologies that work with XML. If you don't plan to make your XHTML well-formed XML, then there's little point in choosing that doctype. The latest HTML 4 spec will probably do everything you need, and it's much more forgiving.
We should always try to make it validate according to standards. We'll be sure that the website will display and work fine on current browsers AND future browsers.
I don't think that, if you specify a doctype, there is any reason not to adhere to this doctype.
Using XHTML makes automated error detection easy, every change can be automatically checked for invalid markup. This prevents errors, especially when using automatically generated content. It is really easy for a web developer using a templating engine (JSP, ASP.NET StringTemplate, etcetera) to copy/paste one closing tag too little or too many. When this is your only error, it can be detected and fixed immediately. I once worked for a site that had 165 validation errors per page, of which 2 or 3 were actual bugs. These were hard to find in the clutter of other errors. Automatic validation would have prevented these errors at the source.
Needless to say, choosing a standard and sticking to it can never benefit interoperability with other systems (screen scrapers, screen readers, search engines) and I have never come across a situation where a valid semantic XHTML with CSS solution wasn't possible for all major browsers.
Obviously, when working with complex systems, it's not always possible to stick to your doctype, but this is mostly a result of improper communication between the different teams developing different parts of these systems, or, most likely, legacy systems. In the last case it's probably better to isolate these cases and change your doctype accordingly.
It's good to be pragmatic and not adhere to XHTML just because someone said so, regardless of costs, but with current knowledge about CSS and browsers, testing and validation tools, most of the time the benefits are much greater than the costs.
You can say that I have an OCD on XHTML validity. I find that most of the problems with the code not being valid comes from programmers not knowing the difference between HTML and XHTML. I've been writing 100% valid XHTML and CSS or a while now and have never had any major rendering problems with other browsers. If you keep everything valid, and don't try anything too exotic css wise, you will save yourself a ton of time in fixes.
I wouldn't use XHTML at all just to save myself the philosophical stress. It's not like any browsers are treating it like XHTML anyway.
Browsers will reject poor mark-up if the page is sent as application/xhtml+xml, but they rarely are. This is fine.
I would be more concerned about things like inline use of CSS and JavaScript with Stack Overflow, just because they make maintenance harder.
Though I believe in striving for valid XHTML and CSS, it's often hard to do for a number of reasons.
First, some of the content could be loaded via AJAX. Sometimes, fragments are not properly inserted into the existing DOM.
The HTML that you are viewing may not have all been produced in the same document. For example, the page could be made of up components, or templates, and then thrown together right before the browser renders it. This isn't an excuse, but you can't assume that the HTML you're seeing was hand coded all at once.
What if some of the code generated by Markdown is invalid? You can't blame Stack Overflow for not producing valid code.
Lastly, the purpose of the DOCTYPE is not to simply say "Hey, I'm using valid code" but it's also to give the browser a heads up what you're trying to do so that it can at least come close to correctly parsing that information.
I don't think that most developers specify a DOCTYPE and then explicitly fail to adhere to it.
while I agree with the sentiment of "if it renders fine then don't worry about it" statement, however it's good for follow a standard, even though it may not be fully supported right now. you can still use Table for layout, but it's not good for a reason.
No, you should not use XHTML if you can't guarantee well-formedness, and in practice you can't guarantee it if you don't use XML serializer to generate markup. Read about producing XML.
Well-formedness is the thing that differentiates XHTML from HTML. XHTML with "just one" markup error ceases to be XHTML. It has to be perfect every time.
If "XHTML" site appears to work with some errors, it's because browsers ignore the DOCTYPE and interpret page as HTML.
See XHTML proxy that forces interpretation of pages as XHTML. Most of the time they fail miserably. This is one of the reason why future of XHTML is uncertain and why development of HTML has been resumed.
It depends. I had that issue with my blog where a YouTube video caused invalid XHTML, but it rendered fine. On the other hand, I have a "Valid XHTML" link, and a combination of a "Valid XHTML" claim and invalid XHTML is not professional.
As SO does not claim to be valid, I think it's acceptable, but personally if I were Jeff i would be bothered and try to fix it even if it looks good in modern browsers, but some people rather just move on and actually get things done instead of fixing non-existent bugs.
So long as it works in IE, FF, Safari, (insert other browser here) you should be okay. Validation isn't as important as having it render correctly in multiple browsers. Just because it is valid, doesn't mean it'll work in IE properly, for instance.
Run Google Analytics or similar on your site and see what kind of browsers your users are using and then judge which browsers you need to support the most and worry about the less important ones when you have the spare time to do so.
I say, if it renders OK, then it doesn't matter if it's pixel perfect.
It takes a while to get a site up and running the way you want it, going back and making changes is going to change the way the page renders slightly, then you have to fix those problems.
Now, I'm not saying you should built sloppy web pages, but I see no reason to fix what ain't broke. Browsers aren't going to drop support for error correction anytime in the near future.
I don't understand why everyone get caught up trying to make their websites fit the standard when some browsers sill have problems properly rendering standard code. I've been in web design for something like 10 years and I stopped double codding (read: hacking css), and changing stupid stuff just so I could put a button on my site.
I believe that using a < div> will cause you to be invalid regardless, and it get a bit harder to do any major JavaScript/AJAX without it.
There are so many standards and they are so badly "enforced" or supported that I don't think it matters. Don't get me wrong, I think there should be standards but because they are not enforced, nobody follows them and it's a massive downward spiral.
For 99.999% of the sites out there, it really won't matter. The only time I've had it matter, I ran the HTML input through HTMLTidy to XHTML-ize it, and then ran my processing on it.
Pretty much, it's the old programmer's axiom: trust no input.