Arquivos de Posts
Why I avoid the DOCTYPE declaration
Damn this whole shit regarding the DOCTYPE declaration and the differences between browsers! I just hope there's nothing getting loose inside my already so messed up brain... Testing HTML code in two different Internet softwares can be a darn thing to do, especially if one's under professional pressure. I've been reading so many pages in English for the last few days that my native language for the next week is going to be English. Good rewards and sweet sugar do not come without suffering, and I had my quote for the time being. Here follows important observations concerning only pages with frame lay-outs (such as mine) that I collected BEFORE trying to validate any page:
- The W3C Transitional/Loose DOCTYPE declaration worked pretty nice with IE and NN.
- The W3C Transitional/Transitional DOCTYPE declaration caused one main problem in Internet Explorer only. It made an annoying horizontal scrollbar to appear whenever there was an image in the page (tag <img>), only when the document was opened inside a frame. If the document was loaded on a page of its own, the horizontal scrollbar disappeared.
- If the W3C Strict DOCTYPE declaration was used in the document, the annoying horizontal scrollbar would be overridden and the page would display wonderfully in both browsers. The challenge here is always to cope with all the irritating W3C Strict rules, which is sometimes virtually impossible for the desired lay-out.
And here follow very important issues related to webdesign itself:
- The <body> tag does not support the event handler
onResize
in XHTML Strict. It is necessary to add the JavaScript command linewindow.onresize=functionName
for any resizing routine to be executed properly. Additionally, any event handler must be written in lowercase according to XHTML Strict (where allowed,onResize
is to be rewritten asonresize
). - All DOCTYPE declarations seem do demand the complete specification when defining spaces. In this way, a style defined by
'margin: 100'
is completely ignored, also causing malfunctions in JavaScript coding. It is strictly necessary to specify the units desired (px, cm, etc.). For pixels, the correct line in this example would then be'margin: 100px'
. I spent nearly a whole day trying to figure out why I couldn't apply the width style to a simple <div> tag and, as usual, I learned my lesson the hardest way. - The inclusion of all the page content inside a <div> tag has many advantages when complying with XHTML Strict. One of them is that, according to this standard, <br /> tags are not accepted when included loosely inside the <body> tag, but execute well inside <div> tags.
- For compliance with Netscape, all <div> tags with relative positioning must have a
width
style, or else a horizontal scrollbar appears, with the same size of theleft
style applied relatively. - Quirks mode (also referred as Compatibility mode) and Strict mode (also referred as Standards-Compliant mode) are the two 'modes' modern browsers use to interpret CSS. Old pages are displayed according to the old rules (Quirks mode), while new browsers are able to display pages according to the standardized CSS convention (Strict mode). The mere presence of the DOCTYPE declaration is enough to trigger Strict mode, although the page does not have to validate according to the chosen doctype! The fact is that this really works, as long as only one DOCTYPE declaration exists in the document (there can be no other DOCTYPE, even inside comments, otherwise the page reverts back to Quirks mode).
However, Strict mode pages generated an inexplicable horizontal scrollbar when displayed inside my frames. Thus, I assume that Strict mode (implying in DOCTYPE declarations) is perfect only for new frame-free sites being developed from scratch.
One strange thing I noticed, and this could have been caused by stress and by the fact that I was pretty tired, is that sometimes the Loose and the Transitional standards behave awkwardly, assuming each other's characteristics when displayed inside a frame. I was actually beginning to think that the use of Loose and Transitional validations (the practical ones, disregarding the hard and time-consuming Strict) was related to UTF encoding: if one had special characters in the page, even if the UTF encoding was declared, one should use Loose; for no special characters (as with texts written in English), the Transitional validation could and should be applied. Even so, what I just wrote is worth nothing whatsoever.
After suffering for 2 days straight, I could not figure out why (in IE only) documents containing the most common types of DOCTYPE declarations have such unpredictable behaviour when displayed inside frames (for these pages are loaded with no flaws on windows of their own). The oddest thing was validating my pages through http://validator.w3.org. While one of the documents was XTHML 1.0 Strict compliant and perfectly displayed in my main frame, AFTER THE VALIDATION the damn horizontal scrollbar appeared in it once again! An it wouldn't by any means disappear! Now tell me... How is anyone supposed to work with validated documents if such crap keeps happening on frame-based sites???
I do think though that this behavior is somewhat a subtle way that W3C found to disencourage webdesigners in the use of frames... The only measure I can take in order to keep working with frames while maintaining my pages without the fucking horizontal scrollbar is to omit the DOCTYPE declarations in my documents, even though all or most of them remain XHTML Strict compliant (at least for the time being)!!! For instance, the only thing missing for this page to be validated as XHTML Strict is the DOCTYPE declaration (it should be actually Transitional, just because of the target
attribute in the <a> tag...)! As an orientation measure, from now on I will always add the concerning DOCTYPE declaration within comment signs.
And that's all for a short spell, people. Let's move on.
Texto postado por Kollision em 9/Março/2005