[consulting] XHTML doctype

Tue Mar 10 04:21:16 UTC 2009

Jeff,

Quick comment, in the previous email, I wrote 'application/html' a lot 
when I should have written 'text/html'. Oops!

To check with firebug, just click on the 'Net' tab in the Firebug 
window. You may need to click a checkbox to enable 'Net' at this point 
for drupal.org (or whatever site).

The 'Net' tab should now load up with all requests that your browser 
made to display the page you are looking at. The top one should be 
'drupal.org'. If you click to expand it, you should see both the 
Response Headers and Request Headers. In the Response Headers, look for 
the 'Content-Type' line.

You will see that for Drupal.org, it is 'text/html', which means that it 
is treating what it gets back from the server not as XHTML, but as 
regular good old tag soup HTML.

I should just clarify that writing a document that validates as XHTML, 
but serving it as HTML isn't that bad from a practical perspective at 
this point in time - the XHTML syntax is (by necessity) understandable 
by the HTML parser. It's more or less a restricted subset of what HTML 
allows with different comment strings. However, it is the *wrong* way of 
doing it. That is, it is misusing a standard. And while it works for 
now, it's not guaranteed to be future proof.

Let's say there was a new release of Apache that adjusted the content 
type based on the declared DTD, or something along those lines. 
Immediately, millions of sites would break. Sticking to the established, 
documented standards helps 'future proof' your work to a certain degree.

Brian

Jeff wrote:
> Thanks Brian, a most interesting topic.
>
> Firstly, a silly question — would you mind telling me how to use  
> Firebug to examine the response? I looked everywhere and didn't find  
> the "application/html" you mentioned.
>
> Second, since sites such as drupal.org are written in XHTML,  
> presumably they too are not being served with an xhtml mimetype or IE  
> would die on them, as indeed would any browser if a node had invalid  
> markup (quite possible, since d.o allows user-submitted HTML markup to  
> a degree sufficient to break XHTML structure).
>
> Jeff
>
> On 10/03/2009, at 12:09 PM, Brian Vuyk wrote:
>
>   
>> Jeff,
>>
>> Perhaps the quickest way to tell what content type the server uses  
>> when sending a page is to use firebug and examine the response. For  
>> the site in question, it shows 'application/html' instead of  
>> 'application/xhtml+xml' as would be required to trigger the XML  
>> parser XHTML is supposed to use. The content-type sent by the server  
>> is what most major browsers (Firefox, Opera, Safari, and possibly  
>> IE) use to determine how to interpret the content - not the DTD.
>>
>> As long as your browser is treating the site as application/html,  
>> it's just tag soup, and you don't get to take advantage of any of  
>> the functionality unique to XHTML. In short - your document is  
>> parsed as normal HTML, not XHTML.
>>
>> XHTML does have some validation issues that can be a pain, including  
>> the escaping you need to do in certain circumstances, such as when  
>> dealing with arguments in linked URLs.
>>
>> XHTML, when parsed as XHTML instead of HTML, is not tolerant of  
>> mistakes in the 'well-formedness' of the document. Any mistakes,  
>> such as mismatched tags, invalid elements or invalid usage, will  
>> cause the parser to fail with an error message to the screen. Now,  
>> just wait until a client edit his own content and tries to wrap a  
>> <h1> with <strong> tags. Suddenly, the page they were working on  
>> only shows a big nasty error message.
>>
>> Internet Explorer does not support XHTML without some nasty non- 
>> standard hacks. I am not sure whether IE8 handles this correctly -  
>> it would surprise me if they did. There is a semi-functional   
>> workaround: http://www.w3.org/MarkUp/2004/xhtml-faq#ie
>>
>> I think http://www.webdevout.net/articles/beware-of-xhtml is a very  
>> good read for any web developer considering writing a page in XHTML.  
>> It does a good job of describing both the benefits and pitfalls of  
>> using XHTML.
>>
>> Regards,
>>
>> Brian
>>
>>
>>
>>
>>
>> Jeff wrote:
>>     
>>> Did either of you actually turn Javascript off and reload the site?
>>> I'd have thought it fairly common knowledge that Superfish menus
>>> degrade without JS, relying on the semantic and validating <ul>
>>> foundations of the underlying menu markup to do the work when only  
>>> CSS
>>> is available.
>>>
>>> George, if you can put together a site like the demo in 10 minutes or
>>> so, please get in touch with me asap, we can make you rich :)
>>>
>>> I'm not saying this demo site or the theme are earth shattering and I
>>> have no connection with fordrupal themes whatsoever (never heard of
>>> them or their founders before), nor do I have the need to ever buy a
>>> theme, but honestly George, it feels like you have other reasons for
>>> being harsh on this.
>>>
>>> Anyway, of more interest to me is Brian's xhtml comment — is this a
>>> server config issue? How do you know it's not sending it as
>>> application/xhtml+xml? I thought the browser looked at the doctype in
>>> the markup?
>>>
>>> "Future validation headaches" — are you refering to html 5? Isn't it
>>> realistic to think that xhtml is going to be supported until half the
>>> people on this list have retired, given the ongoing infestation of
>>> Internet Explorer and its associated lack of speed of improvement? In
>>> other words, isn't the web moving so slowly (because of IE and the
>>> w3c) that xhtml is going to be around for many years yet? Drupal.org
>>> and Garland are both xhtml.
>>>
>>> Jeff
>>>
>>>
>>> On 09/03/2009, at 11:46 PM, Brian Vuyk wrote:
>>>
>>>
>>>       
>>>> That is a fairly attractive theme visually. However, George makes  
>>>> some
>>>> good points about it w.r.t the JS menus.
>>>>
>>>> Why XHTML? Your server isn't sending the site as application/xhtml
>>>> +xml,
>>>> so the user is getting none of the benefits of XHTML with all the
>>>> future
>>>> validation headaches.
>>>>
>>>> Brian
>>>>
>>>>         
>>> _______________________________________________
>>> consulting mailing list
>>> consulting at drupal.org
>>> http://lists.drupal.org/mailman/listinfo/consulting
>>>
>>>       
>> _______________________________________________
>> consulting mailing list
>> consulting at drupal.org
>> http://lists.drupal.org/mailman/listinfo/consulting
>>     
>
> _______________________________________________
> consulting mailing list
> consulting at drupal.org
> http://lists.drupal.org/mailman/listinfo/consulting
>   