intertwingly

All on Ubuntu Breezy:

Yup- Firefox 1.5.0.2 Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.2) Gecko/20060308
Yup- Seamonkey 1.0 Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060130
Nope - Konqueror 3.5.2/KDE 3.5.2
Nope - Liferea 1.0

Um - what’s in the present??  Did you leave it behind?

Camino 1.0.1 on OS X does.

Gregarius (based on MagpieRSS): nope, even if I add all of the svg tags and attributes (sans xlink:href, which it only allows as xlinkhref) to its tag whitelist.

On OSX
Sarari 1.3.2 - Nope
FF 1.5.0.4 (as you might expect seeing as it works elsewhere) - Yes.

I’ll try Safari 2 on another box shortly.

No go on IE 6.0 either but that is probably to be expected.

No luck on Safari 2.0.3 (417.9.3)

No luck either on NetNewsWire 2.0.1

Yes on Opera 8.02 (Mac).

No go on Safari 2.0.3 on OSX although it is coming apparently.

I wouldn’t hold your breath Microsoft are more interested in shipping WPF/E than SVG (in a classic case of the usual NIH).

Safari with a recent nightly build of WebKit shows the inline svg if the page is sent as xhtml (which it isn’t). It works as a local file with a .xhtml file ending.

The official Safari 2.0.3 release does not handle inline svg.

Fine on Firefox 1.52, running on Linux 2.6 Intel, Displaying on Solaris 10 on Intel. Also fine on Firefox (Deer Park), native on Solaris Intel.

I see a parcel too.

All on Windox XP SP2 (up to date):

NO: IE6 (Latest version: can’t copy/paste versionr.)
NO: IE6 + [link]
NO: IE6 + [link]

Yes, but no transparency (white background): Opera Version 8.51, Build 7712
Yes: FF 1.5.0.4

Opera 9 beta 1 (Win XP): I can see it.

Transparent in Opera 9. Works like a charm.

Works fine on Firefox 1.5.0.4 on OS X when viewing the site (Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.4) Gecko/20060508 Firefox/1.5.0.4), but Bloglines seems to have stripped the SVG.

hi there,

  firefox 1.5.04 on window xp sp2.

BR,
~A

To see it in WebKit, you need a nightly and the content served using an XML media type. But then the image placement isn’t quite right.

On Mac, the rendering is broken in Opera 9 (build 3336).

As above, works just fine in Firefox.

Not shown in Google Reader.

Firefox 1.5.0.4 on Win XP SP2: no problem.

Works for me:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.4) Gecko/20060508 Firefox/1.5.0.4

It’s too bad, though, that you can’t yet do something like this:
<img src="bench.svg" />

@Duncan:
Um - what’s in the present??  Did you leave it behind?

Think Forrest Gump.

I can see it fine in epiphany/ffox when looking directly at your blog, Sam, but I don’t see it in planet.intertwingly.net.

I Lied. Deer Park doesn’t display it. This was caused by the shell relaunching the running Linux-remote instance of Firefox. Whoops. Sorry.

The markup is present in bloglines but not displayed (Firefox 1.5.2, WinXP).  The media type of the page (from bloglines) is text/html.

Firefox 2.0a3 (Bon Echo) - OK
Firefox 1.5.0.4 - OK
Opera 8.54 - OK

I don’t see it in planet.intertwingly.net

I’m nearly there now.  It is little problems like the fact that the viewBox attribute is camel case that is tripping me up.  But I will get there.

Flock beta 1 - yes.

NO: Firefox 1.0.7

SVG 1.1 is a beastly-huge spec. How did you decide what subset to whitelist?

SVG 1.1 is a beastly-huge spec. How did you decide what subset to whitelist?

I took four small samples and added only enough to support those particular samples.  I don’t claim to support SVG just yet, or even a useful subset.  I’m just exploring to see what the issues are.

OK in Firefox 1.5.0.4 on a WinXP/SP2 machine.

No way in Thunderbird 1.5.0.4 (same machine): the markup’s there, but not displayed. I suppose it’s because Thunderbird’s message/rfc822 “internal” representation of the entry uses Content-Type: text/html; charset=UTF-8 (text/html, not application/xhtml+xml).

It is not visible in the newsfeed reader in Opera 9, though it shows up fine in the browser. I can see the SVG elements are preserved, but they are not used in the mail view.

An old version of inlining SVG has been supported in IE since early 2000 (although it isn’t supported natively).  It is done via a nasty hack of an object tag, a PI instruction, the Adobe SVG viewer, and an IE only technology called element behaviors.  You can see an example of this here: [link].  But, I don’t think you could get this old style of inlining to work for your test (and I’m pretty sure it isn’t even worth the effort, as the new inlining is a much better way to do it).

Don

No: Newsfire 1.3 (OSX)

As everyone else reports, it’s fine in FF 1.5.0.4. When I read the feed through NewsGator Online, the SVG doesn’t carry through, though.

FeedDemon 2 (synchronized with NG Online) entirely strips the SVG.  NewsGator Online (in Firefox 1.5.0.4) displays the inline text “Bench, Forest Gump Box of Chocolates Bench”, I’m guessing that it’s stripping unknown markup and leaving the text, though I’m not familiar with that part of the code.

With SVG intergated in FF, not a plugin, the svg is just part of the dom and you can use e4x to manipulate it.

I took four small samples and added only enough to support those particular samples.  I don’t claim to support SVG just yet, or even a useful subset.

In the case of Presentational MathML, you had an inside track that 27 of the 32 elements in the Specification comprised a “useful subset.”

In the case of SVG, you could either look at what subsets are produced by common authoring tools (e.g. Adobe Illustrator). Or you could look at what subsets are supported natively by browsers (Firefox, Opera and WebKit).

Unfortunately, these subsets are not the same ...

Philippe Janvier : Inline SVG - “Browsers and aggregators support with inline SVG”. Tags : svg agregateurs navigateurs...

Unfortunately, these subsets are not the same ...

Fortunately, all I need to support is the subset of SVG which is likely to be placed inside of a feed.  At the present time, I seem to have a monopoly on that.  ;-)

At the present time, I seem to have a monopoly on that.

Only because Mozilla/Firefox doesn’t implement certain (to me crucial) features of the SVG Spec.

There are things I’d love to do, which would work perfectly in a compound (XHTML+)MathML+SVG documents. Unfortunately, after noodling around for several hours, it transpires that (for instance) it’s just not possible to embed MathML in SVG with the current Mozilla/Firefox SVG engine.

So, for the foreseeable future, you’ve got the (XHTML+)SVG in Atom playing field all to yourself ...

some of the latest work being done on Moz SVG:

[link]

Umh, yeah. Seems to be some support for <foreignObject> in the latest nightly build.

Still can’t embed MathML, though...

No SVG display in IE7 (without adobe plugin), works in Firefox/1.5.0.4

“Browsers and aggregators support with inline SVG”....

“Browsers and aggregators support with inline SVG”....

Don’t write your interactive Web application in custom Javascript! The Web’s Declarative nature needn’t be broken just because you want two-way dynamic data instead of one-way documents on your site. Instead, write Declaratively to generic...

Don’t write your interactive Web application in custom Javascript! The Web’s Declarative nature needn’t be broken just because you want two-way dynamic data instead of one-way documents on your site. Instead, write Declaratively to generic...

Using ZipProtocol you can use
<img src="Zip:;;/YourDomain.com/YourSvg.svg">
or
<style>
.{backgound-image:"Zip:;;/YourDomain.com/YourSvg.svg"}
</style>
using Google gor ZipProtocol will lead more info.

Konqueror 3.5.5 with the KSVG plugin does not display the bench, though Konqueror will display SVG files directly in the file browser.

no with konqueror 3.5.6 although this link here works fine with it. I guess there is not only incompatibility within different browsers being able but also how to get them to do it. the other link btw. does not work with firefox, but firefox 2.0.0.2 works with this site

As you may or may not have noticed, I switched my web site to serving pages as XHTML, using a Wordpress plug-in Content Negotiation. Until I work through all the kinks, the pages may serve up oddly based on browser. One thing about this approach is...

The bench looks perfect on Safari beta under Windows XP. Cool! Works perfectly under Opera, works perfectly under Firefox... bye-bye IE!

Oh, I’m only testing on Windows because some of my clients are still under the impression that Linux is difficult to use ;-)

Bench displays in Galeon, a Mozilla variant on debian linux.

Fine in Firefox2.0.0.6, but if the filename is .html, rather than .xhtml it doesn’t work.

The accessibility orthodoxy does not permit people to question the value of features that are rarely useful and rarely used....