- From: <tina@greytower.net>
- Date: Fri, 27 Jun 2003 00:23:30 +0200 (CEST)
- To: w3c-wai-ig@w3.org
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. -- - Tina Holmboe Greytower Technologies tina@greytower.net http://www.greytower.net/ [+46] 0708 557 905
Received on Thursday, 26 June 2003 18:23:54 UTC