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.
Related
My question is similar to what this poster is asking:
What are the concrete risks of using custom HTML attributes?
but I want to know what can happen if I use custom elements and custom attributes with the current html specs (html 5).
Example
<x a="5"> abc </x>
Visually I see no issues in any browser. js works:
x = document.getElementsByTagName('x');
alert('x has attribute a=' + x[0].getAttribute('a'));
css works too:
x{
color: red;
}
x[a]{
text-decoration:underline;
}
Possible Risks include
Backward compatibility. In particular, IE8 and below won't understand your tag, and you'll have to remember to write document.createElement('x') for all your new elements.
Semantics - having your html machine-readable may not be your goal, but there may come a time when it needs to be parsed in a moderately useful fashion.
Portability & maintenance - there are plenty of current html tags that almost certainly do what you want them to do. At some point, someone else may have to look after your code. Is there anything to be gained from having them spend time learning what all your new tags are for?
SEO - don't take the risk of a penalty just because it's something you can do..
For completeness, there are justified reasons to do it though. If you can demonstrate your new tag improves the semantics of your page (your example of 'x' obviously doesn't) and you can think of some use-case where your page will be machine-parsed by your own process, then go for it.
The only issue I can think of is that other applications, including search engines, won't recognize your custom elements and properties, so they won't know what to look for or how to use them which is a decided disadvantage for SEO. Other applications trying to access your content, including RESTful apps, will not know either without you telling the app developer.
This was always listed as one of the disadvantages of XML/XHTML but here we are again, back full circle to where we should have been in the first place, the use of XML on the web ... but I digress.
The main reason custom elements were frowned upon in the past is because browsers don't know what to do with them and there was no standardised way of telling them what they are.
What are the risks of using custom HTML elements in HTML5 without following standardisation?
Browsers will handle them differently:
Some browsers may ignore the elements and pretend they're not there; <x>, I don't know what <x> is, lets get rid of that.
Some browsers may attempt to convert the element into something else; define a <tab> element and a browser may think you've mis-spelled <table>, for instance.
You'd have to handle what the element is supposed to do across a large range of devices; just because it works on your PC doesn't mean it works on your phone, or your TV, or your e-reader... or your WiFi-powered fridge...
The good news is that there is some new documentation being written up to allow developers to define their own custom elements in a standardised way. Custom Elements, as it's titled, gives both developers and browser vendors the know-how to allow developers to implement and script custom elements in a way which will work across all supporting browsers... or that's the idea, anyway.
I am using HTML5 tags like header and was using html5shiv: http://code.google.com/p/html5shiv/.
Looking through the files, it's seemed like everything is overdone with a bunch of unnecessary files, so I researched of an easier way through html5shiv http://css-tricks.com/snippets/javascript/make-html5-elements-work-in-old-ie/ and simply adding the "hotlink": http://html5shiv.googlecode.com/svn/trunk/html5.js and letting them host the rest.
Then I was thinking, even this code seems overdone. Why can't I just use createelement http://reference.sitepoint.com/javascript/Document/createElement, why do I need all the html5shiv code in general?
Here is some of the code from: http://html5shiv.googlecode.com/svn/trunk/html5.js
.cloneNode():f=c(a),f.canHaveChildren&&!d.test(a)?
g.appendChild(f):f},a.createDocumentFragment=Function("h,f","return function(){var
n=f.cloneNode(),c=n.createElement;h.shivMethods&&("+i().join()
I am not a professional at JavaScript, but I don't understand why this is necessary?
HTML5Shiv fixes several issues with using HTML5 element in IE, not just the obvious one of being able to create the elements in the first place. The first version was just that, but later versions have added further fixes for other issues.
The two other issues that I know of are:
Bugs with printing pages containing HTML5 elements.
A bug with .innerHTML when used with an HTML5 element.
The basic issue of allowing these elements to be added to the page is a pretty short and easy bit of code, but these other two issues are where the bulk of the HTML5Shiv code comes from.
A full write-up of the history of HTML5Shiv and when these things were added can be found here: http://paulirish.com/2011/the-history-of-the-html5-shiv/
I've done a little bit of playing around with the new HTML5 tags and read up on all the new ones at W3cschools, etc. and I'm a little confused.
If I create an HTML page that uses "areas", "sections", "asides", etc. Nothing happens? I have to manually style them - which is FINE, but am I missing something? What's the point of declaring a tag an "aside" if I have to make it ASIDE (common css: float:right;width:30%, sorta thing)?
Why not just stay with DIV tags and style them?
I also noticed new attributes, such as "draggable", but, surprise-surprise, it doesn't drag! I have to code it to drag too (javascript/jquery??) ? What's the point of declaring it draggable? I can create a div tag and drag it using JQuery, so someone please enlighten me as to what's so "whoopty doo" about html5?
This is how the web changes in respect to HTML.
First new tags are created by browser makers for advanced users to try out.
Then they are added to the standard
Then they actually get implemented in the various browsers and devices.
Then they become widespread and useful.
Then they become universal and are implemented by 99.9% of devices.
For the tags mentioned they are probably between steps 2 and 3
It may not be "whoopty doo" but this is how changes occurs in this system
Developers who accept, embrace and use this pattern of evolution help move this process along.
It's a bit zen-like.
Additionally, as Aaron points out in his comment above (+1), these particular tags are semantic tags for organizational/outlining and search engines, screen readers and the like. So you yourself may not see much up front for them.
Might not be the case but at least I know for me I make this mistake every now and then. Don't forget to include at the top <!DOCTYPE html>. Furthermore, not all browsers support HTML5 yet I believe so make sure the browser version you are using supports it (most of them should support it nowadays though).
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.
Generally, what's the best way to tackle a layout bug in IE6? What are the most common bugs or problems that one should look for when trying to figure out why your page suddenly looks like a monkey coded it?
First Things First
Get yourself the Internet Explorer Developer Toolbar. It's a life saver and works great with IE6 and/or IE7. It's no replacement for Web Developer Toolbar or Firebug for Firefox, but it's better than nothing.
Know Thy Enemy
Read up on the quirks of IE — particularly hasLayout and overflow and the like. There are also many CSS niceties that you'll have to either do without or find alternatives. Look into how many of the popular JavaScript toolkits/frameworks/libraries get around different issues.
Rome Wasn't Built in a Day
The more you have to work with it, the more you'll remember off hand and won't have to lookup as often. There's just no replacement for experience in this. As several have pointed out, though, there are great resources out there on the net. Position Is Everything is certainly up there.
http://www.positioniseverything.net/ will certainly address your problem.
It provides comprehensive and in-depth descriptions of browser bugs along with options to work around them. A must read, in my opinion,
One good way to start learning about how IE happens to be mangling the page is to turn on red borders on different elements with CSS (border: 1px solid red;). This will immediately tell you whether it's a margin problem or a padding problem, how wide the element really is, etc.
The box model is usually the culprit. Basically what this means is that any div you are trying to position and use unsupported CSS with will cause this problem.
You may find it happens if you are using min-{width,height} or max-{width,height}.
this provides a great reference for checking compadibility with different versions.
http://www.aptana.com/reference/html/api/CSS.index.html
Noticed that Marc's post is at a -2 =D. He's only saying "resort to tables" even though they blow, because in sucky browsers like IE6, some of the broken CSS commands work in tables only (who know's why... dam you Bill Gates!!!). Here's a good reference to see what works and doesn't work as far as CSS goes. http://www.quirksmode.org/css/contents.html . It's a great reference to check on what cool effects work/don't work with various, widely used browsers. Also, always have a go-to plan for users who browse with IE6 (even though it's just about as old as mechanical dirt) as many businesses still use older browsers (including non-profits/3rd world countries etc.) So by all means, create the bugged out drop-down menu that looks WAY better than a standard horizontal menu, but create a secondary one specifically for IE6 that becomes the default when the page receives a request from an IE6 browser.
how do you define layout bug? the most frustrating layout implementation (i don't know if this should be defined as bug) in IE is we need to always specify style="display:inline" in the HTML <form> tag so that a blank line won't appear to disturb the form layout.
This question I believe has far too much scope.
Validate your code, and if pain persists, well, good luck.
The only real solutions, as with any other ballpark bug type are to google for a solution, or ask somebody who knows, ( ie: give the exact problem to us here at stackoverflow ).
You can use the IE Dev toolbar to glean an Idea, but many of the bugs are random, inexplicable, and esoteric. IE: the guillotine bug, the random item duplication bug, etc etc, the list goes on, and you can spend hours literally goofing with stupid variables everywhere and achieve nothing.
I have a simple strategy that works every time.
First, I develop the site using commonly accepted CSS to look good in Safari and Firefox 3. See w3schools.com for details on browser support.
Then, I go into IE6 and IE7 and alter the CSS using conditional includes.
This is hack free and lets you handle different browsers (IE6 and IE7 have separate issues).
Most of the issues you'll find come from unsupported features in IE (like min-width), errors in the box model (IE adds unseen extra padding (3px) to some boxes), or positioning issues. Go for those first as they are often the issue.
A common problem is padding not getting added to the width of a block element. So for layout div's, avoid using padding and instead use elements within them to define the padding.
I use Rafel Lima's Browser Selector when I need to tweak differences between IE/Standards browsers. It greatly reduces using "hacks" in your HTML to solve common problems.
You can target CSS statements for different browsers, or even different versions of browsers (Hello IE 6). It's very simple to implement, but requires the user has JavaScript turned on (most do).
.thing { ....}
.ie .thing { ....}
.ie6 .thing { ....}
We had a floating div issue that was only evident in a particular version of IE6. It was fixed by downloading the latest service pack.
In theory, use CSS compatible with IE6 layout bugs, utilise only well known workarounds (css and html filters) and code for them in a way that wont break forward compatibility, test for quirks/strict mode.
In reality, resort to tables.