Ceci est une ancienne révision du document !
In this instalment I’m going to cover a common requirement that I overlooked when introducing the use of SVG files in a web browser: turning an object in an Inkscape file into a clickable link that loads a different URL. There are a couple of ways of dealing with this: the first is to use JavaScript to respond to the ‘click’ event that fires when an object is clicked on. I covered various ways to add JavaScript to an Inkscape file across several articles. See FCM #142, #143 and #146 for the specifics. What I didn’t describe was how you could use JS to change the URL loaded in the browser.
Dans ce numéro, je vais parlé d'une demande classique que j'ai laissé de côté quand j'ai parlé de l'utilisation des fichiers SVG dans un navigateur Web : transformer un objet d'un fichier Inkscape en lien cliquable qui charge une autre URL.
Il y a plusieurs façons de faire ça : la première est d'utiliser JavaScript pour répondre à l'événement Clic qui est déclenché quand on clique sur un objet. J'ai montré plusieurs manières d'ajouter du JavaScript dans un fichier d'Inkscape dans plusieurs articles. Regardez les FCM n° 142, 143 et 146 pour les détails. Ce dont je n'ai pas parlé c'était comment vous pourriez utiliser JS pour modifier l'URL chargée dans le navigateur.
In the most basic form, where you just want to move to a fixed URL when an object is clicked, you can use the one-line “onclick” field in the Interactivity section of the Object Properties dialog (FCM #142). For example, to make a button that goes to the Full Circle Magazine website, you would do the following: • Draw your button. Use multiple objects and text as you wish. • Put all of the button’s content into a single group. This is where we’ll attach the click handler. • Right-click on the group, and select “Object Properties”. • Expand the “Interactivity” section, if necessary. • Add the following JS code to the “onclick” field: window.location.href = “https://fullcirclemagazine.org/”; Your button and dialog should look something like that below.
Save the SVG file then load it into a web browser and you should find that clicking the button takes you to the FCM website (or whatever URL you used). You’ll probably have noticed what you don’t get for free with this approach: there’s no change of style of the button as you hover over it, and the mouse pointer remains as an arrow rather than changing to the “pointing finger” which is usually used to denote a clickable target. Both these shortcomings can be addressed with a little CSS, but that’s yet another chunk of code to manually add to your SVG file (FCM #145 will help with this). If all you want is a link to another URL, however, there’s no need to mess with JavaScript at all (though you may still need some CSS). Inkscape provides a simpler way to turn an object into a clickable link – and it’s this part of the UI that I overlooked in my previous articles. All you need to do is to right-click on the object and select “Create Link” to open the generically named “Object attributes” dialog:
That’s a lot of fields for a simple link. The reason for this is that Inkscape creates an SVG 1.1 version link, which is actually implemented via an XML standard called XLink. It dates from the time when the W3C was trying to create a wide ranging collection of XML-based standards, with the idea being that a single file might use elements from across multiple specifications, allowing each spec to focus on doing one thing well. XLink, therefore, is a standard that deals with nothing but links between documents – but in trying to include numerous use-cases for links it has a whole load of optional attributes that most people will never need. Hence all the fields. The only essential field is the first one, “Href” (an abbreviation of “hyperlink reference”). A better title would have been “URL”, “Address” or “Location”, but this dialog just uses a capitalized version of the attribute name from the XLink standard. So the “href” attribute used in the XML becomes the awkwardly capitalized “Href”. With a URL in this field, save the file and load it into your web browser. You should find that clicking the button takes you to the destination page. Furthermore, you’ll get the right sort of pointer as you move your mouse over the button, so that’s one less bit of CSS to add to your page.
Let’s take a look at the XML editor to see what this small change has actually done to your SVG file (shown above). The first thing to note is that the new attribute hasn’t just been added to the existing <g> element. Instead, Inkscape has wrapped the group in an <a> element, and the attribute has been applied to that. Anyone who has written some HTML will be familiar with <a> as the “anchor” element which is used for links in that language. Here we have essentially the same element, but in the “svg” namespace (hence it appears as <svg:a …> in the XML editor). The URL is added as an attribute in the XLink namespace. If you were to look at the XML file in a text editor, the relevant bits of code would look like this: <a id=“a973” xlink:href=“https://fullcirclemagazine.org/”> <g id=“g952”> … </g> </a>
Let’s fill out most of the remaining fields in the Object Attributes dialog, to try to make our link more fully featured. Having already created the link, you will find that a right-click on the object within the Inkscape window now shows the “Create Link” option as disabled. Instead, a little further up on the context menu, you’ll find that the usual “Fill and Stroke…” menu item has been replaced with “Link Properties…” which will open the same dialog (below). The first thing I’ll note here is that you will almost certainly never need to fill out this many fields. “Href” is required, and “Title” is a good idea for accessibility purposes, and also because desktop browsers will use it to create a tooltip when you mouse over the object. You might need to use the “Target” field, depending on how you want the link to behave, but I’ll come on to that shortly.
Let’s skip to the “Type” field. This describes the nature of the link, from a specific list of options in the XLink specification. For a normal link to another page (or within the same page), “simple” is all you need. This also happens to be the default behaviour if it’s omitted, so you should just leave it blank. The other possible types are all used for more complex linking between and within XML files. If you need to use them then you probably already know about them – and I doubt very much that you’d be using this dialog to edit them anyway. One of those more advanced types is “arc”, which indicates that the link is being used to connect two other resources, identified by the “to” and “from” attributes. A “resource” in these terms is anything that can be identified with a URL, such as a website, a specific page or file, or a named element on that page. As you may have noticed, the “to” and “from” attributes aren’t present in the dialog, so you can’t actually create a valid arc link through this UI even if you knew why you might want to! For this reason the related “Arcrole” field is also completely useless (if you could create an arc link, this would hold the URL of a resource that describes it).
Based on that description of “Arcrole”, you may not be surprised to find that “Role” field is also intended to hold a URL that points to a descriptive resource. In this case it should hold the address of a resource that describes the nature or purpose of the link. Since your web browser doesn’t natively do anything with this attribute, however, you may as well omit it. The “Actuate” field is intended to indicate when the link should be followed. This attribute can only take very specific values but, once again, it’s completely ignored by the web browser regardless of what you enter. The easiest option is therefore to leave this blank. The “onRequest” option I’ve used in my example just means “follow this link when the object is clicked”, but that is, once again, the default behaviour anyway.
All that remains are the “Target” and “Show” fields. These attributes actually perform the same purpose, but “target” is part of the SVG spec for the <a> element, whereas “show” is an XLink offering. They affect where in the UI the browser loads the linked resource – whether it replaces the SVG file in the same frame or tab, or opens in a completely new tab or window. The main values to be aware of are as follows (note the underscores before the values for “target” (see table below). As you might guess from the missing values in the “show” column, there’s rarely much need for “_parent” or “_top”. The best policy is usually to leave the “target” and “show” attributes empty, so that the behaviour of the browser is purely defined by the user’s settings. If you’re really sure that you want to open a new tab or window when the element is clicked, then use “_blank” in the “Target” field. But that’s pretty much the only legitimate use of this field for most people.
As you can see, it’s possible to enter conflicting values for “Target” and “Show”. Experiment indicates that, for Firefox at least, “Target” takes priority. All the more reason to leave the “Show” field blank. So there you have it: a dialog with eight fields, of which you only really need one (Href), might use two if you want to have a tooltip (Href, Title), or stretch to three if you also want to force links to open in a new tab (Href, Title, Target). The remaining fields should always be left empty, unless you really know what you’re doing and are something of an XML/XLink expert. But in that case you’re undoubtedly either editing the XML content by hand, or via some other XML-based workflow. In neither case is this dialog likely to be of much use to you.
There’s one large elephant in the room, however: the use of XLink at all. As I mentioned earlier, this dialog creates an SVG v1.1 link. But since version 2.0 of the SVG spec there’s been no need for XLink. The “href” attribute has been promoted to the SVG standard, together with the “target” attribute. Oddly, however, the “title” attribute has not been promoted, though the “xlink:title” version has been deprecated. The recommendation now is to use a <title> child element instead, which seems a little overkill for a simple tooltip. With this in mind, an SVG2 link might look something like this: <a id=“a973” href=“https://fullcirclemagazine.org/” target=“_blank”> <title>Full Circle Magazine</title> <g id=“g952”> … </g> </a>
For now – and for the foreseeable future – browsers continue to support the SVG 1.1 approach, so there’s no urgency for Inkscape to change what it outputs. Modern browsers will also accept the SVG2 version, though, so perhaps some future release of Inkscape will replace this generic dialog with something more tailored to the task, and will replace the output with an SVG2 version at the same time. The last thing to note on this topic is that the URL you link to doesn’t have to be a separate file. You can also link to a named anchor within the current file. This is particularly useful with the techniques I described for creating named views in parts 79 and 80 (FCM #139, #140). For example, given a named view of “starView”, simply creating a link with an href of “#starView” would mean that the image would switch to that view when the object is clicked. A similar effect can be achieved with the full viewBox syntax, using an href of “#svgView(viewBox(0, -250, 250, 500))” for example.
This can be an easy way to introduce interactivity to an SVG file. Consider a slideshow in which each slide is a separate part of the SVG image, and a viewBox is used to show just the first slide by default. By adding “Previous” and “Next” buttons which have viewBox links attached you can make a simple linear slideshow – or you could add more links to let you jump directly to any other part of the file. Of course you’re also free to mix XLink-based links with those created via JavaScript, picking the best tool for the job. One thing you can do with JS which isn’t possible with the simpler form, is to provide additional logic to determine the target location. You might change to different URLs based on the time of day, or prompt the user for some additional information that is then encoded into the URL. Consider a web-based storybook, for example, in which XLink is used to move between the pages, but JS provides extra interactivity when elements are clicked on, or hovered over.