[consulting] XHTML doctype
Jeff
jeff at marmaladesoul.com
Wed Mar 11 00:11:58 UTC 2009
Very enlightening indeed; thanks for raising it and for following
through with answers to all my questions :)
Jeff
On 10/03/2009, at 4:48 PM, Brian Vuyk wrote:
> You are starting to see the ongoing debate ;p
>
> We have enough breaks from standardization already on the internet.
> Adding the wrong DTD to a HTML document offers absolutely no benefits
> over well-formed HTML.
>
> If you are using the XHTML DTD simply because you like the W3Cs
> validator to ensure matching tags etc., just override the doctype when
> doing the validation. There is a nice little box there expressly for
> that purpose - just change it from 'auto-detect' to 'XHTML 1.0
> Transitional', and leave the HTML DTD in your document.
>
> It's not worth breaking from the standard for the type of reasons I
> usually see in this debate. They shouldn't have to always build in a
> 'backwards compatibility' mode for people who don't want to put the
> effort into conforming to a standard - that defeats the whole
> purpose of
> creating standards in the first place. It's kind of the 'Microsoft
> mentality'. We need to make all our websites jump hoops for IE because
> MS found it easier to ignore the standards as well.
>
> Here's a challenge: next time a client asks for his site to be done in
> XHTML, deliver it in XHTML like they ask for, and see if they enjoy
> the
> debugging. Or at least explain to them exactly what XHTML is, and why
> they probably don't actually want it.
>
> Brian
>
>
>
> Jeff wrote:
>> 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
>>>
>>
>> _______________________________________________
>> 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
More information about the consulting
mailing list