Domain: goer.org
Stories and comments across the archive that link to goer.org.
Comments · 7
-
Re:It's definately possible.
If you can use javascript to help with some more complex positioning (especialy relative resizing and such), XHTML 1.1 really isn't bad at all.
Um. Yes. Yes, it is. XHTML 1.1 is an utterly useless format, but not for reasons having anything to do with CSS; per the W3C's notes on media types for XHTML, XHTML 1.1 should be served with the MIME-type application/xhtml+xml, and never with the MIME-type text/html. But Internet Explorer, even IE7, does not understand this MIME-type (though, to be fair, they've only had seven years to get this right; I figure by the time we have flying cars and robot maids, IE will handle the XHTML MIME-type just fine) and will display its generic "I don't know what to do with this file, do you want to download it?" dialog.
XHTML 1.0 does have provisions for being served as text/html, but there are deep issues with that which most people who use XHTML are blissfully unaware of (hint: all modern web browsers treat XHTML-as-text/html as an unrecognized language, and kick into "tag soup" mode to parse it); if they ever switched to the XHTML MIME-type, or even to an XML MIME-type like application/xml (which works in IE, and is permitted for XHTML but not the recommended thing to use), they'd be in for some nasty surprises.
XHTML, at this point, is basically dead in the water; hordes of people switched to it because it was the latest and greatest, but did so with no understanding of how XML actually works or the constraints created by reformulating HTML in XML. It's only the fact that none of them are actually serving it as XHTML -- because everybody just goes ahead and uses text/html -- that's saved them from their ignorance thus far. Even the W3C seems to have reluctantly accepted this, with Tim Berners-Lee recently announcing that there will be a shift from the "forget HTML, XHTML is the only way forward" mentality to a revival of the HTML working group and a series of gradual refinements and improvements of HTML until (if ever) the world is really ready for XHTML. Which could be a while; a couple years ago, Evan Goer took a sampling of 119 sites which claimed to use XHTML, and tested for valid, well-formed XHTML served using content negotiation to send the proper MIME-type to browsers which understood it. Of the 119 sites -- cherry-picked to include a large concentration of professional web designers and developers, who really ought to know how to do this right -- only one was found to conform, and 74% failed the first step of checking the W3C validator. In the two years since, he's managed to find about a hundred sites on the entire Web which are correctly doing XHTML. 99 sites in two years isn't a rosy picture.
-
Re:Blink Support?
Yeah, poor IE users will never be able to see The Page of The Damned in all its glory.
Source -
Re:Blink Support?
Yeah, poor IE users will never be able to see The Page of The Damned in all its glory.
Source -
Re:Once again, why needless use of Javascript is B
Are you trying to imply that the thousands of XHTML Strict websites out there produced by web/graphic designers, web developers, bloggers, and those who are supporting the standards are doing something wrong?
Yup. Check out Ian Hickson's "Sending XHTML as text/html Considered Harmful" for a quick primer on what most sites that do XHTML are doing wrong. Check out Evan Goer's list of "X-Philes" for a list of the very few sites which get it right, and his purge of sites from that list for an indication of how easy it is to go wrong even after you've initially gotten it right.
As for HTML generally not producing good markup and being "too loose", I hate to break it to you but XHTML 1.0 and HTML 4.01 are element-for-element identical; the only difference between the two is that one is an SGML application and one is an XML application. And when you serve XHTML 1.0 as "text/html" (e.g., when you do XHTML the way ESPN and others do) you don't gain any of the strictness benefits of XML. And the only thing XHTML 1.1 does on top of that is deprecate a couple more things and add modularization and ruby support, so I'm really not sure where all the "good markup" would come from in a transition to XHTML. Plus there's no reason to believe that serving XHTML 1.1 as "text/html" is conformant, so if you use 1.1 you either break the spec or you shut out IE. Likewise, switching to an XHTML DOCTYPE and using XML syntax doesn't magically confer accessibility on a page; it's just as easy to write a horrid, bloated, table-based images-for-everything page in XHTML as it is in HTML 4.01.
I suspect that you're making a common mistake among people who've just discovered web standards: you're confusing XHTML with good markup and best practices (check out Molly Holzschlag on what standards are and aren't). Anyway, it's quite possible to write beautiful, clean, accessible, semantically rich HTML 4.01 with separation of content from presentation; after all, it's got the same set of tags and attributes as XHTML 1.0, so if you can do it in one you can do it in the other just as easily. And when you consider that serving valid, well-formed XHTML according to the spec can be a nightmare at times, it's no surprise that even "gurus" of the standards world (e.g., Mark Pilgrim, Anne van Kesteren) have gone back to or recommended sticking with HTML 4.01 unless you really need one of the features gained by an XML-based HTML.
And lest you continue to think I'm some sort of skeptic or enemey of web standards, well, every site I've built in the past three years (basically, since I discovered there was such a thing as a "web standard") has been valid, accessible, and CSS-based. I just know from experience that valid markup and stylesheets are one part of the equation, and there are an awful lot of those "best practices" that aren't ever published in a spec from the W3C or anyone else.
-
Re:Once again, why needless use of Javascript is B
Are you trying to imply that the thousands of XHTML Strict websites out there produced by web/graphic designers, web developers, bloggers, and those who are supporting the standards are doing something wrong?
Yup. Check out Ian Hickson's "Sending XHTML as text/html Considered Harmful" for a quick primer on what most sites that do XHTML are doing wrong. Check out Evan Goer's list of "X-Philes" for a list of the very few sites which get it right, and his purge of sites from that list for an indication of how easy it is to go wrong even after you've initially gotten it right.
As for HTML generally not producing good markup and being "too loose", I hate to break it to you but XHTML 1.0 and HTML 4.01 are element-for-element identical; the only difference between the two is that one is an SGML application and one is an XML application. And when you serve XHTML 1.0 as "text/html" (e.g., when you do XHTML the way ESPN and others do) you don't gain any of the strictness benefits of XML. And the only thing XHTML 1.1 does on top of that is deprecate a couple more things and add modularization and ruby support, so I'm really not sure where all the "good markup" would come from in a transition to XHTML. Plus there's no reason to believe that serving XHTML 1.1 as "text/html" is conformant, so if you use 1.1 you either break the spec or you shut out IE. Likewise, switching to an XHTML DOCTYPE and using XML syntax doesn't magically confer accessibility on a page; it's just as easy to write a horrid, bloated, table-based images-for-everything page in XHTML as it is in HTML 4.01.
I suspect that you're making a common mistake among people who've just discovered web standards: you're confusing XHTML with good markup and best practices (check out Molly Holzschlag on what standards are and aren't). Anyway, it's quite possible to write beautiful, clean, accessible, semantically rich HTML 4.01 with separation of content from presentation; after all, it's got the same set of tags and attributes as XHTML 1.0, so if you can do it in one you can do it in the other just as easily. And when you consider that serving valid, well-formed XHTML according to the spec can be a nightmare at times, it's no surprise that even "gurus" of the standards world (e.g., Mark Pilgrim, Anne van Kesteren) have gone back to or recommended sticking with HTML 4.01 unless you really need one of the features gained by an XML-based HTML.
And lest you continue to think I'm some sort of skeptic or enemey of web standards, well, every site I've built in the past three years (basically, since I discovered there was such a thing as a "web standard") has been valid, accessible, and CSS-based. I just know from experience that valid markup and stylesheets are one part of the equation, and there are an awful lot of those "best practices" that aren't ever published in a spec from the W3C or anyone else.
-
Re:A quote:
What are you gaining by using XHTML if you're just jumping through more hoops to make it work? You can only serve documents as text/html while they meet the compatability profile (does the W3C validator check that you followed *that*?), which basically tries to keep it looking to browsers like malformed but parseable HTML 4; and that's exactly how they handle it. How is that better than having them handle well formed HTML 4.01 Strict sent with the proper MIME type with no extra complications dealing with Accept headers and content types?
For the record, I once bothered to do it properly. HTML 4.01 Strict to most clients; XHTML 1.1 to clients which claim to accept it. Costs a bit of string matching, a small XSLT and a lot of testing.
The benefit? Uh, well, I got on the X-Philes and learnt some stuff about XHTML; namely that it's not really worth using in most circumstances. -
Re:I can help
there is no point using CSS without using XHTML, IMHO.
If you can come up with a single persuasive reason why anyone should use XHTML 1.0 over HTML 4.01 I'll be impressed. The standards are practically identical, except XHTML introduces concerns over stylesheet linking (you should be using <?xml-stylesheet .. ?> rather than <link>), content type (application/xhtml+xml, *not* text/html), content negotiation (client doesn't report XHTML support in Accept:? The right thing to do is to send it.. HTML 4!), breaking browsers which properly support HTML+SGML (you know <br /> means something completely different in HTML, right?), and an almost complete lack of support in IE (what's there is is mainly a hack, just like serving XHTML as text/html to more powerful browsers).
The only compelling reason I can think of is that XML's nicer to parse (might as well provide an Atom feed or so rather than encourage parsing your XHTML) and has a bunch of nasty API's and languages to manipulate it (DOM, XSLT, etc). Be honest; how many sites actually use an XSLT pipeline to generate content? Those that do can either just emit HTML (which XSLT supports anyway), or really should add the extra complication to do either; XHTML only doesn't make a lot of sense.
And yes, I got on The X-Philes, and was once the only site on there which actually linked stylesheets in properly. I can't say it was worth it beyond sheer geek appeal*
* (Which means I'll probably do it again in future sites, bah ;)