See also: IRC log
<trackbot> Date: 22 January 2015
<scribe> scribe: Nikos
<scribe> scribenick: nikos
<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
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
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
+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> 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?
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
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/
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
This is scribe.perl Revision: 1.140 of Date: 2014-11-06 18:16:30 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/remove in SVG 2/remove in SVG 3/ Succeeded: s/ECT/UCT/ Found Scribe: Nikos Inferring ScribeNick: nikos Found ScribeNick: nikos WARNING: No "Present: ... " found! Possibly Present: AmeliaBR ChrisL ChrisLittle Doug_Schepers IPcaller MarkS P1 P10 P15 P17 P18 P2 P7 TabAtkins Tav Thomas_Smailus aaaa astearns birtles cabanier ed heycam https krit mihnea_____ nikos pdr__ plinss richardschwerdtfeger scribenick shane shepazu slightlyoff smailus stakagi trackbot You can indicate people for the Present list like this: <dbooth> Present: dbooth jonathan mary <dbooth> Present+ amy Agenda: https://lists.w3.org/Archives/Public/www-svg/2015Jan/0026.html Found Date: 22 Jan 2015 Guessing minutes URL: http://www.w3.org/2015/01/22-svg-minutes.html People with action items:[End of scribe.perl diagnostic output]