Update: Good news, Matt Sweeney from Yahoo! answered that they are in the process of rolling in XHTML support.
This issue should thus rapidly become an old story!
That’s probably well known but I have been surprised to see that the Yahoo! UI Library doesn’t support XHTML or rather that it supports only XHTML documents that pretend to be HTML!
If you use YUI with XHTML documents served as they should be served with a application/xhtml+xml media type, you’ll see strange errors pop up. This is because YUI uses the HTML DOM inner property to insert HTML elements which names are uppercase and HTML entities which are not built-in in XHTML.
It appears that the issue has already been mentioned in the ydn-javascript mailing list that supports the YUI and a fix has even been proposed in July by Laurens Holst.
For whatever reason, the YUI team which is usually pretty reactive on bug reports doesn’t seem to be interested by this issue and there has been no answer to this suggestion.
The only answer (so far) to my own post on the same subject came from another user and is interesting to read:
I think you’re confused. No versions of IE (even IE7) support this, for example. http://www.w3.org/People/mimasa/test/xhtml/media-types/results
In other words, I must be wrong if I care about a web standard that isn’t implemented in Internet Explorer!
I wouldn’t go as far as Karl Dubost who has decided to server all his pages with an application/xhtml+xml media type (link in French) without bothering upsetting Internet Explorer users to whom he kindly advises to use another browser, but it is quite easy to setup a web server so that XHTML pages are served with the right media type to compliant browsers and as text/html to other browsers…
Easy, except that YUI doesn’t work any longer and that you would have similar issues with other scripts such as those from Google Ads.
What I find most disappointing is that YUI seems to get pretty much everything right except for this « detail ». For instance, I like very much the way you can, with the YUI, produce clean XHTML code that will display correctly in any browser (including text based browsers) and animate this page for recent graphical browsers. This feature means that, with sufficient care, you can use the YUI to produce accessible applications which happens to be an issue for most Web 2.0 applications.
Let’s hope that the YUI team will change their mind and decide that, after all, being conform to the standard isn’t optional!
Hey Eric,
I lost track of this conversation (been working on that problem recently. Would be interesting to gain your thoughts and insight if you have a moment: http://groups.google.com/group/llup/browse_thread/thread/c9b8ccee7f4e4dee) and in doing a quick blog round-up, realized I had left this comment so am just now reading your follow-up.
With this disclaimer in mind: You’ve got a very valid point! Any progress on the Yahoo! « call-back »?
Someguy,
According to Webster, the term « standard » designates something « which is established as a rule or model by authority, custom, or general consent » and I think that we can say that W3C recommendations are established by an authority!
If you don’t agree that the W3C is an « authority » or if you restrict the term « standard » to designate only rules established by common usage (which we often call « de-facto standards) then you can say that the W3C publishes notes and recommendations that may or may not become standards :) …
Anyway, none of these definitions mean that there cannot be several standards in the same domain and HTML and XHTML are both (and equally) standards.
That being said, I was also refering to the IETF RFC 3236 that defines the
application/xhtml+xmlmedia type when I spoke of standards. The YUI raises errors when you use this specific one…Eric
David,
A fork shouldn’t be necessary! Yahoo! answered my mail to say they were « in the process of rolling in XHTML support » which is a very good news IMO.
A part from that, I understand your points but I think that it doesn’t mean that we should accept this attitude! In this specific case, I am not asking to lower the support of Internet Explorer and making sure that applications developed to be conform to the current standards do work with other browsers. That just seems like the right thing to do!
Eric
Whoa! Where’d all my paragraphs go? Sorry for the text cluster! I swear before I clicked Post there were lines in between suggesting a break in the thought flow.
Eric, I understand your frustration, but the one thing you have to keep in mind is the fact that regardless of the growing usage of more standards compliant browsers on the market, IE6 still holds a HUGE lead in comparison to its nearest competitor: Firefox. Furthermore, IE5.x still commands a significant amount of marketshare as to be deemed necessary to support. Therefore, developing using IE as the lowest common denominator, regardless of whether someone cares about web standards or not, market factors force your hand to do things a certain way.
That said, the market is changing, just not as fast as us geeks would like it to.
Of course, I do recognize your point regarding implementing different document types for different browsers. The problem with this, however, is that most web developers and admins don’t and/or won’t go to the effort of learning how to do this, or why it is important, and therefore force us all to live in a state in which products such as YUI are forced to adhere, once again, to the lowest common denominator for the simple reason of a products adoption rate and related support. If you’re desire is to saturate a market, as opposed to serve the needs of a niche market, you have to design your product around what the practices of the most common web developer and server admin.
While it seems backwards to us, the reality is that the reason IE is the way it is has nothing to do with MSFT not desirous to implement standards that we hacker-types recognize as better. In most cases they recognize them as better as well, but like Yahoo! they are forced to write their software in a way that matches the habits of the more common webdev and admin.
In this regard, if Yahoo! wants to penetrate the webdev market with a product, they have to do so based on the understanding that if they implement more than one way to do something, and one of the other ways requires a particular doc-type setting on the server that goes against what the majority of web servers will serve as the default document type, too many webdevs and admins will simply not make the effort or do not understand how to do what seems trivial to the rest of us, and therefore must play by their rules.
Of course, as I was reminded by Alex Bosworth a while back when I asked him if he knew whether or not Google would accept updates to the AJAXSLT code base from the community, there is an alternative given the fact that the code is OSS — Create a fork.
I must be fairly tired because I did click on Karl’s link from an IE browser (company policy… *sigh*) and of course I got the expected Save As dialog box. I knew it would happen though and I still did it.
Need some sleep.
Hello,
I agree with your sentiment. However, when you write « conform to the standard » (in your last paragraph), it is my opinion that this is less than completely accurate or explicit.
Two points:
Regardless, I again express my agreement with your sentiment.
Thanks, with warm regards.
Hi,
Any 2007 updates on this?
It’s been a while… does yui_2.2.0a.zip work well with XHTML documents?