Another interesting part is that HTML5 supports embedding SVG. That is, you can put SVG code directly in your HTML5 document and it’s going to render correctly. You can also style it through your website’s CSS file and manipulate the elements via JavaScript.

Though as others pointed out, it’s technically not HTML but XML. For example, you have to close all the elements and quote all the attribute values. But when you embed it inside a HTML document, those rules get relaxed to adhere with HTML. (I.e., you cannot write <circle r=5> in SVG (it must be <circle r="5" />) but you can when you embed it in HTML).

More precisely, both are flavors of XML.

They can include runnable JavaScript too, which can cause vulnerabilities in certain contexts. One example from work some years back: We had a web app where users could upload files, and certain users could view files uploaded by others. They had the option to download the file or, if it was a file type that the browser could display (like an image or a PDF), the site would display it directly on the page.

To prevent any XSS (scripts from user-provided files), we served all files with the CSP sandbox header, which prevents any scripts from running. However, at the time, that header broke some features of the video player on certain browsers (I think in Safari, at least), so we had to serve some file types without the header. Mistakenly, we also included image files in the exclusion, as everyone through image files couldn’t contain scripts. But the MIME type for SVG files is image/svg+xml… It was very embarrassing to have such a simple XSS vuln flagged in a security audit.

Oooh, neat! [Cunningham’s Law] (https://en.m.wikipedia.org/wiki/Ward_Cunningham#Cunningham’s_Law) in action!

Ommigod, these kids :)

SVG comes XML (a more coherent/simple version of the SGML that is behind HTML), and specifically from a time where people took XML and made it hyper-complicated with a flurry of extensions and specifications (look up “xml namespaces” “xslt” “xml schema”).

The most apparent difference between SGML and XML is than in the former you write tags like <br> without a corresponding </br>, and in the latter you have to close them like <br/> (which is shorthand for <br></br>).

So… today you learned that what you learned earlier today was close to truth, but not true :)

PS: A lot of document formats are undercover/zipped XML (eg. the libre office documents, IIRC microsoft’s .xlsx and .docx). This is not dissimilar to how json/yaml are widely used today.

No, it’s XML. It’s an ancestor of HTML and, unlike HTML, it can be losslessly converted.

for example, on a linux distro, we could modify the desktop environment and make it waaaaay lighter by getting rid of jpg or png icons and just using pure svg on it.

Isn’t that how it already works? GNOME system icons are all SVG - that’s what allows them to change colors when you change themes or switch between light and dark mode.

main difference between raster graphics and vector graphics was the quality

It’s not. The primitives, the most basic constitutive building blocks, are different, for raster it’s the pixel (a mix of colors, e.g. red/green/blue) whereas for vector it’s the … vector (a relative position elements, e.g. line, circle, rectangle or text start with).

This is a fundamental distinction on how you interact with the content. For raster you basically paint over pixels, changing the values of pixels, whereas for vector you change values of elements and add/remove elements. Both can be lossless though (vector always is) as for raster can have no compression or lossless compression. That being said raster does have a grid size (i.e. how many pixels are stored, e.g. 800x600) whereas vector does not, letting you zoom infinitely and see no aliasing on straight lines.

Anyway yes it’s fascinating. In fact you can even modify SVG straight from the browser, no image editor or text editor needed, thanks to your browser inspector (easy to change the color of a rectangle for example) or even the console itself then via JavaScript and contentDocument you can change a lot more programmatically (e.g. change the color of all rectangles).

It’s a lot of fun to tinker with!

I don’t think it would be lighter, SVGs need a rendering tool to read the code and draw the artwork for the vector based images. This has always been slower than just displaying a bmp, jpg, or PNG.

for example, on a linux distro, we could modify the desktop environment and make it waaaaay lighter by getting rid of jpg or png icons and just using pure svg on it.

this has largely happened; if you’re on a dpkg-based distro try running this command:

dpkg -S svg | grep svg$ | sort

…and you’ll see that your distro includes thousands of SVG files :)

I made an interactive map: drew in Inkscape, gave the interactive elements numbers for ids, then substituted the id=‘xxx’ in vim with the php code and js function calls, picking up the number from the id tag and inserting it appropriately in php code and function arguments. 250 interactive elements taken care of in a single vim substitute. My bestest development power move yet :D

Postscript is also literally just a text based programming language for drawing stuff. You can create loops and recursions and all kinds of crazy transformations with a few lines of code.

Hold on now. If an svg will render as valid html in browsers, does that mean I can use Inkscape as a wysiwyg webpage editor, and just export that to html?

Damn, I actually did not know that. I thought it was just an image file.