I recently encountered an “experienced web designer” who advised my not to waiste time learning XHTML, but rather concentrate on HTML5. Please comment on this and if as a total novice to website building, is it best (or a good idea) to simultaneously learn the latest version of Dreamweaver along with XHTML (or HTML5 as advised)
The current standard is HTML 4.01. HTML5 isn’t a recommendation yet and I’d not start with that but with HTML 4.01.
Dreamweaver is a WYSIWYG (What You See is What You Get) editor. You don’t need it as it’s quite expensive, unless you already have it, of course.
HTML 4.and XHTML 1.0 became the recommended standard in 1999.
While work was proceeding on XHTML 2.0 there are still browsers that don’t support XHTML at all and so a decision was made to drop XHTML and develop a new HTML instead. Based on progress to date HTML 5 might be a recommedned standard somewhere between 2020 and 2025.
I personally won’t bother with HTML5 until it becomes a recommended standard and if ie9 (or whatever version of ie is out when HTML5 becomes a recommended standard) as ie as a whole (all versions) still have a very sizable chunk of the browser market (about 60% according to Net Applications) then I will never bother with it.
Then that guy is a complete Muppet if they asked you to concentrate on a ‘non-normative’ markup language.
If you want; tell the “experienced web designer” that is a sure way to “waste your time” learning HTML5, when it isn’t finalised or fully supported by any mainstream browser.
If HTML5 ever gets finalised it will have to support XHTML anyway but typically like was mentioned you are best starting with HTML 4.01.
Yeah, those muppets at Google/YouTube using HTML5… Says someone named xhtmlcoder.
Seriously, just because it’s not supported by some browsers doesn’t mean you shouldn’t learn it. NetTuts video podcast has an episode titled “How to Make All Browsers Render HTML5 Mark-up Correctly? Even IE6”. Have a look.
If they want to use nonsense proprietary, hacks, client-side scripts (that won’t work if script is disabled) and voodoo, etc. they can do; I aren’t stopping them…
Though I think the problem is suggesting that a beginner would be practically better off learning a ‘non-normative’ draft “first” rather than something which actually has been finalised, i.e. HTML 4.01 grammar is counter productive in most cases.
Google isn’t using HTML 5. The short doctype that HTML 5 uses is equally valid for HTML 2.
HTML 4.01 Strict is the best toy to play with. HTML 5 is not ready, and while it doesn’t hurt to include some of its features to enhance your site, where they are supported in some browsers and don’t cause others to fall over, it isn’t worth investing too much time and effort when the spec could still change significantly.
Unless you know that no-one wanting to visit your site will be using any form of Internet Explorer (up to and including IE8), there’s no point in worrying about XHTML. You can only serve it as fauXHTML, so you don’t get any of the advantages of the X, you just end up having to jump through more hoops and run with messy code to achieve the same outcome.
Sounds like the developer is trying to use the terms like buzzwords (like when everyone said… you must replace everything with AJAX).
PS: They are using HTML5 Stephen, YouTube’s HTML5 version uses the <video> element and Google Wave uses many HTML5 functions.
Those are specific experimental applications though. Google also use the same doctype on some of their mainstream pages where there is no HTML 5 used in the page because they still need it to work both in browsers that don’t support those HTML 5 tags and where they also don’t want to have to change things when the HTML 5 rules for the tag are updated.
Could you please point me to the W3C recommendation that describes the
<video> element? No, not the draft; the final version! No?
Then this argument is rather silly. I could write whatever tag soup I like and claim that it is HTML6, which may or may not appear eventually and then may or may not correspond to my present-day tag soup.
You can’t use HTML5 today, because HTML5 does not exist yet. It may, one day (hopefully not within my lifetime) but your guess is as good as mine as to what it will contain. There might very well be a
<video> element and it might even work as outlined in the current draft. Then again, it might not.
Sorry but that comment is daft, just because HTML5 isn’t complete doesn’t mean we cannot refer to the name HTML5 and imply what is currently in a draft format, let’s not fool ourselves here… the chances that someday HTML5 will become a recommendation is certainly not out of the question and it’s unlikely to ever be confused with anything else. I can see a cause for concern if I was stating something which didn’t have any factual grounding for existence like saying a W3C specification called CRAP was being adopted (Cybernetic Reality Augmented Protocol)… but to say a draft doesn’t exist because it’s not finalised is like saying that half of Google’s business has been built on non-existent products that millions of people use everyday (due to their beta status) or that evolution doesn’t exist as it’s not finished.
That’s not the point. The point is that because it is only a draft using it in live web pages is not a safe option because you don’t know if it will still be defined the same way once it becomes a recommendation.
We have already been down that path once with Microsoft jumping in too quick to start implementing the CSS 2 draft in IE5. The draft was amended to change the way the box model was defined with the result that the way it was defined in IE5 ceased to match the standard and look at all the issues that is still causing ten years later.
Everyone who wants to recreate the Internet Explorer incompatibility problems of the past ten years should insist on the browser that they hate the most jumping in and adopt all the draft HTML 5 code now. Everyone else should insist that it not be used except for preliminary testing until all the garbage it currently contains is fixed and it becomes a recommendation.
I agree that it’s unsafe to some extent, but I wouldn’t say implementation should be out of the question for people who regularly maintain their websites and consistently evolve their designs rather than simply saying “project complete!” and leaving it as-is (except perhaps for the odd bug fix or content updates). I think in many ways web professionals have become rather sloppy in the industry that they make websites and then leave them (as-is) - though I guess that’s just the nature of the beast as to the way we do business on contract rather than with regular maintenance. Having a website should be an ongoing process of evolution and adoption and if you’re going to regularly improve upon your work (and can dedicate the time to-do so) I see no reason why you shouldn’t pro-actively implement a draft (while accounting for updates as they appear). CSS3 used in gracefully degrading cases is a perfect example of this in action.
Feel free to think so, if you like.
To me, what’s daft is relying on a specification draft for a production website. As Stephen said, we’ve been down that road once before and suffered the consequences.
I’m not a fan of HTML5 in the first place, since it seems to have been hijacked by people who failed to grasp what made STRICT so much better than Transitional in the first place… As if they are bound and determined to waste extra tags to replicate existing meanings, add new tags for no good reason (audio and video for example), and make websites an even more bloated mess than they already are.
But even if I take my complete dislike for the specification out of it, and look at CSS3 which I DO like a lot of… There are two things working against HTML5/CSS3 that make them NOT real world deployable in my book…
The first is obvious - IE lags behind, majority of people still use IE and more people use IE today than they did when they had 90% of the market… (what’s more, 90% of 1 billion or 54% of 2 billion? Next person who says there are less IE users due to loss of market share is getting by boot up their backside)… given that most CLIENTS seem to still be using IE and it’s better not to argue their stupidity with them, that means whatever you do HAS to work for them. Suck it up and deal.
The second though is the simple fact that both are still in DRAFT. Draft means it’s there to play with to say “Gee isn’t it neat what we MIGHT be able to use in a decade”, NOT for building real world deployable pages.
It really seems lately like people don’t understand that “BETA” or Draft means “don’t use it for production work!”
I still maintain that it can be used for production environments as long as you DO ensure you keep it up-to-date with the changes which occur to the specification. I’ve always been of the opinion that a website shouldn’t just cease development when people feel it’s baked, it’s a constant evolutionary process and if you’re like me (where you regularly update your site) then I see no justification not to make use of draft components if you ensure that you update those components as and when changes that affect the code are made. I think the problem isn’t that people don’t see BETA or draft as “fit for production”, it’s the opposite, most people think “design complete” means you can abandon the site or continual enhancement process (without updates) for months on end.
Only thing that should need updating is the content, not the layout the content is in; As such it’s ridiculous to keep screwing with the layout as you’ll end up wasting time on presenational crap that could be better spent on what people actually visit websites for:
If you need to update your layout/template code more than once every year, you’re probably doing something WAY wrong.
I’m not talking about just tweaking the layout and ignoring content, I’m talking about continuously evolving the experience in preference to just overhauling once a year. I certainly wouldn’t put the design or functional enhancements above content writing either, the content is the most important aspect of the website. But there’s absolutely nothing wrong with enhancing the layout and functionality of your website more regularly if the improvements will better the user-experience.