XHTML 1.0 Strict -- The Follow Up

2. Anne said:

I see what the problem is. Probably Safari has the same DOCTYPE swithcing as Mozilla. Besides quirks mode, Mozilla has almost standard compliant mode and standard compliant mode. The latter is only triggered with a Strict doctype (XHTML 1.0 Strict, HTML 4.01 and XHTML 1.1 (which is irrelevant, since IE doesn’t support real XHTML)) or an XML content-type/MIME type.

The advantage of using a Strict doctype would be that your document complies to the standards as close as possible, since that is what standard compliant mode is for and you are probably as forward compatible as possible.

Personally, since I always need to work around for Internet Explorer, I put that browser into quirks mode before I start writing code :-). That makes coding for it a lot easier in my experience, especially since you have to deal with IE5.x+ as well and those browsers behave the same as IE6 in quirks mode.

PS: sorry for the double post last time.

Posted on April 28, 2004 11:05 PM | #

4. Rimantas said:

Well… I think HTML4.01 Strict is OK for me, but only for mime-type issue. And it is strictier than XHTL transitional.

The only big reason to use XHTML is if you are going to use XSLT transformations. That offers some really interesting possibilities.

Still, I am in favour of XHTML, but only serving it as HTML for IE and alike and XHTML with application/xhtml+xml for those accepting this mime type.

Sure this technique may look very puristic and an total overkill, but there is some pleasure in “doing things right”. It also gives better understanding how things work.

For those interested I can offer an old and so far the best text on the topic.

And there is something from W3C.

Posted on April 29, 2004 01:36 AM | #

6. Pat 'hakjoon' said:

It’s funny that there is always mention of all the pain and suffering that IE causes, but I have been finding in my experience that once you learn how IE thinks it is very predictable. In fact, in Strict mode I find it behaves almost exactly like Mozilla. I much more difficulty with Opera, Safari and IE5:mac. iThey seem to behave like neither IE or Mozilla which gives you a whole other bag of bobcats to tackle. Funny how mileage varies.

-PatW

Posted on April 29, 2004 07:38 AM | #

8. manuel said:

Maybe what matters is getting used to a certain (mis)behavior with a certain doctype (any), its corresponding hacks and workarounds. I’ve personally got used to xhtml1.0s (sent as html), and when I have to code for quirks mode it’s a real pain… (not as much of a pain as using tables for layout, if you’ve tried recently, but a pain anyway)

Posted on April 30, 2004 12:48 PM | #

10. Wayne said:

“I’ll put my hand up and admit I’m one of the dozen or so people that use XHTML, and serve it with the correct MIME type, application/xhtml+xml after sniffing if the user agent is able to accept it in the first place.”

Actually, Jonathan, there are at least 62 of us. I guess you’d make number 63, since I don’t currently see your site on the list.

Posted on May 1, 2004 03:03 PM | #

12. Andrei Herasimchuk said:

Using a strict doctype encourages developers who validate their documents to remove inline formatting. A transitional doctype allows

font style elements.

While there defintiely are some real advantages to this that can open new possiblities due to clean separation of form and content, the above is in and of itself not a clear-cut advantage, as yuo assume it is.

That chip you have on your shoulder is pointless. This isn’t second grade. Get over yourself.

Posted on May 8, 2004 10:56 AM | #

14. Andrei Herasimchuk said:

Which doc has better markup?

I can only assume you either too young to see the point past your chutzpah, or that you have a hard time with simple logic problems.

“Better markup” is not in and of itself a clear advantage. What you have failed to do, which is at the core of Keith’s post, is describe in what ways “better markup” will help the world.

Will developers be able to create new programs that analyze and reuse markup because the code is easy to traverse? Can code use the DOM to do new and interesting things? Can new applicaiton sbe built that take advantage of bette rmarkup that is nearly impossible to do with crappy markup?

Even if you think these points are obvious, you should seriously consider that they are not. Then maybe you’ll get the point.

Posted on May 10, 2004 02:17 PM | #

16. Mitch said:

Interesting articles on XHTML. I’m new to this field but like you, already finding issues in the CSS styles between agents. I don’t think your original issue is with XHTML strict or compliance but really with the old problem we have all had….the same old CSS and formating differences between browsers.

Its actually a bit more complex than who’s browser is right in XHTML strict, and the “correct” formatting designs you seek using CSS are not always based on standards compliance, or correct logic by the W3C.

You used divs and CSS ‘border’ attributes and saw some problems. Since table elements are supported and compliant with XHTML strict DOCTYPE (as I understand it), you can also switch divs to tables and use them for your page formatting and use alternative styles like ‘border-collapse’ and such to control margins. This may fix your issue. Using tables, though I know we are trying to get away from them, makes my point here, that you can use an older technology (tables and CSS-based heights) in a newer stricter doctype (xhtml strict) to address an old cross-browser problem (heights of content blocks-tables), that is actually worse when using a newer technology (divs and CSS). Plus the browser (IE) that displays that newer technology correctly (divs with borders and 100% heights) is actually using non-standards compliant calculations (for the block-level heights of elements)! (confused yet???)

Im guessing your original issue was the changes in a bottom border property both between browsers using divs and then between standard and “quirks” mode. The issue is really with how IE and Mozilla-based browser interpret height as CSS, I think, as Mozilla uses the current viewport height (compliant with w3c standards, which in my opinion are a poor interpretation of ‘height). While IE uses the old logic and pushes vertical spacing (including borders, as they take up vertical height calculations) correctly in a visual sense and is non-compliant with standards, actually allows you to create true div cells of empty content that stretch to match of the greater of the current content or the viewport (browser window) height. This makes IE’s interpretation actually more viable visually for designers, even if not standards based, xhtml strict or not. At first I thought this ‘height’ CSS issue wasnt a big deal, but turns out its huge if you are trying to designs sites that stretch properly between the big players (IE and Mozilla), and creates something of the same issue seen in table heights, much like found between old Netscape 4.8 and IE 5. In that case Netscape wanted to collapse all tables to the minimum height required to hold the content by default, even though height for tables was set to 100% in certain scenarios. Funny because new Netscape 7 seems to have fixed that (so I thought), but actually in its tables in html 4 standards, again uses the 100% viewport height, and does not extend and divs or tables with 100% height beyond that pixel value. Content breaks out of the div and scrolls out of the page in the case of divs with height 100% and html and body tag’s heights style set to ‘100%’, as recommended by some people. To make a long story short, seems that whether you use XHTML strict and check standard versus quirks, or which browser you try, IE uses the non-standard CSS rules for formatting div height values, but which are visually (logically) correct, while Netscape/Mozilla uses the correct standard but is visually illogical, as setting height 100% on anything should allow for extending that height if the content extends beyond it. In Mozilla, your choice is either collapse the content box to the minimal avilable content if its less that available viewport height, but let my styled divs stretch as needed past that, or stretch the empty divs like IE to 100% of the height (viewport), setting html to height:100%, and if content extends beyond 100%, let the content spill over the container box. I bet your border between divs is wrapped up in that issue. Thats what I see happening….misinterpretation of height ranges….and obviously a CSS issue. Solve that problem, and all the xhtml and xslt technologies become much more viable on all platforms for the design world, even if partial support exhists for parts of the xhtml standard, which I honestly dont think is the case. It certainly is in CSS. thats were both the w3c and the browsers need to have a meeting of the mind. Until then we are stuck using middleware CSS/XHTML technologies like transitional, I hate to say!

To finally answer your question, YES, YES, YES…use XHTML, in any form and go to strict if you can. The point of it is, your code will be reusable as xml later for other purposes, turns your site pages into a data island of sorts because of the xml and the separation of content, and later you can repurpose that content using xsl if needed. Makes content managemnet easier, and makes it ‘possible’ now to deliver that page to other devices and agents. But the issue is visuals….can you live without target and name tags and image maps in XHTML strict or will your client complain? Will you have people in a GUI editing the structure and adding html and not able to validate as they work (yes, for most of us!). Can you live with, in some cases, severe formatting differences in your CSS between agents? When I evaluate all that I have realized that I still have to use some old proprietary html tags to address the buggy CSS compliance and so have XHTML Transitional left on my plate, hate to say. I think thats what most of us are doing and so I guess you are as well.

sorry for the long-winded post :o) - MS

Posted on July 2, 2004 02:16 AM | #