Ok,… I’m not jumping all over the HTML5 bandwagon and I don’t care to debate why “it’s seriously the best thing since mosaic” or “why it’s a giant step backwards in standards”. I’ve listened to arguments from both camps and have my own ideas/misgivings about HTML5. What I have done is come to accept that it isn’t a matter of if I will use HTML5, it’s more of a matter of when will I use it in my development.
HTML5 with all it has to offer will allow us to do amazing things somewhat easily in modern browsers but what about the not-so-modern browsers that maybe the majority of regular people use? How are we going to develop websites using HTML5 so that when older browsers default back to HTML4 standards there isn’t a hole where the media, animations etc… exist?
I’m really interested in how we’re going to roll out our shiny HTML5 websites they will cater to both cutting edge browsers and the older set.
and I don’t care to debate why “it’s seriously the best thing since mosaic” or “why it’s a giant step backwards in standards”.
You mean why
“it’s srsly teh BESTUS THING since Sl1ceD BreaD!!1!!!1” or “destr0yz teh wereld & cauzez Tsunam1s”.
How are we going to develop websites using HTML5 so that when older browsers default back to HTML4 standards there isn’t a hole where the media, animations etc… exist?
I’m really interested in how we’re going to roll out our shiny HTML5 websites they will cater to both cutting edge browsers and the older set.
Well, by only using the stuff that degrades.
-short doctype
-short metas
-new form element types (they default back to text)
-canvas if you’re just using it for retarded stuff like unicorn rainbows that follow your mouse (srsly tho don’t do like that site where if you try to “read” text with your mouse (like people do with their index fingers) you get distracted with srsly retarded canvas stuff behind the text)
I can’t get behind the “wrap the new elements in divs with ids” thing. Since nobody is actually getting any semantic benefit from the newer tags yet (and the one group you may actually care about, screen readers, can haz roles and still they are hiccupping on new HTML5 elements + roles so stick to HTML4 + roles), I don’t see the point in repeating everything twice just so you can say “I’ve got HTML5 elements! Weeeee!” But that’s me: you can see Roger Johansson does this on 456bereastreet.com.
Like Stephen said, you have to wait first before it becomes mainly normative and then another several years before browser market share alters enough makes it feasible. Then scratch your head and ask if JavaScript really means markup, and then realise you’d be mainly still better off using HTML 4.01 for most things.
Meh, you can totally get away with the stuff I listed above in all currently-used user agents. Lynx included. With some of the new form elements, you get stuff like type=“email” bringing up an @ key in iWhatevers and some easier CSS hooks and JS hooks (so long as you don’t mind older browsers not getting those styles or scripts).
Really? So for all the fan fair and discussion about HTML5, nobody has come up with a set of specifics on how we can integrate it into the real world without leaving the majority of web users in the dust?
That sounds like a golden opportunity for a new Book
They have. It’s done with JavaScript, but it amazes me that even standaristas are using this approach, as it seems to unravel all the work done in the area of graceful degradation / progressive enhancement. Rather than a new book, we just need a new term: “Disgraceful Degradation”.
And this is why it’s 100% fail for me. A user agent should really not have to be required to use a script simply to read markup. It automatically locks out all non-scripting user agents who don’t understand HTML5 (and while many newer user agents understand many of the newer HTML5 tags, still not one builds a document-structure correctly based on HTML5). Which breaks the whole wonderfulness of the basic idea from Tim Berners-Lee: that various devices and user agents, no matter who or what or where they are, have access to this central repository of information, by understanding a basic markup language wrapped around the content. Call me a bleeding hippy.
If my pages can’t work with Lynx, they are not web pages. They are something else. So far, our insurance sites are the ONLY ones I could find (of all our competitors) that actually lets you just simply buy vehicle insurance with Lynx. If it works there, it works everywhere. As it should. My company has no business telling customers which software they must use to do something stupid simple that, in decades past, they could do on the phone, through the mail, or in person. If the internet is going to replace these methods (and it slowly is: see banking, commerce), then it must be broadly (not narrowly) accessible.
I’m so obviously not talking about games or entertainment. That’s fun, but not required in daily life. I’m talking about real websites that Do Something People Need.
For stuff like, My Personal Design Site, go use Remy’s shiv. For experiments, use Remy’s shiv.
For games, videos, fun-stupid-timewaste, use Remy’s shiv.
or shim, or whatever people are calling it these days.
@[COLOR=#ff6600][B]Stomme poes[/B][/COLOR], I have to agree with you there… Using Javascript as a method to ensure compatibility seems to be a bit of a catch-22 and what I would deem as a decades old hack at best.
I was more interested in seeing more real world industrial strength solutions like Video For Everybody. The beauty of that is that it relies on the browser’s support for HTML (and various mime types). I’m not sure how it will degrade to browsers like Lynx or Konqueror and of course it is depending on browser support for Flash on non HTML5 browsers but if it works for 99% of visitors that’s pretty good.
I stil think this would be a timely topic for a book on doing HTML5 right and not leaving older browsers in the dust.
And of course if someone were to spend the time writing such a book it would correspond to the period when the HTML5 draft undergoes huge changes with half the current proposals being dropped and several new ones being proposed so that the book will be out of date before it is published. That is just about guaranteed to happen when someone tries to write a book covering a preliminary draft.
I agree with Felgall that such a book would be best off waiting a bit. I mean, they’re actually still fighting over codecs somewhere, and <hgroup> is getting strong opposition… I mean, some stuff is pretty stable but enough isn’t that it’s a good idea to wait (unless you mean an online book about what someone can try to do today, assuming they’re ok with changing/updating that code in 6 mos or so… I mean, right now I’ve got Bruce&Remy’s HTML5 book and it’s already so contradicting what they recommend in so many places. Paper was maybe not the best idea there).
Though hopefully anyone seeing this thread who know more about stuff like that Video for Everyone it would be nice to have some kind of repository of links.
I suppose such a resource would also of course include Remy’s shim/shiv/jive/Clyde.
Well you basically describe every .NET book I’ve ever bought
Practices are practices… We know that various elements of HTML5 don’t work in older non-HTML5 browsers, that will never change regardless of a spec in draft or not. What I’m proposing will not become obsolete because older browsers are here and well documented. You can look at the various elements of HTML5 and document workarounds for older browsers. I don’t see the problem.
That’s true but that wasn’t what I was referring to.
HTML5 is still an early draft and therefore greatly subject to change. THe current draft contains lots of new tags that are not actually necessary. Once enough people try them out and see how unnecessary they are they’ll be dropped from the draft. Any book that references those tags will then be referring to tags that are not a part of HTML 5.
A similar thing happened with an actual web browser with regard to CSS 2. Internet Explorer 5 decided to implement a large part of CSS 2 while it was still an early draft. In between their making that decision and releasing IE5 the draft changed how the box model was supposed to work. IE5 implemented the draft version as it existed at the time the programmers wrote the code and thus quirks mode was born to represent web pages that expected browsers to handle the box model according to the early abandoned draft rather than the correct was according to the standard.
Any reference to HTML5 at this point in its development is guaranteed to be out of date before it is even published. The review copies would go out and all the reviews would appear saying something along the lines of “well written book, pity HTML 5 no longer has all those useless features and an even bigger pity that the book doesn’t cover the many useful features that HTML 5 just adopted”.
We have more than one browser that support the fairy dust tags you’re referring to and we have influential tech corporations who are pushing HTML5 both in developer communities and in public announcements (read Apple, Google, MSFT).
I remember all to well Netscape layers and IE5.5 CSS behaviours fiasco however this isn’t a competition about one browser supporting a set of tags against another. This time there it appears to be a more consistent rush to support the same set of tags (regardless of whether they are in draft). Have a look at video, audio, source & canvas all of which have partial or full support (even Inline SVG has near full support): Comparison of layout engines (HTML5) - Wikipedia, the free encyclopedia
So, what’s to become of browsers in the wild that currently support and partially support these tags?
My best practices for HTML5 when forced is validate under HTML 4.01 strict and switch the doctype for the reasons already mentioned. I mean… section, aside, nav, header, footer are neat and all but in my opinion they get in the way. Besides, the draft isn’t even complete so its not even worth the possible issues down the line since I would be the one updating the code years from now if written to HTML5 and the draft significantly changed – no thanks. I’m fine with using a HTML5 doctype and my mark-p not being as semantic as it could with the extra elements still in draft stage.
You almost answered your own question – which is DON’T. I mean look at Oddz answer – which is don’t, then slap the short doctype on it for… well, who can figure out why. I mean, if it’s valid 4 strict ONLY, what’s the point of the retard lip service doctype.
HTML5 really offers little practical benefit over HTML4 (once you strip away all the stuff CALLED HTML 5 that has nothing to do with markup) – I still say that’s one of it’s greatest shortcomings. Sure some of the form stuff is neat, but since ALL of that needs to be checked again server side (since you cannot EVER trust client side validation) what’s the point? Apart from that, all the interesting bits and pieces of it fall into two categories…
Offer no real benefit over HTML 4.
Have NOTHING to do with markup… like CANVAS (which being useless without javascript shouldn’t even HAVE a tag), scripting controls for AUDIO and VIDEO (which again make me ask why the devil isn’t that on OBJECT), etc, etc…
So the proper answer at this point is DON’T. It’s cute to play with, but don’t use it for deployment yet… if ever.
I remember all to well Netscape layers and IE5.5 CSS behaviours fiasco however this isn’t a competition about one browser supporting a set of tags against another.
Heh, you’ve been missing how much each browser proclaims how much HTML5 they support. It’s a race, it’s a competition, it’s a war.
Yeah, browser wars. Again.
I mean, if it’s valid 4 strict ONLY, what’s the point of the retard lip service doctype.
Cause the minimalist look is in. See current browsers’ chrome setups. Abtholutely fabulouth.
Besides, if we’re only using that doctype for the validators, then why not use a shorter doctype? It’s not like browsers give a rat’s…
Sure some of the form stuff is neat, but since ALL of that needs to be checked again server side (since you cannot EVER trust client side validation) what’s the point?
Every time someone f’s up a form, their chances of leaving the site increase (everyone who researches shopping carts has seen this).
Whether it’s Javascript or new form tags, the point is to help the user put the right information in the right form in the right place the FIRST time. Ideally your back-end validation runs, but just once.
Offer no real benefit over HTML 4.
Today, this is true. However I’ll concede that if we end up with a bunch of user agents who understand both the newer tags AND the new “HTML5 document structure” (maybe this is an if rather than a when), then these newer tags could indeed make markup more semantic.
Then again, people have trouble with the current tags, so, meh.
True to an extent, but if the form and data are so big it takes long enough to send/recieve to the server that such a problem has an effect, the problem likely lies with a fat bloated page of nothing with a 100:1 page to content ratio – so throwing more code at it isn’t the answer.
Which admittedly is more of an issue for the people using javascript now – something HTML5 DOES address with it’s validation stuff; it’s sure as shine-ola going to kick a lot of stuff people are throwing scripting at for no good reason to the curb – But I’m not convinced it’s the proper solution in most cases.
Kind of ties into this… fear developers seem to have of page refreshes now. It was cute on things like quick-replies in forums, but it’s increasingly being thrown at EVERYTHING when frankly, it’s taking MORE bandwidth and LONGER thanks to the need for more code to make it work in the first place, and it’s just not as useful.
But again, if your markup is so bloated and your so reliant on scripts to even get the page to render that it takes too long for a simple server refresh, throwing more code at it is NOT the answer.
That’s how we end up with the people out there using 1.2 megabyte pages in 100 separate files to deliver 10k or less actual content.
And we come round full circle to the reason I posted this topic.
The spec might still be in draft but it’s already supported and the industry… “leaders” have been proclaiming it as the second coming for more than a year now. Some online “authorities” (note the use of quotes) are urging developers to start using HTML5 right now however the question still remains, how can we do that and still support backwards compatibility?
The answer to that is the same as it has always been. Don’t expect all browsers to support the new features and make sure the page still works without them.
