> Michael, as far as SVG goes, until the day when
> Internet Explorer supports SVG natively, and you > don't have to install a plugin to view SVG, I
> think it's perfectly fair to categorize SVG as
> I've done.
I don't think it would be possible for me to disagree more with that statement. The "installation" of Adobe SVG in brainless at best. And with a little auto-detection scripting its easily automated.
Look at Flash. If a user doesn't have Flash installed which, given that Flash has always been a plugin and never a function of the browser itself, they have been required to visit the site to download and install it(read: If it shipped with the browser natively, requiring no effort by the end user, your point might have some validity.) What your suggesting could never happen with SVG in IE is exactly how Flash became embedded in 96% of the worlds browsers -- 95% of that 96 was IE.
What makes Flash capable and yet Adobe SVG incabable? Whether or not Adobe agressively begins to push there SVG plugin, or stear more towards Flash is of no great concern or consequence. Its available, easy enough to write a script to detect for it and if not available, link or redirect to the download site. And with as many rendering engines that are coming from every direction you look, if Adobe decides to bail out on it you can rest assured someone else will take advantage of the bad press and become a household name overnight.
In fact, for a small company who has a few investment dollars available I would recommend this as a fantastic strategy to gain some serious notice in a hurry. Even if they continue to waffle on SVG for the next couple of years like they have for the last, theres still plenty of opportunity to take advantage of their waffling by making sure that those with the ability to get the word out in a hurry know about your product such that when the pressures begin to mount over the next 6-12 months for Adobe to make a decision you can be recommend as an alternative which, as long as your solution ROCKS!!! will be just what the doctor ordered to push your company into hyperdrive.
Don't know any developers capable of writing an SVG rendering engine? Don't worry, I know plenty... I don't have experience in this area and you would need someone with experience to do it right the very first time around. But like I said I know MANY developers in this area. If you're that company, let me know > m.david@xmlhacker.com < and I'll help get you in contact with the right person/people.
---
One last point. The fact that XMLHTTP doesnt require a browser refresh to update content doesn't make it asyncronous. Try setting async to false and point it at a hefty XML file or even a regular web page with lots and lots of content and graphics and then try to work within your browser while that process is taking place. You can't. The browser will lock things up until the 'syncronous' operation is complete.
I don't think there is an argument here. It seems to me that the author is just saying that this is the current status of these technologies.
Lets be honest, SVG is not a very pervasive or ubiquitous technology, and I know from experience that if you are in a large national or multinational firm and want to get end users to install plugins or other software, it's a logistical nightmare. To some degree you can control the browser platform they are using since those are well understood and trusted technologies, but beyond that.. forget it. (Am I wrong??)
ok so my opinion is that Ajax appears to offer a middle of the road solution that circumvents the kinds of issues that face large corporations, and allows for some pretty powerful and creative solutions in the way that other technologies mentioned here (XUL, SVG) do.
michael_c_harris wrote:
"It's not really fair to lump SVG in with Java and Flash as requiring a the user to install a plugin"
JordanFrank wrote:
"Michael, as far as SVG goes, until the day when Internet Explorer supports SVG natively, and you don't have to install a plugin to view SVG, I think it's perfectly fair to categorize SVG as I've done."
xmlhacker wrote:
"I don't think it would be possible for me to disagree more with that statement."
What could you possibly disagree with. Nothing that I wrote was subjective. I simply stated that Flash, Java, and SVG all require proprietary browser plugins in order to operate on all the major browsers. This is a fact. This is not something you can agree or disagree with.
To address your point about what makes Flash capable but SVG incapable, I have the following to say. I don't think that SVG is not capable of gaining widespread traction. I never said that, and I wouldn't. When Flash came out though, it was the only major technology of the sort that had a huge, smart vendor behind it. I don't remember it facing any tough competition when it came out. If it did, it very quickly blew the competition out of the water. The same cannot be said about SVG. There's VML, which Microsoft has integrated into Internet Explorer, and there's XAML, which will also include the same capabilities. There's also XUL, and Canvas, and a bunch of technologies that can do similar things. SVG doesn't fill a niche that is currently unfilled. Flash did. And so SVG is going to have a much harder time gaining traction. Maybe it will, maybe it won't, but I wouldn't advise anyone to put all of their eggs in the SVG basket. Anyways, this may not be the best forum for debating the merits of SVG, but if you want to continue this conversation, then feel free to email me at jfrank@ebusiness-apps.com.
As far as your point about the XMLHTTP Request object, you are correct. The object does allow for both synchronous and asynchronous behaviour via the async property.
Cheers,
Jordan Frank
eBusiness Applications - http://developer.ebusiness-apps.com/
"Michael, as far as SVG goes, until the day when Internet Explorer supports SVG natively,<snip/>"
My point is that I don't believe in any way that native support for SVG in IE is as important as you are making it seem. As I stated the ability to view SVG in IE exists and has existed for quite a while. The fact that in addition to the Adobe SVG plugin for IE both Mozilla/Firefox and Opera (Tiny SVG only) now have support will result in more sites offering SVG as a viewing option. While Moz/Fx may never take the majority share of the desktop market the impact that it has had and will continue to have on the development trends can not be taken for granted.
I do agree that XAML is an important technology as well. I'm a HUGE proponent of XAML. But I'm a huge proponent of SVG as well. At the moment, all that SVG can do XAML can do as well + the added benefit of integration into the .NET Framework Class Libraries. But thats only part of the story. The fact that SVG has a degree of separation from any specific platform lends well to its credibility as a cross-browser/cross-platform solution. This is an important point. It really does matter. Add to this the fact that the Mozilla Foundation has put heavy emphasis at bringing SVG support to the Mozilla platform while at the same time making it *EXTREMELY* easy to mix and match XUL, SVG, HTML/XHTML and you have what can easily be seen as a fairly sophisticated cross-platform solution that is right in line with what XAML has to offer as far as functionality is concerned.
What will result from this in the end? Well, with the impact that Moz/Fx has had thus far, I wouldn't turned a blind eye to what could very well become the defacto web-based standard for markup languages. XAML will still very much exist. With Mono's XAML implementation of courtesy of Google's Summer of Code this only makes XAML a stronger case as the basis for the defacto standard for cross-platform desktop applications. At the moment, while the line between web-based applications and desktop applications is becoming more and more transparent, its still exists, and probably will for at least another 3-5 years in one form or another. As such, its risky to say the least to underestimate the impact that the Moz/Fx XUL/XHTML/SVG/CSS solution can and more the likely will have on the future of web-based application development.
Another point to consider is the number of mobile phones/devices that now offer SVG support (via Tiny SVG) [SEE: http://svg.org/special/svg_phones] which as of this post stands at Seventy Two(72). As the mobile market continues to expand their support of SVG this will become and even more appealing option for web developers who are looking to maximize their reach while minimizing their overall code base. This factor alone could have a greater impact than any of the other points made above. Combined.
Previous Message
Up
