<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Versioning, Compatibility and Standards</title>
	<atom:link href="http://webkit.org/blog/155/versioning-compatibility-and-standards/feed/" rel="self" type="application/rss+xml" />
	<link>http://webkit.org/blog/155/versioning-compatibility-and-standards/</link>
	<description>All about WebKit development</description>
	<lastBuildDate>Sat, 21 Nov 2009 23:00:28 -0800</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.5</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: kgretton</title>
		<link>http://webkit.org/blog/155/versioning-compatibility-and-standards/comment-page-1/#comment-23866</link>
		<dc:creator>kgretton</dc:creator>
		<pubDate>Wed, 30 Jan 2008 11:42:00 +0000</pubDate>
		<guid isPermaLink="false">http://webkit.org/blog/155/versioning-compatibility-and-standards/#comment-23866</guid>
		<description>I think this sums up the Internal IT Department issue quite well.  However, the use of the additional modes and version identifiers will simply server to continue the problem.

Any developer designing web content today needs to understand web standards or remain where they are today.  Therefore, IE8 should only have two modes: Standards-compliant mode and Quirks mode - much in the same way that WebKit does (with a few internal workaround modes no doubt).  The Quirks mode should be no different between IE7 and IE8, IEx.  ie. the only mode that is updated and fixed going forwards is the web standards mode.

What does this achieve?  Well all of the Bob&#039;s will be forced to fix their existing sites and content (which they are being forced to do anyway) to work with IE 7 either by updating the content to use standards (unlikely) or removing a DOCTYPE that should not be there and fixing any other issues..  IE 7 is frozen in time and no new functionality added, no rendering changes introduced for any version thereafter.

IE 8&#039;s web standards mode can then rapidly progress in the same way as all the other browsers - particularly WebKit - are doing without needing to worry about breaking quirks mode.  Then we can get monthly bug fixes and enhancements to the IE web standards compliant modes and regular (say annual) major engine updates without breaking the old quirky stuff.</description>
		<content:encoded><![CDATA[<p>I think this sums up the Internal IT Department issue quite well.  However, the use of the additional modes and version identifiers will simply server to continue the problem.</p>
<p>Any developer designing web content today needs to understand web standards or remain where they are today.  Therefore, IE8 should only have two modes: Standards-compliant mode and Quirks mode &#8211; much in the same way that WebKit does (with a few internal workaround modes no doubt).  The Quirks mode should be no different between IE7 and IE8, IEx.  ie. the only mode that is updated and fixed going forwards is the web standards mode.</p>
<p>What does this achieve?  Well all of the Bob&#8217;s will be forced to fix their existing sites and content (which they are being forced to do anyway) to work with IE 7 either by updating the content to use standards (unlikely) or removing a DOCTYPE that should not be there and fixing any other issues..  IE 7 is frozen in time and no new functionality added, no rendering changes introduced for any version thereafter.</p>
<p>IE 8&#8217;s web standards mode can then rapidly progress in the same way as all the other browsers &#8211; particularly WebKit &#8211; are doing without needing to worry about breaking quirks mode.  Then we can get monthly bug fixes and enhancements to the IE web standards compliant modes and regular (say annual) major engine updates without breaking the old quirky stuff.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: mbear</title>
		<link>http://webkit.org/blog/155/versioning-compatibility-and-standards/comment-page-1/#comment-23859</link>
		<dc:creator>mbear</dc:creator>
		<pubDate>Mon, 28 Jan 2008 15:53:15 +0000</pubDate>
		<guid isPermaLink="false">http://webkit.org/blog/155/versioning-compatibility-and-standards/#comment-23859</guid>
		<description>From the original &lt;a href=&quot;http://alistapart.com/articles/beyonddoctype&quot; rel=&quot;nofollow&quot;&gt;Beyond Doctype&lt;/a&gt; article:

&quot;In an ideal world, of course, all specifications would be perfect from the get-go, and their implementation in user agents would be immediate and flawless. In a slightly more down-to-earth version of an ideal world, browser vendors would immediately integrate regularly updated standards into new user agents—and users would have instant access to the latest version of those browsers without having to lift a finger.&quot;

When I read that I thought &quot;Doesn&#039;t my antivirus software do this every day?&quot; Each day at 2 AM it downloads an updated database of virus information and automatically installs it. Maybe the thing to do for Microsoft (and others) is to create a &quot;standards database&quot; that can be updated every so often automatically by the application.

In fact this could easily function as an improvement of or extension to the Firefox/IE/Opera update mechanism that alerts me that a new version is available. Just tell me that an updated &quot;DTD entry&quot; is available and tell me to install it. Or even better, have the browser automatically pull it down and install it.

(yes, this is pretty much a copy of another comment I posted at A List Apart and Ars Technica and the IE Blog. The more times I say it the better chance someone will see it.)</description>
		<content:encoded><![CDATA[<p>From the original <a href="http://alistapart.com/articles/beyonddoctype" rel="nofollow">Beyond Doctype</a> article:</p>
<p>&#8220;In an ideal world, of course, all specifications would be perfect from the get-go, and their implementation in user agents would be immediate and flawless. In a slightly more down-to-earth version of an ideal world, browser vendors would immediately integrate regularly updated standards into new user agents—and users would have instant access to the latest version of those browsers without having to lift a finger.&#8221;</p>
<p>When I read that I thought &#8220;Doesn&#8217;t my antivirus software do this every day?&#8221; Each day at 2 AM it downloads an updated database of virus information and automatically installs it. Maybe the thing to do for Microsoft (and others) is to create a &#8220;standards database&#8221; that can be updated every so often automatically by the application.</p>
<p>In fact this could easily function as an improvement of or extension to the Firefox/IE/Opera update mechanism that alerts me that a new version is available. Just tell me that an updated &#8220;DTD entry&#8221; is available and tell me to install it. Or even better, have the browser automatically pull it down and install it.</p>
<p>(yes, this is pretty much a copy of another comment I posted at A List Apart and Ars Technica and the IE Blog. The more times I say it the better chance someone will see it.)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: David Smith</title>
		<link>http://webkit.org/blog/155/versioning-compatibility-and-standards/comment-page-1/#comment-23858</link>
		<dc:creator>David Smith</dc:creator>
		<pubDate>Sun, 27 Jan 2008 09:34:42 +0000</pubDate>
		<guid isPermaLink="false">http://webkit.org/blog/155/versioning-compatibility-and-standards/#comment-23858</guid>
		<description>One problem with that is that it would likely involve backporting quite a bit of the rest of the system as well. 10.2 doesn&#039;t have CoreText, for example, or many many other APIs. WebKit is relatively independent of its host OS, but it still doesn&#039;t live in a vacuum.</description>
		<content:encoded><![CDATA[<p>One problem with that is that it would likely involve backporting quite a bit of the rest of the system as well. 10.2 doesn&#8217;t have CoreText, for example, or many many other APIs. WebKit is relatively independent of its host OS, but it still doesn&#8217;t live in a vacuum.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: richcon</title>
		<link>http://webkit.org/blog/155/versioning-compatibility-and-standards/comment-page-1/#comment-23857</link>
		<dc:creator>richcon</dc:creator>
		<pubDate>Sat, 26 Jan 2008 22:29:05 +0000</pubDate>
		<guid isPermaLink="false">http://webkit.org/blog/155/versioning-compatibility-and-standards/#comment-23857</guid>
		<description>One solution to the pages-rendering-differently-in-different-versions-of-Safari problem would be, simply, to make the current version of WebKit available to all past versions of Mac OS X that has shipped with some version of Safari. Instead of having to support people with outdated versions of WebKit, you could be getting everyone onto the latest and greatest version. Slap it into System Update, and it&#039;ll trickle down to every Safari install out there. No need to support older engine versions anymore.

(If you&#039;re worried about breaking other OS services that use WebKit, then keep the old WebKit in /library/frameworks and stick the new one in Safari directly.)

I know plenty of people who still use (gasp) 10.2, and their version of Safari seems broken in comparison. When I design  for the web, if I really want to reach the whole of the Mac community, I have to think about how the page will look in those older Safari versions.</description>
		<content:encoded><![CDATA[<p>One solution to the pages-rendering-differently-in-different-versions-of-Safari problem would be, simply, to make the current version of WebKit available to all past versions of Mac OS X that has shipped with some version of Safari. Instead of having to support people with outdated versions of WebKit, you could be getting everyone onto the latest and greatest version. Slap it into System Update, and it&#8217;ll trickle down to every Safari install out there. No need to support older engine versions anymore.</p>
<p>(If you&#8217;re worried about breaking other OS services that use WebKit, then keep the old WebKit in /library/frameworks and stick the new one in Safari directly.)</p>
<p>I know plenty of people who still use (gasp) 10.2, and their version of Safari seems broken in comparison. When I design  for the web, if I really want to reach the whole of the Mac community, I have to think about how the page will look in those older Safari versions.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Kody Bryson</title>
		<link>http://webkit.org/blog/155/versioning-compatibility-and-standards/comment-page-1/#comment-23848</link>
		<dc:creator>Kody Bryson</dc:creator>
		<pubDate>Thu, 24 Jan 2008 20:37:38 +0000</pubDate>
		<guid isPermaLink="false">http://webkit.org/blog/155/versioning-compatibility-and-standards/#comment-23848</guid>
		<description>@NtroP

I was referring to the fact that you can&#039;t blame them for their current actions to try to maintain backward compatibility to prevent loss of market share. That&#039;s a logical goal for them. And even then it&#039;s only &quot;in a way&quot; because I also state this is still a bad idea.

I totally agree with you that they are responsible for the situation they are in now and everything else in your comment.</description>
		<content:encoded><![CDATA[<p>@NtroP</p>
<p>I was referring to the fact that you can&#8217;t blame them for their current actions to try to maintain backward compatibility to prevent loss of market share. That&#8217;s a logical goal for them. And even then it&#8217;s only &#8220;in a way&#8221; because I also state this is still a bad idea.</p>
<p>I totally agree with you that they are responsible for the situation they are in now and everything else in your comment.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: DJCarbon43</title>
		<link>http://webkit.org/blog/155/versioning-compatibility-and-standards/comment-page-1/#comment-23846</link>
		<dc:creator>DJCarbon43</dc:creator>
		<pubDate>Thu, 24 Jan 2008 15:38:14 +0000</pubDate>
		<guid isPermaLink="false">http://webkit.org/blog/155/versioning-compatibility-and-standards/#comment-23846</guid>
		<description>Well said NtroP! :D

&quot;...their sheltered little dystopia...&quot; and &quot;...it’s CELEBRATE!&quot;  hahah made my day!</description>
		<content:encoded><![CDATA[<p>Well said NtroP! <img src='http://webkit.org/blog/wp-includes/images/smilies/icon_biggrin.gif' alt=':D' class='wp-smiley' /> </p>
<p>&#8220;&#8230;their sheltered little dystopia&#8230;&#8221; and &#8220;&#8230;it’s CELEBRATE!&#8221;  hahah made my day!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Nicholas Shanks</title>
		<link>http://webkit.org/blog/155/versioning-compatibility-and-standards/comment-page-1/#comment-23843</link>
		<dc:creator>Nicholas Shanks</dc:creator>
		<pubDate>Wed, 23 Jan 2008 21:10:56 +0000</pubDate>
		<guid isPermaLink="false">http://webkit.org/blog/155/versioning-compatibility-and-standards/#comment-23843</guid>
		<description>Have those inside Apple got a roadmap for the removal of modes, or the reduction of old modes&#039; footprint within the code base? For example you say there is a mode for Dashboard compatibility. Widget authors seem fairly responsive from my point of view, they are active and can fix things if they are told that there is something wrong. Competent users can even fix other people&#039;s widgets on their behalf (though re‐releasing them might be problematic, legally). If widgets in Dashboard compatibility mode caused a small error message to be displayed elsewhere on the dashboard, outside of the widget&#039;s normal bounds, both authors and users could update, and this mode could be retired. People who don&#039;t update their browser aren&#039;t likely to update their widgets either, so would be oblivious.
A list of known XHTML vs. HTML rendering inconsistencies would be very useful too. Perhaps this already exists?</description>
		<content:encoded><![CDATA[<p>Have those inside Apple got a roadmap for the removal of modes, or the reduction of old modes&#8217; footprint within the code base? For example you say there is a mode for Dashboard compatibility. Widget authors seem fairly responsive from my point of view, they are active and can fix things if they are told that there is something wrong. Competent users can even fix other people&#8217;s widgets on their behalf (though re‐releasing them might be problematic, legally). If widgets in Dashboard compatibility mode caused a small error message to be displayed elsewhere on the dashboard, outside of the widget&#8217;s normal bounds, both authors and users could update, and this mode could be retired. People who don&#8217;t update their browser aren&#8217;t likely to update their widgets either, so would be oblivious.<br />
A list of known XHTML vs. HTML rendering inconsistencies would be very useful too. Perhaps this already exists?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: NtroP</title>
		<link>http://webkit.org/blog/155/versioning-compatibility-and-standards/comment-page-1/#comment-23842</link>
		<dc:creator>NtroP</dc:creator>
		<pubDate>Wed, 23 Jan 2008 19:09:40 +0000</pubDate>
		<guid isPermaLink="false">http://webkit.org/blog/155/versioning-compatibility-and-standards/#comment-23842</guid>
		<description>&lt;i&gt;In a way you can’t blame Microsoft. They have market share to maintain and the current climate already promotes change away from Microsoft.&lt;/i&gt;

I disagree.  Microsoft is entirely to blame for their predicament.  It was their decision to intentionally break standards in order to leverage their position in the market to stifle any competition and force the world to use their twisted offerings.  The amount of pain and suffering we web developers have been put through because their arrogance has ensured each and every one of their developers and management their own special place in Hell.

They made their bed, now they must lie in it.  They are losing market-share and mind-share.  As soon as this reaches critical mass, even those poor souls who live in a completely isolated MS world will realize they&#039;ve been the laughingstock of the rest of the industry for years.  In fact, as I was writing this one of my coworkers came in to ask why something wasn&#039;t working in their browser while it worked fine for their secretary.  While I was digging for more information the secretary came in and said: &quot;I figured it out.  You are using IE.  You need to use FireFox or Safari...&quot;   

I&#039;m so proud of her!  Even my boss, who is a die-hard MS supporter has come to the sad realization that using IE is just more trouble than it&#039;s worth when compared to FireFox.  The forced upgrade from IE6 to IE7 and the problems that it caused was the first nudge.  The policy that all future internal and external web documents were to be standards-based and section 508 compliant was the next blow.  It didn&#039;t take long for her to realize all the work that was required just to make allowances for IE when preparing the documents for *all other browsers* was trivial.

I used to be a Microsoft developer.  As long as you never leave their sheltered little dystopia life is great - they really do offer a good suite of self-referential products.  It reminds me of the movie Pleasantville.  When I was working exclusively in that environment I was  I was happy.   Ah well, we were all young and foolish once.

I didn&#039;t mean to turn this into a rant.  I appreciate the level-headed tone and clear thinking in the article.  I guess I just have a visceral response this topic. It&#039;s like the revelation that I had when I started working outside the MS fold. I felt like the old, pious, priest that finally got to see the original, hand-of-God, version of the Bible that all other copies were made from, only to come weeping from the secret room saying &quot;It&#039;s CELEBRATE!&quot;

Anyway, great article.</description>
		<content:encoded><![CDATA[<p><i>In a way you can’t blame Microsoft. They have market share to maintain and the current climate already promotes change away from Microsoft.</i></p>
<p>I disagree.  Microsoft is entirely to blame for their predicament.  It was their decision to intentionally break standards in order to leverage their position in the market to stifle any competition and force the world to use their twisted offerings.  The amount of pain and suffering we web developers have been put through because their arrogance has ensured each and every one of their developers and management their own special place in Hell.</p>
<p>They made their bed, now they must lie in it.  They are losing market-share and mind-share.  As soon as this reaches critical mass, even those poor souls who live in a completely isolated MS world will realize they&#8217;ve been the laughingstock of the rest of the industry for years.  In fact, as I was writing this one of my coworkers came in to ask why something wasn&#8217;t working in their browser while it worked fine for their secretary.  While I was digging for more information the secretary came in and said: &#8220;I figured it out.  You are using IE.  You need to use FireFox or Safari&#8230;&#8221;   </p>
<p>I&#8217;m so proud of her!  Even my boss, who is a die-hard MS supporter has come to the sad realization that using IE is just more trouble than it&#8217;s worth when compared to FireFox.  The forced upgrade from IE6 to IE7 and the problems that it caused was the first nudge.  The policy that all future internal and external web documents were to be standards-based and section 508 compliant was the next blow.  It didn&#8217;t take long for her to realize all the work that was required just to make allowances for IE when preparing the documents for *all other browsers* was trivial.</p>
<p>I used to be a Microsoft developer.  As long as you never leave their sheltered little dystopia life is great &#8211; they really do offer a good suite of self-referential products.  It reminds me of the movie Pleasantville.  When I was working exclusively in that environment I was  I was happy.   Ah well, we were all young and foolish once.</p>
<p>I didn&#8217;t mean to turn this into a rant.  I appreciate the level-headed tone and clear thinking in the article.  I guess I just have a visceral response this topic. It&#8217;s like the revelation that I had when I started working outside the MS fold. I felt like the old, pious, priest that finally got to see the original, hand-of-God, version of the Bible that all other copies were made from, only to come weeping from the secret room saying &#8220;It&#8217;s CELEBRATE!&#8221;</p>
<p>Anyway, great article.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: squareman</title>
		<link>http://webkit.org/blog/155/versioning-compatibility-and-standards/comment-page-1/#comment-23841</link>
		<dc:creator>squareman</dc:creator>
		<pubDate>Wed, 23 Jan 2008 18:47:20 +0000</pubDate>
		<guid isPermaLink="false">http://webkit.org/blog/155/versioning-compatibility-and-standards/#comment-23841</guid>
		<description>Regarding the &quot;bobs&quot; in IT: Maybe MS should just provide a new application called &quot;Intranet Explorer&quot; and go ahead and make Internet Explorer 8 a proper Web player. 

Frankly, I&#039;m hoping all this bloat of providing multiple engines will just make other browsers more attractive. Go for it Microsoft! ;)</description>
		<content:encoded><![CDATA[<p>Regarding the &#8220;bobs&#8221; in IT: Maybe MS should just provide a new application called &#8220;Intranet Explorer&#8221; and go ahead and make Internet Explorer 8 a proper Web player. </p>
<p>Frankly, I&#8217;m hoping all this bloat of providing multiple engines will just make other browsers more attractive. Go for it Microsoft! <img src='http://webkit.org/blog/wp-includes/images/smilies/icon_wink.gif' alt=';)' class='wp-smiley' /> </p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Kody Bryson</title>
		<link>http://webkit.org/blog/155/versioning-compatibility-and-standards/comment-page-1/#comment-23840</link>
		<dc:creator>Kody Bryson</dc:creator>
		<pubDate>Wed, 23 Jan 2008 17:25:24 +0000</pubDate>
		<guid isPermaLink="false">http://webkit.org/blog/155/versioning-compatibility-and-standards/#comment-23840</guid>
		<description>It&#039;s an interesting problem that IE faces. Microsoft gets a lot of push from people, usually IT departments with no budgets or people to change anything for backward compatibility. It&#039;s not cnet.com or digg.com that wants it, it&#039;s Bob in AT&amp;T&#039;s IT department and other Bobs all over the world that have web documents that haven&#039;t been touched in 5 years. Bob has an environment that&#039;s exclusively Windows and IE so there was no need to test against standards or other browsers. In fact the HTML in Bob&#039;s organization is probably malformed would make most web developers cringe. Bob has made a mistake, but a very human mistake busy IT departments make every day.

Apple doesn&#039;t (yet) let itself get held back by this as much. They&#039;d probably like to have this problem, but since they don&#039;t they&#039;re growing as a company and Safari as a web browser very fast. Microsoft is stagnating. It&#039;s very hard to make change happen inside Microsoft now. You can make half a change because the people inside Microsoft talk a good change. But then there&#039;s always the painful compromise. This meta tag is the painful compromise.

In a way you can&#039;t blame Microsoft. They have market share to maintain and the current climate already promotes change away from Microsoft. However there will be a breaking point. The code will get too complex and change will be further limited. Firefox and Safari will be faster. People will just slowly switch to get away from meta tags. Microsoft doesn&#039;t understand that essentially they have no choice but to issue a kind apology, html translation tools, and some tough love to their customers. It&#039;s either that or die. Sounds like hyperbole, but believe me, it isn&#039;t. Keep watching.</description>
		<content:encoded><![CDATA[<p>It&#8217;s an interesting problem that IE faces. Microsoft gets a lot of push from people, usually IT departments with no budgets or people to change anything for backward compatibility. It&#8217;s not cnet.com or digg.com that wants it, it&#8217;s Bob in AT&amp;T&#8217;s IT department and other Bobs all over the world that have web documents that haven&#8217;t been touched in 5 years. Bob has an environment that&#8217;s exclusively Windows and IE so there was no need to test against standards or other browsers. In fact the HTML in Bob&#8217;s organization is probably malformed would make most web developers cringe. Bob has made a mistake, but a very human mistake busy IT departments make every day.</p>
<p>Apple doesn&#8217;t (yet) let itself get held back by this as much. They&#8217;d probably like to have this problem, but since they don&#8217;t they&#8217;re growing as a company and Safari as a web browser very fast. Microsoft is stagnating. It&#8217;s very hard to make change happen inside Microsoft now. You can make half a change because the people inside Microsoft talk a good change. But then there&#8217;s always the painful compromise. This meta tag is the painful compromise.</p>
<p>In a way you can&#8217;t blame Microsoft. They have market share to maintain and the current climate already promotes change away from Microsoft. However there will be a breaking point. The code will get too complex and change will be further limited. Firefox and Safari will be faster. People will just slowly switch to get away from meta tags. Microsoft doesn&#8217;t understand that essentially they have no choice but to issue a kind apology, html translation tools, and some tough love to their customers. It&#8217;s either that or die. Sounds like hyperbole, but believe me, it isn&#8217;t. Keep watching.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
