Minutes, 22 January 2015 SVG WG telcon

Full minutes at
http://www.w3.org/2015/01/22-svg-minutes.html<http://www.w3.org/2015/01/15-svg-minutes.html>
and below as text


                    SVG Working Group Teleconference

22 Jan 2015

   [2]Agenda

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

   See also: [3]IRC log

      [3] http://www.w3.org/2015/01/22-svg-irc

Attendees

   Present
   Regrets
   Chair
          Cameron

   Scribe
          Nikos

Contents

     * [4]Topics
         1. [5]Linköping F2F date move request
         2. [6]Welcome Amelia
         3. [7]Neutering or dropping SVGSVGElement.forceRedraw
         4. [8]Defining or dropping SVGSVGElement.deselectAll
         5. [9]Doug's reminder
         6. [10]How to proceed on cleaning up chapters
     * [11]Summary of Action Items
     __________________________________________________________

   <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> [12]https://codereview.chromium.org/868603003/

     [12] 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>
   [13]https://codereview.chromium.org/868603003/patch/1/10004

     [13] 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:
   [14]https://github.com/search?l=javascript&q=suspendredraw&type
   =Code&utf8=%E2%9C%93

     [14] 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>
   [15]https://github.com/search?l=javascript&q=forceRedraw&type=C
   ode&utf8=%E2%9C%93

     [15] 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>
   [16]https://github.com/search?utf8=%E2%9C%93&q=suspendredraw+sv
   g&type=Code&ref=searchresults

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

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

     [17] 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

   +1

   <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>
   [18]https://www.w3.org/Guide/1998/08/teleconference-calendar#s_
   6329

     [18] 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>
   [19]https://svgwg.org/svg2-draft/text.html#__svg__SVGTextConten
   tElement__selectSubString

     [19] 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>
   [20]http://rawgit.com/w3c/aria/master/svg-aam/svg-aam.html

     [20] 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 [21]https://lists.w3.org/Archives/Public/public-svg-a11y/

     [21] 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

Summary of Action Items

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