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

Re: SVGWG SVG-in-HTML proposal (Was: ISSUE-41: Decentralized extensibility)

From: Sam Ruby <rubys@us.ibm.com>
Date: Tue, 29 Jul 2008 08:00:42 -0400
To: Ian Hickson <ian@hixie.ch>
Cc: Erik Dahlström <ed@opera.com>, Henri Sivonen <hsivonen@iki.fi>, Julian Reschke <julian.reschke@gmx.de>, HTML WG <public-html@w3.org>
Message-ID: <OF3B376332.0E4950CF-ON85257495.0041194F-85257495.0041FB86@us.ibm.com>

Ian Hickson <ian@hixie.ch> wrote on 07/29/2008 07:38:59 AM:

> On Tue, 29 Jul 2008, Sam Ruby wrote:
> >
> > Not too long ago, the presumption was that trailing soliduses in tags
> > must always be treated as an error, lest the web would break.  This was

> > replaced by the assumption that trailing soliduses in all but a few,
> > well defined places would be treated as an error.
> Indeed, I even mentioned that very case in the e-mail to which you
> replied:
> | Sometimes one agrees with the choice, and sometimes one doesn't, e.g.
> | as I don't in the issue of including XML-like syntactic placebos in
> | text/html. That's just the way the chips fall.
> We have to base our decisions on evidence, not our wishes.
> > Yes, some people here have the assumption that namespace prefixes must
> > always be treated as an error, lest the web would break.
> Note that this isn't really a technically similar case. The placebo
> in text/html does nothing at all -- it's just allowed so as to reduce
> author confusion. Namespace prefixes _do_ have a practical effect, so
> not just about whether they're allowed or not, it's about whether they
> supported or not.
> Evidence suggests that they cause great author confusion (e.g. [1]). In
> addition, specific syntax like XML's wouldn't work in text/html due to
> problem you mention (the undesired effect on legacy content). We have to
> balance these two relativel major negatives against the benefits of
> prefixes. These are basically limited to the ability to mix multiple
> vocabularies in a very interleaved fashion. Since there really is no need

> to do this in HTML, at least so far, the negatives strongly outweigh the
> positives. (Note that here I'm talking specifically about namespace
> _prefixes_ and their associated declarations, and not namespaces in
> general. There are many ways of designing namespace syntax, and many do
> not use any kind of indirection like prefixes.)
> As I said, these issues were studied years ago, and underlie much of
> HTML5's design. There isn't really much point discussing the issue unless

> some radical new evidence has come up since the 2003/2004 timeframe.

While radical new evidence would certainly merit reopening this issue, but
meanwhile reevaluating the unstated assumptions made when that analysis was
done is also in order.  I'm sure I could find it (and perhaps you can find
it quicker than I can) but when I brought up the issue of trailing
soliduses, you stated rather categorically that it could not be done, based
on your prior analysis.  This turned out to be a mere approximation of the
truth, and that alowing trailing soliduses in a few, well defined places,
was indeed possible.

My point isn't that these issues are similar (they are not, nor are the
issues of predictable error recovery and namespace prefixes, for that
matter), just that issues aren't always all-or-nothing.  It might turn out
that namespace prefixes in a few well defined places is possible, or that
the predictable error recovery currently specified can be tweaked (while
still retaining the quality of being predictable).

> [1] "As the author of an O'Reilly book on XForms, I can report that 90%
> the technical questions from readers involve confusion related to
> namespaces."
>   -- http://www.w3.org/2004/04/webapps-cdf-ws/papers/verity.html
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Tuesday, 29 July 2008 13:16:23 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:44:34 UTC