SVG Working Group Teleconference -- 22 Jan 2015

<trackbot> Date: 22 January 2015

<scribe> scribe: Nikos

<scribe> scribenick: nikos

Linköping F2F date move request

<AmeliaBR> nikos: yep!

heycam: Brian suggested moving one week later
... Seemed like it would be ok from the organising end of things

<AmeliaBR> sorry, heycam. Hello to everyone.

ed: either week is fine

heycam: any objections to moving it later a week?

ed: Do we want Tuesday 9th to Friday 12th?
... or Monday - Thursday?

birtles: i wouldn't be able to make the Monday

Tav: I'd have a little trouble making the Monday
... Tues-Friday would be ok, I might just have to leave Friday afternoon

RESOLUTION: June F2F will be Tuesday 9th June to Friday 12th June

Welcome Amelia

AmeliaBR: Hello everyone! Thanks for having me
... I won't be able to make the June F2F I'm afraid

heycam: glad to have you here

Neutering or dropping SVGSVGElement.forceRedraw

heycam: I was looking through the open issues in the second half of the structure chapter
... which covers SVG element dom stuff
... one issue is what to do with this forceRedraw method
... was wondering if we should define it more clearly
... it's a bit hand wavy
... or we could drop it
... searching the mailing list I came across a discussion about dropping this and suspendRedraw family of methods
... Erik was going to try removing them from Blink

<ed> https://codereview.chromium.org/868603003/

ed: I didn't get an action so never did it back then
... but filed a patch today for dropping this - it's waiting review, but no failures in LayoutTests
... so unlikely it'll break anything

AmeliaBR: so script would break if someone's script called it?

heycam: yes
... our guess is that pages aren't calling this method at all so should be safe to remove it
... we can check in with Erik in a couple of weeks to see how this is going?
... I'm interested in making a decision within the time frame of making changes to the SVG 2 spec
... do you think we'll know by then, or can we drop until LC and see what happens?

ChrisL: I'd prefer we drop it and if it turns out at last minute that major uses cases are deployed we can roll back

heycam: would there be an issue adding things back in without dropping back to WD?

ChrisL: there's no problem in new procedure - there's no LC status anymore
... but you have to show wide review in CR
... you can change as much as you want before CR
... after CR you can update CR with editorial changes, major changes require transition meeting
... another alternative is to deprecate it but that's probably the worst of both worlds

ed: implementation right now is empty methods

ChrisL: I'd be happy blowing it off

AmeliaBR: my perspective as an author is that because of the nature of these methods - they don't return or do anything, it's harmless to have them as methods taht don't do anything
... if they cause an error then someone's script is broken
... and don't know if people would pick that up
... with a test suite

heycam: if we do this experiment removing it from Blink and don't get any problem reports would it satisfy you that it's safe to remove?

AmeliaBR: probably
... I reference them in an SVG book that got published last year
... but don't know how much they're used in the wild

shepazu: Cameron are you suggesting we remove them and throw an error?

heycam: we've already neutered suspendRedraw but not forceRedraw
... neuter is minimum level I'd like

<ChrisL> (discussion on removal with error, or silent neutering)

<ed> https://codereview.chromium.org/868603003/patch/1/10004

ed: To clarify, the Blink patch hasn't landed but it does remove the methods

krit: did you measure usage?

ed: no

<ChrisL> Its removing *stubs*

<ChrisL> / Stubs for the deprecated 'redraw' interface.

krit: would be good to have feedback first

ChrisL: these don't do anything currently - they're just stubs - so are people really likely to be relying on that?

heycam: you can imagine only accidently

<ChrisL> void forceRedraw() { }

<ChrisL> unsigned suspendRedraw(unsigned) { return 1; }

heycam: I'd be happy, now, neutering it in the spec and waiting to see how the patch goes

<krit> ChrisL: right, that is how WebKit implements it

heycam: I wouldn't even be that unhappy if it just remained neutered in the spec

AmeliaBR: I think Doug's and my concern was about not wanting to throw errors in scripts that currently work

shepazu: that's the core issue - having a void function that returns nothing is fine

ChrisL: I understand about errors being thrown, what I was wondering was whether anyone was using these in practice since they don't do anything

krit: what about saying it may redraw in the spec
... then it's up to the browsers

<cabanier> 1800 hits on github: https://github.com/search?l=javascript&q=suspendredraw&type=Code&utf8=%E2%9C%93

<ChrisL> void forceRedraw() { alert("clean up your code, dammit!")}

krit: if we don't get any negative comments from Chromium we can drop the whole API

<krit> cabanier: but is it a property that is called?

heycam: I think may would be too cautious - it would be fine to neuter immediately and decide about dropping later

<cabanier> krit: yes

<krit> cabanier: there are hacks for redrawing that are called the same way too

<heycam> https://github.com/search?l=javascript&q=forceRedraw&type=Code&utf8=%E2%9C%93

heycam: Rik linked to a github search - there are some files calling forceRedraw

krit: looks like forceRedraw are unrelated to svg

heycam: the first result looks like a real svg usage

AmeliaBR: some of these are svg calls

krit: I'm not doubting suspendRedraw but forceRedraw does not do anything svg specific

<heycam> https://github.com/search?utf8=%E2%9C%93&q=suspendredraw+svg&type=Code&ref=searchresults

<heycam> https://github.com/search?utf8=%E2%9C%93&q=forceredraw+svg&type=Code&ref=searchresults

krit: if you're unsure keep wording in svg but make it 'may'
... that way if there are implementations that do something for svg they can continue

heycam: Blink does nothing, WebKit does nothing, Gecko does nothing for suspend but does something for forceRedraw
... I'm not sure it does anything helpful

shepazu: straw poll. Current request is to remove or netuer?

heycam: I'm leaning towards just neutering

<ChrisL> silent neutering

heycam: but I'm still interested to see results of Erik's removal

shepazu: all in favour of neutering and speccing that it does nothing?

<ChrisL> +1 to silent neutering

<heycam> +1

shepazu: if you think something else (remove, change to may, etc), then type -1

<Tav> 0

<smailus> 0

<richardschwerdtfeger> +1

<shepazu> +1

<ChrisLittle> 0

<AmeliaBR> +1

<krit> 0-1

<cabanier> 0

<ed> I prefer dropping it completely

<ChrisLittle> Bye

<krit> Little, Chris

<krit> (good standing)

<krit> Picture of Chris Little

<krit> Met Office

<heycam> i remember now. sorry for not introducing you ChrisLittle :)

<ChrisL> our booking is indeed 12

<ChrisL> https://www.w3.org/Guide/1998/08/teleconference-calendar#s_6329

ed: I'd prefer to remove it completely from the spec because I think it's not a good idea to have methods that don't do anything
... seems pointless
... what about content that will break?

shepazu: what about content that will break?

<ChrisLittle> 44775388aaa was me

krit: would be helpful to get use count numbers

heycam: are you ok with neutering in the spec until we get the results back from the Blink test?

ed: that's the right direction

smailus: was this previously deprecated?

AmeliaBR: wasn't in 1.1 but there was the decision to deprecate in 2

smailus: seems to do it well we should deprecate it first to give people time to fix their code

shepazu: that's the argument towards neutering
... we could deprecate/neuter in svg 2 and remove in svg 3

heycam: I'm a bit suspicious of deprecation like that having much of an effect
... think people may not notice

<ed> these methods haven't done anything useful for a very long time

<ed> in any recent browser

smailus: at least you're giving a heads up

ChrisL: the question is whether deprecation will cause people to remove usage

heycam: do you have any history of when these became useless in Firefox?

<ChrisL> the problem with strict deprecation is that it is still a MUST so implementors still have to implement it and will fail tests if they do not

heycam: a couple of years ago I think - forceRedraw still does something
... I'm happy to neuter and add a note saying it does nothing

<AmeliaBR> The existing SVG 2 text for the suspend methods is "This method is deprecated, and is only kept due to compatibility with legacy content. Calling this method has no effect on redrawing."

heycam: then wait to see what the results of Eriks tests are and decide if we drop completely
... anyone happy with that plan?

RESOLUTION: forceRedraw and suspendRedraw will be neutered/deprecated and may be removed in future depending on the results of Erik's tests in Blink?

Defining or dropping SVGSVGElement.deselectAll

heycam: this is a similar question
... we haven't really talked about this before
... may not need to make a decision now
... this method was meant to do something like unselect any selected text in the document
... but definition is hand wavy
... think there's a clear way to define it if we want to keep it
... but I think it probably doesn't make much sense as an svg thing
... and if it's safe to remove we should do so
... if not we can define current behaviour

shepazu: is there an equivalent in dom?

heycam: equivalent would be window.getSelection.removeAllRanges

shepazu: my immediate reaction is we need better defined selection behaviour
... not just for text, also for shapes, but text at a minimum
... and we should do it however dom does it
... so we should remove this particular method

heycam: given discussion on the safety of removal
... is that what you'd like to do?

shepazu: I doubt anyone is using this, but I'd say neuter and put warning. Deprecate in spec and remove in SVG 3

<ChrisL> +1

heycam: if nobody objects, lets resolve the same approach

<ed> my question was: are the DOM selection specs (DOMRange etc) required in svg2?

<ChrisL> (debating whether text selection is required functionality in SVG2, what DOM2 and DOM4 say, etc)

heycam: selection is probably more important than other APIs

ed: did you consider dropping the selection methods on the text elements?

heycam: No I didn't - that's where you actually select things isn't it

ed: yes

<ed> https://svgwg.org/svg2-draft/text.html#__svg__SVGTextContentElement__selectSubString

heycam: good point
... I guess I'd go for the whole set
... these are all things you can do with the selection API

shepazu: I think some of these are more likely to be used
... but I think we should deprecate them at the least

AmeliaBR: I think the long term goal should be to synch with whatever is happening in core DOM
... but it sounds like nobody on the call is totally sure what is happening in core DOM
... not wanting to break current scripts so deprecate the svg specific methods with the goal of using core DOM methods
... but we need to clearly work out what methods they are and in what spec

heycam: what if I came back with exact equivalent
... of svg api calls
... and define ours in terms of that
... and we still deprecate and remove in future
... and tighten definition of svg calls in terms of core dom methods
... in the meantime

AmeliaBR: sounds sensible to me

shepazu: think it sounds sensible but think we should deprecate still

heycam: agree

ed: agree

shepazu: we want people to realise they should be using core dom methods

RESOLUTION: The SVG text selection methods will be defined in terms of selection API calls and also deprecated

Doug's reminder

shepazu: planning to publish something from SVG 2 accessibility API
... so if you're interested in what's going on
... you should at least look at the spec
... or if you're more interested you should attend the telcon
... Friday 9am EST US

<ChrisL> 3pm France

shepazu: 2PM UCT
... everyone is welcome
... irc channel is #svg-a11y
... we are anticipating asking svg wg for approval to publish some time in February

<AmeliaBR> http://rawgit.com/w3c/aria/master/svg-aam/svg-aam.html

shepazu: this is a FPWD, not perfect, but please take a look - Amelia has already given good feedback

<AmeliaBR> Also, there is feedback/discussion on the mailing list https://lists.w3.org/Archives/Public/public-svg-a11y/

How to proceed on cleaning up chapters

ChrisL: I've looked at the first chapter - lots of easy issues to close
... should I just do it?
... or do I need to propose and get agreement

heycam: I'd like people to make changes - we can look at the commit messages
... want to limit process overhead

shepazu: agree

<ChrisL> cool, thanks

shepazu: what do people think of the idea of having a telcon where people talk about changes they've made recently
... here's what I did, what comments I received, rational, etc

heycam: I like that idea
... especially for things where we haven't discussed the issue previously
... would be good to give a heads up
... chairs could think about this maybe
... we'll keep a look out for commit emails
... and put items on the agenda

- DRAFT -

SVG Working Group Teleconference

22 Jan 2015

Attendees

Contents