<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 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> https://svgwg.org/svg2-draft/implnote.html#issue1

<ed> http://bryanbraun.github.io/after-dark-css/all/flying-toasters.html

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/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: http://www.w3.org/2015/06/10-svg-minutes.html
People with action items: cameron