I have a very old application, written of the time of IE-5. Some of the pages in IE-11 are not rendering despite having used the meta tag with ie=5 value.
I had this similar problem for making it work with IE-10 and the meta tag seemed to be working fine there.
Please provide your inputs on this ?
Without more information about the specific features that are failing, it's hard to say what might be the problem.
A number of features supported by IE5 are no longer supported by IE11, including ActiveDesktop, CDF, VML, CSS expressions, conditional comments, binary behaviors, and others.
The IE Compatibility Cookbook is a good resource for this sort of thing; it summarizes major compatibility changes to IE over the last several versions. (There's also a page that contains links describing minor changes to the browser.)
One of the biggest changes is what happens when you load a page that does not contain a document type directive. Prior to IE10, this would enable legacy (IE5) quirks mode. Starting with IE10, it enables a standards-based quirks mode based on the HTML5 specification.
Unfortunately, there's no comprehensive list of all changes as that would be very hard to put together and maintain. (Trust me on this one.) But, this blog also has a lot of useful information.
Hope this helps...
Is there a formal standard I can use to to rate the accessibility, especially for visually impaired people, of my MVC3 web application? If there are various standards, as I suspect, which should I give preference to for a web application primarily targeted at people with no or minimal visual impairment, but strongly wanting to offer as much as possible to visually impaired people? This is a learning management application, so wide accessibility is important.
I am trying to stick to best practices in terms of HTML and CSS semantics and such like things, documented in the handful of books I have, and I am using HTML5 validation in Visual Studio for my Razor views. What other tools can I use, preferably on the development side, before I deploy and can use the various online validators? Are the any online rating tools?
Standard (and reference list)
The W3C standard is WCAG 2.0.
The WCAG 2.0 Recommendation tries to be technologically agnostic and to apply to all kinds of websites, even web apps but the consequence is that it's rather unspecific. HTML/CSS/Script Techniques (as well as the Failure ones and Flash/Pdf/Smil if you use them) and the Understanding part are good reads.
For daily auditing I prefer to use:
AccessiWeb 2.2 reference
list,
"a methodology to verify conformance to WCAG 2.0" that "facilitates
(its) understanding and implementation".
There are references to WCAG 2.0 Success Criteria and Techniques but alas no links. Hyperlinks exist on the french version but weren't added on the english one, alas (I'll try to fix it with them this month).
The script part, essential to webapps, is again partly unspecific but that's because it's hard to be so without having 10x as tests! There are thousands of things to do with JS when there are a hundred of HTML elements.
EDIT 2014: this checklist has been updated to new techniques in HTML5/ARIA (an awesome work imho) but only in french. AccessWeb HTML5/ARIA (in french) May be translated in english in 2014 or 2015 or try an online translation service ;) 70% of tests are common with AccessiWeb 2.2 and the new tests are up to date HTML5/ARIA techniques already working in modern websites with the browsers and screen readers quoted in Annexes.
ARIA, as in Accessible RIA, is another work from W3C-WAI:
(ARIA) especially helps with dynamic content and advanced user
interface controls developed with Ajax, HTML, JavaScript, and related
technologies.
No doubt this is the future of accessible web apps but its support is a work in progress in browsers and assistive technologies. Also old screen readers'll never be compatible with ARIA and they're very slowly being replaced for newer versions because they cost A LOT (thousand(s) of USD/EUR for JAWS).
Thus webdevs must always create apps compatible with both old plain techniques (using tab key and space to access information and interact with it) and new ones (manipulating a tree with arrow keys, being informed of changes in a Live region while reading another part of the page).
ARIA is complicated, needs time and experience, etc
ARIA doesn't replace WCAG 2.0; huge improvements'll be seen with WCAG 2.0 only.
not everything is as complicated as a tree implementation. Landmark roles are very easy to add in any website for example.
If you use jQuery UI, there exists an accessible version of popular modules/scripts: http://hanshillen.github.com/jqtest/
It isn't perfect yet but it's far better than the original. In my experience, you can't mix the legacy jQuery UI scripts and these ones (though I didn't try for too long, I could easily be wrong).
Testing
I wrote about 2 useful services, Opquast and Tanaguru, in another answer. The other answer from BrendanMcK related to automated tests is a must read.
WAVE (fluffmyboner already wrote about it in the other answer) both exist as a toolbar and as a webservice. Main difference afaik: the WAVE toolbar'll analyze the DOM of your page while the webservice'll analyze the HTML+CSS sent but won't execute any JS
TAW (select inglès than WCAG 2.0) is another service for analyzing a few criteria
Wave is my go-to for accessibility validation, although I'm not too sure about what you can use to check pre-deployment.
My environment is Visual Studio 2010 with Resharper 6.0. I have a large website with many CSS files with many styles.
I would like to tidy these up as a lot of them are no longer used, I noticed that Resharper allows you to track usages but obviously this can miss out CSS class specifications in code-behind etc.
My only solution is to do a Find In Files in VS but obviously when you have a large amount of styles this proves too slow and cumbersome.
Has anyone had a similar predicament?
EDIT: It's worth mentioning that the site is a CMS comprising around 10,000 pages, so anything that requires browsing pages might also be a bit tricky.
There is a firefox extension called dust me selector that does this. You enable it and then navigate to each page. It keeps track of all used css. You spit out a new css file with all the tracked css styles.
The Web Essentials Visual Studio Extension has a BrowserLink feature which comes with a way to track unused css in your site while you browse around the site.
A way to do that is running your site in a headless browser like PhantomJS and inspecting the styles applied in order to remove the ones not being used.
Fortunately, there is a nice tool built on node called uncss doing exactly this:
https://github.com/giakki/uncss
I found it here:
http://addyosmani.com/blog/removing-unused-css/
About browsing all those pages, well, I dunno, if you can generate all the possible URL's then you can automate the process.
Give it a try and let me know if it helps.
Has anyone successfully gotten swfaddress to work with IE8 and above?
It seems that when using standards mode, swfaddress will appear to work fine in IE8 and IE9, however, once the user modifies the hashtag in the address bar, the history list becomes corrupted.
In cases where the user starts the application via the hash tag (http://myapp.com/#/test), and then visits another hash (http://myapp.com/#/test1), the history is never saved.
I have tried playing around with swfaddress 2.5 in the svn repository. Interestingly,
the code is similiar to JQuery Address (by the same author). I also note that JQuery Address suffers from the same problem.
If I turn on compatibility mode in IE, the swfaddress and JQuery Address works perfectly. I have been looking into how compatiblilty mode works, and it does not seem like it would modify or affect javascript execution.
Was anyone able to successfully solve this issue? If not are there any other deep linking libraries for flex or flash that contains all the feature sets of swfaddress?
After looking at libraries such JQuery Address, other JQuery state management plugins and even the BrowserManager that ships with Flash and Flex builder, I discovered that they all ran into the same issue as SwfAddress.
At the moment, SwfAddress offers that best features and comes with a .swc and .as files to easily interface with Flash and Flex applications.
Since the other javascript libraries ended up with the same problems, I have decided to stick with SwfAddress.
On a related note, the author has stated that he is no longer working on SwfAddress, so it would be cool if someone in the community can pick up on where it was left off.
Short version: What is the cleanest and most maintainable technique for consistant presentation and AJAX function across all browsers used by both web developers and web developers' end-users?
IE 6, 7, 8
Firefox 2, 3
Safari
Google Chrome
Opera
Long version: I wrote a web app aimed at other web developers. I want my app to support the major web browsers (plus Google Chrome) in both presentation and AJAX behavior.
I began on Firefox/Firebug, then added conditional comments for a consistent styling under IE 6 and 7. Next, to my amazement, I discovered that jQuery does not behave identically in IE; so I changed my Javascript to be portable on FF and IE using conditionals and less pure jQuery.
Today, I started testing on Webkit and Google Chrome and discovered that, not only are the styles inconsistant with both FF and IE, but Javascript is not executing at all, probably due to a syntax or parse error. I expected some CSS work, but now I have more Javascript debugging to do! At this point, I want to step back and think before writing piles of special cases for all situations.
I am not looking for a silver bullet, just best practices to keep things as understandable and maintainable as possible. I prefer if this works with no server-side intelligence; however if there is a advantage to, for example, check the user-agent and then return different files to different browsers, that is fine if the total comprehensibility and maintainability of the web app is lower. Thank you all very much!
I am in a similar situation, working on a web app that is targeted at IT professionals, and required to support the same set of browsers, minus Opera.
Some general things I've learned so far:
Test often, in as many of your target browsers as you can. Make sure you have time for this in your development schedule.
Toolkits can get you part of the way to cross-browser support, but will eventually miss something on some browser. Plan some time for debugging and researching fixes for specific browsers.
If you need something that's not in a toolkit and can't find a free code snippet, invest some time to write utility functions that encapsulate the browser-dependent behavior.
Educate yourself about known browser bugs, so that you can steer your implementation around them.
A few more-specific things I've learned:
Use conditional code based on the user-agent only as a last resort, because different generations of the "same" browser may have different features. Instead, test for standards-compliant behavior first — e.g., if(node.addEventListener)..., then common non-standard functions — e.g., if(window.attachEvent)..., and then, if you must, look at the user-agent for a specific browser type & version number.
Knowing when the DOM is 'ready' for script access is different in just about every browser. A good toolkit will abstract this for you.
Event handlers are different in just about every browser. A good toolkit will abstract this for you.
Creating DOM elements, particularly form controls or elements with attributes, can be tricky with document.createElement and element.setAttribute. While not standard (and kinda yucky), using node.innerHTML with strings that contain bits of HTML seems to be more reliable across browser types. I have yet to find a toolkit that will let you use element.setAttribute to add a 'name' to a form element in IE.
CSS differences (and bugs) are just as important as JS differences.
The 'core' Javascript features (String, Date, RegExp, Array functions) seem to be pretty reliable and consistent across browsers, especially relative to the DOM/CSS/Window functions. There's some small joy in the fact that the language isn't entirely different on every platform. :-)
I haven't really run into any Chrome-specific JS bugs, but it's always one of the first browsers I test.
HTH
Chrome is actually a little different to Safari, it uses a completely different javascript implementation and problems have been reported with both prototype and jquery. I wouldn't worry about it too much for now, it's still an early beta version of the browser and such inconsistencies will probably be treated as bugs. Here's the bug report.
One "silver bullet" you may consider turning to is Google Web Toolkit (GWT).
I believe it supports all the browsers you are interested in, and gives you the ability to code your UI in a Java-compatible IDE such as Eclipse. The advantage of this is you can use IDE tools for code completion and compile-time error checking, which greatly improves development on large-scale UI projects.
If you use GWT UI components, it will hide a lot of browser-specific nastiness from having to be dealt with, but when you compile, will create a compact, deploy file for each browser platform. This way you never download any IE-specific code if you are viewing the app in Firefox. You will also have a client-side stub generated which will load the appropriate compiled bundle of JS. To sweeten the deal, these files are cacheable, so perceived performance is generally improved for returning visitors.
The landscape has evolved considerably to accommodate cross-browser development. jQuery, Prototype and other frameworks exist for cross-browser Javascript. CSS resets are good for starting on a common blank canvas for all browsers. BluePrint and 960 are both CSS frameworks to help with layouts using CSS grid layouts techniques that seems to be getting very popular these days.
As for other CSS quirks across the different browsers, there is no holy grail here and the only option is to test you website across different browsers and use this awesome resource and definitely join a mailing list to save up soem time.
If you are working on high volume production site then you can use a service like browsercam.com in the end game to ensure the site doesn't break horribly in some browser.
Lastly, don't try to make the site look the same in every browser. Your primary design should target IE/FF and you should be okay with reasonable compromises on others. Use the graded browser chart to narrow in on browser support.
As for best practices, starting using wireframes on blank paper or a service like Balsamiq mockups. I am still surprised how many developers start with an editor instead of a wireframe but then again I only switched a year back before realizing how big a time saver it is. Have clean seperation of layout (HTML), presentation (CSS) and behaviors (Javascript). There should be no styling elements in HTML, no presenation in Javascript (use .addClass('highlight') instead of .css({'background-color': 'red'});).
If you are not familiar with any of the bold terms in this post, Googling them should be fruitful for your web development career and productivity.
If you're starting from a base reset or framework and have accounted for IE and it's still all freaky, you may want to recheck the following:
Everything validates? CSS and HTML?
Any broken links to an included file (js, css, etc?). In Chrome/Safari, if your stylesheet link is busted, all of your links might end up red. (something to do with the default 404 styling I think)
Any odd requirements of your js plugins that you might be using? (does the css file have to come before the js file, like with jquery.thickbox?)
For UI, check out Ext.
It's great as a standalone library, though it can also be used with jQuery, YUI, Prototype and GWT.
Samples: http://extjs.com/deploy/dev/examples/samples.html
I've found four things helpful in developing JavaScript applications:
Feature detection
Libraries
Iterative Development using Virtualization
JavaScript: The Definitive Guide, Douglas Crockford & John Resig
Feature Detection
Use reflection to ask if the browser supports the desired feature. If you want to know what event handling a browser supports, you can if(el.addEventHandler) for W3C compliance, if(el.attachEvent) for the IE-type, and finally fall back on el.['onSomeEvent'].
ONE BIG BUT!
Browsers sometimes lie about what features they support. I can't remember, but I ran into an issues where Firefox implemented a DOM feature, but would return false if you tested for that feature!
Libraries
Since you're already working with jQuery, I'll save the explanation. But if you're running into problems you may want to consider YUI for it's wonderful cross-browser compatibility. They even work together.
Iterative Development with Virtualization
Perhaps my best advice: Run all your test environment's at once. Get a Linux distro, Compiz Fusion and a bunch of RAM. Download a copy of either VMWare's VMWare Server or Sun's Virtual Box and install a few operating systems. Get images for Windows XP, Windows Vista and Mac OS X.
The basic idea is this: Compiz Fusion gives you 4 Desktops mapped onto a Cube. 1 of these desktops is your Linux computer, the next your Virtutual Windows XP box, the one after that Vista, the last Mac OS X. After writing some code, you alt-tab into virtual computer and check out your work. Plus it looks awesome.
JavaScript: The Definitive Guide, Douglas Crockford & John Resig
These three sources provide most of my information for JavaScript development. The Definitive guide is perhaps the best reference book for JavaScript.
Douglas Crockford is a JavaScript guru (I hate the word) at Yahoo. Lookup his series "Douglas Crockford Theory of the DOM", "Douglas Crockford Advanced JavaScript", "Douglas Crockford Theory of the Dom", and ""Douglas Crockford The Good Parts" on Yahoo! Videos.
John Resig (as you know) wrote jQuery. His website at ejohn.org contains a wealth of JavaScript information, and if you dig around on Google you'll find he's given a number of presentations on defensive JavaScript techniques.
... Good luck!
Just so you've got one less browser to worry about, Chrome uses the same rendering engine as Safari. So if it works in Safari, it should work exactly the same in Chrome.
See this post on Matt Cutts' blog.
Google Chrome uses WebKit for rendering, which is the same rendering engine as Apple’s Safari browser, so if your site is compatible with Safari it should work great in Chrome.
Update: Looks like this is now out-dated info. Please see Vox's comment on this answer.
If your very top priority is exactly consistent presentation on all the browsers listed with no disparities, you should probably be looking at AS3 and Flex.
Personally, I use Mootools as a simple lightweight javascript framework. It is simple to use and supports all the browsers above (except Chrome, but that seems to work too as far as I can tell).
Also, to ensure consistency across the browsers, I get a feature/style/behaviour/etc. to work in one browser first (usually Firefox 3 with firebug), then immediately check to make sure it works in all the other browsers (leaving IE6 for last). If it doesn't, I inveset the time to fix it right away, because otherwise I know I won't have time later (in my experience, getting things to work cross-browser takes about 50% of my dev. time ;-) )
Validating your javascript with a "good parts" + browser on JsLint.com makes it less likely to have JavaScripts behaving differently in FF, Safari etc.
Otherwise - using standards and validating your code as well as building on existing techniques like jQuery should make your site behave the same in all browsers except IE - and there's no magic recipe for IE - it's just bugs everywhere...