- From: Cameron McCormack <cam@mcc.id.au>
- Date: Thu, 11 Jun 2015 02:38:26 +1000
- To: www-svg@w3.org
http://www.w3.org/2015/06/10-svg-minutes.html
[1]W3C
[1] http://www.w3.org/
- DRAFT -
SVG Working Group Teleconference
10 Jun 2015
See also: [2]IRC log
[2] http://www.w3.org/2015/06/10-svg-irc
Attendees
Present
Jun, Satoru, Nikos, Cameron, Frederick, Erik, Tav, Dirk,
Rossen, Bogdan
Regrets
Chair
Cameron
Scribe
Cameron
Contents
* [3]Topics
1. [4]removing features without replacements
2. [5]path segment list DOM API
* [6]Summary of Action Items
__________________________________________________________
<trackbot> Date: 10 June 2015
Zakim: room for 4?
<scribe> ACTION: Cameron to make blue boxes have a separate
section for x/y/width/height presentation attributes on rect
etc. [recorded in
[7]http://www.w3.org/2015/06/10-svg-minutes.html#action01]
<trackbot> Created ACTION-3799 - Make blue boxes have a
separate section for x/y/width/height presentation attributes
on rect etc. [on Cameron McCormack - due 2015-06-17].
removing features without replacements
<scribe> ScribeNick: heycam
<scribe> Scribe: Cameron
AmeliaBR: I feel there was a desire to clear off and remove
undefined behaviour, but I'm not sure that getting rid of
things is a good outcome of that
... especially the getTransformToElement, it's something that
works most of the time
... and to remove it because there are some undefined edge
cases seems like a step backwards
... the other thing from yesterday that at first glanced looked
the same was external <use>
... I think from reading the notes that it's clear nobody wants
to remove this
... just clearly explain that there are some situations that
are undefined relating to them
... but we don't want to step backwards just to avoid undefined
behaviour
ed: for the <use> element, I don't think we concluded whether
we should add a new module or not
... there was some resistance unless we have someone to take
ownership of that and drive it forward
... so there's not really any place to put the definitions that
would be required to have external <use>, unless there's
someone to drive it
... I think the idea right now would be to try to figure out
the things that are undefined, and make them explicitly
undefined in the SVG 2 spec
AmeliaBR: I'll follow up this and send something in writing,
but are you comfortable with the idea of wording that more
precisely abotu which aspects are undefined?
... specifically say, script, style sheets and the size of the
viewport used are undefined
... which seems like a lot, but avoids the most common use case
of external use for a page full of symbols
... and a page full of symbols works just fine, in all browsers
except one
... and we don't want to make it seem like that's suddenly a
scary area that authors couldn't rely on
ed: yes, if you do avoid scripting and certain things, then yes
there are fewer things under/undefined
AmeliaBR: I'll follow up and send a written reply, trying to
narrow down exactly what currently is undefined, and I'll
follow up with something addressing it
ed: the spec does have some issues listed around the <use>
element, detailing some of the things that are not defined well
... so you could use that as a start
... some of those things have been resolved already
... and I hope those issues in the spec has links to the
resolutions
... not sure I've updated each one of them
AmeliaBR: that whole section is half issue text right now
path segment list DOM API
AmeliaBR: seems like people want to deal with these, and so
want to remove them
... it depends on what's happening with the more generic DOM
geometry spec
... is there a commitment to cleaning up DOM for SVG 2?
... or is it something that should be formally put aside
heycam: I think we did put aside the great DOM overhaul
... but there are still some issues that people wanted to
discuss
... like removing animVal or making it an alias for baseVal
AmeliaBR: it's the question of getting rid of something that
works some of the time, without having something that works all
of the time yet
... Web Animations should have some sort of replacement for
accessing animation data, but it's not stable and implemented
yet
ed: some parts are being implemented, at least in Blink
nikos: for me, looking at WebKit stuff, animVal is making
implementing Web Animations stuff a lot more difficult
... if we could get rid of it first, we could get Web
Animations going a lot quicker
... otherwise we might not bother
AmeliaBR: for that particular case, I'm not going to be too
much of a defender. there are a few use cases where it's nice,
but generally cases where you shouldn't be using SMIL animation
... if you need to find the animated value half way through you
should be using scripted
... I think I was a bit worried about the approach of using use
counters to get rid of features that don't necessarily have
easy alternative ways of getting them
... sounds like there is a strong push cleaning up some of the
basic DOM now, and if a future spec extends DOM then that'll be
something better and greater
heycam: at one point people were talking about removing more,
like rect.x, but I think that's a step too far currently
AmeliaBR: now that we've promoted these to properties, getting
a computed style value makes more sense than the SVG DOM
interface
heycam: and making animVal an alias to baseVal would avoid the
need to define how to reflect computed property values in
animVal
[some discussion about aliasing animVal to baseVal]
AmeliaBR: I know I've used demos that rely on animVal actually
doing the animated value, but I'm not sure how much practical
use case there is
... and already it's annoying, beacuse it only reflects SMIL
animation and not CSS animations
ed: what are the other options we have?
... dropping animVal completely. might be hard.
nikos: the problem with that is that animVal seems the natural
choice to read from over baseVal
... you think, might as well read from animVal, in case it's
animated
ed: ok. not objecting, just wondering what other options we
have.
AmeliaBR: what happened to the idea of getting new functions on
the SVGAnimatedLength? so that you could use units directly on
there.
heycam: that got removed
AmeliaBR: so it's a "we'll fix this in the future"
ed: the only possible objection I have is that it makes it
harder to remove baseVal
AmeliaBR: I had an intention of going through the spec and
adding issues as I go
... also was going to clean up the multiple fills/strokes
definitions, since they're not implementable
... I got good feedback from Tab/Dirk about why the spec is as
is
... I added a couple of points on the agenda -- one of which is
relating to DOM more useful, but if the decision was to not
fuss with the DOM maybe that won't happen
<BogdanBrinza>
[8]https://svgwg.org/svg2-draft/implnote.html#issue1
[8] https://svgwg.org/svg2-draft/implnote.html#issue1
<ed>
[9]http://bryanbraun.github.io/after-dark-css/all/flying-toaste
rs.html
[9] http://bryanbraun.github.io/after-dark-css/all/flying-toasters.html
Summary of Action Items
[NEW] ACTION: Cameron to make blue boxes have a separate
section for x/y/width/height presentation attributes on rect
etc. [recorded in
[10]http://www.w3.org/2015/06/10-svg-minutes.html#action01]
[End of minutes]
__________________________________________________________
Minutes formatted by David Booth's [11]scribe.perl version
1.140 ([12]CVS log)
$Date: 2015/06/10 16:36:59 $
__________________________________________________________
[11] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[12] http://dev.w3.org/cvsweb/2002/scribe/
Scribe.perl diagnostic output
[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.140 of Date: 2014-11-06 18:16:30
Check for newer version at [13]http://dev.w3.org/cvsweb/~checkout~/2002/
scribe/
[13] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/
Guessing input format: RRSAgent_Text_Format (score 1.00)
Succeeded: s/an g/and g/
Found ScribeNick: heycam
Found Scribe: Cameron
Default Present: svgwg, [IPcaller], AmeliaBR
Present: Jun Satoru Nikos Cameron Frederick Erik Tav Dirk Rossen Bogdan
Found Date: 10 Jun 2015
Guessing minutes URL: [14]http://www.w3.org/2015/06/10-svg-minutes.html
People with action items: cameron
[14] http://www.w3.org/2015/06/10-svg-minutes.html
[End of [15]scribe.perl diagnostic output]
[15] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
Received on Wednesday, 10 June 2015 16:38:55 UTC