Hi, Maciej-
I'm taking this discussion to www-archive, since it affects
a lot of
groups and a lot of interests. I'm BCCing related groups
(HTML, SVG,
MathML, CDF, XHTML2), but discussions should take place on
www-archive.
(This is part of a couple of long threads that started on
blogs and
IRC, and were continued on public-html; I'd suggest that
those
interested in this review those threads. [1][2])
To broaden the dialog to other audiences, so I'm going to
try to
summarize the issue along the way. Please correct me if I
fall astray,
or expand on points. I'm going to talk about SVG, but many
of the same
issues may apply to MathML.
Maciej Stachowiak wrote (on 3/16/08 1:12 AM):
>
> HTML has the feature of two serializations: a classic
serialization that
> is error-tolerant, and an XML-based serialization that
has draconian
> error handling. These have different costs and
benefits, ultimately it
> is a benefit to HTML authors that they have a choice. I
think SVG
> deserves to have this feature as well, there's no
reason it should fall
> short of HTML in this regard. Supporting SVG inline in
text/html seems
> like a good opportunity to add this feature to SVG.
There are 2 scenarios here: SVG inline (Compound Documents
by
Inclusion), and external SVG (Compound Documents by
Reference). Your
proposal is that, in order to facilitate inline inclusion of
SVG into
text/html, changes should be made to other uses of SVG,
including those
intended for SVG-only UAs. I'll ask you to detail what
changes would be
required, but the topic of hottest debate so far is the
ability to use
unquoted attribute values in SVG, when there are no spaces
or other
ambiguous characters. This would look something like this:
<circle id=circle_1 class="category1 medium"
cx=75 cy=25 r=20
fill=orange stroke=red stroke-dasharray="3 5"
/>
You characterize this as non-draconian error handling; for
the purpose
of authoring conformance, would this fragment indeed be in
error (and
therefor in need of error recovery behavior), or would this
be legal
syntax?
A counter-proposal is that SVG retain its existing
serialization
(meaning, among other things, that it would require quoted
attributes),
for inline (in both XHTML and text/html) and for external
SVG documents
(standalone or externally referenced). I'm going to argue
for this
proposal, as a Devil's Advocate, but I'm actually open to
any proposals
that can be demonstrated as workable.
Given past author practice of copy-paste authoring, SVG that
is written
inline in HTML is unlikely to stay there exclusively; it
stands a very
good chance of being extracted and reused, be it referenced
as an
external image, or as standalone content in a mobile
SVG-only viewer, or
pasted into a graphical SVG authoring tool. Content that
breaks from
one UA to another is too brittle, and would fracture the SVG
market.
So, I agree with you here, that we shouldn't burden users,
authors, and
vendors with multiple non-interoperable serializations.
As you mention, there are indeed known costs to any change
in the
written form of SVG (the serialization), notably
incompatibility with
all existing SVG viewers, authoring tools, automatic
generators, and XML
processors up and down the entire toolchain in general.
There is an
enormous infrastructure investment involved in an enterprise
like this,
which affects not just SVG and MathML, but XML in general,
and which
would require substantial costs in money, developer hours,
and time to
market.
On mobile devices in specific, this would require
implementors to write
a new parser (which has yet to be shown as practical on the
Web in
general, or with SVG in specific); this may not be a burden
for Apple
(or certain other desktop browser vendors), which has
already invested
resources in an HTML UA, but it would certainly be for
multiple other
mobile vendors (those not on the iPhone), who have a very
large (in the
upper hundreds of millions) existing SVG UA deployment, and
this could
have a substantial cost for them.
For desktop browsers, your proposed content would not work
in the most
widely deployed SVG UA plugin for Internet Explorer (the
Adobe viewer,
which though no longer maintained, is still the best and
fastest overall
SVG UA for browsers); again, I can see this being a benefit
for Apple,
but not necessarily for SVG. If Microsoft were to pledge
and deliver
resources for adding high-quality native SVG support (at
least as good
as Firefox, Opera, and WebKit), this would certainly
alleviate my
concerns about desktop browsers.
With the XML serialization of SVG (the way it is now),
authors are
already able to do inline SVG in the XML serialization of
HTML (XHTML);
this works even in Internet Explorer using the Adobe viewer,
by use of
"XML data islands"... and in fact works equally
well in text/html and
XHTML (though it has to be served as text/html, a known
problem in IE in
general).
Since it's not clear what changes would have to be made to
SVG, your
proposal may or may not affect existing SVG content that is
intended for
insertion into text/html; that is, presumably content can be
made that
works in all SVG UAs, following the existing rules for SVG.
So, this is
a neutral point... neither proposal would break existing
content from
existing SVG authoring tools and generators. Still, it
would be best to
get feedback from known tool vendors that produce SVG, such
as Inkscape,
Illustrator, CorelDraw, GraphViz, Visio, and others (I'm
probably
forgetting someone major, sorry).
As far as I know, there has been no implementation of the
HTML5 parser
by a major browser vendor (though there have been test
implementations
by others). The algorithm is relatively untested on the
vast body of
existing HTML content on the Web, and completely untested
for SVG
content. I'm concerned that this is taking an unnecessary
risk with
SVG's future, in spite of its already growing appeal and
popularity
across a variety of platforms, since it is competing with
similar
proprietary technologies. I argue that this is a bad time
to be taking
risks for what I see as a largely theoretical benefit to
authors.
As I've stated before, in 8 years of active participation in
the SVG
community, I've heard no serious request for unquoted
attributes; by
contrast, I have heard many people extolling the benefits of
the cleaner
XML model in contrast to the more complex HTML legacy. As
it happens,
SVG makes liberal use of spaces in attributes, much more so
than HTML,
so the analogies between the two are not quite accurate; the
majority of
SVG content uses not the basic shapes like circles, lines,
rectangles
and ellipses, but the more complex shapes represented by
paths,
polygons, and polylines, and those elements use attribute
values most
clearly represented by space-separated coordinate pairs.
It's not clear
that there would be a substantive gain by authors in
real-world content
by excluding attribute value quotes. Since SVG doesn't have
the legacy
content of HTML content's unquoted attributes, there is
little need to
extend the same rules to SVG as are necessary for HTML.
You state that "SVG deserves to have this feature as
well" and that
"there's no reason it should fall short of HTML in this
regard" as if
unquoted attributes are innately a clear benefit, rather
than a burden
that implementors of HTML vendors and authors have to put up
with,
because vendors have to deal with legacy content, and
authors have to
maintain content they didn't create; SVG authors have never
had to deal
with this before, and it's really not clear they want to.
You represent
this as an authoring benefit, but I have not seen the
evidence that this
is something authors are requesting. I may be wrong, but
I'd like to be
proven wrong, rather than take it on faith.
In summary, as I see it, my proposal works today in a larger
number and
wider variety of user agents, and imposes less burden on
vendors, and
arguably on authors.
Could you summarize all the changes that you would require
for SVG UAs
and authors to implement your proposal, and give the
benefits and
rationales for each?
[1] http://lists.w3.org/Archives/Public/public-html
/2008Mar/0039.html
[2] http://lists.w3.org/Archives/Public/public-html
/2008Mar/0124.html
Regards-
-Doug Schepers
W3C Team Contact, SVG, CDF, and WebAPI
|
