W3C home > Mailing lists > Public > public-html@w3.org > August 2008

RE: Extensibility strategies, was: Deciding in public (Was: SVGWG SVG-in-HTML proposal)

From: Justin James <j_james@mindspring.com>
Date: Sat, 2 Aug 2008 00:42:01 -0400
To: "'Julian Reschke'" <julian.reschke@gmx.de>
Cc: "'Karl Dubost'" <karl@w3.org>, "'Ian Hickson'" <ian@hixie.ch>, "'Sam Ruby'" <rubys@us.ibm.com>, "'HTML WG'" <public-html@w3.org>
Message-ID: <045001c8f45a$1b4acca0$51e065e0$@com>

> -----Original Message-----
> From: Julian Reschke [mailto:julian.reschke@gmx.de]
> Sent: Friday, August 01, 2008 2:12 PM
> To: Justin James
> Cc: 'Karl Dubost'; 'Ian Hickson'; 'Sam Ruby'; 'HTML WG'
> Subject: Extensibility strategies, was: Deciding in public (Was: SVGWG
> SVG-in-HTML proposal)
> Justin James wrote:
> >> Yet another example where people resorted to hacks in order to work
> >> around the missing extensibility model.
> >
> > Browser vendors have been pulling tricks like this forever. Remember
> when
> > the <script> tag was allowed (indeed, *supposed to*) appear within
> <!-- -->
> > comments, so that browsers that did not support scripting wouldn't
> trip over
> > it? At least in that case, they were using a hack to try to avoid
> causing
> > problems that their un-standardized extension was creating.
> Yes, understood. If there's no extensibility model, but you want to
> extend, you need to use a hack.
> BR, Julian

I think that the history of HTML and browsers has made it abundantly clear
that browser vendors will extend the spec when it is in their best
interests, even if HTML does not provide these mechanisms. It is also pretty
clear from history that these extensions have a significant chance of
causing a lot of chaos.

Initially, I was quite against the idea of providing an extension mechanism.
But the more I considered this simple truth, the more I came to understand
that we are faced with two options here:

1) Provide some sort of defined extensibility mechanism that is simple
enough for people to use, and flexible enough to actually be used.

2) Continue to try to prevent browser vendors from extending HTML in
non-standard ways, and then retroactively add the best extensions into the
HTML spec, sometimes years later.

I think that choice #1 is the correct approach; if choice #2 were a good
path, why are we still having problems with browser vendors extending HTML,
15 or so years later?

I also think that strict XML is not the solution that achieves #1. Why? Go
look at the size of an XML book. I read an XML book once, in 2000 or so. XML
is an excruciating system to work in. If you look at how people in "the real
world" use XML, they are essentially using it as a really inefficient CSV
replacement, representing rectangular data sets in a very verbose manner.
Very few people are actually using it for its real purpose of a
self-describing data exchange format, what with all of the namespaces,
inheritance, etc. It is simply too complex, and there is little reason to
use it like that most of the time.

Very few of the pro-extensibility advocates on this list seem to want a full
XML system either. They all have their reasons, but it is clear to me from
where I sit that any extensibility mechanism that relies upon a full and
strict XML system won't have high adoption.

So let's figure out something better. I would suggest something much more
like CSS, but instead of providing presentational information, provided
handling and semantic information. It would also be able to include the ARIA
stuff too, for that matter.

Received on Saturday, 2 August 2008 04:43:20 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:36 UTC