I like reading A List Apart. The site taught me how to do a lot of things, but sometimes they get it wrong. This time some of the details are missing, in my opinion. In The Accessibility Hat Trick: Getting Abbreviations Right the author talks about both forward and backwards compatible markup. XHTML 2.0 no longer contains (it does not deprecate it, it simply is not there) an acronym element so we should use abbr instead. But hey, that is not supported by Internet Explorer. There are various things wrong here. For one, Internet Explorer does not support XHTML. I believe they are not planning to support it in the next version either, but that is not entirely clear as they talked about application/xml+xhtml which is not really a registered media type. Then again, they also mix up the XML Declaration with the XML Prolog. The other thing is that in XHTML 2.0 all elements are not backwards compatible. They are in a completely different namespace according to the current plan which will lead to duplicate semantics and all that. It also means that abbr is not abbr. Or should I say xhtml:abbr is not xhtml2:abbr? (This is the case per the Architecture of the World Wide Web, Volume One W3C Recommendation and I think that Namespaces in XML also supports this view.)
What also is important is that XHTML 2.0 can still change a lot and that trying to be forward compatible with it is a waste of your time. The other article in this ALA issue, Web 3.0 by Jeffrey Zeldman was fun. Comments appreciated.
I think people are overreacting. This kind of stuff is really interesting if you're building websites for the academic purpose of it, but people are trying to do be academic (use the right element) and practical (it must work in IE and browsers like JAWS). I think there's no way to do all that and also have nice source-code.
I think it's good that there are people talking about the integration of all these things, but it shouldn't be published on a site which says: "For people who make websites".
I think they have strange interpretations of Accessibility; Level Triple-A, it is not actually achievable under 99% of cases. Most people who claim Triple-A don't know what they are talking about and totally misinterpreted the Guidelines, or just use the Checklist.
Also which part of the WCAG 2.0: Until WCAG 2.0 advances to W3C Recommendation, the current and referenceable document is Web Content Accessibility Guidelines 1.0 (WCAG 1.0), published as a W3C Recommendation May 1999.
....
XHTML 2.0:
This document is the seventh public Working Draft of this specification. It should in no way be considered stable, and should not be normatively referenced for any purposes whatsoever.
Did they misunderstand; I am wondering if the entire article just theoretical?
Good points Chris and Robert. Referencing and quoting working drafts without acknowledging they are just working drafts is harmful. Especially on such websites. Could have said that myself.
I think Microsoft is planning on supporting xHTML with the 'text/html' mime type. Thus xHTML will just be HTML with the acknowledgement of alternative syntax. It's a bit naff I know, but never the less it is a reality. Personally I don't see XHTML coming to fruition within the next five years at the very very least.
I will however continue to use xHTML syntax because I feel very comfortable using it and my code is a bit cleaner. It's a bit naff I know.
Personally, I don't mind if I have to write HTML or XHTML. They're both designed for writing documents. A lot of people really seem to care if you use an <ul> or a <p> for a navigational list. Well, big surprise, most of the times it really doesn't matter. Why would you choose one of them? Because it's better for blind people? The only reason I'm trying to be precise is maintainability and search engines. I can imagine values an h1 as more important than an h2, but I personally don't think that it discriminates between an ul- or a p-element.
I personally don't care if MS is going to support XHTML and application/xhtml+xml and all that stuff. Really, what's the difference? What does the developer or the end-user gain over the current situation? Sure, you've got nice XML documents, but I personally think you can use any fileformat, as long as you use a certain structure and convention. Most of the times, if you use a text-based format, it's quite easy to convert to another format.
Btw, Anne, you need to change the 2005 into 2006 in your template. Happy new year!
Using acronym and abbr properly in the xhtml namespace is perfectly fine and fully forward compatible in that future browsers will recognize the namespace and all the tags that are included in it. Whereas, if you want to port your code to xhtml2, then that's a different story.
We need to get our terminology right. Unfortunately it seems to me that due to the fact that most people still deliver xhtml with text/html, they don't see the difference between html and xhtml and they think that xhtml and xhtml2 are just different in their semantics. They're in fact two different xml languages. In reality, by using the proper namespaces, everything stays neatly in its own "space" and nothing breaks in the future.
Rant over.
I thought you'd complain about XHTML again, but you're not. I'm glad. I also agree with what you're saying here. You can't be forward and backward compatible when it comes to crossing over namespaces, because they're always two different elements no matter what their element name is. I should point out that this isn't neccessarily a bad thing. (pssst... XSLT and Xquery make the underworld fun!)
XHTML 2.0 no longer contains an acronym element so we should use abbr instead.
Yep, and I consistently do so. Real reason: people never get the ‘when to use <acronym>’ thing right anyway, and as for me, I find it easier to simply not worry about it anymore. Which happens to coincide with the reason that it’s taken out of XHTML2.
Amidst the 99% of the web pages that do not use <abbr> or <acronym> at all, I think I can live with my website not offering such functionality to IE users either. ;)
~Grauw
XHTML 1.1 and 2 are indeed quite naff themselves...focusing on theory more than practical issues. My money's on html 5.
ALA's always been up and down...and och it gives pendantic people something to talk about in cases like this.
Laurens, I assume you noticed that acronym is not an option here (for leaving a comment) either.
To quote Egor Kloos:
A lot of people really seem to care if you use an <ul> or a <p> for a navigational list.
Most discussions about semantics fail to remember that websites are primarily written for people. For instance, text marked up with <i> has largely the same effect as text marked up with <em>. The only people that really mind are the people that go around viewing other people's source (like me).
I use <ul>'s for my navigation lists because they show up nicely when the stylesheets aren't there, not only because it's semantic (though of course I care about that too).
Most discussions about semantics fail to remember that websites are primarily written for people. For instance, text marked up with <i> has largely the same effect as text marked up with <em>. The only people that really mind are the people that go around viewing other people's source (like me).
I bet blind people, for instance, care too.
I use <ul>'s for my navigation lists because they show up nicely when the stylesheets aren't there, not only because it's semantic (though of course I care about that too).
Yes, that's a good reason to use them, I think. We shouldn't use html to represent semantic data, I think we should use something like RDF. HTML is for documents, and documents are most of the times the poorest form data is coming in. So don't try to capture the whole world in HTML.
Anne,
Great work, but it's application/xhtml+xml, not application/xml+xhtml per the IANA's Application Media-Types.
That is exactly what I (implicitly) pointed out. What is your point? :-)
(Oops.)
In that case, just great work.
I bet blind people, for instance, care too.
Are there browsers for the blind that present em and i differently?
Are there browsers for the blind that present
emandidifferently?
I don't know. Probably. em might be read with a different voice tone or similar in a speech based browser, while i maybe won't. It was just an example, and I tried to illustrate the fact that not only "source-viewers" will care.
Mark Kenny
I use <ul>'s for my navigation lists because they show up nicely when the stylesheets aren't there, not only because it's semantic (though of course I care about that too).
And what about the element <menu>? I think, this is the most semantic element for navigation lists and it has the same effect as <ul>. And you don't need to use id=".." (<ul id="navigation">) if you have one navigation list.
HTML is for documents, and documents are most of the times the poorest form data is coming in.
RDF is probably better if you are talking about pure data delivery. But saying that HTML is for documents is a bold statement considering the whole web, with all it's interactivity is driven by it. Google search is, to all intents and purposes, a pure application. I wouldn't call it a document. Also consider the efforts by OpenOffice and MS to standardize open document formats... Why would they do that if HTML was so suitable for that purpose?
Personally i think HTML is not for documents, but for views. It's not the model in a model-view-controller pattern sense. Who stores the HTML itself? No one does. It's generated on the fly based on data in the database, user permissions, preference settings etc. An HTML page is a view on underlying data, customized to the person receiving that view. That's the power of it.