Re: SVG and MathML in text/html

On Mar 10, 2008, at 23:14, Jeff Schiller wrote:

> On 3/10/08, Henri Sivonen <hsivonen@iki.fi> wrote:
>> On Mar 10, 2008, at 19:03, Jeff Schiller wrote:
>>> Then we'll have people creating inline SVG for HTML that won't
>>> work in the many SVG tools and viewers that are already out there
>>> and we'll just have frustrated authors.
>>
>> As pointed out above, SVG in text/html won't work in existing SVG
>> tools and viewers even if the syntax inside HTML was a well-formed  
>> XML
>> island. After realizing that I won't work anyway, there's no point is
>> sticking strictly to XML tokenization.

Oops. ...it won't work anyway... I was typing way too fast. :-(

> Sorry, I mis-understood something earlier.  Can you please help me
> understand why the following:
>
> <html ...>
>  <body>
>  <svg xmlns="http://www.w3.org/2000/svg"
> xmlns:xlink="http://www.w3.org/1999/xlink" ...>
>    <a xlink:href="foo.svg"><circle .../></a>
>  </svg>
> </body>
>>> </html>
>
> wouldn't work (i.e. copy-paste the SVG section into a <?xml
> version="1.0"?> doc?  To my knowledge it would work just fine (and
> has).

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.

>>> Then some tools might feel forced to accommodate the lax HTML-style
>>> of SVG,
>>
>> Indeed. If we enable SVG in text/html, this will be the case even if
>> we insist that only XML-looking stuff is conforming.
>
> Again, I guess I didn't understand this.  Why would conforming SVG in
> text/html not work in tools?

Because tools aren't expecting SVG to be wrapped in non-XML stuff  
(HTML). And usually SVG editors don't expect the image to be wrapped  
even in XHTML, right?

>>>   2. I hear that some browser don't properly handle namespaced
>>> content or colons or something.  Can someone clarify which
>>> browsers?  Can someone further clarify what exactly the problems
>>> are?  Can someone confirm if that browser will have fixed itself,
>>> say, next year would we be good to go?
>>
>> IE does its own thing in text/html with the colon. OTOH, other
>> browsers don't do anything in particular with the colon in text/html
>> and existing content expects that they don't. We cannot specify a
>> colon-based mechanism that would cause spectacular breakage with
>> existing content that expects browsers other than IE not to do
>> anything special on the colon.
>
> This is the case that I would like to understand.  What type of
> text/html content uses a colon and doesn't expect "anything special"?
> And what does "special" mean in this case?  What kind of colon-ized
> content is out there that we can't break in Firefox, Opera, Safari?

We cannot break output from Microsoft Office foremost. Also, as far as  
colonless xmlns processing goes, we cannot let an xmlns on root to  
have an effect because there all sorts of bogus declarations out  
there. I believe Opera has more experience with this. It would be good  
if an Opera representative could comment more specifically.

>> I have a problem with namespace URIs every single time I need to deal
>> with XHTML, SVG, etc. I always have to waste time looking up and URI
>> to copy and paste because trying to go by memory and getting it wrong
>> (which year? trailing slash?) would waste even more time.
>
> My primary concern is that we have an existing XML language that is
> relatively widely deployed - a variety of tools out there, a variety
> of viewers out there.  Changing the language means that some tools
> will support the changes and others may not.

Yeah, introducing SVG in text/html would cause incompatibility with  
existing SVG viewers. In order to bootstrap the system, it is crucial,  
though, that XML-based SVG images can be pasted into the text/html  
direction.

> This will lead to frustrated authors and frustrated developers.


The expected good thing is that SVG could be used more if it could be  
used with non-XML content management systems and decorative SVG could  
degrade gracefully in legacy browsers without content negotiation.  
Trading one frustration for another. Whether it is a good idea depends  
on what value you assign to each frustration.

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Monday, 10 March 2008 21:44:38 UTC