HTML 5 Browser Compatibility Chart - HTML 5 in Old Browsers? - html

I have just started considering using the HTML 5 api for a Rails/JQuery project, so I can use that great data- attribute to store values.
I am worried though about browser compatibility issues. I have two questions (basic questions):
In order to use HTML 5, do people need to upgrade their browsers? How does that work?
Is there an up-to-the-day chart of what features each browser layout engine supports, more up-to-date than this Wikipedia article on comparing HTML layout engines and this When can I use... HTML 5 page?
Is it going to be an issue with people using IE6 for example? Lots of non-computer saavy people I've talked to who want to get an internet presence themselves use, and the people they talk to use, still, IE6!
If it's not an issue, and you can use HTML 5 on old browsers, how do you? Or what docs should I look at :)? Thanks.
Update: I will post some interesting links as I find them below.
FindMeByIP: "A simple app which reveals your browsers' support for CSS3 and HTML5 features in an easy to read format using Modernizr." - Browser Support for CSS3 and HTML5

It is not useful to consider HTML5 as a single entity, that browsers either ‘support’ or ‘don't support’. HTML5 is:
an attempt to codify widespread existing practice beyond the limits of what the previous W3 HTML and DOM standards had covered, such as IE and Firefox extensions that the other browsers have copied, and long-standing ‘DOM Level 0’ behaviours that everyone took for granted but weren't written into any spec before.
a random selection of new extensions not yet in widespread use, which it is hoped browser manufacturers will support. Some have already succeeded, heading into all new browsers already; some have been spun off into their own specifications (which is much more manageable for everyone), some are controversial, and some no-one cares about at all.
It has been, IMO, an enormous mistake to try to cover these two bases at once. I would have preferred an HTML 3.2-style ‘catch-up’ standard plus many separate extension specifications. But there's nothing can be done about it now.
HTML5 is also:
Not finished. The specification is massive, complicated, incomplete, and likely to change in details (or maybe more than that) before it becomes a proper standard. No-one can say they ‘support HTML5’ yet, because no-one knows yet what ‘HTML5’ is actually going to be.
In practical terms: there are some parts of HTML5 that have long been in use. There are some parts that you can use safely on modern browsers. There are some parts that you can use on new browsers except for IE. There are many parts you can use with fallback workarounds or ‘graceful degradation’. There are some parts you may never be able to use. For now you will have to learn each separately, because there won't be a browser that supports absolutely everything in HTML5 for many, many years. If ever. Add the extra features you like gradually as you go along and they're supported by a greater share of browsers; there will be no ‘big bang’ where everyone updates their browser at once.
As for data- attributes, well, yeah, you can kind of get away with using them, in that most browsers have always allowed any old attributes to go through anyway. This is typical of several HTML5 extensions, the browser doesn't need to explicitly ‘support’ it for it to work.
But since there are other ways of passing data (classes, comments, script blocks, etc.), I'm not wholly convinced it's worth dropping (universally supported, validatable against a fixed standard) HTML4/XHTML1 pages just for that one feature yet.

You might want to check out diveintohtml5.ep.io and modernizr.com.
Modernizr is a small and simple JavaScript library that helps you take advantage of emerging web technologies (CSS3, HTML 5) while still maintaining a fine level of control over older browsers that may not yet support these new technologies.
Here's an interactive chart of html feature support:
http://a.deveria.com/caniuse/
As you can see, there are a lot of browsers that support quite a few of the H5 features.

If you're using jQuery, concerned about interoperability, and the only reason you're investigating HTML5 is to use the data-* attribute set, then I would consider switching back to a better-supported doctype and using jQuery's $().data() method, which allows you to bind arbitrary pieces of data to DOM nodes, similar to how the data- attribute set does.
Example:
<button id="set">Click me!</button>
$('button#set').click(function(){
if($(this).data('name')){
alert('Clickin\' again so soon, ' + $(this).data('name') + '?');
}else{
$(this).data('name', prompt('Hey good lookin\', what\'s your name?', ''));
}
});
Try it out!

My answer might not be the one you would like but I would say - don't. Don't use HTML 5 just yet.

Use Protovis. It uses javascript and HMTL5. No Flash here. More important, Protovis has BSD license. So you can use it in commercial projects. Although D3 is the a newer project that authors of Protovis are working on.

Although this is an old(ish) question, the topic of browser support will always be relevant. There's no right way or wrong way to approach it, but take a look through one of the many browser feature support tables that show you what percentage of users will see a certain feature and then be brutal.
Don't try to please everyone. Don't kill yourself to catch a few percent of the Luddite's who are still using IE7. Next year, substitute that for IE8. Personally, I would be happy to lose 8% in order to spend that time on forward thinking practices rather than catering for those who don't know what an upgrade is.
Maybe your site will cause people to upgrade. These people will come round eventually.

Related

What is the use of HTML5 semantic markup for intranet applications?

As far as I understand, the only real advantage of HTML5 semantic markup is for search engines and web crawlers to interpret the document better.
Since intranet applications have nothing to do with search engines or web crawlers, what are the advantages of using semantic markup in HTML5?
There is no straightforward example to point out, but the website (even intranet) can be consumed by different user agents (on different devices).
You are probably familiar with Skype (and the iOS Safari) making phone-number-like words clickable. In the future I can easily imagine mobile browsers being smarter to assist the user in completing tasks on the page, like importing a clearly indicated contact to the address book.
Screenreaders for blind people?
While there is not a whole lot of immediate benefit for non-disabled people, it is still good practice. Does your company not have any externally facing sites? If it does, do those people not look at internal page code? Good practices spread just like bad ones.
see also: http://en.wikipedia.org/wiki/Semantic_HTML
Simply said there the only rule you have to follow if you create your html documents is that it is valid html, otherwise you will have the problem that the browser would try to correct your broken syntax which may result in defects of the visual representation of your content.
In modern browsers you can use display to given any element - with some limitations e.g. with input element - the same visual look and behavior then any other element.
So if you ask what are the advantages of using semantic markup in HTML5 you should ask, why to use any of the semantic markup if it is possible to have the same result using css.
The short answer is, no one will stop you if it is your own project where you are responsible to - except the client that probably gives you requirements.
It is similar to asking: Language xyz provides comments and there is a syntax for doc-comments, but why should I use them?.
Using the semantics wisely increases the readability and thus maintainability. You are not required to use every possibility of semantics at all costs.
Using them will help you to get into the code again if you haven't looked at it for a longer time, e.g. to distinguish between the elements that encapsulate logical parts and elements that are used for styling. Especially if you use a template engine to create your code or to search for certain elements in multiple files.
Even if you are now the only one who works on the code it may happen that if the project grows that you need other people to work on the code. Or for the situation, you for some reason are not available, someone else needs to maintain your code, a good markup is essential.
Using the correct markup and additions like WAI-ARIA is not only essential for handicapped people, but also allows the browser to recognize the meaning of elements, allowing to e.g. improve the keyboard navigation. Especially in a productive environment where you need to type much, it is often faster to navigate with keyboard then using a trackpad or a mouse.

What issues need to be considered when using HTML5shiv?

I am thinking about starting to use some HTML5 elements in my sites. With the varying lack of support for HTML5 in Internet Explorer I was considering using HTML5shiv. I have read that I would need to set the CSS for various unrecognised elements to be block level and also the possibility of issues with loading HTML5 elements via ajax.
I would like to know what issues others have encountered when using this script. Thanks.
If you're going to dynamically load HTML5 elements you'll need the innershiv. You'll also need to bear in mind that if the IE user has JavaScript disabled, it won't work at all.
I've found the existing solution to be highly unreliable when used in real world scenarios - it's fine for noddy little "hello world" examples but as soon as the pages start getting more complex then you will find that styles will stop applying on some requests etc.
It's not a very nice answer, but the truth is that if you need to support older IE versions then you basically can't rely on being able to style HTML5 elements reliably. If you can get away with using the elements but use superflous markup (divs etc.) to do things like layout then you might get away with it, but then it depends what you consider to be the lesser of the two evils : Loads of noddy markup or no IE support.

To what point is making an HTML page valid worth it?

Since a long time ago, when I found out about the W3C Validator, I made sure every HTML document I made was valid HTML.
However, I think sometimes it just isn't necessary to waste time making it valid. Of course, for actual Internet pages may be important, but is making pages on an Intranet, or even little front-ends that are used with other programs, when the HTML page renders correctly in the most used browsers (not necessarily counting IE 6 and 7).
I think I'm mostly talking about little improvements over code, such as wrapping every shown element of the page on <p> or <div> tags.
Making a page validate for its own sake is not really a business proposition. What happens for end-users (with their cranky browsers) is the real test.
That said, validating periodically will help you debug. It'll catch the more salient errors like unclosed tags. Which, in turn, does affect end-users. So treat validation like compiler warnings -- good for discipline.
It's the best practice, but it really comes down to an organizational requirement/desire. Is it important enough that standards add value for your organization? Or is it simply enough that it displays correctly? Often with intranets its the latter.
Making an HTML page "valid" is worth it if you intend to be future friendly. That is, when browsers begin to strip out deprecated or vendor specific tags, you will find your page displaying incorrectly.
Web standards are there for a reason - to ensure consistent display/output among web browsers and interpreters. Choosing to write your pages in non-compliant HTML is your decision. It is also, to take an old adage, your "funeral".
What happens when the browser of choice for the intranet changes? There really isn't a way to guarantee that the code you have will render correctly in EVERY browser. But in a lot of cases the browsers will be reasonably close to the standard. I think it also depends on how complex the page is because the chances it renders differently in different browsers increases as the complexity of the CSS and tag depth does. The best way is to write valid cross-browser code and test for target browsers. Its silly to think write-once and render the same everywhere is possible for all browsers. But adhering to the standards is the best way you can get close.

Will deprecated elements be removed from future browsers?

What are cons to using deprecated elements if I don't care about validation and I use that DTD which supports them? Will deprecated elements will not be rendered by future browsers?
Some online WYSIWYG editors (which we use in CMS) still give output in deprecated elements. Must I invest the time to change the output for a client?
alt text http://easycaptures.com/fs/uploaded/241/3445655293.jpg
Should we avoid deprecated elements at any cost?
Currently all mainstream browsers show all deprecated elements.
I just wanted to know the disadvantages of using deprecated elements to give to a non technical client even if all are working today in all browsers.
Update:
you can meet guideline 1.3 ensure that
information and structure can be
separated from presentation by using
font and align elements if you like.
Yes, that’s right. You can use an
element which was deprecated in HTML
4.01 nine years ago that ties the presentation of your page is into the
page structure and content — there’s
no success criterion telling you not
to use deprecated features, and you
can still pass all of the success
criteria for the guideline which
states “ensure that information and
structure can be separated from
presentation.” And this is a step
forward?
I found this in this article http://accessites.org/site/2006/06/the-wcag-20-what-a-whopper/
Future browsers may not support them, and you should always follow spec. If you make a habit of deviating with trivial HTML, your future as a professional programmer will be dim.
If you're using an editor that still uses deprecated elements, you should replace them. Fortunately, this can be as simple as a find/replace command.
There is normally a reason for deprecating things, and more often than not, another way of doing the same thing that isn't deprecated.
First, deprecated elements are usually not the best elements to use. They are generally deprecated for a reason, as there are better ways to do it.
Second, they could go away in future browsers. (Whether they will is a complicated question.)
For these reasons, you should always avoid deprecated functionality. It isn't a matter of avoiding it at all costs, since deprecated functionality is almost never the best way of doing something.
Whether it's worth changing an existing product is another question. Most web sites will need revision for other reasons later on, and that can include removing deprecated elements. Many will be removed from the web (for various reasons) long before any browser that doesn't support them gains popularity.
However, you're talking about a tool, and that's different. A tool should be more strict than an end product, since it affects not only today's work but work extending into the indefinite future, thereby raising the chances for problems. I'd say that the tool needs to be changed.
The cons ?
well... they are deprecated ..

HTML 5 - Early Adoption Where Possible - Good or Bad?

This question was inspired a bit by this question, in which the most upvoted answer recommended using a feature from HTML 5. It certainly seemed to be a good method to me, but it made me curious about using features from a future spec in general.
HTML 5 offers a lot of nice improvements, many of which can be used without causing problems in current browsers.
Some examples:
// new, simple HTML5 doctype (puts browsers in standards mode)
<!doctype HTML>
// new input types, for easy, generic client side validation
<input type="email" name="emailAddress"/>
<input type="number" name="userid"/>
<input type="date" name="dateOfBirth"/>
// new "required" attribute indicates that a field is required
<input type="text" name="userName" required="true"/>
// new 'data-' prefixed attributes
// for easy insertion of js-accessible metadata in dynamic pages
<div data-price="33.23">
<!-- -->
</div>
<button data-item-id="93024">Add Item</button>
Many of these new features are designed to make it possible for browsers to automatically validate forms, as well as give them better inputs (for example a date picker). Some are just convenient and seem like a good way to get ready for the future.
They currently don't break anything (as far as I can tell) in current browsers and they allow for clean, generic clientside code.
However, even though they are all valid in HTML 5, they are NOT valid for HTML 4, and HTML 5 is still a draft at this point.
Is it a good idea to go ahead and use these features early?
Are there browser implementation issues with them that I haven't realized?
Should we be developing web pages now that make use of HTML 5 draft features?
There are several things to consider:
First, validation doesn't mean that much, because an HTML page can very well be valid but badly authored, inaccessible, etc. See Say no to "Valid HTML" icons and Sending XHTML as text/html Considered Harmful (in reference to the hobo-web tests mentioned in another response)
Given this, I'd highly recommend using the new DOCTYPE: the only reason for having it in HTML5 is that it's the smallest thing that triggers standards mode in browsers, so if you want standards mode, go with it; you have little to no reason to use another, verbose, error-prone DOCTYPE
As for the forms enhancements, you can use Weston Ruter's webforms2 JS library to bring it to non-aware browsers
and finally, about the data-* attributes, it a) works in all browsers (as long as you use getAttribute()), b) is still better than abusing the title or class attributes and c) won't bother you with validation as we said earlier that validation isn't that important (of course it is, but it doesn't matter that your page is invalid if the validity errors are willful; and you can already use HTML5 validation in the W3C validator, so...); so there's no real reason not to use them either.
Good question!
In short: it depends on your context, and risk tolerance :)
Slightly longer:
I think it's always good to push the envelope on early adoption of technology. It gives you an advantage over late-comers in the commercial world, and also gives you much more leverage in influencing the technology as it emerges.
If you don't want to have to re-write code, or update your source, then early adoption may not be for you. It's perfectly respectable to want to write solid, stable code that never has to change, but it's entirely up to you (and your business context)
If your page relies heavily on search engine placement, it may be worth considering that some engines give priority to validating HTML (Source: http://www.hobo-web.co.uk/seo-blog/index.php/official-google-prefers-valid-html-css/).
Also, it is worth considering that relying on the new date input elements (such as those in Opera, possibly others) allows for more convenience on the part of the developer, it typically precludes including more complex Javascript controls which would better server older browsers (typically falling back to a simple text input field).
Of course and as always, don't rely on browser side checks and validate all input server side.
Please don’t use the new features before you can test them in at least one browser. For example, if you use the now form features, be sure to test in Opera. Otherwise, you’ll likely do more harm than good by contributing to a poisoned legacy out there.
When a feature is already implemented in browsers and you are testing with those browsers, sure, please use the new features.
See also an older answer.
See Robustness principle:
In RFC 761 (Transmission Control
Protocol, 1980) American computer
scientist Jon Postel summarized
earlier communications of desired
interoperability criteria for the
Internet Protocol (cf. IEN 1111, RFC
760) as follows:
TCP implementations should follow a
general principle of robustness: be
conservative in what you do, be
liberal in what you accept from
others.
So, imho, no.
I will not implement new features from HTML until at least they have support from all major browsers.
Clients don't care if your page is valid, they care much more if it works cross browser. Even if we fight to implement the latest standards there will be still clients and companies that will never shed their IE6, and IE6 will be on their browser requirements list for still a while.
The new form types are welcomed, nevertheless the forms have to be checked in the server side.
Passing to HTML5 existing documents will require a lot of effort and adaptation and in my estimate will not happen overnight. Expect at least a 3 years until it will hit the mainstream.
I would use HTML 5 just for fun and learning, but definitively I wouldn't touch any of my production code (existing code) with this new standard, at least by now and until I have a valid reason to support this move.