Re: SVG and MathML in text/html

Doug,

Maybe you (or others on the WG) know the history behind integrating
Xlink with SVG?  It's weird that SMIL entities don't require special
namespace declarations yet xlink: is required.  I guess that's because
SMIL was designed to "be adopted" into a host language?  Or was it
because SMIL came before XML namespaces?

Maybe some future SVG spec can "adopt" the xlink attributes directly
and we'd be left with only the SVG namespace for pure SVG content?  It
still leaves the issue of RDF or MathML or HTML content inside SVG, of
course.

FWIW, I wouldn't mind giving up the xmlns declarations on SVG.  Since
I've been using it so long I have the namespaces memorized.  It's
really not that hard to remember: XHTML, XLink are 1999, SVG is 2000.
I end up looking up spec details on properties and attributes more
often than looking those up.  I do recognize that not everyone will be
able to do that.  What would be required to make the years optional in
the namespace? :)

On the other hand, I don't want to give up case-sensitive
elements/attributes nor quoted attributes since those are much harder
to correct when importing SVG snippets into a standalone document for
editing purposes...

That's just my opinion, of course.

Regards,
Jeff


On 3/11/08, Henri Sivonen <hsivonen@iki.fi> wrote:
> On Mar 11, 2008, at 11:16, Doug Schepers wrote:
>
>  > Jeff Schiller wrote (on 3/10/08 7:21 PM):
>  >> On Mon, Mar 10, 2008 at 4:44 PM, Henri Sivonen <hsivonen@iki.fi>
>  >> wrote:
>  >>> On Mar 10, 2008, at 23:14, Jeff Schiller wrote:
>  >>>
>  >>> I meant that a text/html doc with SVG inside it won't be readable by
>  >>> existing SVG tools and viewers in general, because the surrounding
>  >>> HTML almost always isn't well-formed and because the tools probably
>  >>> aren't expecting some non-SVG stuff around the SVG markup. In your
>  >>> sample case the HTML happens to be well-formed if treated as XML but
>  >>> this is not generally true of HTML.
>  >> Thanks for clarifying Henri.  I was talking from a copy-paste
>  >> perspective.  For instance, it's perfectly conceivable that someone
>  >> might view > source, take the <svg> snips out into their own text
>  >> editor and bring the SVG up in a SVG editor like Inkscape.  I've done
>  >> this and it works quite nice...
>  >> But I agree that editors would have a problem with the surrounding
>  >> HTML "cruft", which I wouldn't expect them to handle.
>  >
>  > Jeff has stated my own concerns eloquently, so I won't repeat them
>  > (especially since you and I already had a similar conversation on
>  > IRC).
>  >
>  > In addition to the use case of extracting the SVG from an HTML
>  > document for the purpose of editing it, there is the strong case for
>  > reuse.
>
>
> I agree that extracting an SVG part of a text/html page and taking it
>  into an SVG editor is a worthy use case. But I think defining
>  conformance in an XML-like way is not an effective way to achieve it.
>
>  The conformance definition is not an effective way to achieve it,
>  because with non-Draconian error handling, there *will* be a non-
>  trivial proportion of instances where the embedded SVG island does not
>  adhere to the conformance criteria and, therefore, won't parse as XML
>  if extracted on the source text level.
>
>  I am assuming non-Draconian error handling for two reasons:
>   1) Experience with XML has shown that Draconian error handling is
>  worse than defined error recovery for Web formats.
>   2) Draconian error handling would be bad strategy since it would
>  work as an implementation deterrent: If a new browser can throw a
>  fatal error on a page that legacy browsers parse to the end (even if
>  the SVG parts don't render), the new browser risks losing market
>  share, and browser vendors generally avert changes that would lead to
>  market share loss.
>
>  I think there are two ways of addressing the editing use case more
>  effectively:
>   1) Making the browser serialize a DOM range into XML (roughly like
>  View Selection Source serializes from the DOM in Firefox) and copying
>  and pasting the result as opposed to copying and pasting source.
>   2) Adding a text/html parser to the SVG editor.
>
>
>  > The fact is, there is a very large deployed base of SVG UAs on
>  > mobile devices, many hundreds of millions, that cannot easily be
>  > upgraded or revised.  Deliberately making incompatible changes to
>  > SVG such that the resulting content will not be viewable on the vast
>  > majority of deployed UAs is a very risky strategy, one that I don't
>  > think can be taken so lightly.
>
>
> Note that putting SVG in an text/html wrapper breaks compat with those
>  viewers *anyway*. Whether attributes are quoted doesn't matter at that
>  point.
>
>  On Mar 11, 2008, at 11:16, Doug Schepers wrote:
>
>  > Henri Sivonen wrote (on 3/10/08 3:03 PM):
>
> >> Allowing inline SVG in text/html is an interop problem with
>  >> existing UAs no matter what. The justification for introducing such
>  >> an interop problem is the assumption that the non-inlineability of
>
> >> SVG in text/html is holding SVG back and enabling SVG in text/html
>
> >> would allow SVG (in the sense it exists as a DOM language) take off.
>  >
>
> > I disagree that this is what is holding SVG back.  I believe that
>  > one of the major things that's held it back is that, until the
>  > couple of years, there have not been desktop SVG User Agents that
>  > implemented a complete and interoperable enough subset of the spec
>  > to make it useful for authors to deploy.
>
>
> Yes, the lack of UAs has held SVG back. One could speculate on the
>  relationship of lack of text/html integration and pressure to implement.
>
>  Anyway, lack of text/html is holding back using SVG as an inline
>  progressive enhancement as in Sam Ruby's blog:
>  http://intertwingly.net/blog/
>
>  Those SVG icons are nice to have. They are not essential, so losing
>  the visibility of the text content in IE would be an unreasonable
>  trade-off. Moreover, unlike Sam, normal people use content management
>  systems they didn't write themselves and that they cannot easily patch
>  to be well-formedness bullet-proof.
>
>  As it stands, a random Web author whose publishing workflow is just
>  putting static files in a directory somewhere cannot easily use this
>  progressive enhancement, because making the main content visible in IE
>  while making the enhancement visible in Gecko/Opera/WebKit would
>  involve tweaking mod_rewrite which may not even be available for
>  tweaking.
>
>  For a random author using a typical PHP blogging system (which could
>  be patched to vary the Content-Type header with relative ease),
>  turning all the bogo-XHTML output into real bullet-proof well-formed
>  XHTML output is too big a hurdle standing in the way of dropping some
>  SVG inline.
>
>  When people find that adding SVG eye candy is too hard and continue
>  without adding it, the existing installed base of SVG viewers doesn't
>  win. However, SVG as a plausible DOM language loses.
>
>
>  > Obviously, the other thing that's held it back is the fact that
>  > Internet Explorer has not yet implemented it natively.
>
>
> More to the point, making inline SVG work elsewhere, the document has
>  to be served using a content type that hides even the XHTML parts from
>  IE. This pretty much defeats the progressive enhancement use case
>  whereas the lack of all SVG support in IE is a problem when the SVG
>  images are essential content.
>
>
>  > Now, SVG is much more widely deployed, and implemented natively and
>  > well on 3 of the 4 major browsers.  IE's browser share is declining
>  > steadily, making the browsers with native implementations much more
>  > important, despite lack of support in IE.
>
>
> The bulk of complexity in those implementations is above the DOM
>  layer, though. It is already possible to inject SVG elements from JS
>  into a DOM initialized from text/html, but doing so is hard. It seems
>  silly not to tear down the last barrier.
>
>
>  On Mar 11, 2008, at 11:16, Doug Schepers wrote:
>  > Henri Sivonen wrote (on 3/10/08 4:51 PM):
>  >> Pure technology value is a characteristic of a given technology
>  >> without regard to how it interacts with other stuff. For example,
>  >> the number of polygons a game console can shade per second is a
>  >> characteristic of the game console that doesn't depend of external
>  >> factors. A game console becomes more valuable when there are more
>  >> games available for it and more games become available as there are
>  >> more console units sold. A game console with higher shader
>  >> throughput but no games is of no value compared to a less
>  >> performant console that has a lot of games available for it. When a
>  >> new console with almost no games is launched, it is less valuable
>  >> than a console from the previous generation with a lot of games. A
>  >> smart strategist creates the new console to leverage the network
>  >> effects of the existing ecosystem by making the new console
>  >> compatible with the games of the previous generation.
>  >> XHTML totally failed to use the well-known strategy of leveraging
>  >> the existing network effects by being compatible with the installed
>  >> base of the previous technology generation.
>  >
>  > I strongly agree with you here.  I think that that was a serious
>  > failing of the deployment of XHTML.
>  >
>  > I also want to emphasize, however, that the same situation obtains
>  > in reverse here.  SVG already has a wide deployment base on mobiles,
>  > and in legacy viewers, that demands strict content (with the odd
>  > exception in the case of namespace declaration in Adobe's viewer).
>  > The network effect would be critically lessened if an incompatible
>  > serialization of SVG were deployed, as I said before.
>
>
> Indeed, enabling SVG in text/html would not tap into the network
>  effects of the existing SVG viewer installed base. (It would tap into
>  existing SVG renderer code, tough. And to the network of SVG creation
>  tools.)
>
>  There are different network effects to tap into. After all, XML did
>  plug into an existing network--SGML--but that ecosystem was less
>  important for Web success than the text/html ecosystem derogatorily
>  dismissed as tag soup.
>
>  The idea of enabling SVG in text/html assumes that tapping into the
>  network effects of text/html on the open Web (the ultimate network
>  effect?) is more important than failing to enrich the existing network
>  of SVG-enabled handsets directly. Note that enabling SVG in text/html
>  would drive demand for improvements in code that would be shared
>  between serializations in software that'd end up supporting both and
>  would drive demand for SVG creation tools. So I do believe SVG in text/
>  html would give a boost to SVG on the whole.
>
>  --
>
> Henri Sivonen
>  hsivonen@iki.fi
>
> http://hsivonen.iki.fi/
>
>
>

Received on Tuesday, 11 March 2008 14:52:06 UTC