Re: David Baron: The W3C Member Companies Conspire to Kill the Web

On Wednesday 2004-07-07 12:24 +0200, Robin Berjon wrote:
> Yes, his reasoning is that a world controlled by three browser vendors, 
> two of which are closed and controlled is much better.
> 
> Follow the money. Some companies have a strong interest in keeping the 
> Web in the tag soup mess that it is today. Microsoft, because it means 
> that IE stays. Opera, because its business is in selling IE emulators 
> and proxies for mobile devices. And now the Mozilla Foundation is being 
> financed by Nokia to compete with Opera in the 
> tagsoup-rendering-for-mobile space.
> 
> I'm not saying there's no good faith from at least some of those people. 
> Simply, some people have much higher financial interest in incremental 
> hacks on the status quo, and those people aren't the content producers.

I'm not saying that people with financial interests in this argument are
only on one side of it.  However, I am saying (1) that the financial
interests of some W3C members have led the W3C to produce standards in a
process in which the primary use cases during the design were not cases
on the Web and (2) that standards produced in such a process are not
necessarily appropriate for the Web.

> >     David writes:
> >
> >  SVG and XForms weren't even designed for the Web.
> >SVG was designed by graphic designers who wish the
> >fact that Web pages aren't printed on paper would go
> >away and by mobile phone businesses who want vector
> >graphics for sending non-Web content to their mobile
> >phones. Never mind that it ignores one of the key
> >architectural principles of the Web.  The main
> > arguments for XForms always seem to relate to
> > "intranet" forms (where companies can earn money), not
> > Web forms (where they can't earn nearly as much, since
> > they can't charge for clients).
> 
> That's called trolling FUD. There isn't even the beginning of a fact in 
> there. Until David can make an articulate argument, it's a waste of time 
> discussing this.

I made part of the argument in the next paragraph (which wasn't quoted),
where I wrote:

# The use of compound documents could have been the killer app for
# switching to XHTML, but the SVG spec defines stand-alone SVG
# incompatibly with CSS's processing model and syntax and doesn't
# describe how SVG works when combined with the formats that existed
# before it.

Let me expand on that a little:

 * When I hear Web authors talk about SVG, the interest I hear is
   generally that they want to include bits of SVG in (X)HTML+CSS pages,
   not that they want to replace their (X)HTML+CSS documents with SVG
   documents.  So I would have expected that a vector graphics
   specification designed for the web would have had a processing model
   that fully defines how this works and had an extensive test suite to
   ensure interoperability (because without such a test suite experience
   has shown that the level of interoperability needed for use on the
   Web is unlikely).

 * By syntax, I was referring mainly to the unitless lengths issue,
   although also the general extensibility issue of SVG adding
   properties without any namespace.

 * By processing model, some things I was thinking of were:

   + The CSS model is defined in terms of boxes, but the SVG model is
     defined in terms of elements, and no mapping from elements to boxes
     is provided.  (Inline elements broken over lines are split into
     multiple boxes [2], and likewise for block-level elements split
     across pages.)  Thus a definition in a spec written in the SVG
     model can't be mapped automatically into the CSS model, or vice
     versa.

   + The SVG model adds an additional dimension of complexity to the
     decision of what stylesheets should be used by defining svg:use so
     that the stylesheets applied are those in the imported document
     rather than the master document.  This adds to a process that
     already had two dimensions (media-specific stylesheets and
     alternate stylesheets) and adds significant ambiguity to the
     definition of one of those dimensions (alternate stylesheets).

> Someone that does their homework as opposed to pointing 
> random fingers when they run out of Prozac might have noticed for 
> instance that SVG Print is the least advanced of all SVG specs and at 
> least come up with different gibberish, if not something sensical.

The level of advancement of SVG print is irrelevant -- and you probably
would have known that if you hadn't been reading what I wrote quoted out
of context.  In context, you would have seen that the words "Web pages
aren't printed on paper" were a link to John Alsopp's classic 1999
article [1] and thus that the whole phrase "graphic designers who wish
the fact that Web pages aren't printed on paper would go away" was
referring to the mentality discussed in that article.

-David

[1] http://www.westciv.com/style_master/house/good_oil/not_paper/
[2] 6th paragraph of
    http://www.w3.org/TR/2004/CR-CSS21-20040225/visuren.html#inline-formatting

-- 
L. David Baron                                <URL: http://dbaron.org/ >