By now “everyone” must have heard of SVG. The problem I have with SVG (besides actual problems in the specification) is that it is a presentational markup language. It is also not just an image format. In some way it tries to compete with Flash and therefore copies most of the features Flash has instead of trying to do something better. (Well, I assume the XML part is found to be better by some.) However, the markup you get is like the font element. For example:
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 2 2"> <circle cx="1" cy="1" r="1" fill="lime"/> </svg>
Now it is quite nice that you get a scalable circle with a few lines of “human readable code,” but markup like that is not something you want to intermingle with your XHTML. We would get the whole semantic versus presentational markup debate all over again. Using one of the XBL languages out there it would be possible to integrate it more or less given that XBL does not affect the semantics of the document it is bound to. However, having Vector Graphics in CSS would be even more useful.
What's wrong with presentational markup? All that matters to me is that the diffent things are separate: Document is separate from Style is separate from Templating is separate from Application UI. How each thing is actually written doesn't much matter—if CSS were XML-based, it would be a "markup language", and that would be fine.
(Note that I'm not advocating that CSS should be reformulated. I like it just fine the way it is.)
(Also note that we don't currently have separation of Document/Template/Application UI.) :-(
What is wrong with it is the way it is currently defined. SVG is starting to become some kind of application format, that is what is wrong. Another problem is integrating it with XHTML. It is possible, but not what you really want as it mixes presentation and content.
Having it in CSS keeps that separate and allows you to apply “SVG logic” to arbitrary elements.
(Note: here I'm talking about SVG as a concept, not as it's actually specified now.)
SVG is a document format. Just as HTML is a document format (mainly) for text, SVG is a document format (mainly) for images. How does one document an image? I would do it by saying "Here is a square; It is blue. Here is a circle; it is red."
What it appears (correct me if I'm wrong) Vector Graphics in CSS is doing is removing the description of the image from the document, and placing it into the presentation. Without the CSS now—without the presentation—instead of having an image you have simply a collection of meaningless elements that do not describe an image.
CSS does have a role in SVG: it's useful when what's being presented to the user is not the unmodified image. To take a real-world example, I've seen (implemented in Flash) a comic strip, where when the user hovers over a panel that panel lights up and everything else is dimmed. Here the original image would be the strip, and some pseudo-CSS that applied would be
panel{ brightness:.5;}
panel:hover{ brightness:1;}
That's all well and good. The point here is that the SVG describes image, and the CSS describes how it's presented to the user. Having CSS describe image itself is wrong.
As for SVG-as-it's-specced-now being too application-like, I agree that that's very wrong. As for what your example document with SVG embedded in XHTML... Well, I'm trying to wrap my head around what exactly it means. It's not a text document with an embedded image (it would be if you wrapped the SVG in an <object>). And it's obviously not an image document. It's a single document that is part text and part image. Which is... weird, but I'm starting to think of a few things where it might actually be correct.
SVG already uses CSS for some things. One good example is how it uses CSS for color offsets in gradients:
<linearGradient id="fugly" gradientUnits="userSpaceOnUse" x1="0" y1="0" x2="387.4998" y2="216.6664"> <stop offset="0" style="stop-color:#ED1C24"/> <stop offset="0.1854" style="stop-color:#FFC20E"/> <stop offset="0.1869" style="stop-color:#F5C122"/> <stop offset="0.1953" style="stop-color:#CEBD5A"/> <stop offset="0.2047" style="stop-color:#A6B97F"/> <stop offset="0.2149" style="stop-color:#7DB599"/> <stop offset="0.2259" style="stop-color:#50B2B0"/> <stop offset="0.2381" style="stop-color:#00B0C3"/> <stop offset="0.2519" style="stop-color:#00AED2"/> <stop offset="0.268" style="stop-color:#00ADDE"/> <stop offset="0.2879" style="stop-color:#00ADE6"/> <stop offset="0.3158" style="stop-color:#00AEED"/> <stop offset="0.3933" style="stop-color:#00ADEF"/> <stop offset="0.618" style="stop-color:#008EAF"/> <stop offset="0.6734" style="stop-color:#008EAF"/> <stop offset="0.6934" style="stop-color:#008FAC"/> <stop offset="0.7076" style="stop-color:#0092A7"/> <stop offset="0.7192" style="stop-color:#00969F"/> <stop offset="0.729" style="stop-color:#009C94"/> <stop offset="0.7378" style="stop-color:#2DA387"/> <stop offset="0.7457" style="stop-color:#54AC74"/> <stop offset="0.7527" style="stop-color:#74B85A"/> <stop offset="0.7584" style="stop-color:#8CC63F"/> <stop offset="0.7602" style="stop-color:#91C843"/> <stop offset="0.7699" style="stop-color:#A5D065"/> <stop offset="0.7809" style="stop-color:#B8D987"/> <stop offset="0.7927" style="stop-color:#C7E0A1"/> <stop offset="0.8055" style="stop-color:#D6E8B9"/> <stop offset="0.8197" style="stop-color:#E1EECE"/> <stop offset="0.8357" style="stop-color:#EBF4DF"/> <stop offset="0.8544" style="stop-color:#F3F8EC"/> <stop offset="0.8775" style="stop-color:#F9FCF5"/> <stop offset="0.91" style="stop-color:#FDFEFC"/> <stop offset="1" style="stop-color:#FFFFFF"/> </linearGradient> <rect fill="url(#fugly)" width="387.5" height="216.667"/>
What I'd really like to see is a better use of CSS than that. That entire <linearGradient> element can be used in CSS like in that css-vg document with the @fill. I personally don't care for stop-color either. It could be all integrated into something like (I'll be using more than just gradient):
@fill fugly
{gradient-type: linear;
gradient-direction: -29.21deg;
gradient-color}
Personally, I get sort of lost when I try to think of a way to add the functionality of the <stop> elements into css. It would be really nice to handle gradients in the @fill rather than having to use <linearGradient>.
In that example it would be so much shorter to just use the stop-color attribute, or whatever it is called. That SVG uses CSS is also besides the point. At least, besides my point.
I never said that it was the point. I was showing a real-life example of a gradient and how they are done in SVG, and how your provided link to a css-vg WIP could be improved. It would be shorter to use the stop-color attribute, but I grabbed this from a generated SVG gradient in Adobe Illustrator because it's a pain to create a gradient this complex with SVG. I then cleaned it up a bit. I didn't change the attributes. I don't know why. :D.
I think the best solution would be to have vector graphics in CSS. It's a great idea. It would greatly simplify SVG in my opinion.
Personally, I'd rather see SVG used with the "background-image" property than see a whole vector graphics language in CSS. Vector graphics in CSS would make it neigh impossible to author CSS by hand and use vector graphics in a style at the same time. By using SVG as a CSS image type, I can simply author an SVG file in my favorite vector graphics editor and use it as a background image in CSS. (Granted, the image won't stretch in CSS 2.1, but we have the same problem with raster graphics files.) The area that's clickable can simply be inherited from the vector graphics file.
As SVG is not really an image format (Vector Graphics in CSS is not either, but it would not have links for instance) it is still unclear to me how you can use it as in the CSS background or similar properties. This problem is actually not specific to me, most implementors have issues with that.
SVG is not really an image format
I assume by this you mean "the way it's currently specified, it's not", but you would like it to be?
Another problem is integrating it with XHTML. It is possible, but not what you really want as it mixes presentation and content.
Did I understand right that if I have a vector illustration in a textual document (not just a pretty effect but eg. a graph of some kind), you think it is a bad idea to deliver them as one XML document in one HTTP resource and the illustration should be instead be included by reference as a separate HTTP resource?
Depends on whether or not data URIs count as HTTP resources. I think not. A graph of some kind described with elements like svg:rect will still not be meaningful.
I got into a little argument with some people in #svg (including Jim Ley) after I became frustrated with trying to create a sort of map using SVG and CSS. I also struggled with the scripting because they bury properties under layers of other animation-specific properties.
I believe, with regard to using CSS, I was trying to create a popup menu with an offset. I think the only way to do this was with transformations, but that meant I had to update all these elements just to adjust the offset.
With scripting I wanted to do some drag/drop stuff. The viewport screwed that up, as did burying the element coordinates 5 levels deep.
In the end I switched to using images + CSS. Much simpler though it meant I couldn't do lots of stuff I had planned.
I agree completely that they are trying to replace Flash. All we developers really wanted was a way to include vector graphics in our web pages. Instead we get some botched up attempt at a Flash replacement.
Where's my stroke-position you dorks!