W3C home > Mailing lists > Public > public-svg-wg@w3.org > July to September 2011

Minutes, July 7 2011 SVG WG telcon

From: Erik Dahlstrom <ed@opera.com>
Date: Thu, 07 Jul 2011 23:34:55 +0200
To: "public-svg-wg@w3.org" <public-svg-wg@w3.org>
Message-ID: <op.vx9p8h10geuyw5@mbp-2.local>
Minutes from today's telcon here:


and as plain text:


       [1] http://www.w3.org/

                                - DRAFT -

                    SVG Working Group Teleconference

07 Jul 2011



    See also: [3]IRC log

       [3] http://www.w3.org/2011/07/07-svg-irc


           heycam, Doug_Schepers, +1.408.839.aaaa, [IPcaller], ed,




      * [4]Topics
          1. [5]TPAC 2011 registration
          2. [6]FX charter items
          3. [7]opentype / svgfonts
          4. [8]SVG 1.1 second edition
          5. [9]canvas accessibility
      * [10]Summary of Action Items

    <trackbot> Date: 07 July 2011

    <thorton> Zakim: +1.408 is me

    <scribe> scribeNick: ed

TPAC 2011 registration

    <heycam> [11]http://www.w3.org/2011/11/TPAC/

      [11] http://www.w3.org/2011/11/TPAC/

    CM: recently opened, it's in november
    ... wanted to clarify when the meeting will be?

    ED: svgopen is October 17 to 20, 2011
    ... TPAC is 31 October to 4 November 2011

    DS: there is some overlap in the dates for SVG, Webapps and (missed

    <shepazu> [12]http://www.w3.org/2002/09/wbs/35125/TPAC2011/

      [12] http://www.w3.org/2002/09/wbs/35125/TPAC2011/

    CM: it says SVG may move to thu-fri

    <heycam> shepazu, [13]http://www.w3.org/2011/11/TPAC/

      [13] http://www.w3.org/2011/11/TPAC/

    ED: would like to know when we'll meet at TPAC, mon-tue or thu-fri

    CM, DS: would prefer thu-fri

    ED: that's fine with me

    CM: if we ask them to swap to thu-fri that wouldn't cause any
    ... maybe SVG was put mon-tue to not overlap with HTMLWG

    DS: will see if we can get it changed to thu-fri

FX charter items

    CM: vincent mailed the sheet with the latest discussions we had
    ... and CL said CSSWG was happy with those
    ... so both groups can move forward with chartering



    FTR this was the proposal from the svg wg:


    DS: will get to it this week, certainly before the next meeting
    ... anything we need to discuss wrt that?

    CM: is there an FX call before the F2F?

    ED: might be good, will send out an agenda for next monday

    DS: the pointer-event spec hasn't been updated lately, maybe we need
    a status update

    CM: might be only on www-style
    ... TH are you attending the F2F in Seattle?

    TH: I might

    CM: another reminder for people to put their agenda items on the

opentype / svgfonts

    CM: on the call last week we had a generally positive response to
    the proposal
    ... i think it would be good to send a response on the mailinglist,
    perhaps an offer to work together

    DS: i'm interesting doing more advanced fonts

    ED: i do like the markup way, as already speced, to be able to mix
    the content and do dynamic updates
    ... but I do see the positive aspects of the proposal
    ... it's just another way to encapsulate the font

    CM: the proposal does seem to allow you to do dynamic stuff, but
    with a wrapper and do some binary stuff
    ... point being, it's possible but not simple, to modify the font
    ... i think it does move to dynamic in-document manipulation

    DS: interpreting and rendering the font is the bulk of the work, the
    serialization is relatively minor
    ... if this is an acceptable format that everyone supports then we
    can try to solve the serialization problem later if appropriate

    CM: i agree with that
    ... whenever we expose lower level apis ninja javascript library
    authors tend to make some nice abstractions from them
    ... bringing this topic up was to ask how the group should respond
    to the thread

    DS: i think we should offer to help, and send a positive response

    ED: adding another serialization of svgfonts is fine with me

    <scribe> ACTION: CM to respond to the opentype/svgfont thread on
    behalf of the group [recorded in

    <trackbot> Sorry, amibiguous username (more than one match) - CM

    <trackbot> Try using a different identifier, such as family name or
    username (eg. charles, cmccorma)

    <scribe> ACTION: Cameron to respond to the opentype/svgfont thread
    on behalf of the group [recorded in

    <trackbot> Created ACTION-3060 - Respond to the opentype/svgfont
    thread on behalf of the group [on Cameron McCormack - due

SVG 1.1 second edition

    CM: today is the last day to respond to the AC review survey
    ... only complaint is about references and relaxng/dtd



    CM: the DTD files in our repo were modified in the first LC?

    ED: yes



    CM: what were the changes we made?

    ED: see the cvs changelog link above

    DS: the rng would be informative?

    CM: right
    ... so i don't think it's needed with the REC itself
    ... so we haven't made one
    ... we could say someone will make an RNG
    ... i think CL was going to talk to him about this

    <heycam> and murata-san was going to make one


      [20] http://www.w3.org/TR/SVG11/DTD/svg11-flat.dtd

    previous REC linked to

      [21] http://www.w3.org/Graphics/SVG/1.1/DTD/svg11-flat-20030114.dtd

    ED: it's in a different location from the spec itself

    CM: might make sense to install the modified DTD there too

    DS: that works for me
    ... will check if we can make a change to add the informative
    reference when we move to REC

    CM: we need the published REC date in the url anyway
    ... and we need a new errata document to link to too
    ... so I expect such changes to be possible

    <scribe> ACTION: cameron to copy over the 1.1F2 DTD and give it a
    date + link to it from 1.1F2 [recorded in

    <trackbot> Created ACTION-3061 - Copy over the 1.1F2 DTD and give it
    a date + link to it from 1.1F2 [on Cameron McCormack - due

    CM: how do we proceed after today with moving to REC?

    DS: *reading process document*
    ... assume CL and I will take care of it
    ... we'll get the documents in the right place and publish

canvas accessibility

    <shepazu> [23]http://schepers.cc/retain-a11y-immediately

      [23] http://schepers.cc/retain-a11y-immediately

    DS: that's my proposal


      [24] http://www.w3.org/WAI/PF/HTML/wiki/Canvas_Accessibility_Use_Cases

    DS: there has been a long discussion the canvas mailinglist
    ... rich schwerdfeger claims svg is not accessible
    ... canvas is an immidiate mode api, svg is a retained mode api
    ... they want to add retained mode characteristics to canvas
    ... primary use-case is so that screenreaders / magnifiers you'd be
    able to find it and zoom
    ... whatever you need to zoom on
    ... charles pritchard suggested to make a subtree (you can tuck in
    elements inside the canvas element and that's invisible but can be
    exposed to a11y tools)
    ... e.g a dropdown
    ... other aspects of the subtree is that it can retain text
    ... you'd have to do it manually

    CM: you'd have to manually mirror the content
    ... some proposals had some automated parts in it

    DS: the functionality allows you to make an accessible html version
    of whatever you made in canvas
    ... personally i think it's barking up the wrong tree
    ... when it was just functional things, say a form control in canvas
    that you then made an accessible equivalent of that
    ... but then it's also the shape of the thing, the boundingbox of
    the form control
    ... and that's when people said this is svg
    ... instead of making an svg-like thing, why not just use svg?
    ... you can already layer svg on top of canvas
    ... you can integrate svg and canvas on the rendering level, and you
    could put the svg either in the dom, or in the subtree underneath
    the canvas, or you could put it in the dom and reflect it in the
    ... either put it in the dom, or in the subtree-dom, or a pointer to
    the subtree dom

    CM: not sure i follow
    ... the last part

    DS: you could e.g put an svg:use element to link to something

    CM: what is the distinction?

    DS: if you put in svg elements they could render to the canvas
    ... but it would have all the location information

    CM: the inverse of that seems logical
    ... having canvaslike things inside an svg tree
    ... a pixelbased container

    DS: right, that's been discussed before, drawing using the canvas
    api to an svg:image element for example

    CM: that is closer to their main use-case i think
    ... make widgets in svg

    DS: two vendors have already said that they don't want to add
    retainedmode functionality to canvas, since there's already svg

    CM: in the proposals you'd have to do manual work to get things
    ... doing something more complex with WAI and ARIA is what we need
    to do

    DS: CM your aria-region idea was reasonable
    ... curious, how would we like to see svg and canvas mixed? and
    would it satisfy the usecases the a11y ppl are looking at

    CM: probably we'd get back that svg isn't accessible yet, or if it's
    enough to allow aria attributes on all svg elements or if we need to
    do more

    DS: we probably have to do a bit more
    ... first we have the logical form controls
    ... then you have the geometric information
    ... maybe they want to have the geometric info completely separate
    from the logical / navigation order stuff and functionality of the
    form controls

    CM: right, in the subtree theyr'e using aria attributes to have form
    controls as values and tab order
    ... the region where they're painted on the canvas is defined in
    another way

    DS: they're trying to accomplish different things
    ... whole thing seems like a kludge
    ... best thing we can do as a group
    ... with their proposal you'd have to maintain the dom yourself and
    mirror the logics
    ... it seems theyre willing to settle for different but equal, but
    if you have to maintain it yourself it's going to be worse than if
    you have an api that allows you to do both immidiate mode and
    retained mode graphics
    ... with my API you'd say if you wanted retained or not when you use
    the API

    CM: so you can use the smae painting calls?

    DS: yes
    ... if you have an asteroids game you have lots of objects that you
    need to track but they're not possible to interact with, until they
    get close enough to interact with, at which point you say now i want
    retained mode
    ... i think what people liked the most was the idea of only having
    to learn one api for canvas and svg, even if there are some
    differences between the two
    ... would like to have a discussion on canvas/svg integration

    CM: good topic for the F2F?

    DS: yes
    ... they may be thinking of full svg implementation compared to
    canvas implementation in thirdparty products, and then tipping over
    in favor of a simpler model
    ... not necessarily involving browsers
    ... however if it's meant to be proprietary then why force it on
    ... will write up some use-cases around this and put it on the svg
    ... and we can discuss it at the f2f

    <thorton> phone's down!

    <shepazu> nope, all good, heycam

    <shepazu> trackbot, end telcon

Summary of Action Items

    [NEW] ACTION: cameron to copy over the 1.1F2 DTD and give it a date
    + link to it from 1.1F2 [recorded in
    [NEW] ACTION: Cameron to respond to the opentype/svgfont thread on
    behalf of the group [recorded in
    [NEW] ACTION: CM to respond to the opentype/svgfont thread on behalf
    of the group [recorded in

    [End of minutes]

     Minutes formatted by David Booth's [28]scribe.perl version 1.136
     ([29]CVS log)
     $Date: 2011/07/07 21:31:37 $

      [28] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
      [29] http://dev.w3.org/cvsweb/2002/scribe/

Scribe.perl diagnostic output

    [Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.136  of Date: 2011/05/12 12:01:43
Check for newer version at [30]http://dev.w3.org/cvsweb/~checkout~/2002

      [30] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/javascript library authors/ninja javascript library author
Succeeded: s/to do/to add/
Found ScribeNick: ed
Inferring Scribes: ed
Default Present: heycam, Doug_Schepers, +1.408.839.aaaa, [IPcaller], ed
, Tim_Horton
Present: heycam Doug_Schepers +1.408.839.aaaa [IPcaller] ed Tim_Horton
Agenda: [31]http://lists.w3.org/Archives/Public/public-svg-wg/2011JulSe
Found Date: 07 Jul 2011
Guessing minutes URL: [32]http://www.w3.org/2011/07/07-svg-minutes.html
People with action items: cameron cm

      [32] http://www.w3.org/2011/07/07-svg-minutes.html

    End of [33]scribe.perl diagnostic output]

      [33] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm

Erik Dahlstrom, Core Technology Developer, Opera Software
Co-Chair, W3C SVG Working Group
Personal blog: http://my.opera.com/macdev_ed
Received on Thursday, 7 July 2011 21:35:32 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:20:13 UTC