From SVG

This page is an archive of the previous Group's wiki from

NOTE: This wiki is no longer actively maintained.

Please see the new SVG WG wiki instead.

SVG Working Group Wiki


There are two regular SVG teleconferences, Tuesday and Thursday. Each telcon lasts 1.5 hours. Times updated for 11 March 2008 changes:

Day (Chair) W. Europe Eastern US/Canada Pacific US/Canada E. Australia
Tuesday SVG (Andrew) 13:30 08:30 05:30 23:30
Thursday SVG (Erik) 11:30 06:30 03:30 21:30

See also the W3C Teleconference page.

The number for all calls is +1 617-761-6200 (Zakim) with passcode 7841. If you can't get into the bridge, dial *0 to speak to the operator - they can manually connect you. Zakim allows participants to mute themselves by pressing 61# ("M" for mute, then "1" for on) and unmute themselves with 60#.

Minutes are taken on a rotating schedule (ie. the person who took minutes most recently should be the least likely candidate for the next meeting Minutes Archive.

You are encouraged to take minutes on IRC, using the "#svg" channel on In order to get automatic logging you need to tell trackbot to start the relcon. trackbot, start telcon Trackbot in turn invites rrsagent which does logging and makes minutes, and zakim, which does bridge and agenda management. To wind up a telcon and make minutes, do zakim, bye and then rrsagent, make minutes

F2F Meeting Information

Upcoming F2Fs

  • NuremburgF2F2008, 21-24 August 2008, in Nuremburg (co-located with SVG Open on 26-29 August)
  • OttawaF2F2008, 29 September - 2 October 2008, in Ottawa (Test Fest)

Past F2Fs


A list of agenda items can be found on the Agenda page.

Some thoughts about SVG in HTML.

SVG Tiny

For details on SVG Tiny 1.2, see the SVG Tiny page.

Specification Annotations

This Wiki is for the SVG Working Group to annotate our specifications.

Whenever the WG discusses an issue, we should check here first.


It is intended to capture any discussions and rationales that we make that are not represented in the spec itself. There are some areas of specs that have caused a great deal of discussion and have very carefully chosen text. As Working Group members are occasionally replaced, it is important that we record these areas so that they aren't accidentally over-written.

It is not intended that the Wiki (initially, at least) have a complete list - this would be very time-consuming and probably not worth the effort. However, whenever someone has to search through email archives or ask people who left the group what the reasoning behind a particular decision was, we should annotate it. There are also some areas of the spec that continually generate discussion in the public list, and areas that are inherently complex. These should definitely be annotated.

The wiki is not intended to replace the issue tracker or action tools. It is intended as a resource to be used when an issue comes up that has been discussed before.


The Wiki is organised by feature first, and then the specifications that implement that feature.

Rationale: Changes to a feature in one spec may affect other specs.

Wherever reasonable, when editing the wiki, you should include a description of the feature or issue, then a Resolution: and/or a Rationale:, which consisely summarise the decisions made. Multiple resolutions and rationales are fine.