- From: Robert J Burns <rob@robburns.com>
- Date: Sun, 18 Jan 2009 16:51:06 -0600
- To: HTML WG <public-html@w3.org>
Hi Larry, Now that's a section draft I could support. it's NPOV, Fox News Style (fair and balanced). It presents both sides: the one about the openly- produced vendor-neutral language; and then the truth (though I guess they usually don't get to that part at Fox due to time constraints). Take care, Rob On Jan 18, 2009, at 2:36 PM, Larry Masinter wrote: > > I suggested removing section 1.5.4 from the specification. The text > of 1.5.4 mentions vendors 7 times, application developers 4 times, > and users only once. It makes numerous specious claims, including > claims about the similarity or equivalence of the problems > addressed, about the openness of the process by which the > specification was created, about the neutrality of the advantage the > specification plays in the ongoing "browser wars", about the range > of platforms and devices that are supported in comparison with the > languages it is contrasting with, about the benefits to application > developers and the costs of the alternatives, about the cost to > switch between platforms or the relevance of that cost compared to > other costs and benefits. > > I think it's more effective to focus on the technical issues rather > than the political ones, and removing the text seems better than > engaging in further debate. > > > However, I did say I had alternative text which I would offer, if > removing 1.5.4 isn't acceptable. In that spirit, I offer the > following flame for your amusement (do not quote out of context): > > <flame> > Some people claim that this specification is independent of the > various proprietary application languages that various vendors > provide, but is intended to address many of the same problems. > > They also claim that, in contrast with proprietary languages, this > specification is intended to define an openly-produced, vendor- > neutral language, to be implemented in a broad range of competing > products, across a wide range of platforms and devices. This enables > developers to write applications that are not limited to one > vendor's implementation or language. Furthermore, while writing > applications that target vendor-specific platforms necessarily > introduces a cost that application developers and their customers or > users will face if they are forced to switch (or desire to switch) > to another vendor's platform, using an openly-produced and vendor > neutral language means that application authors can switch vendors > with little to no cost. > > Others believe that this specification was the product of a self- > selected cabal of browser implementers, with a closely held decision > process in which technical decisions are made by a single individual > and dissent shouted down by his accolades. They believe that it is > equally likely that this specification is intended to preserve the > hegemony of proprietary search engine providers and walled-garden > handset operating system makers by stifling any innovation in the > web that is outside of their control. This specification reifies > and promotes current poor practices of web authors who have taken > advantage of previous proprietary extensions and implementation > accidents in previous browsers, and permanently mandates backward > compatibility of web browsers with current desktop PC applications > in a way that forces a processing model that is inappropriate for > many otherwise legitimate contexts for delivery of web content. > > The web has seen a growth of rich extensions in web functionality > for interactive graphics, video, 3D, image browsing and so on, well > beyond the scope of "HyperText" which is the natural province of the > HyperText Markup Language (HTML). This specification increases the > scope of HTML to include poorly designed equivalents of a small > number of features previously only found in innovative extension > languages -- languages from a wide range of sources, which were > designed specifically for meeting user needs for greater > expressivity. Even though there are widely available implementations > of most of those languages, some browser makers prefer to have the > entire experience in an integrated software package completely > within their control. Of course, any specification of HTML itself > cannot completely satisfy all future needs for expressivity and > interactivity, and so extensions -- whether originally from a single > vendor or an alliance within the broader community -- will continue > to be an important source of innovation for the web and its users. > </flame> > > (tell us how you really feel) > > Larry > -- > http://larry.masinter.net > > > > >
Received on Sunday, 18 January 2009 22:51:46 UTC