<?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: The non-world non-wide non-web</title>
	<atom:link href="http://brendaneich.com/2004/06/the-non-world-non-wide-non-web/feed/" rel="self" type="application/rss+xml" />
	<link>http://brendaneich.com/2004/06/the-non-world-non-wide-non-web/</link>
	<description></description>
	<lastBuildDate>Wed, 16 Nov 2011 22:54:03 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
	<item>
		<title>By: Scoop</title>
		<link>http://brendaneich.com/2004/06/the-non-world-non-wide-non-web/#comment-56</link>
		<dc:creator>Scoop</dc:creator>
		<pubDate>Tue, 14 Dec 2004 16:46:25 +0000</pubDate>
		<guid isPermaLink="false">http://brendaneich.com/2004/06/the-non-world-non-wide-non-web/#comment-56</guid>
		<description>Not withstanding ny previous statement XUL should be a primary focus in the struggle for the open source community.
-------------------------
Scoop
Build With Steel
</description>
		<content:encoded><![CDATA[<p>Not withstanding ny previous statement XUL should be a primary focus in the struggle for the open source community.<br />
&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;-<br />
Scoop<br />
Build With Steel</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Scoop</title>
		<link>http://brendaneich.com/2004/06/the-non-world-non-wide-non-web/#comment-55</link>
		<dc:creator>Scoop</dc:creator>
		<pubDate>Tue, 14 Dec 2004 16:43:27 +0000</pubDate>
		<guid isPermaLink="false">http://brendaneich.com/2004/06/the-non-world-non-wide-non-web/#comment-55</guid>
		<description>I&#039;m with Brendan.
Firefox can and is providing a viable choice in the marketplace. Choice equals competition which equals quality and more choice.
-------------------------
Scoop
Build With Steel
</description>
		<content:encoded><![CDATA[<p>I&#8217;m with Brendan.<br />
Firefox can and is providing a viable choice in the marketplace. Choice equals competition which equals quality and more choice.<br />
&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;-<br />
Scoop<br />
Build With Steel</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Brendan Eich</title>
		<link>http://brendaneich.com/2004/06/the-non-world-non-wide-non-web/#comment-54</link>
		<dc:creator>Brendan Eich</dc:creator>
		<pubDate>Mon, 22 Nov 2004 02:27:50 +0000</pubDate>
		<guid isPermaLink="false">http://brendaneich.com/2004/06/the-non-world-non-wide-non-web/#comment-54</guid>
		<description>Steffen: we&#039;re not squandering XUL&#039;s lead -- Firefox&#039;s huge success is the best thing we could do in 2004, better than polishing &quot;4GL&quot; purity points in the Gecko/XUL platform for some future year&#039;s products.  The platform work we are starting for Mozilla 2.0 (libxul, xulrunner, etc.) needs the kind of distribution demonstrated and projected by Firefox 1.0.
See my latest entry on OpenLaszlo and Eclipse, but please don&#039;t buy into the &quot;nGL&quot; theory of programming language evolution.  Scripting will never die, nor should it, and declarative languages can capture only certain structures without simply obfuscating and bloating the program.  The past 40 years of software are littered with broken monuments to such grand theorizing.
/be
</description>
		<content:encoded><![CDATA[<p>Steffen: we&#8217;re not squandering XUL&#8217;s lead &#8212; Firefox&#8217;s huge success is the best thing we could do in 2004, better than polishing &#8220;4GL&#8221; purity points in the Gecko/XUL platform for some future year&#8217;s products.  The platform work we are starting for Mozilla 2.0 (libxul, xulrunner, etc.) needs the kind of distribution demonstrated and projected by Firefox 1.0.<br />
See my latest entry on OpenLaszlo and Eclipse, but please don&#8217;t buy into the &#8220;nGL&#8221; theory of programming language evolution.  Scripting will never die, nor should it, and declarative languages can capture only certain structures without simply obfuscating and bloating the program.  The past 40 years of software are littered with broken monuments to such grand theorizing.<br />
/be</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Steffen</title>
		<link>http://brendaneich.com/2004/06/the-non-world-non-wide-non-web/#comment-53</link>
		<dc:creator>Steffen</dc:creator>
		<pubDate>Fri, 02 Jul 2004 23:26:42 +0000</pubDate>
		<guid isPermaLink="false">http://brendaneich.com/2004/06/the-non-world-non-wide-non-web/#comment-53</guid>
		<description>The new &#039;less-ugly&#039; internet you predicted is coming with XAML/Avalon/Longhorn.
How ready will Mozilla/XUL be when that apocalypse comes?
Will an installed based of intranet/XUL app users be lined up to sing XUL praises as the open source alternative (to XAML/Avalon)?
Will Mozilla/XUL look like a hacked-up contraption  next to the polished and tightly-integrated XAML/Avalon/.NET juggernaut?
The commodity applications software platfrom is moving from a 3GL/OS-level of abstraction to a better, mostly-declarative, 4GL-level of abstraction.  The frenzy over web applications will be repeated as the old web (app) platform is abandoned for this new web (app) platform.  This is just another turn of a classic cycle.  I can already see the frantic job adverts for anyone with XAML/Avalon skills.  Will anyone be looking for XUL app dev skills?
The future looks like either XAML/Avalon or XUL.  Both probably will co-exist to one degree or another.  The war over this next generation web/software (app) platform is already underway.  Which 3GL &#039;extensibility&#039; language is available will hardly matter.  All eyes will turn past the 3GL and to the 4GL.
The &#039;necessary-evil&#039; 3GL might be JavaScript, Python, Perl, etc.  The 3GL might even be JAVA/J2EE (for the write-once-port-to-every-JDK-&amp;-tune-like-crazy JAVA zealots).  We surely will see support for many 3GL options simultaneously.  Yet none of this matters.  What a devastating distraction!  The better the beyond-procedural (i.e. &#039;declarative&#039;), less-ugly-web, 4GL-level, XAML/XUL - the less the 3GL will be used - and the less the 3GL will matters.  Move on.
The single worst strategic blunder the open source community can make right now is to *loose* focus on what really matters:  XUL.  I can scarcely imagine squandering the headstart XUL has  over XAML/Avalon.  Talk about the worst possible time to get distracted!  Yet I hear all kinds of talk about http://www.whatwg.org/.  Wow.  Suicide by standards.
Microsoft must be ecstatic.  First, they steal the XUL concept.  Then as they sweat bullets   trying to catch up, the open source community fragments and dissolves.  They watch the XUL visionaries wander off before the battle even starts.  Microsoft seems to be getting very lucky here ... at just the right time.  They get to grab control of the new XUL-like web/software (app)platform.  The opposition has wandered off.
</description>
		<content:encoded><![CDATA[<p>The new &#8216;less-ugly&#8217; internet you predicted is coming with XAML/Avalon/Longhorn.<br />
How ready will Mozilla/XUL be when that apocalypse comes?<br />
Will an installed based of intranet/XUL app users be lined up to sing XUL praises as the open source alternative (to XAML/Avalon)?<br />
Will Mozilla/XUL look like a hacked-up contraption  next to the polished and tightly-integrated XAML/Avalon/.NET juggernaut?<br />
The commodity applications software platfrom is moving from a 3GL/OS-level of abstraction to a better, mostly-declarative, 4GL-level of abstraction.  The frenzy over web applications will be repeated as the old web (app) platform is abandoned for this new web (app) platform.  This is just another turn of a classic cycle.  I can already see the frantic job adverts for anyone with XAML/Avalon skills.  Will anyone be looking for XUL app dev skills?<br />
The future looks like either XAML/Avalon or XUL.  Both probably will co-exist to one degree or another.  The war over this next generation web/software (app) platform is already underway.  Which 3GL &#8216;extensibility&#8217; language is available will hardly matter.  All eyes will turn past the 3GL and to the 4GL.<br />
The &#8216;necessary-evil&#8217; 3GL might be JavaScript, Python, Perl, etc.  The 3GL might even be JAVA/J2EE (for the write-once-port-to-every-JDK-&#038;-tune-like-crazy JAVA zealots).  We surely will see support for many 3GL options simultaneously.  Yet none of this matters.  What a devastating distraction!  The better the beyond-procedural (i.e. &#8216;declarative&#8217;), less-ugly-web, 4GL-level, XAML/XUL &#8211; the less the 3GL will be used &#8211; and the less the 3GL will matters.  Move on.<br />
The single worst strategic blunder the open source community can make right now is to *loose* focus on what really matters:  XUL.  I can scarcely imagine squandering the headstart XUL has  over XAML/Avalon.  Talk about the worst possible time to get distracted!  Yet I hear all kinds of talk about <a href="http://www.whatwg.org/" rel="nofollow">http://www.whatwg.org/</a>.  Wow.  Suicide by standards.<br />
Microsoft must be ecstatic.  First, they steal the XUL concept.  Then as they sweat bullets   trying to catch up, the open source community fragments and dissolves.  They watch the XUL visionaries wander off before the battle even starts.  Microsoft seems to be getting very lucky here &#8230; at just the right time.  They get to grab control of the new XUL-like web/software (app)platform.  The opposition has wandered off.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ian Hickson</title>
		<link>http://brendaneich.com/2004/06/the-non-world-non-wide-non-web/#comment-52</link>
		<dc:creator>Ian Hickson</dc:creator>
		<pubDate>Wed, 30 Jun 2004 19:02:59 +0000</pubDate>
		<guid isPermaLink="false">http://brendaneich.com/2004/06/the-non-world-non-wide-non-web/#comment-52</guid>
		<description>All significant browsers except Internet Explorer 6. (If you write XHTML and actually send it using an XML MIME type, which you have to to get inline SVG or MathML working, then it will render an XML tree in IE.)
See also http://www.hixie.ch/advocacy/xhtml
</description>
		<content:encoded><![CDATA[<p>All significant browsers except Internet Explorer 6. (If you write XHTML and actually send it using an XML MIME type, which you have to to get inline SVG or MathML working, then it will render an XML tree in IE.)<br />
See also <a href="http://www.hixie.ch/advocacy/xhtml" rel="nofollow">http://www.hixie.ch/advocacy/xhtml</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ian Gregory</title>
		<link>http://brendaneich.com/2004/06/the-non-world-non-wide-non-web/#comment-51</link>
		<dc:creator>Ian Gregory</dc:creator>
		<pubDate>Sat, 26 Jun 2004 14:19:41 +0000</pubDate>
		<guid isPermaLink="false">http://brendaneich.com/2004/06/the-non-world-non-wide-non-web/#comment-51</guid>
		<description>People reading this discussion from a less informed perspective might get the idea that HTML and XHTML are somehow incompatible. When I re-wrote my HTML website in XHTML a year or more ago, it carried on working the same as before in all browsers that I tried. In fact, the XHTML 1.0 spec relies on HTML 4.01 for the meanings of XHTML elements and attributes.
I realise of course that people who have written a website  using some sort of proprietary version of HTML with non-standard extensions may not be able to reproduce the whole look and feel using standard XHTML, but if they produce a new XHTML website providing the same basic functionality as their old HTML site then I wouldn&#039;t have thought they need worry about people not being able to access it.
Now I suppose someone is going to give me a list of historical browsers that don&#039;t grok XHTML, but I would be very surprised if it affected more than 1% of surfers (and those historical browsers would also be unable to access a great many &quot;HTML&quot; sites either).
OK, once you add in things like SVG or MathML then you severely limit your audience, but as I understand it XHTML is itself fully supported by all significant browsers - no?
</description>
		<content:encoded><![CDATA[<p>People reading this discussion from a less informed perspective might get the idea that HTML and XHTML are somehow incompatible. When I re-wrote my HTML website in XHTML a year or more ago, it carried on working the same as before in all browsers that I tried. In fact, the XHTML 1.0 spec relies on HTML 4.01 for the meanings of XHTML elements and attributes.<br />
I realise of course that people who have written a website  using some sort of proprietary version of HTML with non-standard extensions may not be able to reproduce the whole look and feel using standard XHTML, but if they produce a new XHTML website providing the same basic functionality as their old HTML site then I wouldn&#8217;t have thought they need worry about people not being able to access it.<br />
Now I suppose someone is going to give me a list of historical browsers that don&#8217;t grok XHTML, but I would be very surprised if it affected more than 1% of surfers (and those historical browsers would also be unable to access a great many &#8220;HTML&#8221; sites either).<br />
OK, once you add in things like SVG or MathML then you severely limit your audience, but as I understand it XHTML is itself fully supported by all significant browsers &#8211; no?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Rambo Tribble</title>
		<link>http://brendaneich.com/2004/06/the-non-world-non-wide-non-web/#comment-50</link>
		<dc:creator>Rambo Tribble</dc:creator>
		<pubDate>Wed, 23 Jun 2004 14:27:23 +0000</pubDate>
		<guid isPermaLink="false">http://brendaneich.com/2004/06/the-non-world-non-wide-non-web/#comment-50</guid>
		<description>JavaScript has become the Rodney Dangerfield of scripting languages. Dilettantes and Johnny-come-latelies seem to think they enhance their cachet by dissing it. Instead, like the snotty dot-commers, they reveal that it is they who, &quot;Just don&#039;t get &#039;it&#039;.&quot;
</description>
		<content:encoded><![CDATA[<p>JavaScript has become the Rodney Dangerfield of scripting languages. Dilettantes and Johnny-come-latelies seem to think they enhance their cachet by dissing it. Instead, like the snotty dot-commers, they reveal that it is they who, &#8220;Just don&#8217;t get &#8216;it&#8217;.&#8221;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: jackiemcghee</title>
		<link>http://brendaneich.com/2004/06/the-non-world-non-wide-non-web/#comment-49</link>
		<dc:creator>jackiemcghee</dc:creator>
		<pubDate>Tue, 15 Jun 2004 18:36:49 +0000</pubDate>
		<guid isPermaLink="false">http://brendaneich.com/2004/06/the-non-world-non-wide-non-web/#comment-49</guid>
		<description>Point taken, Brendan. My apologies.
</description>
		<content:encoded><![CDATA[<p>Point taken, Brendan. My apologies.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Brendan Eich</title>
		<link>http://brendaneich.com/2004/06/the-non-world-non-wide-non-web/#comment-48</link>
		<dc:creator>Brendan Eich</dc:creator>
		<pubDate>Tue, 15 Jun 2004 16:42:42 +0000</pubDate>
		<guid isPermaLink="false">http://brendaneich.com/2004/06/the-non-world-non-wide-non-web/#comment-48</guid>
		<description>jackiemcghee: I&#039;m sorry if it seemed I thought you were malicious.  My interest here is in reality, the same hard-nosed standards of evidence and reasoning that should inform both the SVG spec and any testcases written to validate implementations of it.
But it seems to me the shoe is on the other foot -- your form is not &quot;good form&quot; by your own standard.
You tried to impeach *all* of Ian&#039;s tests by citing others&#039; authority here.  You used incomplete assertions in comments by Antoine and Robin as &quot;evidence&quot; that Ian&#039;s tests were invalid. Yet you have no answer now that Ian has commented here, except to repeat yourself.
My argument consisted of three parts:
- way too few SVG tests in the official suite;
- other tests showing bugs in implementations;
- the sheer size of the spec combined with the lack of multiple implementations interoperating in the marketplace before it was ratified.
The second plank of this platform is not weak, as far as I can tell.  And even if all of Ian&#039;s tests were completely broken (they are not), the other two planks would stand.
/be
</description>
		<content:encoded><![CDATA[<p>jackiemcghee: I&#8217;m sorry if it seemed I thought you were malicious.  My interest here is in reality, the same hard-nosed standards of evidence and reasoning that should inform both the SVG spec and any testcases written to validate implementations of it.<br />
But it seems to me the shoe is on the other foot &#8212; your form is not &#8220;good form&#8221; by your own standard.<br />
You tried to impeach *all* of Ian&#8217;s tests by citing others&#8217; authority here.  You used incomplete assertions in comments by Antoine and Robin as &#8220;evidence&#8221; that Ian&#8217;s tests were invalid. Yet you have no answer now that Ian has commented here, except to repeat yourself.<br />
My argument consisted of three parts:<br />
- way too few SVG tests in the official suite;<br />
- other tests showing bugs in implementations;<br />
- the sheer size of the spec combined with the lack of multiple implementations interoperating in the marketplace before it was ratified.<br />
The second plank of this platform is not weak, as far as I can tell.  And even if all of Ian&#8217;s tests were completely broken (they are not), the other two planks would stand.<br />
/be</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: jackiemcghee</title>
		<link>http://brendaneich.com/2004/06/the-non-world-non-wide-non-web/#comment-47</link>
		<dc:creator>jackiemcghee</dc:creator>
		<pubDate>Tue, 15 Jun 2004 08:29:58 +0000</pubDate>
		<guid isPermaLink="false">http://brendaneich.com/2004/06/the-non-world-non-wide-non-web/#comment-47</guid>
		<description>Brendan, I think you missed my point, I don&#039;t know whether or not Ian&#039;s test cases are in/valid or should/shouldn&#039;t work. It&#039;s more that I didn&#039;t think it was good form to use Ian&#039;s work as an early plank to build your argument on and then not really have an answer when they are called in to question.
I admire all the work that you and Ian and others put in, I really do (most of my work these days revolves around the DOM and CSS, so I definitely appreciate it). I guess I may have come across as being way more aggressive than I was intending and I&#039;ll put your reaction down to a similar perception, because no malice or anything of that sort was meant.
</description>
		<content:encoded><![CDATA[<p>Brendan, I think you missed my point, I don&#8217;t know whether or not Ian&#8217;s test cases are in/valid or should/shouldn&#8217;t work. It&#8217;s more that I didn&#8217;t think it was good form to use Ian&#8217;s work as an early plank to build your argument on and then not really have an answer when they are called in to question.<br />
I admire all the work that you and Ian and others put in, I really do (most of my work these days revolves around the DOM and CSS, so I definitely appreciate it). I guess I may have come across as being way more aggressive than I was intending and I&#8217;ll put your reaction down to a similar perception, because no malice or anything of that sort was meant.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

