Technical

CSS Link Hack in SVG

While answering a question about styling SVG with CSS in the Freenode #svg IRC channel (yes, people still use IRC), I threw together a simple example to illustrate.  I like to do this, since in keeps me in practice, and gives me a chance to check the state of current implementations in the fast-changing world of SVG browser support.

The question was how to use CSS stylesheets, both internal and external, with SVG in Inkscape.  While I know that Inkscape makes heavy use of CSS inline style declarations on elements (more than is to my personal taste, to be honest), I didn’t (and don’t) know if it has any UI features for adding internal stylesheet blocks, or links to external stylesheets.  So I made a little test…

svgstyle.svg

<?xml-stylesheet type="text/css" href="svgstyle.css" ?>
<svg xmlns="http://www.w3.org/2000/svg"
     xmlns:xlink="http://www.w3.org/1999/xlink"
     width="100%" height="100%" viewBox="40 0 145 70">

  <style type="text/css"><![CDATA[
     ellipse
     {
       fill: lime;
       stroke: green;
       stroke-width: 10px;
     }
  ]]></style>

  <rect id="inline" x="50" y="10" width="30" height="50"
        rx="5" ry="5"
        style="fill:lime; stroke:green; stroke-width:3px;"/>
  <ellipse id="internal" cx="103" cy="35" rx="15" ry="25"
        style="stroke-width:3px;"/>
  <circle id="external" cx="150" cy="35" r="25"
        style="stroke-width:3px;"/>
</svg>

svgstyle.css

circle
{
   fill: lime;
   stroke: green;
   stroke-width: 10px;
}

Which looks like this (at least, in Firefox, Opera, Safari, and presumably Chrome):

Both internal styles worked fine in Inkscape, but the external reference did not, showing just a black circle.  I’m not really surprised.  Note the clunky way that you have to link to external stylesheets in SVG:

<?xml-stylesheet type="text/css" href="svgstyle.css" ?>

That’s really XSLT-licious. I have to confess, I don’t really care for PIs (insert dated Magnum PI joke here), or XML prologs in general… they seem somehow clumsy and un-XMLy, like a throwback to SGML. And as far as I know, they can’t be created or changed dynamically via clientside script. Compare that to the relatively easy and straightforward X/HTML way of linking to external stylesheets:

<link href="svgstyle.css" rel="stylesheet" type="text/css"/>

In the SVG WG, we intend to allow authors to reference external stylesheets in a manner a little more modern and consistent with what authors are already used to using, in some upcoming spec. We could do that a couple of different ways. We could allow them to use an xlink:href attribute on the <style> element, in the same way we currently treat the <script> element (that is, if there’s a resolvable external link, we use that, otherwise we use the child content of the element), or we could add a <link> element like X/HTML, or both. I kinda like the idea of allowing either.

To that end, I made a couple of tests, just playing around, to see if any browsers accidentally supported either of those options, by merit of having some shared codebase with X/HTML in their implementations. Unsurprisingly, neither worked.

But then I had another idea… use the an <xhtml:link> element in the XHTML namespace…

<xhtml:link href="svgstyle.css" rel="stylesheet" type="text/css"/>

With this rather happy result, which works in at least Firefox, Opera, and Safari.
external-link-xhtml.svg:

I don’t know if this is by design, or if it just fell out of the model, but I have to say I’m pleased as punch that it works. If nothing else, it’s a great proof of concept for adding more ways of linking to CSS in the SVG spec. This one goes in my toolkit, and I’m going to try to ensure that it gets standardized, if it’s not already there in some corner of some other spec. Probably somebody already knows about this (hell, probably everybody does, and I’m late to the party), but for me it was a w00ty discovery.

Update: heycam speculated that you might also be able to use @import rules, and indeed you can:

<style type="text/css">@import url(svgstyle.css);</style>

Idiri Firefox Extension

Firefox is my browser of choice. I really like Opera, and it has excellent SVG support, but I’m a creature of habit, and I can’t shake using Firefox. One of my favorite things about it is that you can trick it out to fit how you use it. I’ve installed quite a few Extensions (community-made bits of browser functionality) that I use all the time. They have become such a part of my browsing experience that I have even forgotten they aren’t standard, and when I had a hard-drive crash and had to reinstall, I was a bit at a loss why FF didn’t have some of the core functionality I’d come to rely on… until I reinstalled the extensions. I’ve even made one for my last employer, and in my spare time, I’ve been working on an image- and SVG-specific extension for Firefox, which I’ll be releasing shortly.

One of the other things I love about FF is the context-menu option for “View Selection Source”. I use it to figure out how certain bits of a document are marked up (though I also use Firebug for that). In my standards work, I also find myself needing to cite particular sections of large documents, such as technical specifications or documentation. I cite them to point out errors, to show where a bit of functionality is specified, to help out people with questions by pointing them to a reference, to defend my interpretation of a technical issue, and all sorts of other geekademic occasions. Since these documents are usually quite long, it’s necessary to get as close as possible to the relevant section when supplying a link, and fortunately, specifications tend to be very well marked-up, with logical document structure and plenty of ID attributes for ease of linking. View Selection Source is really great for that, because I can select a section header, open up the partial source in a new window, find the id, select it, append it to the original URL preceded by an octothorpe (“#”), and use that as a reference link; of course, sometimes the id isn’t where you expected it to be, and you need to look around for it a bit…

Okay, you see my problem. As relatively easy as View Selection Source makes the task, it’s still a bit… shall we say, labor-intensive. To be honest, it’s not quite as cumbersome as it sounds, and I’m so used to having to kluge around like that when programming that it somehow never occurred to me that it could be easier.

It just got easier. I spent a few hours putting together a Firefox Extension that automates this process. You just right-click on the section you want to link to, and select “Copy section link”. Idiri, my extension, automagically finds the nearest preceding link to where you’ve clicked, and copies it to your clipboard. It also highlights the element that it found an id on, as a visual indicator that it’s done its job and to let you know where you’ll be linking to. Simple.

You can download Idiri (from “id” for identifier, and “iri” for “internationalized resource identifier”, a fancy way to say URL or Web address), and let me know what you think. More details below…

Continue reading “Idiri Firefox Extension” →

Climbing the Alps

I’ve spent the last week here in Zurich, Switzerland, for an SVG F2F. I’m staying with Andreas Neumann (GIS PhD student, SVG pioneer, and organizer of the SVG Open conference series) and his wife J. (also a cartographer); they’ve been gracious hosts to Erik Dahlstrom and me, providing room and board in their spacious and elegant apartment nestled in a small village outside of Zurich. The weather has been nice, and several times we dined out on their patio, including Friday night when they had the whole Working Group over for dinner. The view is of the Alps is lovely, though Andreas says it’s even better when the sky is clear… they can see higher peaks further away. Yesterday, the four of us took a gloriously scenic train ride down to Lucano, on the shores of Lake Lugano in the Italian part of Switzerland. We hiked up a small mountain and had lunch at a restaurant at the peak. It was somewhat cloudy and rained a bit while we were eating (good timing), but the view was still lovely, and we all had a good time.

Speaking of climbing the Alps, the SVG F2F was a lot like that. We have all been channeling the bulk of our energies for the last several weeks (and to a lesser extent, months) toward preparing for the SVG Tiny 1.2 Test Fest. It’s been like climbing a mountain, with long tedious preparation before the event, culminating in a burst of exertion. Concentrating on the testing, we didn’t have the opportunity to cover as wide a variety of issues as we have in past F2Fs, though we did spend Friday afternoon discussing administrivia, some unresolved issues with the microDOM, and the other specs we’re working on, including Print and Filters.

Read on past the fold if you care for a little more detail about the technical stuff…
Continue reading “Climbing the Alps” →

Microformats and Language Drift

I was sitting at the bar with Chaals and Danny Ayers (who I’d previously only known through mutual friends and by reputation) at the Fairmont Springs at lunch. He’s an RDF guy, and I put to him the question I’d put to Harry Halpin last night (while watching Super Troopers); Harry likes the loose structure of microformats (though he acknowledges the utility of established ontolologies for constrained domains like medicine and physics), and I wondered if maybe the linguistic model of exemplars would be useful in RDF and OWL to add some flexibility.

But if formal ontologies are too rigid, I think microformats is too loose. It’s great that people are tagging their content, and useful things can be done with these tags in the short term. But microformats is not immune to language drift. Someone will see a tag, misgrok the meaning from context, and idiosyncratically misapply it to other content. This is exacerbated by the international and multi-language nature of the Web.

For example, let’s say that someone had tagged some content with the word “meme” 15 years ago; it would clearly have referred to Dawkin’s model of “idea evolution” (where a concept is spread not through accuracy, but through adaption to its mental environment… an idea akin to Colbert’s “truthiness”). But a few years ago, it spread into common use as a synonym for “fad”; so far, it retains some superficial similarity to Dawkin’s idea. In a few more years, it will probably be a very dated word (like “groovy”) and may well shift to a meaning like “old-fashioned”; it would then have completely lost its essential meaning. So, a diagram of Dawkin’s model tagged “meme” would then be misinterpreted, misindexed, and regarded with confusion by a future reader.

In the long haul, RDF provides a more time-proof solution by providing conceptual context, not just a cluster of words.

W3C 2.0

I’m here in Banff, Canada for the 2007 W3C AC (Advisory Council) meeting. The AC is essentially the company reps to the W3C. I played a small part in one of the panel discussions yesterday.

It was the last presentation of the 2-day conference, and the theme was Web2.0: what it is, and how the W3C is adapting to and enabling it. I gave an overview of what Web2.0ey things WAF and WebAPI WGs are doing. It went well… I made a short SVG slideshow with some geeky in-jokes, and it got some laughs. It may have been slightly overshadowed, however, by the conversation between 2 of the other panelists: Sir Tim Berners-Lee (the creator of the Web) and Tim O’Reilly (a prominent tech publisher who coined the term Web2.0). Tough act to follow.

The conference was a lot of fun, as usual, and I got to meet and talk with a lot of technical luminaries, including Dave Raggett, who’s generously letting Chaals and I crash in his hotel room.

Jiggy With SVG, Eh?

We really had a productive face-to-face meeting of the SVG WG last week. Converging on Raleigh were Chris Lilley of W3C (Scottish, but living in France), Andreas Neumann of ETH (Switzerland), Andrew Shellshear of Canon (Australia), Andrew Emmons of BitFlash (Canada), and Erik Dahlstrom or Opera (Sweden), and Antoine Quint of The (mysterious) Venice Project (France). We locked ourselves in a room and finished up the revised test suite, broke the ground on the errata document.

At one point, our Canadian colleague stated, quite straight-faced, that he was (and I quote) “jiggy with” a resolution on a particular technical point. My jaw dropped. I didn’t know anyone was jiggy with anything anymore… but he went on to claim that it’s a common thing for Canadians to say. Just when you think you know a country, they drop a bombshell like that…

Read on for a brief summary of the proceedings…

Continue reading “Jiggy With SVG, Eh?” →

SVG Text, Semantics, and Accessibility

In addition to geometric shapes, SVG has advanced graphical text capabilities. In SVG 1.1, there are several elements specifically designed for the presentation of text. At the most basic level, there is the <text> element, which can have child <tspan> elements that can be positioned and styled independently of the other text content, like this:

Then there are more advanced options, like rotated text
or the <textPath> element

The future of SVG text support holds still more. In the next version of the SVG specification, SVG Tiny 1.2, there are even more useful text features, like the <textArea> element that automatically wraps text to a shape (rectangles on for mobile devices, but any shape at all in future versions of the specification). There is also the new ability to make any text editable by simply including an attribute to the text element. And there are great features from SVG 1.1 (the current version) that are not yet widely implemented, such as SVG Fonts, which let you embed a font into an SVG file so the reader sees the page the way the author intended it, and the <tref> element that lets you directly quote text without duplicating it. All these features will give more control to authors and give a better experience to users.

But is that enough?

Continue reading “SVG Text, Semantics, and Accessibility” →

What is it, this SVG?

I’m going to be writing a lot about SVG, so I thought I’d give some explanation as to just what it is. Scalable Vector Graphics is an XML language for creating graphics. It’s a bit like HTML for images. If you want to draw a circle on your page, you type:

<circle cx="50" cy="35" cx="20" fill="blue" />

And then you have a blue circle with a radius of 20 pixels (more on that in some later post), centered 50 pixels from the left and 35 pixels from the top. Obviously, since people want to draw more than just circles, it gets a lot more complicated than that, but that’s the basic idea. SVG is a vector-based language, which means that rather than a collection of dots, like raster images (rasters are formats like bitmaps, JPEGs, etc.), SVG shapes are sets of instructions that tell the browser how to best draw the image. For instance, a line in a raster is just a series of unconnected dots… if you zoom in on it, that’s what it breaks down into; but an SVG line tells the browser to start at this point and go to that point, and so no matter how you zoom in or out, it remains a smooth, solid line. Each image is composed of a number of shapes, or elements, that have identities and properties. If you move your mouse over an element, or click on it, the browser knows about it, and the author can give instructions (either using script or something called declarative programming) for what to do… it might let you drag the shape, or change its color, or most anything else you want.

SVG is an open format, meaning anyone can make a browser or an authoring tool that uses it without having to pay any royalties. This sets it apart from similar technologies like Adobe Flash and Microsoft XAML. (I strongly believe in open standards, because it gives everyone a chance to control the future of the format; specifically, I think that all democratic governments should use open standards as much as possible, rather than rely on one company who can control the costs and future access to the information stored in their format.) And the fact that it’s open pays off. SVG is supported natively in Firefox, Opera, Safari, and other browsers for both the desktop and mobile devices. Right now, it is not supported natively in Internet Explorer, but you can get a plug-in for that (see later posts for updates on this). No other vector format is natively supported across so many browsers.

SVG can be simple and free to author. There are several good programs that let you draw images and save them as SVG, including Adobe Illustrator and Inkscape (a free drawing app that works on most platforms). But if you want to get your hands dirty, you can dig in and create shapes just by typing out the code; this is how most programmers tend to do it, because it lets you control how the drawing behaves according to scripted instructions. If you want to see how someone drew an image, you can always view the source code and, if permitted, create or change it to suit your needs, just as many people learn HTML and Javascript.

But SVG is not just shapes. Because it is intended to allow rich presentations in an accessible way, you can also use text in SVG, and even define your own fonts (though this is not yet as widely supported). Animation is native to the language, and in later versions (such as ones shipping on phones), audio and video are also available.

Finally, SVG can be used with HTML, to create a rich Internet document. Because it was designed from the ground up to be used with other languages (including styling languages like CSS and XSL), as well as on its own, it is truly a part of the Web, and as it grows more popular, the possibilities of the Web will grow even more.