Using html5shiv/shim for IE and HTML5 elements? Use a local copy

HTML & CSS
1

A long post here explains issues with linking to an external source for 3rd-party JS, but especially for linking to the HTML5shiv that allows IE8-and-under to understand HTML5 elements such as <nav>.

I’ll summarise:
The author is specifically mentioning the html5shiv stored on google.

-it’s not minified/optimised
-it’s out of date
-it won’t cache (so everyone’s re-downloading it every request)
-it won’t offer partial requests
-it’s not code you control.

And there are interesting comments after the article.

2

I wonder how this compares with linking to libraries like jQuery on Google.

3

jQuery is, according to them, cached (why they tell everyone this is a good optimisation, using someone’s CDN) and at worst, breaking jQuery isn’t maybe on the same level as breaking HTML5 tags. Or maybe not, I dunno.

4

Pure comedy. And in other words don’t use HTML5. :slight_smile:

5

Yes, don’t allow your code to evolve. Instead, dumb it down to support browsers people shouldn’t be using in the first place.

6

Thanks Mallory :slight_smile:

I’ve been using the html5 shiv from google repository. After reading the article, most likely, I’ll switch to self hosted. The pro argument in it makes a lot of sense.

7

I don’t surf with JS enabled anyway and probably I’d agree browsers that don’t support RFC 3236 are rather outdated but still used by millions. Plus see the non-normative not stable status of Fred but if you want to experiment fine.

8

Evolving is one thing, but building sites that rely on JS to hold them together because they are built on unfinished technologies that aren’t truly supported in any browser yet … that seems like regression to me. :slight_smile:

9

I won’t go there. I’m not a fan of HTML 5 as yet, but I respect the effort being put into it. Web presentation technologies must evolve, and evolution isn’t always a nice, pretty, well-controlled process. Who knew that the Netscape-IE wars would evolve into the present state of three fairly stable and excellent browsers with IE the ugly-yet-popular stepchild?

As for obsolete browsers, I’ll say for the thousandth time, it’s arrogant, smug, and asinine to sneer down one’s nose at those who use older browsers. Many of them don’t have the time or the knowledge to upgrade, and many others don’t have the option to upgrade. Many users either don’t spend a lot of time, relatively, on the Net and therefore don’t care what browser they use, just that they get the site(s) they want to appear quickly and correctly so they can do their thing and move on to something else. It’s our job to serve the needs of a wide and disparate user base, not to judge and disparage users because they don’t have the knowledge of the ins and outs of Web design elements, including browsers, that we do. Trying to serve the needs of long-obsolete browsers such as Netscape 4 or IE 5 for Mac is not productive, as the user base for those browsers is vanishingly small, but a lot of people still use IE 6 (some by choice, some not), and it’s on us to provide sites that function in that browser (if not sites with all the bells and whistles).

10

… and that’s where we differ; I have no respect for it at all. It offers no real world useful improvements and seems entirely crafted to undo all the progress STRICT gave us, and to encourage the people who used to wrap endless pointless tables around things, who then wrapped endless pointless DIV around things, an excuse to wrap pointless extra tags around existing tags that SHOULD be providing all the semantics a page needs.

Again, can’t believe anyone is DUMB ENOUGH to try and use it on deployment sites – AT ALL. This entire scripted SHIV idiocy only further exacerbates the problem of people jumping the gun on a technology that to be frank, should be put down like Old Yeller right now before it ruins the new carpets.

But of course, then the people writing books and selling lectures wouldn’t have something for nubes and the ignorant to go “ooh, shiney” over.

11

How is this:


<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" 
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
     <head>

         <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
         <title>Page</title>

     </head>

     <body>
          <div id="header">

               <h1>Page</h1>

               <ul>
                    <li><a href="#">Item 1</a></li>
                    <li><a href="#">Item 2</a></li>
                    <li><a href="#">Item 3</a></li>
               </ul>

          </div>

          <div class="section">

               <div class="article">
                    <h2>Article 1</h2>
                    <p>Hello World</p>
               </div>

               <div class="article">
                    <h2>Article 2</h2>
                    <p>Hello World</p>
               </div>

          </div>

          <div id="footer">
               <p>Copyright 2012</p>
          </div>
     </body>
</html>

Any stricter or cleaner than this:


<!DOCTYPE html>
<html lang="en">
     <head>

         <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
         <title>Page</title>

     </head>

     <body>
          <header>

               <h1>Page</h1>

               <ul>
                    <li><a href="#">Item 1</a></li>
                    <li><a href="#">Item 2</a></li>
                    <li><a href="#">Item 3</a></li>
               </ul>

          </header>

          <section>

               <article>
                    <h2>Article 1</h2>
                    <p>Hello World</p>
               </article>

               <article>
                    <h2>Article 2</h2>
                    <p>Hello World</p>
               </article>

          </section>

          <footer>
               <p>Copyright 2012</p>
          </footer>
     </body>
</html>
12

My question would be what do you need all those DIV for on the first one. Unless they are there as hooks for applying presentation (without saying what that presentation is) they serve no purpose. Semantically neutral – it’s why we USE DIV!!!

Making ALLEGEDLY semantic tags to justify the presence of extra wrappers is NOT semantics. It’s crappy coding. My further questions would involve if you have a H2 why do you need a tag to say it’s the start of a subsection like ARTICLE, or SECTION for that matter… also, what makes the footer text a paragraph?

The first one ALMOST makes sense without the DIV, that’s why we use div. Add a HR before the footer and it’s fine.

… and mein gott where did you learn to indent :smiley:

The ONLY reason semantically to need more markup than this:


<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html
	xmlns="http://www.w3.org/1999/xhtml"
	lang="en"
	xml:lang="en"
><head>

<meta
	http-equiv="Content-Type"
	content="text/html; charset=utf-8"
/>

<meta
	http-equiv="Content-Language"
	content="en"
/>
<title>Page</title>

</head><body>

<h1>Page</h1>

<ul id="mainMenu">
	<li><a href="#">Item 1</a></li>
	<li><a href="#">Item 2</a></li>
	<li><a href="#">Item 3</a></li>
</ul>
 
<h2>Article 1</h2>
<p>Hello World</p>

<h2>Article 2</h2>
<p>Hello World</p>

<hr />

<div>Copyright 2012</div>
	
</body></html>

Is some people not knowing how to use header navigation, and for hooks to apply presentation to. Adding extra tags with ‘alleged’ meanings around it serves no purpose other than bloat. The ONLY reason to add div is for hooks to hang your presentation on! (but since they don’t say what that presentation IS, they are NOT presentational in and of themselves)

… and oh noes, the header is a little larger… and clearer… and actually bothers declaring things instead of the idiotic lip-service. Maybe instead of gutting the specification we should ride the browser makers about not bothering to implement it? No, lets crap out some new specification when major engines like Gecko still have 14 year old gaps in the previous one.

JHVH forbid we use numbered headings to indicate the start of subsections, HR to indicate a change in section where a header is inappropriate, and the existing semantic tags to communicate the meaning and navigate; NO, lets just throw more tags at the problem to cause implementation and migration headaches – when most people can’t be bothered to use half the tags we already had properly!

13

Regarding HTML5:

Web developers tried to take the step forward from HTML4 with XHTML. It didn’t work, older browsers didn’t support the correct MIME type for it. That didn’t stop developers from using it though, sending it as text/html.

The step forward was regarded as needed. HTML5 took over. It keeps the XHTML option open, it takes HTML a step forward, it provides backward compatibility with HTML4.

Like XHTML, older browsers don’t have full support for HTML5. Should this prevent me from using it, if I find it’s good for me? NO!

<hr>

Now, everybody clings on HTML4 being the norm. Let’s take a look in the past. HTML4 faced the same heat upon adoption, both from developers and from browsers.

2003

http://comments.gmane.org/gmane.comp.web.html-tidy.devel/870

>> To default to 4.01 has never been the consensus. A great many
>> documents
>> simply do not need anything beyond 3.2 and, therefore, the safest
>> version
>> is still 3.2. Basically, the change of the default from 2.0 to 3.2
>> represents a minor incremental change vs. a radical shift. The basic
>> issue
>> is that version 4 browsers are still in use.

> Defaulting to 3.2 has neither been consensus. If you worry about
> compatibility, please name a browser that supports HTML 3.2 documents
> but rejects HTML 4.01 documents. I claim there is no such browser.

[B]Sorry to butt in here, but there are browsers “in the wild” which offer
HTML3.2 support but only offer a small subset of the HTML4.01 additions.

These browsers, whilst not in the majority, most assuredly still exist
and are still in use daily.[/B]

“Refusing to display” is not the issue. No one (but you) said it
was. Correct display of the document is the issue. I.e. what I did say
is that Netscape 4.7 is still is use[…]

2006

And what is with all the HTML3.2 code?

Heh, I haven’t had the time yet to learn 4.0 …

Forget HTML3.2, learn HTML4.01 (at a minimum) with CSS. It will make
your life a lot simpler.

http://www.cs.tut.fi/~jkorpela/HTML3.2/all.html

Learning HTML 3.2 by Examples

But why HTML 3.2?
The HTML language exists in several variants and continues to evolve, but the HTML 3.2 constructs will most probably be usable in the future, too. By learning HTML 3.2 and by sticking to it as far as possible, you can produce documents which can be browsed by a large variety of Web software now and in the future. Later you may learn to add some useful constructs defined in HTML 4.0 (or future HTML standards as they are defined). This does not exclude the possibility of using other features, such as enhancements provided by Netscape Navigator or Internet Explorer or some other product, if it really serves your purposes and you are willing to accept the consequences (e.g. limitations on accessibility). But it is wise to adopt the habit of producing documents in a standardized language and using extensions only when really necessary.
[…]
The next version of HTML, an extension to HTML 3.2, is known as HTML 4.0 (or the code name Cougar). It was approved as a W3C recommendation in December 18th, 1997, but it takes time before there will be new browser versions which support it and before users widely upgrade to such versions. In particular, Netscape 4.0 and Internet Explorer 4.0 do not support HTML 4.0 in general; see especially Stephanos Piperoglou’s HTML 4.0 in Netscape and Explorer (to which I have some minor annotations). Thus, for quite a long time, netwise long, it will be safest to use HTML 3.2, adding useful HTML 4.0 features when needed. If possible, when using HTML 4.0 try to do things so that they “degrade gracefully” on browsers which only support HTML 3.2.

<hr>

It’s clear from the last quote that while some encouraged others to embrace a new standard they also contradicted them self by trying to suggest to stop there and forget advancement.

IE6 doesn’t support HTML4 properly and it especially doesn’t support CSS 2.1 properly. Being fair, those that raise their voices against HTML5 because of IE6 should also raise their voice against HTML4 and CSS2.1.

Remember ie7-html4.js !!! Please, if you must be so righteous about obsolete browsers, please do advocate against HTML4 too.

<hr>

http://slashdot.org/story/01/02/17/2152248/web-standards-project-upgrade-or-miss-out

Posted by timothy on Saturday February 17 2001, @07:50PM
from the progress-or-tyranny? dept.

DShadow writes:

[quote]"The Web Standards Project launched yesterday a Browser Upgrade Campaign. They feel that the Web is being held back by users who use older versions of browsers. Their solution is twofold. First, they are asking web developers to drop support for old (pre- IE5.5/NS6/Opera5) browsers and code only using the most recent standards. Secondly, they are asking developers to add a bit of JavaScript to web pages that forces browsers to redirect to the a WSP page explaining this. Now, I’m all for using modern technology and phasing out support for the old stuff, but to say that I’d be annoyed when websites start telling me to go away and upgrade my browser (Netscape 4.6) because they don’t want to support it would be an understatement. I’ll upgrade when I’m ready to, and not a moment sooner."

It took me a few reads to realize that they’re serious.
[/quote]

These are the users I should worry about? That’s a laugh.

14

Good point—we can’t bother with making sure obsolete software is 100% supported with no hacks whatsoever, because then we’d still be serving up plain text documents.

@deathshadow: We obviously just disagree on the subject, and there’s not a lot that can be done about that :stuck_out_tongue:

I think that to a certain extent, it makes sense to add wrappers to certain parts of a page. If those wrappers can also be used for styling, that’s just killing two birds with one stone.

The way I see it, if it’s a header, wrap it in <header>. If it’s an article, wrap it in <article>. It just makes sense to me. The code you posted is a fine example of clean and concise XHTML, but it’d be a nightmare to style it. Those articles don’t have any containing elements, so there isn’t really any way to differentiate them from one another.

15

In other words, presentation – which if you are thinking about presentation when making your base HTML, you’re doing it all wrong. That’s what semantics is about, and why tags like section and article… IMHO add meaning to things that already have plenty of meanings; wrapping them in containers that have meanings (as opposed to DIV) serves no purpose when things like the H1, H2 and HR already provide it.

16

//removed long rant because those who’ve forgotten why they do what the do and who they’re doing it for are already a lost cause and I’ve run out of hair to pull out.

You people are so goddamn disappointing sometimes. I don’t even…

Well, whatever, I’m not even a web developer so I’m going to stop here. Have fun you people.

17

If those two are the sole points you’ve seen fit to pinpoint in the whole argument, then

I’m sorry to tell you but you’ve been eliminated from The Amazing Web!

:wink:

<hr>

I am doing it for the users, otherwise I wouldn’t bother keeping up with the new techs or care about solutions to help those left behind by the new techs. Thank you very much for your trust in me… NOT!!!

:slight_smile:

<hr>

What you forgot to mention is that there comes a point where the user has to work with us and with browser vendors too (and all the other permutations: developers with the users and the browser vendors, browser vendors with the users and the deveopers and so on).

Hence my quote outlining that stubborn and misguided users (developers, browser vendors and so on), that only find something to argue against, even when it’s good for them, are irrelevant to me. Since they are irrelevant to web. They only vent on web. They only litter the web with stands that possibly harm other gullible users (developers) too. And they end up silently giving up and fallowing the trend they were so fierce against it. Cowards?

<hr>

Let me give you a real example. In Romania, old apartment building are just walls. The cold and the heat makes the life much harder.

Being that all are owners now, some want to also leave well and pay less. But the thing is, not all owners are rational. It’s not that it’s so expensive, it’s that they just can’t seem understand the benefits. So we had odd looking apartment buildings, where you had parts of it thermally insulated and parts of it not.

That made for ugly looking stuff like this: http://s1.ziareromania.ro/?mmid=87407e1597e052eba Notice how in the bottom right corner they refused proper insulation, even though the payment was made easy to them.

Until city halls stepped in and actually lend the money and forbid this kind of odd behavior, things were not looking right. And they all lived happily ever after… having fun cold or sun!

18

The moral of the story is:

I’m not going to let the 1% users that could actually do something but choose not to, dictate the web experience on my web site for the rest of the 99% users that have the good will. Do you get it now, dear Mallory?

If not, I’m not going to be disappointed. I’m going to try and account for your opinion too.

Thanks again for the info on the shiv. :slight_smile:

19

What I do: make websites. Well, I’m primarily a graphic designer, but on sitepoint I’m in web developer mode.

Who I do it for: Clients, as well as internet users.

Glad we could clear that up, because if you think I’m actually preventing old browsers from accessing content, you’ve got it all wrong.

That example works fine for a browser without CSS, I suppose.

HTML and CSS do go hand-in-hand, and for that reason you DO have to worry quite a bit about styling while writing HTML—to a certain extent. If you’re wrapping every word in <span class=“word”>, you’re going too far. But wrapping an ARTICLE in <article> is not going too far. It’s defining what that part of the document is, as well as making it styleable.

<article> isn’t any less semantic than <div class=“article”>. As I’ve said in other threads, different people might use different terms for articles. Some might call them <div class=“post”>, or <div class=“blogEntry”>, or <div class=“kevinrules”> for all we know. But they’re all articles, so now they can all just be wrapped in <article>.

There’s a big difference between adding tags only for presentation, and using clear tags with defined meanings to divvy up a document.

[QUOTE=itmitică;5118459]
I’m not going to let the 1% users that could actually do something but choose not to, dictate the web experience on my web site for the rest of the 99% users that have the good will. [/QUOTE]

This is the most accurate statement I have ever read. Thank you.

As a web dev it is my job to make sure all the CONTENT on my sites is accessible to all users. I do not care in the slightest, most infinitesimal amount whether or not someone using a ten-year-old browser visits my site and doesn’t have the prettiest experience possible. Chances are, if they’re looking for a site from me, they’re going to want ME to support that ten-year-old browser, which will require extra time that I’m not really willing to put into it. I could politely explain to them that adding IE6 support is going to cost extra because of the time and hair-pulling involved, but in this situation I’m likely dealing with someone who has no idea what IE6 is, because all he knows about the internet is that if he clicks the little blue e his yahoo pops up. And if I’m EXTRA lucky, he’ll think he’s a ****ing computer genius, and I’ll be talked down to for even mentioning that his obsolete, outdated browser will require some extra time and money to develop for. So he’ll go out and find someone who’ll make him a nice website using HTML 3.2 and layout tables, because as long as it works in IE6, he doesn’t care!

Like I said before, it is inexcusable to keep a certain group of people from seeing the CONTENT on a site. That’s why I’m totally against those popups that force users to upgrade if they’re using IE6, otherwise they can’t see the site. Because even though IE6 and IE7 users are dropping every day, maybe somewhere in this crazy, mixed up world of ours there is actually a legitimate reason someone is browsing the internet in the year 2012 with a version of IE lower than 8. I’m more in favor of a bar at the top of the screen explaining that the site looks awful because their browser is awful, and containing several links to the latest versions of newer and better browsers. This can only help without hindering.

And if they DO have a legitimate excuse to use IE6 or IE7 (though I can’t think of many…), they can view all the content just fine. It just won’t look too good, and that’s none of my concern.

But back on the topic of whether or not to use new HTML5 tags yet:

If I’m developing a larger site with a broad scope of users, I’m not going to use the new tags. I’m going to use strict XHTML with an HTML5 doctype, because it’s shorter and more concise and I don’t have to google “xhtml doctype” every time I want to make a page.

But if I’m developing a personal site, or a blog, or anything that it doesn’t really matter if a certain group of people can’t see in all its glory, I’ll go ahead and use HTML5.