Minutes, 26 March 2015 SVG WG telcon

Formatted minutes at
http://www.w3.org/2015/03/26-svg-minutes.html


SVG Working Group Teleconference
26 Mar 2015

   [2]Agenda

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

   See also: [3]IRC log

      [3] http://www.w3.org/2015/03/26-svg-irc

Attendees

   Present
   Regrets
          Dirk

   Chair
          Cameron

   Scribe
          Nikos

Contents

     * [4]Topics
         1. [5]Declarative animation
         2. [6]SVG 2 open issue discussion
         3. [7]Interactivity chapter issue 5
         4. [8]Interactivity chapter Issue 4 - Focus management
         5. [9]SVG 2 Appendices
     * [10]Summary of Action Items
     __________________________________________________________

   <trackbot> Date: 26 March 2015

   <scribe> scribenick: nikos

   <scribe> Scribe: Nikos

Declarative animation

   shepazu: the general topic is svg declarative animation in the
   image element
   ... the svg integration spec says that this should be allowed
   ... implementations that support declarative animation and svg
   in the image tag support this
   ... that's timeline based stuff
   ... it does not allow interactivity
   ... neither the spec nor the browsers allow that
   ... David Dailey made the case that this is limiting how useful
   svg could be
   ... I drew up some short use cases
   ... on the mailing list
   ... I agree that this would be useful
   ... Daniel Holbert (Mozilla) has said this might be an
   interesting idea to support
   ... even if you don't support SMIL you might support CSS
  animation or other interactive things like navigating links or
   hover effects
   ... I'm wondering what you all think - is this a good or bad
   idea?

   AmeliaBR: one important thing - this is coming out because
   people are annoyed that social media won't let them post
   interactive objects
   ... the only option everyday users have is via images
   ... when it comes to svg theres a couple of things
   ... lots of social media don't support svg at all
   ... I think as the first step we should be trying to convince
   people that it's safe to allow svg as an image type
   ... and I'm concerned that if we make svg images less like
   other images (e.g more powerful) that may scare of svg for
   support as an image format
   ... for timeline based animation it's easy to liken svg to
   animated gifs
   ... the other thing to think about is there's already embedded
   objects
   ... there is a means of embedding fully interactive svg
   ... this isn't applicaable to social media sites currently
   ... so not sure what the benefit of making svg as an image a
   duplicate of svg as an object

   shepazu: think there's a lot of value in your comment about
   trying to achieve parity first
   ... if we want people to see that this is as secure as a gif
   ... it's useful to be able to show that
   ... but if it's only as good as those things (e.g. gifs) but no
   better, then why bother
   ... with the capabilities of existing image formats, the costs
   seem relatively small but the benefits seem relatively small
   ... second point you made - why allow this in an image as
   opposed to an iframe or whatever
   ... in an iframe, anything goes
   ... it's not secure
   ... having a declarative way of having simple interactions is
   secure

   <ed> so, how much of this does Content Security Policy + CORS
   address?

   nikos: has there ever been discussion on allowing more fine
   grained control of what is allowed on the object element?

   heycam: iframe has a sandbox feature
   ... don't think it's implemented anywhere at the moment
   ... might be a good solution for this though
   ... could allow interactive svg with the sandbox attribute
   ... but what happens on a browser that doesn't implement the
   sandbox attribute? anything would be allowed.

   Rossen: we've been looking at different solutions. One of the
   solutions that Chrome was going after - SMIL implemented as JS
   ... appears to be palatable to us
   ... but can't add to the current discussion more than that at
   the moment

   shepazu: maybe a good first step would be for me to make some
   tests?
   ... the question of animation is orthogonal to the question of
   interactivity

   heycam: We have a layer in which we handle svg as images - the
   part of Gecko that also deals with raster images
   ... whenever you have an svg doc as an image then there's a
   single document running behind the scenes that we request to
   paint
   ... if we have multiple uses of the one document the timelines
   are synchronised
   ... because there's only really one document running
   ... if we were to support interaction the documents would need
   to diverge

   Rossen: In IE all the resources will be re-used but the
   animations will run separately

   shepazu: another related question - in Gecko, does the SVG
   image actually have a DOM?

   heycam: internally we do
   ... don't have the facility to play animations without having
   the dom there

   birtles: we support event based animations on svg in an image
   ... with a white list of events that are allowed
   ... begin, end and repeat
   ... internal events

   ed: Would people ask for the same level of interaction for
   background images?

  shepazu: I think that would be disruptive - but others said why
   not
   ... personally I'm not in favour
   ... but I can see if someone wants to insert an icon in CSS,
   they might want hover effects
   ... so I can see the use case

   ed: Was also wondering how much of the concerns raised here are
   addressed by the content security policy and CORS?
   ... with CSP you can prevent certain resources from loading

   shepazu: I agree that CSP is probably the right way of handling
   that
   ... if you're interested in this topic - I'd like to see more
   discussion on the mailing list
   ... so we can work towards a solution

   AmeliaBR: we should get feedback on the implementability of
   this
   ... whether there's problems passing events through to the
   image document
   ... maybe talk to the HTML guys

SVG 2 open issue discussion

   heycam: last time we finished which chapter?

   Rossen: co-ords and transforms I think
   ... two issues still to be discussed
   ... haven't seen any discussion on the mailing list
   ... issue 10 and issue 20
   ... Bogdan will create test cases for 10
   ... there was also supposed to be discussion on the mailing
   list but I haven't seen that

   heycam: it looks like those two are waiting on initiation of
   the discussion or some work
   ... so probably don't need discussion right now

   <AmeliaBR>
   [11]https://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Chapter_Assess
   ment

     [11] https://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Chapter_Assessment

   heycam: I recall we discussed some of the issues in the styling
   chapter
   ... in the types chapter - those issues are also waiting on
   some testing or some work
   ... we've done paths and basic shapes
   ... I think there are some issues in text that we haven't
   discussed?

   Tav: think we discussed most of them
   ... might be a few that I need to look at before we discuss
   ... not ready to discuss any now

   heycam: Erik, there's two on the interactivity chapter - can we
   discuss those?

Interactivity chapter issue 5

   <ed> [12]https://svgwg.org/svg2-draft/interact.html#issue5

     [12] https://svgwg.org/svg2-draft/interact.html#issue5

   ed: resize, scroll and zoom are defined as applying at the
   documnet level
   ... there were some comments that resize should apply on each
   svg fragment
   ... but they're not defined that way
   ... I'd like to clarify the term 'document view'
   ... link to whichever spec defines the resize and scroll events
   ... that term is already used there

   heycam: I would hope we don't need to say much at all
   ... about resize and scroll
   ... is scroll a bit different because we dispatch that when the
   current pan and zoom values change?

   Rossen: how would you expect this to differ from html content?
   ... or would you?

   ed: I wouldn't expect it to differ
   ... resize and scroll should be the same
   ... zoom is unique to svg
   ... we have some room if we want to do something special there
   ... but svg zoom isn't implemented that well anyway

   Rossen: wouldn't svg zoom map to css zoom?

   ed: dont' think it does currently - but perhaps it could

   Rossen: I would expect it to map
   ... not that css zoom is currently specced but everyone is
   implementing
   ... it's an action item on Nat Rako (sp?) on my team who is
   going to write a spec about all things zoom related
   ... alongside device pixel ratio
   ... don't know when that spec will happen
   ... as a result I can spearhead at least the css zoom property
   ... which should map fairly well with svg zoom
   ... so svg shouldn't do anything special

   heycam: svg zoom is the only even that we didn't have something
   from the existing dom spec to rename it to
   ... initiall these were all 'svg load', 'svg scroll', etc
   ... if there's a zoom thing we can change it to that would be
   really good
   ... suprised if people are expecting dot type to be svg zoom
   rather than just zoom

   ed: there's a special zoom event interface in the svg spec
   ... not sure it's implemented anywhere

   Rossen: easiest way to find out if people depend on it is to
   try to kill it and see if anyone complains

   heycam: I know I've done content that depends on svg zoom

   <ed>
   [13]http://www.w3.org/TR/SVG/script.html#InterfaceSVGZoomEvent

     [13] http://www.w3.org/TR/SVG/script.html#InterfaceSVGZoomEvent

   heycam: but in these days of of not everyone supporting native
   zoom and pan gestures, I'm not sure if people are doing that
   these days

   <ed>
   [14]https://svgwg.org/svg2-draft/script.html#InterfaceSVGZoomEv
   ent

     [14] https://svgwg.org/svg2-draft/script.html#InterfaceSVGZoomEvent

   heycam: Rossen, could you ask Matt for the recent summaries of
   what the zoom event looks like?
   ... so we can make a decision on how closely it matches svg
   zoom?

   Rossen: yes
   ... going back to the open issue - which is about zoom as well
  as scroll and resize
   ... I wouldn't expect scroll and resize to be different than
   html

   heycam: the scroll event - we have this wording that says 'when
   the current translate property on the root svg element changes
   then a scroll event is dispatched'
   ... that would be in addition to the root element being
   scrollable
   ... that wouldn't be defined in the dom spec
   ... it's svg specific
   ... but we can say in our spec that this is the same event that
   we dispatch for

   Rossen: would be more comfortable with that
   ... introducing an entire event for one small difference is too
   much

   heycam: we already replaced all except zoom with the standard
   ... in terms of this specific issue, it seems like it's just a
   matter of finding the right terms to link to?

   ed: I'm fine doing edits for scroll and resize, thats well
   defined
   ... for zoom I don't mind waiting until we have another spec to
   reference

   heycam: I agree it's probably not critical

   ed: what are people comfortable with - taking out zoom or
   leaving it in?

   heycam: think it should be left in

   AmeliaBR: we could add a more specific issue saying we need to
   follow up with css zoom

   heycam: how about we wait for the info from Rossen about the
   event
   ... and see if we can make a quick decision then
   ... if all implementations match then it will be specced that
   way so it's probably safe to refer to that

   Rossen: if this was the last issue holding back the spec from
   CR would you hold the spec for that issue?

   heycam: if you said you were going to come back in a week then
   probably
   ... otherwise not

   Rossen: I don't think this issue merits that much attention
   ... but will follow your lead

   ed: I have enough information to resolve the issue for scroll
   and resize

   Rossen: let's just repurpose the issue for zoom only then

   heycam: to clarify, you'll do some rewording and pointing to
   another spec right?
   ... document view is completely undefined at the moment

   ed: yes

   <AmeliaBR>
   [15]https://svgwg.org/svg2-draft/interact.html#issue4

     [15] https://svgwg.org/svg2-draft/interact.html#issue4

Interactivity chapter Issue 4 - Focus management

   AmeliaBR: looks like text was copied from HTMl
   ... issue is whether we need to refine it to make it SVG
   specific

   heycam: do we need to have copied this into the spec?
   ... or can we point directly to HTML for the definition of
   focusable and focusing and unfocusing steps
   ... if it's identical we don't need duplicate text

   ed: agree

   AmeliaBR: agree we shouldn't be copying text but we might need
   svg specific clarification on elements being rendered
   ... has come up in svg-a11y TF
   ... it's implicit that certain elements are rendered to the
   screen and others aren't
   ... but needs to be a clearer definition of what that means

   heycam: are you familiar with the parts of the html spec that
   talk about focus?

   AmeliaBR: no

   heycam: if Rich is not here, maybe someone should do a
   comparison with what we have and what's in the HTML spec
   ... and determine whether we need any svg specific differences
   ... and if so, what they are
   ... so we can work out what to do with this section
   ... are you alright with doing that Erik?

   ed: yes
   ... also rendering part should be in the rendering chapter
   somewhere

   <scribe> ACTION: Erik to compare focus text in svg spec vs html
   spec to determine the differences [recorded in
   [16]http://www.w3.org/2015/03/26-svg-minutes.html#action01]

   <trackbot> Created ACTION-3775 - Compare focus text in svg spec
   vs html spec to determine the differences [on Erik Dahlström -
   due 2015-04-02].

   heycam: think that apart from the painting chapter, we've
   discussed all the issues
   ... need people to make progress on the issues that they own

   Rossen: I'll come back with some stuff next week definitely
   ... will clean up shapes and animation
   ... extensibility after that

   nikos: Next week will be Good Friday in Australia

   heycam: I'll be away

   ed: I'll also be away next week

   heycam: should have plenty to discuss the week after

SVG 2 Appendices

   heycam: Bogdan you've taken all the appendices - are you happy
   with that?

   Rossen: Bogdan not here but he picked them up because no one
   else wanted to sign up for them
   ... If anyone would like to offer a helping hand that would be
   good
   ... if no one wants to sign up we'll try to work through them

   heycam: Don't think we had a proper discussion about what
   appendices we want
   ... so everyone if there's one you particularly like then let
   Bogdan know

   AmeliaBR: Rich has been taking care of the accessibility
   appendix
   ... will talk about it on the TF
   ... others not too exciting

   Rossen: don't think there'll be much friction on the issues,
   but there's a lot of content

Summary of Action Items

   [NEW] ACTION: Erik to compare focus text in svg spec vs html
   spec to determine the differences [recorded in
   [17]http://www.w3.org/2015/03/26-svg-minutes.html#action01]

   [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.