)| Code: |
| <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> |
Because your site is very unlikely to be valid XHTML 1.1. To be that, it has to be sent to the browser as XML, not HTML, and this will make IE not display the site at all.
That's the reason why at least 50% of XHTML pages on the web don't actually validate. Then add the idea that there are some tags they shouldn't use (those that they never should have been using in the first place), and things start to get ugly. Then tell them to "try and tell the browser that your page is XML now", and watch them go insane
| Kaneda wrote: | ||
| It's true that Internet Explorer 6 and 7 will behave best when you follow the standards, and specifically when you have a proper DOCTYPE. This is because IE (and other browsers) specifically use the DOCTYPE at the start of the page to switch from "quirks mode" into "standards mode". This is in order to keep backward compatibility while still allowing newer sites to "do things right". Remove the DOCTYPE, and the width of boxes etc. will be different.
However, HTML 4.01 will be just fine (actually better) than XHTML for IE, with a doctype like:
Since IE quite simply doesn't support XHTML at all. It will see a well-formed, valid XHTML document as a document stuffed with errors - errors which it then tries to ignore - but which will (somewhat) make the page actually render slower. Also, if you say you aren't a specialist, I'd encourage you to use that doctype instead Because your site is very unlikely to be valid XHTML 1.1. To be that, it has to be sent to the browser as XML, not HTML, and this will make IE not display the site at all.
As for Flash, it's actually almost impossible to get Flash to work at all in all browsers in any HTML standard, if you put the Flash embedding inside the HTML - but you shouldn't anyway, since a new IE update has made it essential to only include Flash (and QuickTime, Windows Media Player, Shockwave etc.) through JavaScript - otherwise you'll get a "Click here to activate content" problem. Reason: Mozilla browsers mainly recognize the EMBED element for plugin object embedding, and EMBED isn't a part of any HTML standard. Hence, if you make it work in Mozilla, it won't be standards compliant anymore. Standards are a complicated issue right now, and I'd say, about 80-90% of people who claim to write by "strict standards" actually don't. A proper XHTML page, especially when served as XML, offers lots of new things the designer has to get past: - CSS behaves slightly differently (<body> no longer fills the entire browser window, so you have to style <html>). - Javascript behaves differently - tag names used in it are now case-sensitive among other things. Google Maps API, for example, doesn't work on an XHTML page served as XML at the moment. - You can't use entities (like ­ or &cpy; ) - XML only supports 5 entities: & ' " < and > - all others have to be numeric (like € ) or you have to declare them yourself (and don't expect browsers to understand that). - Any javascript inside your HTML file generally (if it includes < or &, and most javascript does) needs to be escaped with <![CDATA[ javascript here ]]> - Finally stopping to use those non-existant attributes and element names (<embed>, target="_blank" etc.) - many other things. For many people, it's clearly hard enough to get used to the strict XML way of doing things - all lowercase, closing tags, closing empty tags even, etc. That's the reason why at least 50% of XHTML pages on the web don't actually validate. Then add the idea that there are some tags they shouldn't use (those that they never should have been using in the first place), and things start to get ugly. Then tell them to "try and tell the browser that your page is XML now", and watch them go insane
For most hobby web developers, going to XHTML is pretty useless, and for now, they might as well stick with HTML 4.01
The more important parts of web standards for "normal people" right now would be CSS, content/presentation/behaviour separation etc. |
 |