Since you're sending it to the browsers as HTML, there's no real safety. In fact, the browser vendors are already hijacking HTML with this HTML5 stuff. HTML4.01Strict should last (and work) as long as XHTML1.0Strict, except you're adding extra bytes to satisfy the rules you've chosen to follow for XHTML (/ to close empty elements basically). Browsers, since they're treating the page as HTML either way, will react the same. Take a regular page, change the doctype, watch what happens. Nothing (so long as it's still a COMPLETE doctype). There will be rendering differences between Strict and Transitional, but not between HTML4 strict and XHTML1.0 strict. Take into account that IE doesn't do anything at all with real XHTML (XML sent as an application of HTML). It'll try to get Firefox or someone to open it for you as a document. The other browsers don't do everything perfect with real XHTML either, but those are small things. For instance, Opera has issues with svg's. OP: Even when you're using placeholders because you're building something, use valid ones. Otherwise you might give yourself bad habits. Don't want to get used to seeing <div><li></li></div> because it should burn your eyes the moment you see it. For page-building placeholders you could do what wd did, though we discourage divs holding anything like text directly (because supposedly we should be using semantic elements around stuff like text like a p or whatever to say what that text is) it is legal though. If these are permanent coloured bars, they should not be divs. Generally decoration should not be in your document. They should be purely CSS. Sometimes that's not realistically possible though, and you sometimes need what's called a "sandbag" (an meaningless element such as a span or div which is there only to hold background images or colours... usually never needed for colours). wd did a fairly nice version of how a page could be set up using very little positioning... the abso-po'd ad is to get the source order different from what you see on the screen. That's one acceptable use of absolute positioning. Floats and margins can position just about any sort of box, but they have weird rules and take a while to learn. I've heard good things about Lydia.com but it's not completely free (some things are free). HTMLdog.com has tutorials, as does SitePoint and a few other places. The thing to keep in mind is, things have a default setup (regardless of browser, so don't confuse this with "browser defaults" which aren't always the same from browser to browser) and you want to use CSS to do the least needed to get someone in place. In other words, you take advantage of the defaults. Less code is easier to maintain. Don't spend time listing things over and over again when you can list it once and let the cascade take over; don't list things that are already the default (you learn these over time); don't over-position everything. It's like a horse. You can try to control every step it makes or you can just guide it to where you want to go.
Nowadays, very little, unless you are using the eXtensibility and namespaces etc of XML. In which case, you aren't making a standard web page for all user agents to view and show. If you write Javascript you'll notice some differences. Remember, everyone says XHTML1 is stricter than HTML4. This is bogus. It is the author who determines the strictness. If you want to make your own little rule that every third line needs to be indented further or every fourth word is " banana", it's your choice as a writer to be strict enough to stick to it. The validator isn't any less stricter, but uses one set of rules to check your page with an XHTML doctype and another set with an HTML4 doctype. But if you want the validator to check your HTML4 page with XHTML rules, just tell it to check as if your page had that doctype. It's a chooseable option. An XML parser is stricter in that it's supposed to stop, wave its arms in the arm, scream YOU HAVE AN ERROR AND I'M GONNA SIT HERE TIL YOU FIX IT and stop rendering the page when it comes to the first error. An SGML parser will continue on blindly, trying to render the error. Bleh.