|Do I REALLY need a DOCTYPES, on my websites? |
DOCTYPES: Please Help
| 12:48 am on Mar 12, 2005 (gmt 0)|
Do I REALLY need a DOCTYPES, on my websites?
I am trying to find some updated information about DOCTYPES. It seems everything I find is about 2-3 years old.
Do I really need to use a doctype? It seems people are pushing this so the websites can be validated, however I want to know if it is mandatory to have for today's Internet world or for the future?
The reason why I ask is because I have designed over 35 websites and all of them are live on the Internet with no doctypes, They seem to look great on all browsers, (IE, Netscape, Firefox, Mozilla) and I have never received a complaint about a site not working.
It seems that people are pushing doctypes because browsers are becoming stricter with the HTML language. My quess, because I cannot find any updated information on doctypes that this has already happened. And since my websites look good on all browsers, should I need to worry.
| 1:06 am on Mar 12, 2005 (gmt 0)|
Welcome to WebmasterWorld, perryc20
How do you validate those sites?
Is looking good all you are interested in?
| 3:25 am on Mar 12, 2005 (gmt 0)|
Welcome to WebmasterWorld, perryc20!
There are many versions and flavours of DTDs (DocTypes). Which one you use is a combination of personal preference and site requirements. But you definitely should use one: it is, at the least, professional best practice.
If you do not declare a specific DocType correctly a visitors browser must "guess" (usually by applying the loosest possible DocType or a "quirks" mode DocType of its own) resulting in slower rendering.
It can also result in display variation between browsers. That your sites all render "as designed" without a DocType indicates that the layouts are by <table> rather than by <div>. This is not "wrong" (it works after all) but it is a "hack" from years past when there was no other broadly supported layout mechanism.
Concerns about display rendering times, bandwidth consumption, regulated accessibility issues etc. as well as newer strict parsing variants (xHTML, XML, etc.) and increasing CSS support are changing web coding.
For as long as browsers incorporate "legacy" compatibility non-DocType sites will continue to look fine. However, if site design is your profession I recommend updating your skill set. The learning curve is steep but the benefits, in fluid flexible layout design, in rapid site maintenance, in site operation cost savings are tremendous.
| 4:19 am on Mar 12, 2005 (gmt 0)|
|...should I need to worry[?] |
If you wish to use the new and more advanced capabilities that exist with HTML 4 and CSS in order to streamline your webpages and have consistency with the box model across browsers, yes.
Otherwise, you are left with the kludge design principles that were used a decade ago.
| 2:18 pm on Mar 12, 2005 (gmt 0)|
I wouldn't worry about it too much, but you should try include doctypes in your future websites and validate them. Preferably, make them by using XHTML/CSS.
| 2:39 pm on Mar 12, 2005 (gmt 0)|
I respectfully disagree that xhtml is best for everyone. I would however encourage a STRICT doctype over a transitional one, whether you need xhtml or html 4.
If you need XML - then go for xthml. Otherwise, what's to be gained? But by learning strict mark-up in either case, you will gain knowledge that can improve your skills and your sites.
| 3:30 pm on Mar 12, 2005 (gmt 0)|
I have never used doctypes in any of my pages and have not run into any difficulty.
| 6:12 pm on Mar 12, 2005 (gmt 0)|
Do you know, then, that all your pages display in "quirks mode", cmatcme? And are you aware that this makes for more significant cross-browser rendering differences, differences in the box model, in default padding and margin for various elements, and so on?
This is not necessarily a problem - and in many basic page layouts, I appreciate that standards vs. quirks mode issues can be a moot point. Just want to bring these issues to awareness for everyone reading along at home.
You tend to stumble over these things more as a page gets more complex, and also you test across different operating systems and browsers.
| 4:25 am on Mar 13, 2005 (gmt 0)|
|Just want to bring these issues to awareness for everyone reading along at home. |
To add to this...
A lot of people seem to think that the only rendering difference when a doctype is applied is in which box model the browser uses. They conclude, then, that if their site uses tables for layout or otherwise avoids box model issues that there will be no difference in rendering. This is simply not true.
The doctype specifies LOTS of things, an important one being how box calculations are made, yes, but that's only one peice of the document. I have seen wild variations in the same page between browsers when no doctype is involved. Margins and padding are handled in seemingly random ways on some browsers without a doctype. Flagrant breaches of the W3 specs are rendered willy-nilly, making cross-browser uniformity a pipe-dream, and even worse, tricking coders into thinking that bad code isn't (and that bad browsers aren't). In just the past few days I've posted to three or four threads in the CSS forum where a lack of a doctype was causing the designer to get rendering problems.
If you think for a moment about what a doctype IS, it's easy to see the logic behind always using one. A doctype is a set of rules that tells your browser how to handle interactions between various peices of code. It just makes good sense to ensure that the rules you are designing according to are also the rules the browser will interpret according to.
You should always use a doctype declaration.
| 2:57 pm on Mar 13, 2005 (gmt 0)|
I currently us FrontPage for designing websites. I also only design information websites such as landscaping business, construction companies etc.
Website that pretty much just give information about the business, (Home page, about page, services, gallery etc.) I am not creating any kind of database driven websites, just basic informational websites.
I also found out the Front Page does not use doctypes because:. "As with most modern Web development tools, FrontPage may use design-time proprietary code and attributes for HTML tags that does not validate according to the standards of the W3C"
If this is the case, am I, OK with creating standard Table layout websites with no doctype.
Is this going to become a problem in the future, or as long as my websites are working correctly on all browsers today, I should not have a problem for the future.
| 3:09 pm on Mar 13, 2005 (gmt 0)|
I'd suggest you use a doctype anyway, and add it yourself if your editor doesn't do it for you.
Using a doctype doesn't mean that your mark-up must validate. As I see it, it is OK not to validate if you know why -- that is, you intentionally include a few proprietary tags for practical purposes, and they are the ONLY places your mark-up doesn't align with a doctype.
But not learning the ins and outs of how the standards work WILL hurt you eventually. And as others mention above, what you learn will bring you solid benefits over time.
| 9:30 pm on Mar 13, 2005 (gmt 0)|
|I respectfully disagree that xhtml is best for everyone. I would however encourage a STRICT doctype over a transitional one, whether you need xhtml or html 4. |
tedster, could you elaborate on this a bit - the pros and cons?
| 10:13 pm on Mar 13, 2005 (gmt 0)|
Internet Explorer does not support XHTML.
Internet Explorer does not support the application/xhtml+xml mime-type.
Serving XHTML as text/html is pointless.
The standard reference is I believe [hixie.ch...]
| 3:16 am on Mar 14, 2005 (gmt 0)|
|tedster, could you elaborate on this a bit |
Well, in the most general terms, transitional means moving away from something and towards something else. If you want to be ready for wherever this web thing is going in future years, it's good to along for this particular ride.
In the beginning of my involvement with the web I had no idea that SGML even existed, say nothing of the fact that HTML was one of her children. I was a marketer of 25 years and I just wanted to get on with the show in this new arena.
This was the mid 90's and Netscape was the really only happening game. The young upstart Internet Explorer came along in 1996, and those two browsers both began innovating like crazy. The W3C was, well, not able to keep pace with this innovation. By this time HTML3 was just sort of hacked together, and we had a nasty mish-mosh going on. But with CSS in the offing, poorly supported as it was, we also had the germ of sanity.
But now, the W3C had taken a very necessary position, and the name of the game is separating structural mark-up of the content from rendering instructions for the user agent. That's the difference between transitional (moving away from the previous confusion) and strict (the first solid move toward separating semantic mark-up from rendering instructions.)
By learning how to write strict mark-up, I found my appreciation growing for what HTML is and what it can be to be. I no longer thought about HTML as a way to layout a web page on screen, I now thought about it as a way to mark-up a document to clarify its structure.
And my pages became quite clear. I can usually read diectly from my source code with very little difficulty. And of course, these documents are more easily spidered and more easily maintained.
In the light of all this, you can see why I have little fondness for "transitional" xhtml. It's already got one foot in the grave before it starts, IMO. The big, important step is from transitional mark-up to strict mark-up, not from html to xhtml.
The pro of strict mark-up? You're now part of the solution.
The con of transitional mark-up? You're still part of the problem.
All kinds of user agents will be able to develop into true sophistication once this evolution has taken place. That will be over the next 5-10 years or so, not tomorrow, so you still have time.
| 5:47 pm on Mar 14, 2005 (gmt 0)|
I did what everyone said, and I added a Doctype to one of my pages to see what happens,
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN""http://www.w3.org/TR/html4/loose.dtd">
However when I upload the new page and looked at it on different browsers, the layout was distorted, (Margins, table etc.)
What happened? If I use a doctype it messes up the websites, If I don't use a doctype it looks great on all browsers.
Also how do I know what doctype to use, I create websites in Front Page and it handles all of the HTML coding.
| 6:01 pm on Mar 14, 2005 (gmt 0)|
What happens when you use a full DTD is that modern browsers switch into Standards Mode rather than Quirks Mode. See [webmasterworld.com...] for the rundown.
You say that your pages used to look good on all browsers - but I'd guess you didn't actually test on all browsers/all operating systems. That's a lot of testing! One good reason for understanding all this is to make your pages likely to display well, even on browsers you don't have and can't test on. Mac browsers like Safari, for example.
How do you know which doctype? The one you used is the best for this situation.
| 6:50 pm on Mar 14, 2005 (gmt 0)|
For what it's worth, I designed a site using Frontpage (which only places a half-doctype by default) and when I looked at it live on the web with Firefox, it was broken - The raw source was displayed. As soon as I corrected it with a full doctype (including URL) it was fine.
| 10:12 pm on Mar 14, 2005 (gmt 0)|
Thanks for the explanation.
>And my pages became quite clear. I can usually read diectly from my source code with very little difficulty.
I noticed this as well after spending the weekend validating some pretty sad looking code.
| 12:05 am on Mar 15, 2005 (gmt 0)|
The problem with designing in Frontpage is it designs for only IE in mind. To get it working in different types of browsers you generally have to go into the code itself and hand edit it. WYSIWYG type editers, like Front Page and Dreamweaver (to an extent), aren't the best things to use to make standards compliant webpages. The only time I use such programs is when I want to get a concept quickly in code, but using them generally takes more time in the end then it would just to write pages from scratch.
If you want to know how your coding falls short of standard you might want to run your site through this program.
It will tell you the coding that is wrong so you can look into finding the standard version of that coding you are using.
Although I don't like the way some of the standards are heading it is the easiest way to make sure your site looks the way you want it to in all modern browsers.