Minutes, 21 May 2015 SVG WG telcon

Formatted minutes at

SVG Working Group Teleconference

21 May 2015


      [2] https://lists.w3.org/Archives/Public/www-svg/2015May/0025.html

   See also: [3]IRC log

      [3] http://www.w3.org/2015/05/21-svg-irc


          Thomas_Smailus, [IPcaller], heycam, Tav, stakagi,
          [Microsoft], nikos_, Rich_Schwerdtfeger, AmeliaBR,





     * [4]Topics
         1. [5]SVG 2 accessibility appendix update
         2. [6]transform on root <svg>
     * [7]Summary of Action Items

   <trackbot> Date: 21 May 2015

   <ChrisLittle> I will lurk - no phone. Sorry.

   <heycam> ChrisLittle, no problem

   <heycam> richardschwerdtfeger, Zakim

   <scribe> Scribe: Nikos

   <scribe> Scribenick: nikos_

SVG 2 accessibility appendix update

   richardschwerdtfeger: until we add some additiona specs - e.g.
   taxonomy for graphics

   <AmeliaBR> [8]https://www.w3.org/wiki/SVG_Accessibility

      [8] https://www.w3.org/wiki/SVG_Accessibility


      [9] https://www.w3.org/wiki/SVG_Accessibility

   richardschwerdtfeger: in addition to api mappings, we're
   looking at navigation models and the semantics
   ... so potentially we can have a new taxonomy to be referenced
   in the appendix
   ... still flushing out the navigation model (stuff other than
   tab index)
   ... not sure if it will make it in time for svg 2
   ... one of the things that was asked was the parts of WCAG that
   apply to the lengths we refer to in the appendix
   ... I haven't had time to do that yet

   heycam: have you touched the currrent appendix?

   richardschwerdtfeger: yes
   ... we wanted to highlight the new features in SVG 2

   <AmeliaBR> [10]https://svgwg.org/svg2-draft/access.html

     [10] https://svgwg.org/svg2-draft/access.html

   richardschwerdtfeger: looking at this
   ... we have new features - list all the places that have
   keyboard support - tabindex, keyboard handlers, scripting
   extensions for setting focus, determining active element
   ... second thing, ARIA support and text alternatives
   ... how they fit in terms of native language semantics
   ... don't think I removed the animation stuff from the spec
   ... we also talk about information in desc and title


     [11] https://svgwg.org/svg2-draft/access.html

   richardschwerdtfeger: and how aria-label and labelby work
   ... finally, we link to specs that have direct applicability to
   vector graphics
   ... all those documents combined state how svg documents are
   mapped to accessibility service layers on the major platforms
   ... refer to aria 1.1 and wcag 2.0
   ... much more comprehensive and svg specific than the old

   heycam: yeah looks a lot better - old appendix was all wishy

   richardschwerdtfeger: the TF has been talking about authoring
   practices - depending on timing we may be able to include that
   ... I think it's very strong - don't know if even html spec has
   this much clarification

   heycam: further edits would be referencing other specs and
   explaining how they work

   richardschwerdtfeger: e.g. keyboard suport - would be nice but
   not sur ewhen it'll be ready
   ... have a question regarding text elements - something new to
   aria 1.1 - we say that this image is text and we can apply the
   text like an aria label to it
   ... so is that something you would want to do in svg?
   ... e.g. this sequence of path drawing calls would produce text
   ... and put role=text and an aria label
   ... is that something you would want to do ?

   AmeliaBR: you would always be able to say role=text and aria
   label and it would be accessible for screen readers
   ... the question is, should we make it accessible to other user
   agents in that way
   ... so if you did ctrl-s on your webpage it would find it as
   ... or you copied and selected, it would copy and select with
   plain text included
   ... this is something new
   ... aria was very careful not to prescribe behaviour for
   browsers other than accessibility tools. So this would be
   something new.
   ... giving that role attribute more power than it has for aria

   heycam: this would be for more than just svg?

   richardschwerdtfeger: could apply to html as well, but we
   thought it was powerful for svg

   heycam: have you asked the html folks about the idea?

   richardschwerdtfeger: no - we were just going through this with
   the TF and we said this capability in aria 1.1 could be
   leveraged in svg
   ... so it's a new idea
   ... but this is up to the host language - not aria

   AmeliaBR: svg can be a testing ground for this
   ... could it be more than just role=text. e.g. widget roles
   like buttons, sliders, etc
   ... they could be mapped to keyboard roles automatically
   ... right now to create accessibility interactive components in
   svg you need to write all the keyboard handlers yourself
   ... it's a big limitation on people making svg accessible

   heycam: in terms of level of difficulty of making it accessible
   - you have to write the keyboard handlers to have the normal
   behaviour anywa
   ... I think of it as an integral part of the component
   ... I'd be a bit worried if the browser was adding default
   keyboard handlers that might not be appropriate for the way the
   widget is presented
   ... you might be using svg to realise some fancy design and the
   defaults wouldn't be appropriate.

   AmeliaBR: there are aria attributes to customise behaviour like
   ... but at this point we don't have a detailed proposal
   ... so just bringing the idea to the group to see whta interest
   there is

   Tav: getting back to text - we talked about something like this
   when we discussed getting rid of svg fonts
   ... so I think it's a good idea

   heycam: I agree we should have something that allows you to
   mark up the graphics as text
   ... so you can do seraching and whatever
   ... might need to think about it some more to decide if
   role=text is the best way to do that
   ... i'm a bit wary of attaching additional behaviour to the
   aria attributes
   ... had a discussion a few years ago about making tooltips
   appear in response to aria roles - had the same wariness then
   ... not sure if fundamentally it's a bad idea - or it just
   has'nt been done yet
   ... so I don't have a strong feeling yet

   richardschwerdtfeger: one of the places we'll see this show up
   is in digital books
   ... we have an aria module that reflects digital publishing
   ... will be used in CMS
   ... specifying browser functionality like - goto glossary
   ... so it's starting to happen, but the aria working group
   wouldn't be the group to define that though
   ... so the question is - do we want to work on the proposal -
   does the group want that?

   heycam: I think there are some details to think about - like
   what happens in terms of highlighting the graphical element
   ... that's the main one I'm thinking of
   ... not an unsolvable problem
   ... but my personal opinion is that I'm not against it - might
   be easier to evaluate with a proposal
   ... in terms of that functionality of declaring some graphics
   as having text attached
   ... that's a feature we want some how

   AmeliaBR: we can look at other options as well
   ... perhaps create a native svg way of doing the same thing
   ... like here's some text - don't render, render this graphical
   object itself

   heycam: that's what I was thinking - divide graphical object
   into vertical slices to represent each character
   ... if you can come up with some solutions to that use case and
   see if role=text or some other method would be better, then
   that would be great

   AmeliaBR: we'll get back to you

   richardschwerdtfeger: what's the timeframe for svg 2?

   heycam: we've made good progress closing issues - should get
   remaining ones discussed at the f2f
   ... so I would say we are aiming for the end of the year or
   tpac for moving to the next publication stage (CR?)

   richardschwerdtfeger: not sure how we would get a new
   navigation model in that time
   ... but it would be nice to have some sort of taxonomy at least
   by then
   ... we'll discuss in the group

   heycam: there's always the time afterwards in terms of the test
   ... so the spec won't be in CR for a short amount of time

   richardschwerdtfeger: are you doing the workflow with multiple

   heycam: depends on the issues raised

transform on root <svg>


     [12] https://lists.w3.org/Archives/Public/www-svg/2015May/0024.html

   AmeliaBR: we have a couple of questions with respect to how
   transformations on the root element
   ... in svg 1 you couldn't put a transform attribut eon an svg
   ... could do it indirectly with url fragments but not well
   defined and browsers are inconsistent
   ... css allows transformatoins on everything
   ... and gives guidance for a general root element case
   ... but 2 thing specific to svg - viewbox is a transformation,
   which comes first
   ... the way everyone has implemented it for inline svg - the
   transformation attribut egets applied in the parent co-ordinate
   system, then the viewbox is applied for the children
   ... so assuming that will be adopted for svg root elements
   ... but transform-origin
   ... the css specs have waffly language
   ... to make up for the fact that svg elements hav etheir
   default transform-origin on the local co-ordinate system
   ... but css offsets the center of the box
   ... I've tested browsers and the results are inconsistent - so
   we need clear guidance
   ... I agree with cam's comment that we need more explicit
   language in css transforms
   ... right now it just says default is 50%,50%... etc
   ... Cameron suggested to rewrite that as the default style rule
   for elements in the svg namespace

   heycam: I think that's the most practical - I cc'd to the fx
   list so hopefully Dirk saw

   AmeliaBR: the question is - are we going to rewrite that rule
   so that it applies to svg that is a root element"?
   ... i pointed out that because we are allowing backgrounds and
   borders and padding that essentially becomes a css layout box
   ... and should be treated the same
   ... though it's more useful to rotate an entire image from the

   heycam: I think it's consistent with root of html elements
   having 50%,50%
   ... and svg child of FO being 50% as well

   AmeliaBR: the other places where it would be a good consistency
   is when you have a transformation on a root svg and you use
   that svg inside an image you would have similar behaviour to
   inline svg
   ... so I think we're agreed there - so next step is to approach
   css transforms about rewriting that wishy washy statement
   ... as a specific default user agent style rule

   <scribe> ACTION: heycam to contact css working group regarding
   default style rule for transform on root element [recorded in

   <trackbot> Created ACTION-3792 - Contact css working group
   regarding default style rule for transform on root element [on
   Cameron McCormack - due 2015-05-28].

   AmeliaBR: the other question is how the svg view fragment
   interacts with the transformation on the root element
   ... all the other svg view parameters replace the attribute on
   the svg root element
   ... so there has been some voice on the mailing list if it had
   similar behaviour
   ... but its complex because you have to deal with css cascade
   ... so when we discussed previously we said it would apply as
   an additional transformation
   ... you take the svg as it is defined in a file and you put it
   inside group that has the transformation from the view

   heycam: I had forgotten that the other view fragment thing
   replaces the attribut evalues on the root element
   ... so it's a bit unfortunate to have transform work
   ... but I think it's more useful to have transform on the
   outside rathe rthan have the author work out what transform the
   yneed to use in the middle of the transform stack

   AmeliaBR: it's also very messy because of css cascade issue -
   if we do anything other than on top we are going to have to
   talk to css
   ... we are saying a url value replaces a style sheet value
   ... and nothing in the css cascade deals with that

   <Smailus> Gotta drop of.

   heycam: could probably deal with it by saying it replaces the
   value given by the presentation attribute

   AmeliaBR: then it would be confusing for authors if it
   overwrote presentation attributes but not styles
   ... in this case you may be embedding an image - not looking
   inside the svg code
   ... if the decision is to go with the idea that it's an
   addtional transformation on top, I will look at getting the
   exact text in
   ... already have a relevant action

   heycam: sounds like it's good enough to move forward then

   RESOLUTION: the default value of transform-origin on a root svg
   element is a default of 50%,50%
   ... the view fragment transform is applied outside all of the
   other transforms that apply to the root element

   heycam: I did bring u pa small question in my email - what do
   we do with foreignobject?
   ... e.g. the element itself

   AmeliaBR: I think the FO lement itself should be treated as an
   svg element
   ... you always have html elements inside it which would be
   transformed according to the html rules
   ... but the FO itself - I think you can currently transform
   with a transform attribute
   ... so we need to keep the current svg rules

   heycam: I was a little confused because we said 'svg element

   AmeliaBR: all the mor ereason to get that language replaced by
   something more precise

   heycam: anything else to discuss?

   AmeliaBR: think that covers all my points

   heycam: don't forget we're switching to webex next week

   how do you make them public again?

   <AmeliaBR> RRSAgeng, make log public

   ahh make log public

   didn't make minutes public use to work?

   <AmeliaBR> You're not allowed to make public minutes of a
   private log, I guess?

   would be a convenient shorthand though =0

   heycam: clever!

   delegating is good

   <heycam> then it will also list out the Present line, too

   <AmeliaBR> Make the robots work for you...

   <AmeliaBR> trackbot, end telcon

Summary of Action Items

   [NEW] ACTION: heycam to contact css working group regarding
   default style rule for transform on root element [recorded in

   [End of minutes]

The information contained in this email message and any attachments may be confidential and may also be the subject to legal professional privilege. If you are not the intended recipient, any use, interference with, disclosure or copying of this material is unauthorised and prohibited. If you have received this email in error, please immediately advise the sender by return email and delete the information from your system.

Received on Thursday, 21 May 2015 23:31:36 UTC