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/
Related
When users visit my website, they don't care about how perfect or how much standard the page is coded. They only care about whether it works or not.
There are tags that are deprecated but have consistent behavior throughout all major, minor, and very minor browsers. They work now and will work in the future. (I'm not talking about optional tags like <marquee> and <blink> which will probably be removed in the future since their non-existence doesn't break pages.) The tags I'm talking about are for example:
<center> (used by google.com homepage, yes and it's May 2014)
<body bgcolor=, alink=, vlink=, link= (all used by google.com)
<font size= (also used by google.com)
If my HTML generator produces tags like <body bgcolor=black>, it is guaranteed to work for near 100% of users.
If it instead produce CSS like background:black;, it will be supported by lesser users compared to <body bgcolor=black>. (Start with https://superuser.com/q/732669/78897 and https://superuser.com/q/447269/78897, though I'm sure they are not the only ones in the whole world.)
Bear with me, this is a real question based on a true problem. Exactly what are the real disadvantages of having these tags as output?
Potential disadvantages include the following:
1) Your customer might actually care about how standard the code is. Maybe not now, but in the future. Maybe for questionable reasons, but still.
2) Deprecated constructs do not always work consistently. For example, align=center attribute set on a table may have different effects depending on browser mode. This is a relatively weak argument, though, since the browser practices have been described rather well in HTML5 CR and you can manage the potential problems. (Besides, even CSS settings may work inconsistently.)
3) There is no guarantee that deprecated features will be supported by all future browsers. On the other hand, the same applies to standard features. In practice, very few features that have been defined in HTML specifications have actually been removed from browsers. (Regarding tags, I think basefont is the only case.) All the examples mentioned, and also marquee, have been described in HTML5 CR as “obsolete” but still well-defined, and according to HTML5 CR, browsers are expected, and partly required, to support them all.
4) Your colleagues (designers/developers/...) may regard your code (and you) as old-fashioned, non-semantic, and whatever.
5) Code maintenance and development may be more difficult. If you have 1,000 pages with <body bgcolor=black> and the customer says they want a somewhat different background color, you would need to edit each page. This argument is, however, weaker than it seems to be. First, how often do such things actually happen? Second, if the pages have actually been generated using suitable tools, perhaps you just need to change the value of one parameter and regenerate them (or just let servers do that, if the pages are dynamically generated). Third, if you have a link element on all pages, referring to basic style sheet for the pages, as you normally should, you just need to add one rule to that style sheet. It is easy to override presentational HTML attributes with CSS.
To summarize, the practical arguments against your approach are rather weak. The most important arguments relate to coding style and principles.
I've added some more disadvantages:
Another disadvantage of using those tags is site bandwidth. When you put in html center, bgcolor and similar tags every time browser needs to load the whole content even if on every page those tags are the same or even if user visited this site many times. But when you place design in css file browsers may cache those files (especially when you set headers properly) so they only load html and images (if no cache is set).
One another thing is that if you decide to redesign the site/style new elements, it's much easier to put changes only in CSS files. It's possible in future you won't be doing those changes on your own or other companies/freelancers will be doing them and it will be much easier for them to make changes in the site. So the site will be cheaper to maintain.
In addition if html / php code is poor (or site is very complex) and many "visual conditions" appear in many files (for example on one page you decide to use one colour and you put it in HTML, on the other another colour) and something goes wrong it will be much easier to find the problem because you may simple cut some css and check where's the problem.
The disadvantage is when one of the major browsers chooses to get rid of the deprecated tag in a future release.
The advantage of using CSS over tags is that you can change the whole web site look and feel in a simple move.
Consider people that require larger font sizes. Colour blindness and also enable the most use of screen readers.
Even those consistent behaviour tags may be removed from browser. What if you would like to create HTML5 website? Then you will need to learn everything from scratch and change literally everything for your website to make it work because you never know if those tags will be supported in HTML 5 in future or only in older HTML documents
CSS provides easier maintenance, for one; client decides they want some elements aligned left instead of center? Change your css rule and poof, you're done. But if you're using old-school valign and such? Get ready to go change every single instance of that in the file(s).
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 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.
I have some special tags on my blogsite which need to be as simple as possible so that my colleges who don't know anything about HTML can use it. For example
<question>...</question>
and
<answer>...</answer>
and then these are styled in CSS. It's far easier for HTML-idiots than to use the <div class="answer">...</div> format.
I've just found out IE8 is displaying it all wrong while Firefox and Chrome do it right. Is that expected or am I doing something wrong? Do you know of any hack to fix this since there are tons of blogsposts I'll have to manually change otherwise!!
You want to create <question>...</question> etc.
These are not HTML (not even HTML5), and you will struggle to get browsers to understand them reliably.
A quick tip that might help you:
You say you've got it working in all browsers except IE. If so, you might be able to hack IE to get it working as well, using a technique similar to the hacks like HTML5Shiv that are being used to get IE to work with the new HTML5 tags. These use Javascript to create a DOM element with the new tag name, after which IE suddenly starts to recognise that tag as being valid HTML.
It might just work. But be aware that it is a hack, and it only targets IE. And since you're using non-standard tags, you also have no way of knowing what will happen in the future in terms of it breaking browsers, even if they work now. (in fact, I would say the worse case scenario would be if one of the tags you've invented is added to the HTML standard at a later date, because then you'll start getting weird layout glitches as it gets added to the default stylesheet)
If you can get it working that way, then well done. But consider yourself warned that it's not good practice.
What you have actually asked for is not HTML, but XML markup. This is perfectly fine, but shouldn't be put directly into a web page in the way you're hoping.
There are a number of well-documented ways to get raw XML code into a browser.
One option is to use XSL to transform it into valid HTML. Another way would be to load it into a DOM object in Javascript and process it using a script. (this is where the 'X' comes in 'Ajax').
My guess is that a simple XSL transformation would do the trick for you. (In fact, it sounds like your use case might be simple enough that even just basic string replacement might suffice for the same end result). You can get your colleauges to create the code using <whatever> <tags> <they> <want>, and you write a script that parses it and converts it to regular HTML prior to merging it with the rest of the page.
In the long term, this would probably be a far better solution than the hack I've described above.
Hope that helps.
I don't know if this answer fits your needs but imho using custom html tags is basically NOT using HTML. Therefore the absence of compatibilty.
If you need to render data in HTML wouldn't be better using XML + XSLT?
You can find guides on w3schools
You can't add new elements like that. HTML has some fixed elements that browsers understand, but if you add your own, browser don't know what to do with them.
HTML5 has some new elements you can maybe find useful : http://www.w3schools.com/html5/html5_new_elements.asp but this won't work with older browser without some kind of javascript to fix things. For example http://remysharp.com/2009/01/07/html5-enabling-script/
However, if you really want to add new tags, it is possible to do so and then "modify" them via javascript to known tags (actually it's what the html5 enabling script of IE do), but it won't be possible to apply CSS easily to the new tags.
In short, I strongly advise against adding new tags. It's not that hard to understand something like <div class="answer">.
sounds like you want to write XML and convert to HTML using XSLT. This is an old tutorial (includes defining an DTD), but a further web search will garner more results that might suit
here you go fella:
http://net.tutsplus.com/tutorials/html-css-techniques/how-to-make-all-browsers-render-html5-mark-up-correctly-even-ie6/
You need to use createElement :)
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.