SVG and the Indexing of Web Standards

wombatmobile writes "The world's most popular search engine company is a leading supporter of open standards. It pours money and people into initiatives that promote, assist, support and implement Web standards. As a core foundation of is mission statement, all web assets should ideally be of a kind that it can work with. Strange then, that the world's most popular search engine doesn't index all of the current important Web standards formats. Doug Schepers of W3C blogs about how Scalable Vector Graphics content is recognized and not recognized by search engines, currently and historically." Readability really helps out on this site.

Comments

Standards?

[girlintraining]

This is the great thing about standards: There's so many to choose from!

Re:Standards?

[Anonymous Coward]

because almost nobody uses svg except the people who care and are aware of it and those people are able to find it. next fucking question, please.

too complicated?

[Anonymous Coward]

i suppose it has nothing to do with the fact that svg is
as complicated as javascript which itself is a more intricate
language than c++.

Re:too complicated?

[digitalunity]

Javascript is not more intricate than C++. Not by a long shot.

Re:too complicated?

[colinrichardday]

SVG may be complicated for animations/interactivity, but static images aren't that hard to do.

Re:too complicated?

[Marillion]

While some meaningful exceptions do exist, SVG is really not much more than an XML based implementation of Postscript.

Re:too complicated?

[Anonymous Coward]

Syntax is irrelevant in C++. You can learn that in a week. You won't actually know C++ even after programming in C++ for 6 years.

Re:too complicated?

[Anonymous Coward]

I've heard template meta programming is only learnable after a mystical experience with LSD.

Re:too complicated?

[Anonymous Coward]

Well, no... templates have a steep initial curve, but once you "get it" then templates have this peculiar self-learning enlightenment moment where everything suddenly makes sense. It's really fun once you realize how elegantly powerful templates actually are.

Severaly flawed stats

[Stan Vassilev]

I don't know why this guy is using filetype Google searches to find out how common SVG and Flash content is.

SVG content makes up just 0.106% of all Web content, by my rough estimation. Flash is almost 5 times as common as SVG. That's pretty grim for SVG. ... But wait, let's put that into perspective. Flash is about 4.8 times more common than SVG. HTML is roughly 838 times more common than SVG. 838 times. Flash content comprises approximately 0.52% of all Web content, and HTML is roughly 189 times more common than Flash.

Let *me* put that into perspective. Most Flash content is deployed via JavaScript, so it won't show in a Google filetype search. None of the sites with Flash I've worked on would pop SWF filetype results in Google. Saying that Flash to SVG are 5 to 1 is hilarious, given the-still-leading browser on the market, IE, supports zero SVG content (to change with IE9 which is in alpha right now).

Saying that Flash is 0.52% of the content of the web is also hilarious. Even just counting the countless embedded YouTube players in blogs would change those numbers drastically.

Re:Severaly flawed stats

[digitalunity]

If they're counting Flash by simply comparing number of SWF files to HTML files, that might be right.

If you were to compare traffic from flash content and compare that to HTML or other web traffic, I think you'd see that a very high percentage of bandwidth is consumed by flash video.

Re:Severaly flawed stats

[Anonymous Coward]

It depends on what you are trying to count. If you want to count the interactive content, where SVG competes with Flash, it may actually be pretty reasonable. If you want to count videos, that is another matter. Sites like youtube only use a handful of flash files to stream millions of videos.

Re:Severaly flawed stats

[Anonymous Coward]

SVG videos are very rare. ;-)

Re:Severaly flawed stats

[I'm Schepers]

Hi, Stan-

You raise a good point, but I'm not actually talking about the actual amount of content on the web, I'm talking about how it is indexed and searchable (in this case, by Google). I'm sure that there is a lot more Flash content than my rough study indicates, and I could be clearer about that in my blog post, but for the purposes of discussing the relative representation in search results, I think it's fair to say that the presence (or lack of presence) of content is distorted by how easy it is to find it through the search engine.

Ultimately, it doesn't matter how much Flash or SVG content is on the web... both should be indexed and represented in search results. How we get to that point, and how we can make is fruitful for people searching for the content, is the interesting question.

Re:Severaly flawed stats

[the_womble]

Google does follow links in Javascript (yes, Googlebot can execute JS these days) and the PS on these sites presumably does contain links to .swf files.

Re:Severaly flawed stats

[Anonymous Coward]

Google does follow links in Javascript (yes, Googlebot can execute JS these days) and the PS on these sites presumably does contain links to .swf files.

Google follows JS links when it's a string literal that looks like an URL. I.e. Google will follow this:

var gohere = 'http://example.com/123.pdf'; ... ...

But it won't dynamically execute and detect urls constructed at runtime, for example:

function openDoc(domain, docid) { document.location = 'http://' + domain + '/' + docid + '.pdf'; }
openDoc('example.com', '123');

A version of the Googlebot can execute JavaScript, that's correct, but that's not used for basic indexing, but for other purposes (aiding spam filtering techniques and so on).

Re:Severaly flawed stats

[Stan Vassilev]

You raise a good point, but I'm not actually talking about the actual amount of content on the web, I'm talking about how it is indexed and searchable (in this case, by Google). I'm sure that there is a lot more Flash content than my rough study indicates, and I could be clearer about that in my blog post, but for the purposes of discussing the relative representation in search results, I think it's fair to say that the presence (or lack of presence) of content is distorted by how easy it is to find it through the search engine.

Ultimately, it doesn't matter how much Flash or SVG content is on the web... both should be indexed and represented in search results. How we get to that point, and how we can make is fruitful for people searching for the content, is the interesting question.

This has been attempted before, which, in the case of Flash, resulted of pages and pages of SERP like these.

It's probably understandable why Google lowered the "rank" of Flash content in their SERP.

Indexing SVG is also of dubious benefits. Flat images may be a nice addition to the images section, if search engines have a good way of recognizing those from SVG-based interactive apps, but that's about it.

However, not all SVG files work outside the page they are embedded in, especially if they depend on related scripts. This is even more so the case with Flash, which often has its data sources loaded externally, based on parameters passed in-page. That's one more reason why people use JS for Flash embedding: it doesn't produce naked SWF files in search results, which rarely works anyway.

Searching is about keywords and phrases, so it works best with HTML, where the majority of text is. Image search is based on the text around the image, and SVG static image search will likely work best that way as well, so there's no pressing need to try to find couple of irrelevant words in a SVG file lost among thousands of vector/color data items.

In other words, indexing Flash/SVG seems to be a solution in search of a problem.

Re:Severaly flawed stats

[l0xin]

None of the sites with Flash I've worked on would pop SWF filetype results in Google.

There's something wrong there then, if, you want the greatest exposure possible for those sites.

Re:Severaly flawed stats

[Anonymous Coward]

I agree that indexing Flash makes little sense, as Flash is opaque by nature and intention. But SVG is much closer to HTML than to other graphic formats in that it is markup. It's marked up text. It's XML, which makes it easy to index -- you don't even have to write a new parser . All markup formats visible[*] on the web should be indexed by search engines. It makes no difference to users whether a string of characters they see in their browser is marked up in HTML, SVG or MathML. It shouldn't make a difference to search engines either.

[*] It might even make sense to index the invisible ones, because they are more semantic, e.g. wiki markup vs the rendered HTML.

Re:Severaly flawed stats

[Stan Vassilev]

There's something wrong there then, if, you want the greatest exposure possible for those sites.

Exposing dyanmic SWF's which just have 50 times repeated "loading... loading..." in them is hardly a good exposure.

The correct way is to have all relevant content in your HTML fallback, which Google will find and index, and thus expose you. Flash is for making the same info more functional, and (let's face it) prettier. Works as it should.

Re:Severaly flawed stats

[I'm Schepers]

Okay, I'm not in a position to defend Flash (I was trying to be nice by giving it the benefit of the doubt), but SVG was designed from the bottom up as a text format, where visible text is exactly that, and while some SVGs don't contain any text or metadata, many do have a significant percentage of relevant textual data. You presume (I believe incorrectly) that the text in an SVG file is irrelevant, because you're comparing it with Flash. SVG is not Flash, and it's not necessarily used in the same way.

But even for SVG files that don't have indexible internal content, they could be treated on par with the support that Google supplies for images, where the surrounding text informs the indexing and ranking.

As for discerning when a file is an application rather than a static file, that's relatively easy... look for a script element. Many HTML files are just as "meaningless", when HTML is used for an application rather than a documents, for what that's worth.

But I'm not saying that all SVGs, today, are optimized for searching and indexing. I think we would benefit from establishing some best practices, and maybe even changing the format a bit, to make SVG files more indexible, where it makes sense to do so... for static, information-rich graphics and so forth.

The problems are real: we need a way for information graphics to be easily created in an accessible way, and we need for those graphics for be readily findable. How we get there is what I'm interested in.

Re:Severaly flawed stats

[jsebrech]

I disagree.

SVG, Flash and HTML don't have a meaningful difference when it comes to their abilities or structure. All three are hierarchies of content nodes, changeable via dynamic scripting. That HTML and SVG use text to demarcate the nodes and flash uses binary blobs is of no consequence, because parsers don't care whether the symbols are text or binary. The fact that HTML is easier to index than flash is not due to any inherent quality of the technology, it's due to the fact that HTML is used for static content and flash is used for dynamic content. Gmail is made in HTML, but it's not indexable (and thankfully so!). It remains to be seen whether SVG's usage will be more static than flash. Quite possibly SVG could end up being just as difficult to index as flash.

I also don't quite agree that staticness can be determined by the absence of dynamic scripting. I think with svg filters and css styles you can do an awful lot of dynamic behavior that isn't actually scripted, similar to the pure-css popup menus that we've seen in HTML.

Re:Severaly flawed stats

[I'm Schepers]

I agree, for some value of the word "dynamic".

Scripted dynamic content often injects new content into the DOM, or replaces or removes existing content. In extreme (but common) cases, the majority of content is dynamically inserted into the DOM clientside, which makes it a very poor candidate for indexing. Without existing structure, hyperlinks, and textual content (text, metadata, titles, descriptions, etc.), search engines have little to go on.

The kind of dynamic interactive content you're talking about, using declarative markup or script that merely manipulates existing DOM content rather than changing it, already has the structure and textual content, and is thus more readily and pragmatically indexible.

It's not black and white, but the presence of script is the most simple heuristic I can think of for detecting content which is less suitable to be treated as an image, or which is expected to dramatically change. I would be satisfied if this were used as a first-pass solution on determining which SVG files would appear for image searches and which would be treated more like HTML.

I don't know enough about Flash to speak about its indexibility compared to HTML, but there are an awful lot of HTML applications which are indexed. So, I don't think it's necessarily how "static" a file is that lends itself to being indexed, but how popular and "contentful" the file or service is. The format of the file shouldn't prejudice a search engine toward or away from indexing it; each file format has its own challenges and benefits.

Re:Severaly flawed stats

[xOneca]

Are there SVG videos? Just curious...

Re:Severaly flawed stats

[Stan Vassilev]

SVG was designed from the bottom up as a text format, where visible text is exactly that, and while some SVGs don't contain any text or metadata, many do have a significant percentage of relevant textual data.

Flash not being readable in Notepad, because it's binary, isn't the primary reason it's less indexable than HTML.

Yes, SVG's official serialization format is text-based (XML-based), but that that's just an implementation detail. The internal structure of Flash is actually quite simple, and also a tree of (binary) tags, and you can easily serialize a SWF to XML and back with no loss, and you'll notice they are very similar, the only difference - Flash is somewhat wider in scope than SVG currently is (audio, timelines etc).

I see repeatedly in this topic people talking about mark-up text and marked-up text as if these are interchangeable concepts. However, the first is the format you use to describe an arbitrary problem, and the second is a particular problem you want to describe. SVG uses mark-up text, but it describes graphics, and that's the information you get out of it.

Having string resources in SVG only play the support role of an accessory in your graphics, say, adding labels for your pie-chart. Using SVG's text abilities for anything more than is abuse of the format. And since the context of the labels in that example is the pie-chart, Google would need to literally understand that image-based context, to extract any useful meaning of the bits of text scattered around it.

I think we would benefit from establishing some best practices, and maybe even changing the format a bit, to make SVG files more indexible, where it makes sense to do so... for static, information-rich graphics and so forth.

I see your point, but we already have a format for describing information-rich structured data, and that's HTML. With HTML you can style text and data using basics, and SVG is intended to display arbitrary graphics, without concerning yourself with semantically mapping every bit of visual content. Attempting to combine both in some uberstandard that's both 100% flexible and 100% indexable would be completely unachievable.

[animal]
    [head]
        [eyes]
            [pupil]...20k of vector tags...[/pupil]
        [/eyes]
    [/head]
[/animal] ... no thanks.

Re:Severaly flawed stats

[I'm Schepers]

You seem to be trying to pit SVG against Flash, though I'm not sure why. My point about indexing SVG has nothing to do with whether Flash or SVG is "better", or even the differences between the formats; in fact, the only reason I mentioned Flash is by way of comparison with relative usage on the Web, and by any metric, Flash is far more widely used currently. If you prefer Flash, by all means use Flash. My blog post was about technical details of indexing SVG in search engines... in that context, I'm only interested in Flash if there are things we can learn from it to accomplish that goal, even negative examples such as the ones you're indicating with the contextless content.

But when I talk about SVG having text-as-text, and metadata attributes and elements, I am specifically talking about the human- and machine-readable content, not about the element and attribute names or geometric values. You may think that doesn't get you very far, but I strongly disagree. Also, the use of ARIA attributes can add an additional semantic layer on top of the structure and textual content, to make it even more accessible and indexible. In most cases, I wouldn't consider an image of an animal as an information graphic (though that depends... an anatomical drawing might be somewhat indexible).

As one of the folks on the SVG Working Group, defining the SVG specification, I can assure you that it is not an abuse of the format to use text content, or metadata; in fact, it's considered a best practice, and encouraged explicitly. It may not be to your taste, but it suits many people very well. HTML is not the only information-rich structured data format, nor often is it the best one... it is almost certainly the most popular, and not just on the Web, but it's not very good at describing graphics, or math, or any number of other areas.

(As an aside, just to clarify your misconception, SVG does have timelines and declarative animation, and SVG Tiny 1.2 for mobile devices also has audio and video; on the desktop platform, we rely on HTML for audio and video, since SVG integrates well with HTML and we don't need to duplicate that functionality. One of SVG's strengths is that it builds on, integrates, and enhances other web standards people already know, like HTML, CSS, DOM, Javascript, etc.)

From TFA...

[Darkness404]

SVG content makes up just 0.106% of all Web content, by my rough estimation. Flash is almost 5 times as common as SVG. That's pretty grim for SVG.

How is that "grim" for SVG? Flash isn't just used for vector graphics and animations anymore....

Re:From TFA...

[pizzach]

Speaking of which, it would be just lovely if you could import SVGs into Flash. You would think it would be something obvious for the developers to add. Maybe they really aren't the same thing? *Cue Twighlight Zone music*

Poorly rendered

[Lord Grey]

That site serves as a poster child for why Safari 5.0's "Reader" feature exists.

Re:Poorly rendered

[Anonymous Coward]

It looks ok to me, though perhaps my browser is broken?

Re:Poorly rendered

[newcastlejon]

That site serves as a poster child for why Safari 5.0's "Reader" feature exists.

And why's that? It's not especially long/tall and even when viewing a 500 pixels rendition in FF there is always a landmark, so to speak, which means one rarely loses their place. Reader is definitely handy; I think it's great for reading short stories posted online*, but I fail to see what's wrong with the site in question besides being another damn blog...

*Preferably as .txts, but anything is better than a 10-page ad fest. One of the good things about adjustable font size is that I can decide how much text will be on a page.

Re:Poorly rendered

[Anonymous Coward]

Could you specify? The only rendering errors I see in Safari are a long URL in the sidebar overlapping into the main column, and some orphaned PHP code at the bottom. The page is nicely designed and good to read.

Re:How I Learned to Start Thinking and Hate the Je

[Anonymous Coward]

I was with you right up until the end - silver bullets only work on werewolves. Nice try, though.

SVG in other files

[colinrichardday]

How does one search for scalable vector graphics that are in *.xml files?

Re:SVG in other files

[abulafia]

I think the answer is, you don't, without a schema that tells you what to expect, at least if you want to do it right.

More generally, you can guess how people embed it, and probably even be right a lot. But considering what a clusterfuck "XML" and things-that-look-like-XML-but-aren't, and things-that-don't-even-come-close-except-for-containing->-and-<, I'd hate to try for any general purpose use that anyone cared about.

I think life would be better for everyone if they stopped thinking about XML as something like a format, and instead looked at is more as a convention. Sometimes, life is good and SAX can parse it. Other times, some ca. 1998 system is emitting something that the marketing literature buried in a filing cabinet somewhere called something that ended in 'ML', and it doesn't have '|' or '::' in it.

canvas

[thoughtsatthemoment]

With Apple and others pushing canvas, the future of SVG isn't looking bright. I am not sure which one is better, but SVG seems to be the one on the way out, especially after Adobe stopped supporting SVG.

Re:canvas

[morgan_greywolf]

And what, pray tell, do you think <canvas> is? Look at the spec. It's SVG written in JavaScript.

Re:canvas

[thoughtsatthemoment]

I meant http://www.w3.org/TR/2010/WD-SVG11-20100622/, not SVG in general.

SVGs are the future, imho

[Mabbo]

We *need* to get full support for SVG going. Not as a replacement for flash, or any of that (though really, they could), but just as a basic image format for non-photographic images in computers. Vector graphics scale beautifully, work well with screen magnifiers for the visually impaired, are lightweight, easy to make and edit by hand (it's xml!).

You could implement whole web-apps as a single SVG file if you so desired. That is, if all browsers had full support of SVGs- and as my job this summer is in part to work on WebKit SVG support, let me assure you, nobody is fully compliant yet. But we're getting there. (Damn you Sub-resource loading!)

Re:SVGs are the future, imho

[gandhi_2]

Vector graphics scale beautifully

I was of the understanding that scaling was the singular purpose.

Fish swim beautifully.

Re:SVGs are the future, imho

[PapayaSF]

We *need* to get full support for SVG going.

Unfortunately, it's not going happen any time soon. What client wants a website with a feature that doesn't work in IE? Never mind IE 9, the websites I build still have to support IE 6! So even assuming IE 9 has good SVG support, SVG won't have a chance on a typical corporate site until IE 9 is in the position that IE 6 is now: the minimum that anyone worries about, with IE 6, 7 and 8 just distant memories with a trivial amount of users who can be ignored the way IE 5 users are now. That could easily be another 6-8 years... or more.

Re:SVGs are the future, imho

[kanto]

Sometimes you have to leave people behind... I nominate the ones using IE.

Back in the day you couldn't use it because just visiting a site would replace your bookmarks with pages of ladies with negotiable virtue. Nowadays, last I looked at it, it's an opera clone; but hell, I guess at least they're mimicking the first class look and feel.

Re:SVGs are the future, imho

[kainosnous]

I completely agree that SVG is a great standard that should be preserved and used more often. However, functionality takes a back seat to status qou and corporate sponsorship. Browsers and viewers tend to spend more energy supporting what people already use unless they see corporations pushing some new flashy thing, at which point they will support that too. People tend to only use those things which are well supported.

It's really a chicken vs. egg problem. There may be the occasional technology that finds its place before being well implemented, however, it seems that most of the new technology that will get pushed is that with commercial backing. Another great idea that hasn't seen any support is WAI-ARIA. Most people see the audio browsing as something only for the handicapped and thus unmarketable. However, it doesn't take much imagination to see how web browsing (especially mobile browsing) could be revolutionised by this technology. Until it seems trendy, it won't go anywhere.

Re:SVGs are the future, imho

[pjt33]

easy to make and edit by hand (it's xml!)

Assuming that you can look at a series of coordinates for Bezier control points and visualise the result. If you can, I venture to suggest that you're exceptional.

Re:SVGs are the future, imho

[JohnnyBGod]

If you've ever studied Bezier splines*, that's really not so hard. Catmull-Rom splines or B-Splines, on the other hand...

* The reason I've studied them is because we have a horribly outdated computer graphics course, at my uni.

Re:SVGs are the future, imho

[mister_dave]

Webkit already supports canvas (which WebGL builds on), why does it need two drawing methods?

Re:SVGs are the future, imho

[BasilBrush]

Not quite the singular purpose. For images that suit line art:
2) ...media size tends to be lower with a vector representation.
3) ...the media remains editable at the line/object level rather than at the pixel level.

Re:SVGs are the future, imho

[Mystra_x64]

It does not necessary need Javascript for once? And is Canvas in CSS background such a good idea?

Re:SVGs are the future, imho

[BasilBrush]

IE8 and earlier are about 50% of browser use out there. So something approaching 50% of browsers in use support SVG. And those that don't can use plugins.

Flash managed to get accepted purely through the plugin route.

Re:SVGs are the future, imho

[Runaway1956]

So, why exactly are you still developing sites for IE? Do you also think that Home Sapiens should be concerned with Homo Erectus, Cro Magnun, and Neanderthal? Should we reserve seats in the UN for them, or what?

Re:SVGs are the future, imho

[PJ6]

I agree that SVG is a good thing, but the ubiquitous attitude of "its in XML, we don't need to have a proper application with a UI that writes it for the user" needs to go strait to hell. HTML can go there, too.

Re:SVGs are the future, imho

[PapayaSF]

It's not my decision, it's the client's. They just want sites to work in all common versions of IE, automatically. I don't like it, but they don't want to hear lectures on web standards and progress.

Re:SVGs are the future, imho

[Anonymous Coward]

Do you understand the difference between retained and immediate mode? SVG is not a "drawing method", it's a graphic description language.

Re:SVGs are the future, imho

[Anonymous Coward]

There's plenty of SVG editors that are user friendly. Inkscape is recommended pretty often. I believe Adobe's vector graphics editor Illustrator can save to SVG as well.

Re:SVGs are the future, imho

[icebraining]

The reason I've studied them is because we have a horribly outdated computer graphics course, at my uni.

Ditto here, just last here.

Re:SVGs are the future, imho

[jsebrech]

You might argue that webkit doesn't need HTML anymore either (except for the canvas tag). Canvas and javascript can render anything, like the bespin web-based code editor, which uses only canvas.

Canvas and SVG serve very different purposes.

Re:SVGs are the future, imho

[badkarmadayaccount]

Sorry to go slightly offtopic, but I think we should provide for each type of general use a separate subspecification, more suited to the venture at hand. For instance, I've alway wondered where should I raise the question of static type inference and OpenCL type extensions to JavaScript, in order to accommodate in-browser codecs.

Well, no.

[abulafia]

SVG is one displayable object type within a canvas.

SVG is something that I wish had taken off, but I think it is doomed. It is a wonderful format - I've written a few SVG generators for various purposes, and it is clean, easy and beautiful. I think it was missing a champion - Adobe dabbled with it, but it seems like it was a hedged bet for them - they always prefer things over which they have more control, which I guess should be expected behavior by now.

Or maybe the problem is that it is too general-purpose, so support has been diffuse, with no clear niche to really win in.

Or both. But this has happened before - a great technology that through historic accident and/or failing to have a compelling story to carry it doesn't quite get the combination of attention and demand that drives adoption. It is too bad - the combination of SVG and JS are really quite elegant for a broad class of neato things. (Which might be the problem- it see like the rule is when given the option, always use elegant for yourself, but bet against it. Enjoy the sushi, but put your money in fast food.)

Re:Well, no.

[Miseph]

I'm pretty sure the real explanation is that porn has no use for SVG.

I'm serious. If the porn industry had any desire to deal in line art, SVG would be all over the place. But they don't, so they only really got on board with JPEG, and that's the only image type most people are even aware exists.

I actually had to argue with other members of a group I'm in about not making our logo a JPEG, and using SVG instead. It was line art and basic text, with a potential need to make it either very small or very big, yet people actually wanted it to be a raster because they had no idea an alternative exists.

Re:Well, no.

[Anonymous Coward]

porn has no use for SVG

Hentai manga that is low-bitrate and crisp at any resolution? No use for that, huh? And think video. Fancy some animated vertical SMIL?

I think the problem with SVG is that the standard is a moving target, browsers are just starting to really support it, and the tools aren't good enough yet. There needs to be a foolproof application that allows you to scan and convert (from raster sources) direct to SVG.

Re:Well, no.

[morgan_greywolf]

SVG is one displayable object type within a canvas.

You don't know anything about SVG then. Read the spec for canvas, read the spec for SVG, then you'll understand what I'm saying. The native drawing commands in canvas like lineto, moveto, and bezierCurveTo are straight from SVG, which, in turn, is straight from PostScript.

I know. I'm writing some code that converts 2D sketches in a CAD tool to and from SVG.

Re:Well, no.

[jsebrech]

I wrote an actionscript app 5 years ago that rendered SVG to screen using flash's drawing API, which looks a lot like canvas. None of this stuff is particularly novel, but then open standards aren't supposed to innovate, they're supposed to standardize the best practices.

Re:Well, no.

[Miseph]

"Hentai manga that is low-bitrate and crisp at any resolution?"

Extremely niche market in these terms. The demand for drawn porn, when compared to the demand for live-action porn, is negligible. Besides that, most people doing elaborate line art do it on paper then scan it to digitize; that trend is just recently starting to change with the advent of decent touch interfaces. In the grand sceme of things, the porn industry just doesn't care about this.

"And think video. Fancy some animated vertical SMIL?'

They had streaming porn on the internet well before SMIL was really ready to serve it up (I know, because i was looking at it), and with MS reluctant to support it the path of least resistance was to use other technologies. Had SVG been the only, or even best, way to do video, porn would have picked it up... but it is neither.

"There needs to be a foolproof application that allows you to scan and convert (from raster sources) direct to SVG."

Oh god yes. Even if it's not very good, that would be the tool to bring SVG into the use it deserves.

Manual editing of graphics files is so 1970.

[Animats]

easy to make and edit by hand (it's xml!).

That is so 1970. Get a draw program.

Re:Manual editing of graphics files is so 1970.

[colinrichardday]

But one can also generate SVG programmatically/scriptably. What kind of drawing programs did you mean, and how scriptable/programmable are they?

Re:Manual editing of graphics files is so 1970.

[Aighearach]

Ever hear of Gtk, the Gimp ToolKit?

Re:Manual editing of graphics files is so 1970.

[ulski]

Microstation can export CAD files to SVG (File->Export->SVG)

Re:Manual editing of graphics files is so 1970.

[colinrichardday]

But how do you generate the CAD files in the first place? And while I haven't found a price for it, I suspect that it's expensive, as well as overkill for the stuff I do (and Microsoft Windows only to boot).

Re:Manual editing of graphics files is so 1970.

[ulski]

There is a "light version" of Microstation called Bentley PowerDraft which is cheaper. Whether it is overkill or not depends of how often you do this kind of work but there is also many free alternatives. You could take a look at the new "Drawings" application i Google docs. In Drawings you can also export to SVG http://docs.google.com/drawings/

Re:How I Learned to Start Thinking and Hate the Je

[Anonymous Coward]

Hey, they work on vampires, too! Although maybe impaling the vicious little spit-monkeys on a wooden stake really would be more appropriate.

Google and Indexing

[mjwalshe]

err sorry there is no god given right for all of your pages to be indexed, Google only indexes pages it considers important and that will (in Googles opinion) add value to a searcher.

What information in a SVG would be useful to a searcher? And SVG and flash are difficult for Google to spider and extract useful information from.

For such low quality pages why should any search engine waste resource on it? Its just wasting their resources and also a svg page counts towards a sites page cap so its not good for the sites owner.

Re:Google and Indexing

[mister_dave]

Excuse my ignorance, but what is "a site's page cap"?

Re:Google and Indexing

[BasilBrush]

What information in a SVG would be useful to a searcher?

Text.

Re:Google and Indexing

[AxeTheMax]

What information in a SVG would be useful to a searcher?

Think of maps and the text in them for a start.

Re:Google and Indexing

[mjwalshe]

the max number of pages that google will index on a given site only realy aplies to the realy big sites

Re:Google and Indexing

[mjwalshe]

bit dificult to get at that data in a meaningfull way I supose if they marked it up using rdf might help a bit- But Google can buy that data or get at it in another way Google LBC for one.

Re:How I Learned to Start Thinking and Hate the Je

[Anonymous Coward]

^^^Jew!

Rough estimate

[torako]

SVG content makes up just 0.106% of all Web content, by my rough estimation.

Wow, that guy's rough estimates are up at the permille level. Impressive.

What company?

[identity0]

The world's most popular search engine company is a leading supporter of open standards.

Bing uses open standards?! o_O I guess Microsoft has changed....

Shameless plug, but...

[bryonak]

... the lack of support for SVG is one of the reasons why the GNU/Linux distro timeline keeps PNGs in addition to SVGs even though they are inferior (file size and hyperlinks).

How can a limited user install a plug-in?

[tepples]

And those that don't can use plugins.

The sorts of PCs that have Internet Explorer as the only installed web browser, especially versions of IE before 8, are also the sorts of PCs where the user lacks the credentials to become an administrator. So even if you do use the Google Chrome Frame plug-in, users are only going to see a password prompt when trying to install it.

Re:How can a limited user install a plug-in?

[BasilBrush]

Again, Flash managed to get accepted as a de-facto standard entirely through the plugin route. So the hurdle you mention clearly doesn't prevent adoption of a standard.

Re:How can a limited user install a plug-in?

[BitZtream]

Yea, when you come bundled by default on 95% of the PCs in the world, the fact that its a plugin means its just like any other plugin you'd try to get installed later.

Flash comes with Windows, all users think is that its being upgraded which is perceptually different to an end user than installing a new plugin, regardless of the fact that the one included with the OS is more or less useless nearly 10 years down the road.

Re:How can a limited user install a plug-in?

[ta bu shi da yu]

You fail to realise that most corporate environments (you know, the one's running IE6) have standard desktop builds they load onto their desktops after they get the computer from the manufacturer.

Eight-segment quadratic Bezier circle

[tepples]

Assuming that you can look at a series of coordinates for Bezier control points and visualise the result.

It's not that hard. Put your on-curve points at horizontal, vertical, or 45-degree slope, and then put the off-curve control points at the intersection of the tangent lines. This involves a bunch of zeroes and the occasional subtraction, but one can get the hang of it.

Exercise: Draw a circle with eight Bezier curve segments. (Answer)

Re:Eight-segment quadratic Bezier circle

[jsebrech]

A few years back I had to port an "ellipse segment" drawing command to a set of quadratic curves because that was all that actionscript supported and the segment was part of a longer path that had to be rendered as a whole path (filled). It took me quite a while to get the hang of it, and I documented the crap out of that code to never forget how it worked. But yes, the resulting code just chops everything up into smaller ellipse segments until they get small enough to turn into a quadratic arc.

You Suck, Google.

[ChaosCon]

They're all preachy-preachy about open standards, but when it comes to *their* products, they mangle them entirely. Take IMAP (Gmail) and CalDAV (Google Calendar), for example. In both cases, The Big G decided to "adopt" the currently in-place standard, with a few modifications because they feel it wasn't done quite right. The end result is a crap experience when you use the services in anything other than a web browser.

Gotta love /. tact.

[abulafia]

And you could do to learn how to behave like a grownup. I'm not going to dickwave about it, but have written rather a lot of code against the relevant specs; if you're working in this space, you're probably using some of my code.

I think we're suffering from a difference of semantics. I wouldn't call PDF Postscript. Because it isn't. Once upon a time, one could be forgiven for confusing the two, and there were even PoC valid-PDF documents that you could pipe to a printer, but they're quite divergent how. Similarly, I don't think that, because they share imperatives, calling Canvas the same as SVG is right, because they are different things and will become more different over time.

Re:Gotta love /. tact.

[morgan_greywolf]

Sorry to sound snippy; I had just been arguing with a 15-year old Apple fanboy when I posted that ... ;)

Similarly, I don't think that, because they share imperatives, calling Canvas the same as SVG is right, because they are different things and will become more different over time.

No doubt, but at this point the similarities are close enough that you could just about write an SVG-to-canvas converter that simply does a little text massaging. My original point is that pretending that HTML 5 canvas is some amazing new technology that we should be worshipping at the altars of Apple rather than an incremental improvement over SVG is rather silly.

Re:Gotta love /. tact.

[thoughtsatthemoment]

My OP was actually a subtle criticism of Apple, because they chose to propose a new spec instead of supporting an existing one. I don't mean to hash you, but I actually think you are probably a teenager, so you would interpret my post the way you did.

Re:Gotta love /. tact.

[thoughtsatthemoment]

typo: hash -> bash