SVG Working Group Teleconference -- 26 Mar 2015

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

- DRAFT -

SVG Working Group Teleconference

26 Mar 2015

Attendees

Contents

Declarative animation

SVG 2 open issue discussion

Interactivity chapter issue 5

Interactivity chapter Issue 4 - Focus management

SVG 2 Appendices

Summary of Action Items

Scribe.perl diagnostic output