W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > April to June 2003

Re: Can Browsers Attempt to Render Broken XHTML?

From: Tim Roberts <tim@wiseguysonly.com>
Date: Fri, 27 Jun 2003 00:56:12 +0200
Message-ID: <3EFB7A0C.5040304@wiseguysonly.com>
To: tina@greytower.net, w3c-wai-ig@w3.org

You are in no way mistaken by what I wrote.

As developers we are sometimes forced to use interim solutions. I 
believe that may even appear in the WAI somewhere; I am sure you can 
find it.
The tells us XHTML is a successor to HTML, and I use interim solutions 
with XHTML. My only crime here is trying to defend standards.

I will also refer you and others to what I said originally and what 
appears in this message:

XHTML does contain much inherent accessibility

Nothing wrong with that.

Are my sites inaccessible because I use interim solutions. No. This is 
nitpicking.











tina@greytower.net wrote:

>On 26 Jun, Tim Roberts wrote:
>
>  
>
>>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.
>>    
>>
>
>  Correct example. All elements which, today, are 'open ended' should,
>  in XHTML, be closed. That *will* increase the bandwith.
>
>
>
>  
>
>>Why is it then that many HTML sites contain much less seperation of 
>>content and style than XHTML?
>>    
>>
>
>  Because IT and in *particular* the Web field contain by far the
>  largest amount of self-taught, delusional, shitty poor authors any
>  professional industry have ever seen ?
>
>  Granted, harsh words. But I'm damned if I ever saw a kid with a 3
>  weeks course in Frontpage ever cut it in any *other* professional
>  field.
>
>
>
>  
>
>>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.
>>    
>>
>
>  ...
>  
>  Now hold it for just one moment. Are you saying that we should
>  strive towards standards compliance in what we do, but *ignore parts
>  of the standard at leisure* ?
>
>  What on earth makes THIS mess any better than the one we have, barely,
>  just left ? What, *exactly*, is the difference between:
>
>    "Oh, I don't need to serve my documents with the proper content type
>     today, since no browsers CARE about it"
>
>  and
>
>    "Oh, I don't need to use the LINK element to create document
>     collections today, since no browsers CARE about it"
>
>  then ?
>
>  Am I utterly mistaken in that you wrote:
>
>   "XHTML does contain much inherent accessibility.  The very first 
>    thing standards based development addresses is the issue of making our
>    documents available to the largest number of web users regardless of
>    the client software they use. Accessibility may I remind you is far
>    from just an issue of physical disability."
>       Tim Roberts in <20030625132800.M27123@wiseguysonly.com>
>
>   Because if I am *not* mistaken, then how on Earth are you going to
>   reconcile "standards based development" with "you don't need to
>   serve the correct mime-type at this time" ?
>
>   IF XHTML is better for accessibility than HTML - everything else
>   being equal - because it FORCES an author to be standards-compliant,
>   then it follows that the document needs to be served up according to
>   the same standard - which means it won't *work* for users of Lynx and
>   IE, among others.
>
>   Frankly, I'm getting abit afraid of the dark here.
>
>  
>
Received on Thursday, 26 June 2003 18:54:08 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 19 July 2011 18:14:10 GMT