SVG Working Group Teleconference -- 11 Sep 2014

<trackbot> Date: 11 September 2014

<ed> ScribeNick: ed

Proposed Sydney F2F dates

CSSWG 9th - 10th

FXTF 11th

SVGWG 12th - 13th

<birtles> fine with me

ed: these are the proposed dates from the CSS WG, they're awaiting our feedback on this

tav: long travel for just two days of meetings

ed: tav, would you rather have more days for the svg part?

tav: yes, one additional day would be good
... suggest 12-14 th Feb

<stakagi> zakim ??P10 is me

ed: the 14th is a saturday, everyone ok with that?

nikos: valentines day
... doesn't bother me though

ed: 14th is fine with me

RESOLUTION: the SVG WG will meed in Sydney, 12 - 14th February 2015

tav: for the FXTF there are some issues surrounding text that we should handle, like fill and stroke on text
... could that be done that day?

ed: sounds like a good topic for FXTF yes

https://www.w3.org/Graphics/SVG/WG/wiki/F2F/Sydney_2015

<scribe> ACTION: ed to update https://www.w3.org/Graphics/SVG/WG/wiki/F2F/Sydney_2015 with dates and registration form [recorded in http://www.w3.org/2014/09/11-svg-minutes.html#action01]

<trackbot> Created ACTION-3669 - Update https://www.w3.org/graphics/svg/wg/wiki/f2f/sydney_2015 with dates and registration form [on Erik Dahlström - due 2014-09-18].

Handling of trailing semicolons in list attributes

<nikos_> scribenick: nikos_

ed: This is a bug that came up on blink. keySplines didn't work with a trailing semi-colo. There was no animation

<ed> https://bugzilla.mozilla.org/show_bug.cgi?id=705236

ed: there's some background regarding how trailing semi-colons are handled

<ed> values, keyTimes,

<ed> keySplines, keyPoints, begin, end

ed: think most browsers are treating these the same way, except for keySplines and the case where you have two or more semi-colons at the end - indicating an empty value
... I guess the only thing that differs is the spec says something different than what implementations are doing
... proposal is to update spec to match implementations
... and to define multiple semi-colons means an empty value
... I saw Dr Hoffman replied - he seems to be in dissagreement

<ed> http://lists.w3.org/Archives/Public/www-svg/2014Sep/0020.html

birtles: think his concern is compatibility of specs, not of browsers. He said svg 2 should be compatible with svg 1 in terms of what the spec says
... but that's not taking into account the accessibility issue of the content
... there's content that relies on ignoring the trailing semi-colon

ed: I think that's a fair point
... people seem to expect that a trailing semi-colon is ignored
... rather than it meaning there's an empty value
... I think the implementation in Gecko is such that when you have two semi-colons then there is an empty value. But don't think that's the case in Blink
... I'd be ok in changing that in Blink
... at the same time I'd also like to align other separators
... trailing commas are not always ignored and I think they should be
... all browsers I tested except FF allow trailing commas

<ed> http://jsfiddle.net/u6s671gb/4/

ed: that's a simple test case
... you'll see there's a comma at the end of the y and rotate
... if it's rotated then trailing comma is allowed
... I'm suggesting we allow trailing commas in all list attributes
... in addition to the original proposal regarding semi-colons

<ed> http://lists.w3.org/Archives/Public/www-svg/2011Nov/0136.html

ed: anyone disagree with this change?

Tav: it would basically just break badly written svg?

ed: yes
... trailing commas already works in all browsers except FF and I'm pretty sure it's been like that for a while
... I'd be surprised if much content relied on the specific behaviour with semi-colons

<birtles> it seems good to me, not allowing trailing commas is a well-known pain point with json

Tav: I'm mostly fine but I think we should ask Dr Hoffman if he has content that will break with this change

<birtles> I believe Ikivo Animator exported content with trailing semi-colons and they agreed to fix the bug but never released another version

<birtles> and the content generated with the buggy version still exists

ed: I think Ikivo was the main source of additional semi-colons

Tav: is this breaking content from Ikivo?

ed: yes if we do something other than ignore trailing semi-colons then content would break
... it was a bug in their software, but content is out there
... may not be very much though

shepazu: it's an easy fix for the content
... we need to have one way of doing it right?

Tav: I would be happy if we made this change if it's demonstrated that there's not much content out there using this

shepazu: we should either just do it for a particular reason (e.g. interoperability) or not do it
... it's going to be difficult to demonstrate the amount of content out there that's using this
... let's just base it on the merits of the idea
... Ikivo content is unlikely to be used with an SVG 2 user agent
... is the proposed change more consistent with the internal model or not?

birtles: in JS you can use trailing commas but in JSON you can't
... and that causes confusion for people
... people expect trailing commas will be ignored

shepazu: is there any analog in CSS?

ed: I think we should allow trailing commas
... that's what 3 of 4 user agents do at the moment
... and we should allow trailing semi colons for all smil attributes
... if you want an empty value two semi-colons are required
... which means you can't have an empty value at the end of the list
... I don't see the value in keeping the spec as is

Tav: anyone object to the proposal? I'm not going to

RESOLUTION: accept Brian's proposal for handling trailing semi-colons on animation attributes
... apply Brian's proposal to trailing commas for consistency

<scribe> ACTION: Erik to update SVG 2 to apply changes relating to handling trailing semi-colons and trailing commas [recorded in http://www.w3.org/2014/09/11-svg-minutes.html#action02]

<trackbot> Created ACTION-3670 - Update svg 2 to apply changes relating to handling trailing semi-colons and trailing commas [on Erik Dahlström - due 2014-09-18].

Pointer events test review

<ed> http://lists.w3.org/Archives/Public/www-svg/2014Sep/0009.html

ed: the pointer events WG has suggested that we review one of their tests for the pointer events spec
... anyone familiar with the specification?
... looking for someone to commit to reviewing the svg tests
... not hearing any volunteers
... they emailed the mailing lists so I guess anyone could review
... but it'd be easier if one of us reviewed
... I'll leave that as an open request

shepazu: the test contains things like scroll values

<shepazu> https://github.com/w3c/web-platform-tests/pull/1121/files

shepazu: it has target0.scrollLeft
... do we have scroll in SVG?

shepazu: is this really a test of pointer events in svg or in an img element?

ed: I haven't read the spec but I think it's trying to test something that doesn't happen on the SVG DOM

shepazu: I'd like to give them some feedback on this test. It seems they're just treating svg as a block level element
... it's not wrong but it's not really a test for SVG

ed: I think it's trying to test touch-ACTION:none on the svg
... which means the element shouldn't trigger any default touch events

shepazu: there's a few tests moving the element different directions
... it's not testing svg, just a block level element
... so it's not testing pointer events on SVG as such

nikos: it looks that way to me

ed: I think that's fair
... you could replace the svg element with another html element

shepazu: do we have examples of some sort of test that might be useful for their purposes?
... nothing springs to mind

ed: I think it would be a good idea to have some more svg tests if they want to test touch events on svg

shepazu: I'll contact the pointer events group

- DRAFT -

SVG Working Group Teleconference

11 Sep 2014

Attendees

Contents

Proposed Sydney F2F dates

Handling of trailing semicolons in list attributes

Pointer events test review

Summary of Action Items

Scribe.perl diagnostic output