Comments on: Dear WebKit Open Source Project http://galendw.wordpress.com/2006/09/20/dear-webkit-open-source-project/ By Galen D. W. Student. Programmer. Mac head. Mon, 31 Mar 2008 10:24:35 +0000 http://wordpress.com/ hourly 1 By: Bestcatalog http://galendw.wordpress.com/2006/09/20/dear-webkit-open-source-project/#comment-1119 Bestcatalog Mon, 12 Nov 2007 14:54:24 +0000 http://galendw.wordpress.com/2006/09/20/dear-webkit-open-source-project/#comment-1119 I am sorry about you that I write here, but I there have really found that that is necessary for me <a href="http://www.himer.us" rel="nofollow">Real Estate</a> I am sorry about you that I write here, but I there have really found that that is necessary for me
Real Estate

]]> By: Galen D. W. http://galendw.wordpress.com/2006/09/20/dear-webkit-open-source-project/#comment-6 Galen D. W. Thu, 21 Sep 2006 03:25:04 +0000 http://galendw.wordpress.com/2006/09/20/dear-webkit-open-source-project/#comment-6 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. 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.

]]> By: bdash http://galendw.wordpress.com/2006/09/20/dear-webkit-open-source-project/#comment-5 bdash Thu, 21 Sep 2006 02:46:20 +0000 http://galendw.wordpress.com/2006/09/20/dear-webkit-open-source-project/#comment-5 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 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

]]>