Almost Daily


Mozilla and Opera SVG Plugin Install Files

I already mentioned below that Adobe released a beta preview of their SVG plugin. Since then a few people have written and experienced difficulties in getting the new plugin to work on Mozilla and Opera.

It appears that on some systems the Adobe plugin is not installing in Opera or Mozilla. On a Windows platform you can copy the plugin files over directly from Program Files > Common Files > Adobe > SVG Viewer 6 into the browsers plugin directory. For Opera 7 this is Program Files > Opera 7 > Plugins and for Mozilla, it is Program Files > > Mozilla > Plugins.

To make life a little easier for users you can download some installation files I made that will load the plugin for the respective browsers on a Windows platform in thier correct default location. Please note, the installation files will load the Adobe plugin files to their default locations for each browser. If you have installed to a different location than the default, then browse to their location during the setup procedure. Just download the zip file you want, unzip it and click on the setup.exe file and it will do the rest.

Before downloading please note the files don't come with any warranty and are to be used at your own risk. This is just a service I am providing, till the Adobe final plugin is released. Hopefully that should see these current installation problems fixed.

For Opera 7, the zip file is located here

Download Adobe SVG Install Files for Opera 7

For Mozilla users, the zip file is located here

Download Adobe SVG Install Files for Mozilla

SVG Section Soon:

I have a fair bit of SVG content offline that I haven't uploaded as yet and I thought that it would be easier to manage this site and also easier for users if a new section housed those files. That section will most likely expand to cover other technologies, such as XAML, MNG, SMIL and what ever else I feel like playing with at the time.

As a bit of a teaser here are a few SVG static files I have produced of late. Both of these files use multiple paths to achieve their outcome, which make them good to learn from. They are not final pieces as both can be optimized further in terms of code weight and efficiency. This will be done before the new section gets under way.

Here are the two teasers for you;

Cartman in SVG

Blue Flowers


A Hat Tip

One of the encouraging things to come out of the last week in relation to different rendering across browsers is that there is an earnest desire to achieve standards; well at least on the part of Opera, Mozilla and Safari. I know this because someone from within one of those organisations has written to me and been prepared to discuss and clarify some things. The only reason I don't mention the person by name is because I have not asked their permission to do so. I will ask for permission to do that, but at any rate, I just think it speaks volumes that at least some people care enough to not only clarify things, but also are prepared to invest some energy into getting things fixed where appropriate.

I think that is worth remembering and its puts things into a more positive perspective.

Now if only Janet Jackson would come over to my place and do a repeat super-bowl performance for me, ill be a happy man :-)

Adobe SVG Plugin Beta

My friend RJ who has contributed to site with some SVG examples ( I have a few more I need to upload) has me thinking about SVG again.

One of the reasons why I backed off SVG was performance related issues. Basically I found that my pc came to a screeching halt when doing some animation work. Adobe released a preview version of the SVG Plugin which seems to have much better performance that its predecessors. On top of that it has a bunch of new features so those interested in working with SVG can download the beta plugin from here;

Link To Adobe Beta Plugin

A Little More on SVG

One thing that's bugging me at the moment with SVG is that clipBegin="1.8s" clipEnd="8.6s" don't be seem to working at least not in a straight forward implementation. I had an idea about making a cool SVG MP3 player. It's not so much that we need another MP3 player out there, but I wanted to do a reasonably in depth tutorial on it and show off how some standards based technologies fit together.

The reason I want to be able to clip audio to a specific region, is so I can cut out the extra information that mp3 hold by default, which throws an mp3 audio loop out of synch. I could do it without mp3 loops, but it kind of defeats the purpose of a web based mp3 player, where we want the file sizes to be comparable to those that Flash is capable of producing.

So unless someone has a bright idea about how to get clipBegin and clipEnd to work, that little project is at a standstill. Hmm maybe using multiple namespaces is the answer here, just a thought.

3-Feb-04 Evening

Ooops Forgot Safari:

I forgot to mention, I have not included Safari in the browser tests below. They are on the way however and the table of results will be amended shortly.


When Supported Doesn't Mean the Same:

I spent the better part of a day testing various implementations of element, CSS and DOM rendering behaviour across browsers. A couple of things stood out in my mind.

You often see cross browser charts stating that such and such a feature is supported. These sorts of charts provide valuable information for developers and designers. But it occurred to me that we also need some additional reference charts that outline the different rendering behaviours of browsers and if possible suggest some interim solutions.

I think it is important for developers and designers to know that the H1 element renders at different heights in different browsers. Equally it is important to suggest that redefining the H1 element in a style sheet definition alleviates the problem.

The problem with that is it will be a lot of work for someone to undertake. Imagine going through every XHTML element, checking each element in each browser, testing each elements height, width, position, stylistic rendering and so on. Then do the same for CSS, then add the DOM and to top it all off, combinations of the three.

But what a valuable resource that would be! A developer could simply go the relevant item and check how it renders on the major browsers and obtain all sorts of valuable information. Similarly the browser manufactory could go to something like this, and bring themselves inline with other browsers.

I am tempted to do something along these lines, but as I said it would be a major undertaking to invest in and I really need to think about this with more depth and clarity before I invest in a project of this scope.

The other thing that occurred to me was part of the differences that occur between browsers is due to a lack of specificity on some W3C specifications. For example, what should the default table borders render as? What color should be used?

The problem this creates is that each browser manufacturer is left to their own interpretation, because there is no specification to work from and consequently we see different rendering behavior. In other words no particular browser manufacturer is in the wrong nor in the right, they are just caught in no man's land.

One solution would be for the W3C to issue new specs, but that typically is a long and involved processes. Perhaps that is more a long term solution, but should be considered at any rate.

Another could be that the browser manufacturer's sit down together and split all the differences into equal proportions. For example, let us say we have Opera, Mozilla and IE and Safari as the major players. When no specification exists, then ¼ of those behaviors would be done the Opera way, ¼ the Moz way, ¼ the Safari way, and ¼ the IE way. This would distribute the work load evenly amongst the browser manufacturers with each having to change ¾ of the way their browser renders.

No doubt someone will come up with a better suggestion and a better way of doing this and really how we get there in the end is irrelevant to me. The only thing that is relevant is that somehow and in some way, we end with standardized rendering behavior across all browsers.

Apart from those thoughts, I actually did do some testing :-) and the results can be viewed by clicking below.

A Few Browser Tests

I need to state that I tested a lot more stuff (that initially appears broken) than appears in the list above. Originally that table was around 70 items long ( and I suspect the rendering differences number in the hundreds rather than tens, there is just so much that I did not test for), but as I thought about what I was going to present, I realized that my testing procedures needed to be a little more refined and stringent and I had to remove certain extraneous variables from tests that may be influencing the results one way or another.

In short I need to retest some things and be a little surer of the results before presenting them.

Blog Archives

Janaury 2004 Archive