Dear WebKit Open Source Project
Regarding you recent blog post: “Understanding HTML, XML, and XHTML”.
Before we begin, I’d like to point out that I did read the whole thing. I didn’t just scroll to the bottom to see how it ended. However, this letter is about one of the last things in the post. I’ll get to the rest of it some other time. Here’s what this letter is about:
The Safari 2.0 version of WebKit had a special quirk for treating script elements with the self-closing syntax (like this:
) as if they were actually properly closed. At the time Gecko-based browsers like Firefox had a similar quirk, and we decided to copy it for compatibility with particular web sites. However, future versions of Firefox will remove this quirk, and this kind of behavior is going to be explicitly outlawed by future standards that build on HTML, such as Web Apps 1.0. So we will probably remove this quirk in future versions of WebKit as well. Unfortunately, HTML relying on this parsing quirk has crept into a lot of Dashboard widgets. A WebKit that didn’t support this quirk would lead to broken widgets – the external script code would never run.
I am strongly opposed to this course of action for the following reasons:
- All of Apple’s own widgets (at least all the ones I checked) have this style of self-closing script tags. However, Apple has the advantage of being able to transparently update all of their widgets and the user would be none the wiser. So I guess I have to start over.
Starting over.
- As the article implies, many, if not most third-party widgets use the self-closing script tag. Now, I think it’s important to point out that this style of tag is fully legal under XHTML 1.0. However, this post pointed out the fact that WebKit (and other rendering engines) doesn’t really care what the doctype says. They only care about the MIME type, which 3rd party widget developers have no way of controlling. So, this would basically be punishing widget developers for following standards.
- Who, exactly, would this course of action help. What would you gain? All you’d get is a lot of pissed off developers and even more disgruntled users because their widgets no longer function properly. So what’s the point?
- Corollary to #2: what do you lose by not changing this? Seriously, what’s it to you if you allow valid XHTML to work the way it’s supposed to, even if it’s in a text/html document.
Update: It was pointed out to me in the comments that widget developers can control this by simply using a ‘.xhtml’ extension, instead of a ‘.html’ extension.
Another problem I have with this: there’s no explicit timeframe. If it’s updated with Leopard then 1) I can understand them not giving us dates because of the NDA and 2) it will allow us to give users a more coherent reason as to why users need to update their widgets. However, if this is changed with 10.4.8… I don’t even want to go there. The real complaint here: not enough info to developers.
So please, WebKit, look over all these points and rethink this decision.
Warm regards,
Galen D. W.
A concerned widget developer.
This entry was posted on Wednesday, September 20, 2006 at 08:06 PM and is filed under Development, Mac, Widgets. You can subscribe via RSS 2.0 feed to this post's comments. You can comment below, or link to this permanent URL from your own site.
Wednesday, September 20, 2006 at 08:46 PM
With regards to point 1: “However, this post pointed out the fact that WebKit (and other rendering engines) doesn’t really care what the doctype says. They only care about the MIME type, which 3rd party widget developers have no way of controlling. So, this would basically be punishing widget developers for following standards”.
Widgets are served from the local file system, and as you note there is no way to dictate the MIME type of a file on disk. When reading files from the local file system the file extension is used. I belive a “.html” extension is treated as text/html, while “.xhtml” is treated as application/xml+xhtml. If you wish to use XHTML, simply use the .xhtml file extension.
It is somewhat amusing that you claim “this would basically be punishing widget developers for following standards”. The point of Maciej’s post on the WebKit blog is to inform developers that WebKit is now going to follow one part of the standards more closely, while in the past it allowed non-standard behaviour. It would be more accurate to say that WebKit would be punishing developers for *not* following standards.
Addressing point 3: you lose compatibility with Firefox. Compatibility is one of the core goals of all web browsers.
“what’s it to you if you allow valid XHTML to work the way it’s supposed to, even if it’s in a text/html document” — if you want to use valid XHTML, use it in an XHTML document. The XHTML specification, and Maciej’s blog post, is quite clear on the MIME type issue. XHTML 1.0 content that is served as text/html must be compatible with HTML, according to Appendix C of the XHTML 1.0 specification. It also states that XHTML 1.1 may not be served as text/html.
Maciej links to three posts by leading members of the web standards world, all of which support the position that the WebKit blog post discusses. I have little doubt that the WebKit team has put a lot of thought into this decision, and are only making a change that can break third-party widgets because they see a real need to do it.
– Mark Rowe
Wednesday, September 20, 2006 at 09:25 PM
As for point 1: Thanks for pointing that ‘.xhtml’ thing out to me. I guess that kinda takes the bite out of that argument. However, what I meant by “punishing widget developers for following standards” was that it under XHTML the self-closing script tag is legal.
One further thing that I probably should’ve put in the post: I intend to follow these guidelines from now on. It just may be a problem for users who wake up one day and suddenly half their widgets don’t work. I only hope that this blog post informed developers of the change with enough lead time to get updates out the door.
Monday, November 12, 2007 at 08:54 AM
I am sorry about you that I write here, but I there have really found that that is necessary for me
Real Estate