Did you just sleep through the day in elementary school when all the other kids learned how to make adjectives? Or do you maybe need a GUI with shiny buttons and help text before you can figure out basic rules of the English language?
Intuit (intiuit), v. Also -ite. 1776. [f. L. intuit-, intueri; see INTUITION.] 1.trans. To instruct. 2. a.intr. To receive knowledge by direct perception 1840. b.trans. To know by intuition 1858. Hence Intuitablea.
I just sat here for a minute cycling through applications which have location fields, and do you know, Ctrl+L focused or displayed the location field in every single one? It worked in Firefox, which isn't a GNOME app. It worked in Nautilus in spatial mode. It worked in everything that offers a location field, so I'm content calling it the standard keyboard shortcut for that action.
And that means it's intuitable. The only intuitive interface, as is often pointed out, is the nipple, and most of its users suck so you probably don't want one of those.
Only ctrl+c/v are widely used shortcuts that have been around a LONG time and were taught through their association with buttons and menu links. Furthermore they speed up the process of doing their respective tasks by removing the need to clickedy clack with the mouse.
Ctrl+L has been around for as long as I can remember. Ditto a bunch of other shortcuts: Ctrl+S saves, Ctrl+O opens a file, Ctrl+Q quits, Ctrl+W closes the window/tab, Ctrl+A selects the contents of the window/field...
These shortcuts work, consistently, in every single application. That means that they're intuitable -- "Ctrl+Foo did this in the other programs, so it'll probably do it in this one too" -- and hence usable.
And I would argue at your definition of "basic features"; I could whinge about how I can't type Perl-compatible regexes in a tcsh script which will execute in the address bar, but then I'd hardly be talking about "basic features" anymore. Many users simply do not use features like tab-completion or even typing the names of files, and so for them an address bar is redundant and confusing. For the minority who want the feature, it's still available using a standard and intuitable keyboard shortcut of the environment, so I fail to see how there's a usability problem here.
Sorry, but this isn't just about GIMP. It's about all GTK apps.
And it's just fine. Think about a different but somewhat analagous case: copy/paste in the GNOME DE. It's always possible to copy selected text to the clipboard by right-clicking and selecting "Copy", and to paste by right-clicking and selecting "Paste"; this is a feature of all GNOME applications. Similarly, it's always possible to copy with Ctrl+C and paste with Ctrl+V.
Would an application which does not provide explicit toolbar controls for these operations be unusable because users must either know the shortcut or know to check the context menu? No; the interface to copy/paste is consistent across all applications, so once it's learned (either from an application with explicit intstructions, or from a manual), no UI is needed to explain it.
Similarly, a text-based address bar can always be obtained in any GNOME dialog or application which offers one, by pressing the key sequence Ctrl+L, even when no UI is provided to notify the user of this. Thus the dialog is still highly usable.
This is what's known in Usability 101 as the difference between "intuitive" and "intuitable"; Google those terms for more.
What's a sig? You shouldn't use specialized terms like that in a forum where not everyone will understand it, or if you do you should explain what they mean. For example:
Take your sig (your "sig", short for "signature", is a short, sometimes funny, sometimes self-descriptive bit of text which you can enter on your user preferences page, and which is appended to each and every comment you post) for example...
That's how you should have responded. But no. You'd almost think that this was a site geared toward programming nerds or something, from the way you were slinging the jargon around...
The code does do something. It's a wrapper around the actual library, making it accessible within PHP. Or would you prefer that every single user of PHP had to write his/her own wrappers to do this? That'd be an awful lot of wheels reinvented.
There is no difference in requirements to purchase a.com,.net, or.org domain, so why should one have a different fee schedule from another?
They're introducing this because VeriSign's contract to administer.net runs out next year; they can take advantage of the bidding process for that contract to insert the fee. And they may do the same when the.com contract runs out in 2007.
Disclaimer: More recently, I have migrated to OS X as my primary platform, and I use very little cross platform software here since it rarely integrates well with the rest of the system or follows the HIGs. Windows and *NIX users are easier to please with cross platform software since programs that don't fully conform to the platform's UI guidelines are the norm.
Or not. Having HIG and following them are two very different beasts, and I'd be willing to bet that GNOME, at least, does a better job of following its own HIG than does Apple.
I think.mobi may actually be the first "useful" domain I've heard so far. If you're on your cell phone and want to be sure that the web site you want to access will be tailored to your needs with a mobile browser, just ensure it is a.mobi domain. I suppose it's just as easy to add "mobile." to the beginning of your site for a mobile compatible page, but this BORDERS on useful.
Imagine a world where every device has its own TLD. Your mobile phone browses only in.mobi, your laptop only in.laptop, your desktop only in.desktop. And within those domains your OS matters -- run Linux on your desktop? Go to foo.linux.desktop. Got a Powerbook? Instead go to foo.mac.laptop for our site. That way you know the page you're looking at will be tailored to your needs, right?
Except this is stupid. CSS already includes a media type for PDAs and phones, with the explicit purpose of defining 'low-res' styling for those devices. So why the hell can't we use the standard we've got and try to keep our pages device-independent?
As it turns out, Sir Tim Berners-Lee doesn't like.mobi for this very reason. But what would he know? He only invented that "web" thing, which never went anywhere anyway. I'm sure that ICANN's lackeys know better.
Right now it doesn't. There's absolutely zero benefit to ESPN.com being marked up in XHTML. Which is why I initially asked whether HTML 4.01 had suddenly been erased from all memory, because it's easier to do right.
Also, no spec says it shouldn't take 60 seconds for your home page to load or that you shouldn't start a popup storm on the user's system. Your preference for hidden protocol details over an optimal user experience makes you seem a bit quacky here. You might want to rethink your position.
You might want to not put words in my mouth. There's a difference between standards and best practices; standards say nothing on the subject of progressive rendering, but best practices say it's a good thing.
Yes, IE sucks. However, you seem to be suggesting that it suck more by misadvertising it's features.
No, I want it to either A) stop claiming it supports XHTML or B) start supporting XHTML.
Not at all. Your client applicaiton can still treat the page as XML no matter what the MIME type is. The type is a useful hint, that's all.
While we're at it, let's just ignore the Content-TYpe header entirely and try to guess what the file is by its first few bytes. Yeah, that's a real great idea, I wonder why nobody's ever tried that before...
Is there some part of XHTML that is invalid HTML? This seems unnecessary. Not that neccessity would enter into your thinking.
Yes, there is. For example, consider the XHTML line break tag, <br/> . There are two ways for an SGML-based HTML parser (e.g., an HTML 4.01 parser) to interpret this:
It can be interpreted as an error and ignored.
It can be interpreted as a line break followed by a literal greater-than sign.
So either your page is invalid, or it displays something different from what you intended. Those are some appetizing options, aren't they?
IRC's always been good enough for me. I still use AIM to talk to friends who won't make the switch, but most folks know they're far more likely to reach me on IRC than on any "IM" network.
You miss the forest from the trees. IE doesn't support XHTML, So, IE is actually correctly not accepting a MIME type that it can't support. The fact that other browsers lie about their XHTML support makes it easier for developers, but it is not necessarily "correct".
Mozilla and others do actually have XHTML support; serve them XHTML with the proper MIME-type and they parse as XML, applying all of XML's constraints. You do lose progressive rendering in Mozilla and that's a bug, but no spec anywhere says that browsers have to support that feature. Internet Explorer, on the other hand, has a validating XML parser to draw on (MSXML), but for some reason won't put it to use when it encounters an applicatin/foo+cxml media type.
Ultimately it's just a MIME type, nothing more. The abstract benefits of XHTML* are all still just as valid even if for practical reasons it's served with the wrong type.
The benefits of XHTML are things like being able to use an XML parser, which you can't do if you're sending your XHTML as text/html. They're things like embedding other XML languages in your HTML content, which you can't do if you're sending your XHTML as text/html. In fact, you lose the eXtensibility of XHTML when you don't serve it as XML, since then you can't use any of XML's extensibility.
The only thing you can do is pretend, before you serve it to a user-agent, that it's XML. Which I guess makes some people happy, but when you go and break the spec on the journey to the client it does tend to bug me a bit. If you're gonna do all that crap on the server-side, use XSLT at the last step to transform to HTML 4.01 Strict or something so at least you'll be sending what you claim you're sending.
I appreciate this conversation and the opinions you've shared, I am learning that not everyone is a supporter of the W3C and their current direction (this is new to me). I am thinking I've had a jaded view through the last year or two because I'm a daily visitor to sites such as Mezzo Blue, Stop Design, A List Apart, etc...
I read all of those sites, too, and I'm read several standards working-group mailing lists. I don't dislike the W3C and I don't dislike standards; in fact, quite the opposite. I just know that in the particular case of XHTML it's not as cut-and-dried as people often make it out to be, and there are a lot of people who simply are not doing XHTML correctly. And if we start out with people not following the standard, we end up in the same place we did with traditional HTML -- browsers will have to work around the parts of the spec people are ignoring, and start accepting certain errors because they're everywhere. That's a Very Bad Thing in my book, so I want people to get it right from the start this time around.
Oh, and by the way: not only is your site not XHTML, it's not valid, it doesn't include a DOCTYPE, and it doesn't specify a character encoding. You might want to look into that, because if it were XHTML and you were serving it as XHTML, there's not a browser on earth that could display it.
Sorry I just don't agree that the XHTML standard is bad. I take it that you don't consider the ESPN and Red Hat (there are many more) sites either "real-world" enough or they are "doing it wrong"?
I'm not saying that XHTML is bad. I'm saying that doing XHTML properly can be a nightmare. And no, ESPN and Red Hat and many more don't do it right; go back to Evan Goer's X-Philes list and read the criteria. Or read my by-no-means comprehensive guide to some of the things you have to do just to switch from HTML 4.01 to XHTML 1.0, and remember that these languages are element-for-element identical.
Consider the HTML 4 spec, which is syntactically difficult to decipher. After writing XHTML pages for several years now (thanks, I'm not a newbie to the web standards world) it's impossible to go back to HTML 4 and have it actually make any sense. For every open tag, you need a closing tag, except if it's horizontal line or a line break or an input or a meta tag or an image or...
And in XHTML you still don't have closing tags, you just have a closing slash on the opening tag; how is that any less confusing? And by the way, that closing slash is fine if you're doing XHTML and serving it with an XML or XHTML MIME-type, but if you serve it as text/html you're gonna give conformant SGML parsers fits (Google "SGML SHORTTAG" sometime). And there's nothing in HTML 4.01 that says you can't close your paragraphs and list items and lots of other elements... I close them because it's good coding practice no matter what version of HTML I'm using. You can do that too if you like.
It's just ugly and difficult to parse. By using XHTML, any XML parser can read a document. It's simple, if there's an open tag, close it. If there's a stand-alone tag, it better have a self-closing end. That is just one small piece of what I like about XHTML.
You've obviously never met the Yellow Screen of Death. And if you seriously believe that parsing XML is as easy as "open the tag, close the tag", I recommend you hang out on XML-related mailing lists for a while. Or just read Sam Ruby's weblog.
Insisting that if a webpage meets the XHTML Strict spec, it doesn't work in IE is just pure ignorance. Yes, typically developers have to put a little extra work into their CSS to get their pages looking as good in IE as they do in Mozilla/Firefox/Netscape/Opera/Safari/etc...
No, it's not ignorance. Go read the article by Ian Hickson I linked in my last comment; if you won't take my word, maybe you'll listen to somebody who's worked on both Mozilla and Opera and who leads the WHAT-WG. This is not about CSS bugs or quirks or rendering differences. This is about the simple fact that XHTML, according to the W3C, should be served with the MIME-type application/xhtml+xml. No version of Internet Explorer ever released on any platform anywhere is capable of dealing with that MIME-type. If you give it a page marked as application/xhtml+xml, IE will prompt you to download the page or specify another application to handle it; it literally does not know what to do with such a document.
Now, with XHTML 1.0 you are allowed to continue serving as text/html so long as you meet the HTML Compatibility Guidelines outlined in Appendix C of the XHTML 1.0 spec. Best practice here is to use some form of content negotiation to send application/xhtml+xml to user-agents which support it. However, XHTML 1.1 makes no provision of any sort for this; XHTML 1.1 is to be served as application/xhtml+xml, which means that there is no such thing as a conformant XHTML 1.1 document which will display in Intern
The "target" attribute still exists in the Transitional and Frameset versions of HTML 4.01 and XHTML 1.0. XHTML 1.1 does not have a Transitional or a Frameset version; however, it is a modularization of XHTML which means that the same functionality can be easily re-introduced. For example, Jacques Distler has produced a page using the "target" attribute which is valid against an extended XHTML 1.1 DTD. This is one of the major selling points of XML-based markup and having true XML parsers as clients.
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?
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., MarkPilgrim, AnnevanKesteren) 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.
Sorry, this is incorrect. For better or worse, according to the W3C, opening windows via JavaScript is the only proper way to create new windows. In fact, the target attribute has been removed from standard HTML since at least HTML 4.01 strict.
Sorry, this is incorrect. The target attibute for anchors still exists in the Frameset versions of the HTML 4.01 and XHTML 1.0 specifications. AN for better or worse, HTML 4.01 and XHTML 1.0 Transitional are still standards published by the W3C. Sure, people who want the absolute latest, newest, shiniest, flashiest, whiz-bangiest version can use XHTML 1.1 Strict (which gets you... er... ruby tags, and that's about it), but it's also currently impossible to build a site which follows the XHTML 1.1 spec and is usable in any version of Internet Explorer.
Well since the target attribute of the anchor link is not part of the XHTML 1.1 Strict standard, web developers who *are* actually concerned about standards are required to use Javascript to perform the pop-up behavior.
Two things:
When did HTML 4.01 and XHTML 1.0 Transitional stop being "standards"?
Show me a "real-world" site that does XHTML 1.1 correctly.
Sorry, 18 months is not an acceptable life cycle. I simply cannot afford to spend the time to reinstall operating systems on a hundred different servers every year and a half.
So how exactly were you affording to use RH products before? And if you're that hung up on it, why not use one of the repackaged RH distributions like White Box?
Slashdot Mirror
So sorry, you fail it.
Did you just sleep through the day in elementary school when all the other kids learned how to make adjectives? Or do you maybe need a GUI with shiny buttons and help text before you can figure out basic rules of the English language?
From the SOED:
You fail it, so sorry.
I just sat here for a minute cycling through applications which have location fields, and do you know, Ctrl+L focused or displayed the location field in every single one? It worked in Firefox, which isn't a GNOME app. It worked in Nautilus in spatial mode. It worked in everything that offers a location field, so I'm content calling it the standard keyboard shortcut for that action.
And that means it's intuitable. The only intuitive interface, as is often pointed out, is the nipple, and most of its users suck so you probably don't want one of those.
Ctrl+L has been around for as long as I can remember. Ditto a bunch of other shortcuts: Ctrl+S saves, Ctrl+O opens a file, Ctrl+Q quits, Ctrl+W closes the window/tab, Ctrl+A selects the contents of the window/field...
These shortcuts work, consistently, in every single application. That means that they're intuitable -- "Ctrl+Foo did this in the other programs, so it'll probably do it in this one too" -- and hence usable.
And I would argue at your definition of "basic features"; I could whinge about how I can't type Perl-compatible regexes in a tcsh script which will execute in the address bar, but then I'd hardly be talking about "basic features" anymore. Many users simply do not use features like tab-completion or even typing the names of files, and so for them an address bar is redundant and confusing. For the minority who want the feature, it's still available using a standard and intuitable keyboard shortcut of the environment, so I fail to see how there's a usability problem here.
And it's just fine. Think about a different but somewhat analagous case: copy/paste in the GNOME DE. It's always possible to copy selected text to the clipboard by right-clicking and selecting "Copy", and to paste by right-clicking and selecting "Paste"; this is a feature of all GNOME applications. Similarly, it's always possible to copy with Ctrl+C and paste with Ctrl+V.
Would an application which does not provide explicit toolbar controls for these operations be unusable because users must either know the shortcut or know to check the context menu? No; the interface to copy/paste is consistent across all applications, so once it's learned (either from an application with explicit intstructions, or from a manual), no UI is needed to explain it.
Similarly, a text-based address bar can always be obtained in any GNOME dialog or application which offers one, by pressing the key sequence Ctrl+L, even when no UI is provided to notify the user of this. Thus the dialog is still highly usable.
This is what's known in Usability 101 as the difference between "intuitive" and "intuitable"; Google those terms for more.
What's a sig? You shouldn't use specialized terms like that in a forum where not everyone will understand it, or if you do you should explain what they mean. For example:
That's how you should have responded. But no. You'd almost think that this was a site geared toward programming nerds or something, from the way you were slinging the jargon around...
The code does do something. It's a wrapper around the actual library, making it accessible within PHP. Or would you prefer that every single user of PHP had to write his/her own wrappers to do this? That'd be an awful lot of wheels reinvented.
They're introducing this because VeriSign's contract to administer .net runs out next year; they can take advantage of the bidding process for that contract to insert the fee. And they may do the same when the .com contract runs out in 2007.
Yes, because Apple always follows guidelines on that stuff.
Or not. Having HIG and following them are two very different beasts, and I'd be willing to bet that GNOME, at least, does a better job of following its own HIG than does Apple.
Imagine a world where every device has its own TLD. Your mobile phone browses only in .mobi, your laptop only in .laptop, your desktop only in .desktop. And within those domains your OS matters -- run Linux on your desktop? Go to foo.linux.desktop. Got a Powerbook? Instead go to foo.mac.laptop for our site. That way you know the page you're looking at will be tailored to your needs, right?
Except this is stupid. CSS already includes a media type for PDAs and phones, with the explicit purpose of defining 'low-res' styling for those devices. So why the hell can't we use the standard we've got and try to keep our pages device-independent?
As it turns out, Sir Tim Berners-Lee doesn't like .mobi for this very reason. But what would he know? He only invented that "web" thing, which never went anywhere anyway. I'm sure that ICANN's lackeys know better.
Right now it doesn't. There's absolutely zero benefit to ESPN.com being marked up in XHTML. Which is why I initially asked whether HTML 4.01 had suddenly been erased from all memory, because it's easier to do right.
You might want to not put words in my mouth. There's a difference between standards and best practices; standards say nothing on the subject of progressive rendering, but best practices say it's a good thing.
No, I want it to either A) stop claiming it supports XHTML or B) start supporting XHTML.
While we're at it, let's just ignore the Content-TYpe header entirely and try to guess what the file is by its first few bytes. Yeah, that's a real great idea, I wonder why nobody's ever tried that before...
Yes, there is. For example, consider the XHTML line break tag, <br /> . There are two ways for an SGML-based HTML parser (e.g., an HTML 4.01 parser) to interpret this:
So either your page is invalid, or it displays something different from what you intended. Those are some appetizing options, aren't they?
The real old schoolers just change the motd to leave a message for the next guy who uses the machine.
No, the old-schoolers use IRC.
IRC's always been good enough for me. I still use AIM to talk to friends who won't make the switch, but most folks know they're far more likely to reach me on IRC than on any "IM" network.
Mozilla and others do actually have XHTML support; serve them XHTML with the proper MIME-type and they parse as XML, applying all of XML's constraints. You do lose progressive rendering in Mozilla and that's a bug, but no spec anywhere says that browsers have to support that feature. Internet Explorer, on the other hand, has a validating XML parser to draw on (MSXML), but for some reason won't put it to use when it encounters an applicatin/foo+cxml media type.
The benefits of XHTML are things like being able to use an XML parser, which you can't do if you're sending your XHTML as text/html. They're things like embedding other XML languages in your HTML content, which you can't do if you're sending your XHTML as text/html. In fact, you lose the eXtensibility of XHTML when you don't serve it as XML, since then you can't use any of XML's extensibility.
The only thing you can do is pretend, before you serve it to a user-agent, that it's XML. Which I guess makes some people happy, but when you go and break the spec on the journey to the client it does tend to bug me a bit. If you're gonna do all that crap on the server-side, use XSLT at the last step to transform to HTML 4.01 Strict or something so at least you'll be sending what you claim you're sending.
I read all of those sites, too, and I'm read several standards working-group mailing lists. I don't dislike the W3C and I don't dislike standards; in fact, quite the opposite. I just know that in the particular case of XHTML it's not as cut-and-dried as people often make it out to be, and there are a lot of people who simply are not doing XHTML correctly. And if we start out with people not following the standard, we end up in the same place we did with traditional HTML -- browsers will have to work around the parts of the spec people are ignoring, and start accepting certain errors because they're everywhere. That's a Very Bad Thing in my book, so I want people to get it right from the start this time around.
Oh, and by the way: not only is your site not XHTML, it's not valid, it doesn't include a DOCTYPE, and it doesn't specify a character encoding. You might want to look into that, because if it were XHTML and you were serving it as XHTML, there's not a browser on earth that could display it.
I'm not saying that XHTML is bad. I'm saying that doing XHTML properly can be a nightmare. And no, ESPN and Red Hat and many more don't do it right; go back to Evan Goer's X-Philes list and read the criteria. Or read my by-no-means comprehensive guide to some of the things you have to do just to switch from HTML 4.01 to XHTML 1.0, and remember that these languages are element-for-element identical.
And in XHTML you still don't have closing tags, you just have a closing slash on the opening tag; how is that any less confusing? And by the way, that closing slash is fine if you're doing XHTML and serving it with an XML or XHTML MIME-type, but if you serve it as text/html you're gonna give conformant SGML parsers fits (Google "SGML SHORTTAG" sometime). And there's nothing in HTML 4.01 that says you can't close your paragraphs and list items and lots of other elements... I close them because it's good coding practice no matter what version of HTML I'm using. You can do that too if you like.
You've obviously never met the Yellow Screen of Death. And if you seriously believe that parsing XML is as easy as "open the tag, close the tag", I recommend you hang out on XML-related mailing lists for a while. Or just read Sam Ruby's weblog.
No, it's not ignorance. Go read the article by Ian Hickson I linked in my last comment; if you won't take my word, maybe you'll listen to somebody who's worked on both Mozilla and Opera and who leads the WHAT-WG. This is not about CSS bugs or quirks or rendering differences. This is about the simple fact that XHTML, according to the W3C, should be served with the MIME-type application/xhtml+xml. No version of Internet Explorer ever released on any platform anywhere is capable of dealing with that MIME-type. If you give it a page marked as application/xhtml+xml, IE will prompt you to download the page or specify another application to handle it; it literally does not know what to do with such a document.
Now, with XHTML 1.0 you are allowed to continue serving as text/html so long as you meet the HTML Compatibility Guidelines outlined in Appendix C of the XHTML 1.0 spec. Best practice here is to use some form of content negotiation to send application/xhtml+xml to user-agents which support it. However, XHTML 1.1 makes no provision of any sort for this; XHTML 1.1 is to be served as application/xhtml+xml, which means that there is no such thing as a conformant XHTML 1.1 document which will display in Intern
The "target" attribute still exists in the Transitional and Frameset versions of HTML 4.01 and XHTML 1.0. XHTML 1.1 does not have a Transitional or a Frameset version; however, it is a modularization of XHTML which means that the same functionality can be easily re-introduced. For example, Jacques Distler has produced a page using the "target" attribute which is valid against an extended XHTML 1.1 DTD. This is one of the major selling points of XML-based markup and having true XML parsers as clients.
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.
So why not switch everything over to one of those versions?
As others are reporting, Links, Elinks and Lynx do not appear to be vulnerable. I'll test w3m-emacs here in a minute...
Sorry, this is incorrect. The target attibute for anchors still exists in the Frameset versions of the HTML 4.01 and XHTML 1.0 specifications. AN for better or worse, HTML 4.01 and XHTML 1.0 Transitional are still standards published by the W3C. Sure, people who want the absolute latest, newest, shiniest, flashiest, whiz-bangiest version can use XHTML 1.1 Strict (which gets you... er... ruby tags, and that's about it), but it's also currently impossible to build a site which follows the XHTML 1.1 spec and is usable in any version of Internet Explorer.
Two things:
So how exactly were you affording to use RH products before? And if you're that hung up on it, why not use one of the repackaged RH distributions like White Box?