| SitePoint Sponsor |
Hi everyone,
I've already created a php site that has the following doctype:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
I need to now add some html5 code but wondered if I need to change the doctype in order to do this. If yes, how would I do this?
I wondered if anyone could give me some advice?
Thanks in advance
If you are going to use HTML5 code, you should certainly change the doctype to something like this:
If your doctype is stored in one place and fed to templates via an include or something similar, it will take just a few seconds to update the site.Code:<!DOCTYPE html> <html lang="en"> <head> <meta charset="utf-8">
Be aware of a few things, though. HTML5 is still in development and has little true browser support, so use it sparingly and judiciously. Also be aware that some old-style code that is allowed under a transitional doctype (like the one you have now) is not allowed under more modern conditions (strict doctypes) ... although the rules of HTML5 seem to be pretty forgiving/lax in relation to strict coding practices, so you may be fine. (And none of this means that the site will stop working, but rather that your pages may get more errors and warnings if you run them through a code validation service to check for errors or potential problems. In reality, browsers are very forgiving.)
Thanks for the reply,
My current doctype is a public one as it's pointing to a public .dtd file. Do I need to do this with the html or just insert what you suggested?
Just insert the code I posted above. That's the complete doctype for HTML5, but it is backwards compatible, too, so it won't break anything on current sites. A lot of people use it for all their sites, whether or not they have any specifically HTML5 code.
Ok thanks
The reality is that browsers don't care at all about what comes after "<!doctype html..." It doesn't matter to the browser if your doctype is HTML or XHTML, and it doesn't matter if it's strict or transitional. That's why the HTML5 doctype is backwards compatible, because the browsers never read beyond that point anyway.
So the good news, gwh, is that it's pretty much impossible to break your page with these kind of changes. You can use HTML5 stuff even if you still keep your same old doctype. Or you can switch to the new HTML5 doctype, and browsers won't even know the difference.
My question would be why do you "need" any of that HTML 5 bull... Well, unless for some reason you 'want' VIDEO, AUDIO or CANVAS; the first two of which just being a way for browser makers to further fragment online video with their favorite pet codecs (while exploiting the ignorant dirty hippie FLOSS whacko's delusions to justify it), the latter serving no practical purpose as a HTML element since it's useless without javascript. (and for those of you about to pipe in with the "fallback content" Bull, that's NOSCRIPT's job!)
The rest of HTML 5? Do yourself a favor, forget it exists... You should probably be learning STRICT before even thinking HTML 5 anyways, so you're qualified to tell if the DRAFT is worth using... and at least drag the markup out of 1998. That's what TRANSITIONAL means -- code in transition from 1997 to 1998 practices; which means it's probably already chock full of fat bloated nonsense and accessibility failings; slapping the absurdly loose HTML 5 nonsense on top of it? Not a good answer to ANY problem.
No.Originally Posted by gwh
Jeff has it correct: browsers don't give a rat's. Any browser who has shipped with an HTML5 parser (and they're all partial since HTML5 is still in draft) will see *any* page served as text/html as "HTML5" no matter what the doctype claims. Any who hasn't, will use their HTML4 parser (yes, even XHTML... browsers ignore those closing slashes and other silliness too).
Validators care though. But even that only matters if you don't like wading through "errors" that you understand aren't really errors, or if you're worried about missing a stylistic error you were hoping a stricter validator would call you on (like using "checked" instead of 'checked="checked"' for example).
As a card-carrying dirty hippie FLOSS whacko, I f*ckin HATE Flash and the way Adobe's hatred and bigotry against Linux has caused us unreasonable problems with videos on our "open sores" internets. Screw Adobe with the longest, most barbed pole you can find... maybe one of those things cops lay on the road to make cars' tires go flat. One company controlling how a form of media can be used and played? With closed software that gets hacked and uses its own cookies (separate from deleteable browser cookies) so they can spy on us more? That sucks, and that's, like, my opinion, man.
* all software has bugs and can get hacked. It's that I like more eyes and immediate response and fix like I get from the dirty hippies than waiting on Adobe to decide when they'll get around to my OS...
Canvas is getting retarded though, since the folks pushing it into the spec keep saying "all it does is make a picture by colouring pixels on the screen using coordinates, don't use this to make GUIs and things" and then what do people do? Make (naturally inaccessible at this point) GUIs and things with it. As everyone should have expected, being all new and pretty and coupled with the HTML5 hype and coming from the shiny Apple guys and, most importantly, not as scary-looking as SVG. (and for games, not as slow, I'll give them that)
The only thing the fallback content can do is show up when the browser doesn't support CANVAS, whether JS is there or not. <noscript> has no place on modern pages: it cannot detect if scripts are being blocked, only whether the browser has a JS engine and it's enabled (meaning, Javascript should check this by *removing* the content you used to put in a <noscript>, NOT relying on the browser to correctly display the <noscript> text). A plugin or a firewall blocking scripts means no <noscript> showing up (unless the plugin is well-written and works around this, like the awesome NoScript plugin does. weee ♥). If you're doing something in canvas, your Javascript had better be checking and supplying the fallback content, and the fallback of canvas when no JS should say "You don't support canvas. This website sucks but we'll blame you for it." Done.(and for those of you about to pipe in with the "fallback content" Bull, that's NOSCRIPT's job!)
I assume when the OP says s/he needs to use HTML5, s/he means "needs one of the new APIs". Which is Javascript anyway. So reliance on JS here is moot.
That's why I said "why do you 'need'" -- without knowing what it is the OP is actually trying to do/use, we're guessing blindly or making assumptions. We actually don't know what's being asked -- could be something that you can do without any HTML 5 stuff in the markup, could be something like the new form stuff that you have to double-check server side anyways (kind-of defeating the point of using it), could just be handing the client who heard a buzzword what they want even if they don't understand it's nothing more than a sick fad that offers no advantages and many disadvantages.
Off Topic:
That's been a real problem I'm seeing of late here, people not providing enough information to answer the question.
But that makes it fun!
If it encourages and increases these, it's a Good Thing:could be something like the new form stuff that you have to double-check server side anyways (kind-of defeating the point of using it)
that the user fills in
the RIGHT information
in the RIGHT field
in the RIGHT format
the FIRST time (before they hit submit and get that disappointing set of error messages)
then it's awesome. Not all the new HTML5 form thingies do this, but the ones who do, I'm all for. They were never meant for actually sanitising data.
That "autocomplete" is default on inputs is retarded and a security risk, causing us to add more retarded code just to stop it. YES, AUTOCOMPLETE MY PERSONAL INFO, CREDIT CARD, ACCOUNT NUMBERS AND EVERYTHING ELSE, WHAT A WONDERFUL IDEA. Seriously that shizzle should be OFF by default.
Well, that's just the old problem of what the end user wants for convenience vs. what we as developers want for security. Remember, the number one security hole is little more than PEBKAC.
Off Topic:
I just learned a new word ... well, two actually: PEBKAC and luser.
Yer right, on that...
Yes and no -- per script blocking is problematic, but that's why scripts should enhance content whenever possible, and if not use the DOM to attach your scripted content and remove/hide the non-scripted.
Which is actually what I did with my little canvas demo I wrote a year or two ago:
Code:<div id="canvasHolder">This program requires the CANVAS element to function properly</div>flat dom replace of the firstchild -- said firstchild naturally being the DIV's textnode. You could also do:Code:var cCanvas=document.createElement('canvas'); if (cCanvas.getContext) { var container=document.getElementById('canvasHolder'); container.replaceChild(cCanvas,container.firstChild);
To replace the div with the new canvas element... just beware that container would be invalidated by that.Code:container.parentNode.replaceChild(cCanvas,container);
Either way, there's no reason for CANVAS to have a tag since it's useless without javascript... just like there's no reason it couldn't have simply been made a property object you could optionally attach to any element drawing over it's content... after all that's what an object model is FOR.
Posting Permissions
Reply With Quote
Bookmarks