[consulting] XHTML doctype

Tue Mar 10 06:04:35 UTC 2009

Thanks Troy and Brian for your help with Firebug. I see it now.

I have to admit, this whole topic leaves me a bit confused as to  
current best practice. If I look at some "big" sites, I'm not seeing  
any consensus. Drupal.org is XHTML, apple.com isn't. Then I see that  
the new Microsoft site is XHTML... ? Ironic? And on your referenced  
site (http://www.webdevout.net/articles/beware-of-xhtml#broken_xhtml)  
about half or more of the "big-name" web-standards people are doing  
xhtml served as html...

Like Ng said, clients want XHTML, but as you have pointed out,  
probably all based on a misunderstanding.

I don't really fear apache (or the like) changing something drastic  
without some kind of backwards-compatibility option. So pragmatically,  
with a site design life-span of certainly no more than 5 years (more  
likely 2-3), does it really matter that much?

Jeff

On 10/03/2009, at 2:21 PM, Brian Vuyk wrote:

> 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
>>
>
> _______________________________________________
> consulting mailing list
> consulting at drupal.org
> http://lists.drupal.org/mailman/listinfo/consulting