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 02:51:10 -0400
To: "'Ian Hickson'" <ian@hixie.ch>
Cc: "'HTML WG'" <public-html@w3.org>
Message-ID: <045b01c8f46c$25ef8a80$71ce9f80$@com>

> -----Original Message-----
> From: Ian Hickson [mailto:ian@hixie.ch]
> Sent: Saturday, August 02, 2008 1:43 AM
> To: Justin James
> Cc: 'HTML WG'
> Subject: RE: Extensibility strategies, was: Deciding in public (Was:
> SVGWG SVG-in-HTML proposal)
> On Sat, 2 Aug 2008, Justin James wrote:
> >
> > 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?
> Are the problems caused by browser extensions caused by the syntax, or
> by
> the extensions themselves?

Sometimes a mix, but usually the extensions themselves are the problem. I
see the point you are making here, but what I think is that by providing
them with a *safe* and *standard* way to provide extensions is better than
the status quo. It's like how if you had a teenager learning to drive, you'd
get them the safest car you could, not the coolest car. :)

> Would <marquee> have been ok it was really <ie:marquee>?
> Would <blink> have been ok if it was really <nn:blink>?
> Would <canvas> have been ok if it was really <wk:canvas>?

No, but that is not exactly the best alternative either, in my opinion. :)

> It seems to me that we would be in a _worse_ state right now if all
> these
> extensions had become widely spread while having extra syntax around
> them.

Maybe the extra syntax would make them less likely to be adopted? At the
very least, it would indicate to HTML authors, "hey, this isn't standard!"

> The problem, IMHO, is not that these extensions step into the
> vocabulary
> of HTML. <marquee> and <blink> haven't prevented us from creating new
> elements or anything like that. We could easily have called <canvas>
> something else in the standardisation stage, we didn't have to use
> <canvas>. The problems, as far as I can tell, were with the features
> themselves, regardless of their name. They didn't have enough peer
> review
> before being shipped.
> The solution to a lack of peer review is peer review, not syntax.

I agree *completely*. But we need *something* in place that lets browser
vendors extend HTML at the speed which they code, not the speed which we get
specs out the door.

> > 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.
> What would you say the requirements of such a system were? What is the
> problem being solved?
> Before solving this kind of problem, we need a very clear idea of what
> we're trying to solve, how to determine if we've solved the problem,
> and
> what the requirements are. Then we can look to see if we already have a
> solution, and if we don't, we can design one and evaluate it in terms
> of
> those requirements.

I agree. I'll hash something together over the next few days and put it out
to this list.

I have a third choice here:

Periodically (once per year? Every 6 months? Every 2 years?) we should
publish a "supplement" to the existing HTML standard (not the working
draft). For example, HTML 4.1, 4.2, etc. Browser vendors would be able to
get minor, less contentious items peer-reviewed and standardized (or
rejected, which might convince them to not create something like <blink> I
hope...) quickly. This would effectively reduce much, if not most, of the
need for extensibility mechanisms to be included in HTML, while still
maintaining the benefits of the centralization that this group (or an "HTML
4 supplement group") provides.

One of the primary tenets of my world view which I have forgotten here is:
"When people consistently work outside of the process, that indicates that
the process is broken."

The fact that browser vendors keep working outside of our process and come
to the W3c *after the fact* is a strong sign of a broken process.

Received on Saturday, 2 August 2008 06:51:52 UTC

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