Re: Can Browsers Attempt to Render Broken XHTML?

Kynn Bartlett wrote:

>
> On Thursday, June 26, 2003, at 09:46 AM, Tim Roberts wrote:
>
>> How can they be losing presumed accessibility benefits if the 
>> document is:
>>
>> Well structured, with style seperated from content.
>
>
> That's not an advantage of XHTML over HTML.  (An HTML 4.01 could very
> well separate content from presentation.) 


OK, I didn't say anything about advantages over HTML.  Refer to what you 
were replying to above to see this.

>
>
>> Equipped to apply any of the operations that could be applied to XML 
>> on the
>> server side to accommodate alternative browsing devices.
>
>
> Except that if something is sent as text/html -- and not as
> application/xhtml+xml -- what justification is there for using
> XML tools on it?  It's just HTML, right?  Even if you coded it
> as XHTML...


Yes, agreed. You can easily reformat your valid XML (XHTML) document 
into HTML and in many different ways, including
a total overhaul of your content if you wish. And all without altering 
the original document. Is this bad?

>  
> (You'd have to make a bad assumption, and then be prepared to handle
> SGML-based HTML if you're accepting text/html and assuming it's
> XML -- so you lose the benefits of XHTML here.)
>
>> Possibly lighter on bandwidth if CSS/XHTML combination is used 
>> correctly.
>
>
> No, there's nothing about XHTML+CSS that makes it lighter on bandwidth
> than HTML+CSS.  In fact, XHTML is often going to be slightly "heavier"
> than HTML:
>
>      <br>        four characters
>      <br />      six characters

Convenient example.

>
>> It seems like occasionally this discussion is veering towards an 
>> anti-XHTML
>> stance just for the sake of it.
>
>
> Um, nope.  I'm trying to make several points here:
>
> 1.  The "benefits of XHTML" presented are generally just the
>     benefits of XHTML _or_ HTML (such as your "separation of
>     content and presentation" argument).  In these cases,
>     XHTML and HTML are equal.

OK.

Why is it then that many HTML sites contain much less seperation of 
content and style than XHTML?

>
> 2.  There are a number of complications with using XHTML
>     (such as the mimetype and the possibility of poorly formed
>     documents breaking entirely) which are not well-known even
>     to proponents of XHTML.

Not really. How to present XHTML is well documented on the internet. It 
is forward thinking. You don't need to serve the correct mimetype at 
this time, but you can easily adjust that in the future.

>
> 3.  Thus, XHTML 1.0 may actually be a less reasonable choice than
>     HTML 4.01 for general use on the Web.  It certainly is not
>     a slam dunk that XHTML is superior.

I don't think it is less reasonable. HTML and XHTML are very close in 
what they do. It is *my opinion* that XHTML has a slight edge. More like 
a pleasent dribble to the hole and a gentle roll off the palm into the 
net. (sorry I am english, I hope my basketball terminology works). My 
argument was never about a gaping difference. Just what I feel from 
experience has made development slightly easier for me.

>
> The notion that XHTML is boon to accessibility has to be carefully
> considered.  Many will take it for granted because it's the
> latest-and-greatest; it may be the latest, but when it comes to
> accessibility considerations, it's not necessarily the "greatest. 


>
>
> Does that make me "anti-XHTML for the sake of it?"  Gosh, I hope
> not.

Nor am I anti-HTML. I just prefer XHTML. Is that hard to swallow. Gosh I 
guess so.

>
> --Kynn
>
> -- 
> Kynn Bartlett <kynn@idyllmtn.com>                     http://kynn.com
> Chief Technologist, Idyll Mountain                http://idyllmtn.com
> Author, CSS in 24 Hours                       http://cssin24hours.com
> Inland Anti-Empire Blog                      http://blog.kynn.com/iae
> Shock & Awe Blog                           http://blog.kynn.com/shock
>
>

Received on Thursday, 26 June 2003 16:50:37 UTC