Can any one please give me some clarification on this:
I have to do some annotations on images like measurements, mark and text. Is this possible with SVG?
Do we need to install any external plugins to work with SVG in a web browser?
Will it be supported by mobile browsers?
what are the advantages of SVG over HTML5?
Question: I have to do some annotations on image like measurement,mark and text. How can it possible with svg?
Answer: This is possible using a combination of SVG, which when embedded in HTML becomes part of the DOM, and JavaScript to manipulate the SVG elements just as you would with any HTML element and JavaScript.
Question: Do we need to install any external plugins to work svg in a web browser?
Answer: No, most modern browsers render SVG.
Question: Will it support mobile browsers?
Answer: http://en.wikipedia.org/wiki/Scalable_Vector_Graphics#History_of_SVG_mobile_support
Question: what are the adventages of svg over Html5?
Answer: SVG is part of the DOM, which means it can be styled by CSS, manipulated with JavaScript, animated, etc.. Html5 Canvas is a JavaScript API which allows us to draw programatically. This means that SVG is nice for quick sleek graphics and can also be created with commercial or open-source SVG Editors. SVG can be animated or interacted with via JavaScript and styled via CSS. With the HTML5 Canvas you must use the JavaScript API to give life to your canvas. HTML 5 Canvas is higher difficulty curve, but can be much more robust than SVG (Chrome Experiment).
Related
Setup
The topic SVG vs. Icon Font is well covered in the web. But even after long searches, I did not find advice concerning my special situation.
I have a site served by a CMS. On one page, I have elements containing several icons. These elements are repeated over the page. So each icon shows up a lot of times on the page. Now I have a hard time to figure out how to realize those icons best.
Inline SVG
In general, I totally see the benefits of using Inline SVG. It's most simple and straightforward, and you can do the most with it. On other, non-repeated places on my website I already use it and I love it.
But: Repeating the exact same svg markup over and over again seems like blowing up the document unnecessarily.
Referenced SVG
I could use the SVG via the <img>, <object> or <embed> tag. Doing this, the SVG would be referenced and therefore only data that is unique is transfered via the web.
But: Besides things like using the side CSS for the SVG ist not possible, I have several extra HTTP requests.
Icon Font
I could use an Icon Font. Only one HTTP request and content is referenced.
But: Bad markup, bigger file than the SVGs.
SVG Sprites
I could use a SVG sprite. Only one HTTP request and reference.
But: It's quite comlicated and feels as much as a hack as using the Icon Font does. Plus I have the impression that background-SVG ist not so easy to use.
Conlusion
To come up with the best solution, I think the following questions are relevant:
Is repeating the SVG markup so bad compared to the other solutions? It's what I do with the HTML markup anyway. A SVG-Icon are about 30 lines / 1.6kB of code
Networkwise: Are several small HTTP requests (referenced SVG) or one big (bigger than the small ones combined, icon font) request faster?
Which advantages do I really have using SVG sprites compared to using an Icon Font? I guess it's at least as much CSS-fiddeling as an Icon Font.
Please note: I use AJAX, so only content is transferred. The icon font would load with the first request of my website (and then be cached), the referenced SVGs would load with the first call of this special page and then be cached. Inline SVG would be transferred on each call of this page, as content is not cached in the browser.
My feeling is an icon font or inline SVG would be best. But I am thankful for every contribution and aspect of this topic.
Why would you repeat exactly the same markup when you could use <use> elements to reference and display multiple instances of that markup? Here's a link to an example.
As for <img> <object> etc browsers can cache these if you set Expires and Cache-Control appropriately in your http responses.
Using Icon fonts would seem like you're shoehorning into something inappropriate for your use case.
In all given your requirements, <use> elements would seem most appropriate.
There might not be a best fit answer to this situation beyond weighting out the pros and cons of each.
I personally tend to go on the all inline approach, especially if the combined file footprint is smaller than a font or one huge svg.
using <img> is great if the browser can cache them (especially if you have lots of repeat visitors)...but you end up giving up on the styling and interaction options. you also need to add a bit extra mark up for some older browsers to serve a png file in the case that svg is not supported.
If you are interested, here is a hack I use for serving pngs vs. svg basically it fixes IE:
<!--[if lte IE 8]><img src="img/youricon.png" /><![endif]-->
<!--[if gt IE 8]><img src="img/youricon.svg" /><![endif]-->
<!--[if !IE]> --><img src="img/youricon.svg" /><!-- <![endif]-->
If I want a simple two color gradient background, would it be accurate to say that SVG would have more cross-browser support than HTML5?
I checked for Gradient support in old browsers in SVG and they all appear to support them. However, some real-world experience can help shed some light on the pros and cons of these two choices? There are some questions asked earlier but they do not address this specific case of a simple two-color gradient to be used as a background and comparison with HTML5 gradient support.
Also, I would like to know if the same SVG or CSS, whichever option is chosen, will work for all the major browsers or is there tweaking required to support different browsers. For emphasis, I repeat: I AM NOT LOOKING FOR ANY FANCY BACKGROUND, JUST A TWO-COLOR GRADIENT.
(An auxiliary optional question: Will SVG support eventually die in browsers given its lack of popularity?)
The only browser version with significant marketshare that supports SVG but not CSS3 gradients is Internet Explorer 9.
Pros of using SVG gradients
IE9 support
It's cleaner linking to an external SVG file rather than
using vendor prefixes for gradients
Cons of using SVG gradients
Causes an additional request unless you base64 encode it and embed it in the CSS file.
If you embed the base64 version of the gradient then it's difficult to modify.
Your concern for SVG's future is greatly exaggerated. There's plenty of interest in SVG given new high resolution displays ("retina") an it is used by major javascript data-viz and graphing libraries. If anything, the future actually looks brighter for SVG.
I personally use SVG gradients when I need IE9 support. I use Microsoft's SVG Gradient Generator and use the base64 version as to not cause an additional request. I haven't run into any issue at all, SVG gradients behave just like their CSS3 counterparts.
I have two SVG images, both together have about 8000 lines and consist of several shapes with gradients. No patterns, filters, texts, just basic graphical elements with strokes, simple- or gradient fill.
At the moment they are injected inline into the HTML while it is generated, so the source code becomes quiet large. Does this decrease performance for animation, so that it would better to embed the svg differently?
Is there a general rule of thumb to follow when embedding svg?
Greetings philipp
If you use the HTML5 SVG tag to embed the SVG inline that will not just increase the html file size but also keep DOM busy and your browsers renderer.
If you use iframes you don't really know when it gets loaded or rendered, at least not for all browsers.
HTML5 offers you JavaScript and that might be the solution.
Just wait for the body to load and then inject the SVG.
You can use body-onLoad or jQueries ready()-funktion
Here is how it's done in jQuery:
<!DOCTYPE html>
<html>
<body>
<div id="svg-01" class="placeholder"></div>
<script src="path/to/jQuery.js"></script>
<script>
$(document).ready(function(){
$("#svg-01").replaceWith('<svg><!--// some svg //--></svg>');
});
</script>
</body>
</html>
I would even go a step further and rather use replace it with an iframe and gziped SVG as described here.
I have a web service that returns a string of svg code. My problem is, I'm not sure what to do with it. I've never worked with SVG before. My questions are:
Does SVG have strong support by common browsers?
How do I actually display the image that the SVG represents?
SVG is supported by nearly all major browsers except IE i think but that also can be rendered with some plugin. IE renders VML
I suggest using RaphaelJS http://raphaeljs.com/reference.html#image
EDIT :
var r = Raphael("holder", 600, 540); //"holder" is the id of an empty div in html file
r.image("lion.svg", 140, 140, 320, 240);// r.image(src,x,y,width,height)
Svg is a specification for XML. Most modern browsers can just display it inline, but Internet Explorer can't.
I recommend wrapping all your svg content in svgweb, which is a thin layer around the svg code. If the user is using a standard compliant browser, it will display the svg normally. Otherwise, it converts it into flash content.
Starting with HTML5, you can embed SVG directly in a HTML document. This is supported by all of the major modern browsers, except Internet Explorer. You can use the HTML canvas concept (as illustrated here )
But, since you most likely can't leave IE folks behind yet, you can go with one of the three legacy options shown here
Most state-of-the-art-browsers do support SVG,
but few still used browsers (for example Internet Explorer 7) fail.
So for perfect compatibility you should stick to gif, jpg or png formats.
Test your own browser here: http://alphanemoon.com/2008/artikel/inline-svg-browser-test.xhtml
Is it possible to draw with your finger using the iPhone or iPad in HTML5? If the user were on a PC then the user would need to be using a mouse for the same effect.
Yes.
Check out deviantART's new drawing tool Muro for an example, and Apple's Safari DOM Additions Reference for an overview of the API.
It sounds like you're looking for something along the lines of SketchPad. It uses a <canvas> element in browsers that support it (and fakes it in IE).