20:29:22 <RRSAgent> RRSAgent has joined #svg
20:29:22 <RRSAgent> logging to http://www.w3.org/2013/07/11-svg-irc
20:29:24 <trackbot> RRSAgent, make logs public
20:29:24 <Zakim> Zakim has joined #svg
20:29:26 <trackbot> Zakim, this will be GA_SVGWG
20:29:26 <Zakim> ok, trackbot; I see GA_SVGWG(SVG1)4:30PM scheduled to start in 1 minute
20:29:27 <trackbot> Meeting: SVG Working Group Teleconference
20:29:27 <trackbot> Date: 11 July 2013
20:30:24 <krit> krit has joined #svg
20:30:31 <Zakim> GA_SVGWG(SVG1)4:30PM has now started
20:30:39 <Zakim> + +2aaaa
20:30:47 <Zakim> +[IPcaller]
20:30:49 <heycam> Zakim, [ is me
20:30:49 <Zakim> +heycam; got it
20:31:14 <Zakim> + +33.9.80.39.aabb
20:31:20 <krit> zakim, who is on the call?
20:31:20 <Zakim> On the phone I see +2aaaa, heycam, +33.9.80.39.aabb
20:31:28 <Cyril> Zakim, aabb is me
20:31:28 <Zakim> +Cyril; got it
20:31:31 <Zakim> +Rich_Schwerdtfeger
20:31:44 <krit> zakim, 2aaaa is me
20:31:44 <Zakim> sorry, krit, I do not recognize a party named '2aaaa'
20:32:00 <krit> zakim, aaaa is me
20:32:00 <Zakim> +krit; got it
20:32:14 <Zakim> +??P10
20:32:32 <ed> Zakim, ??P10 is me
20:32:32 <Zakim> +ed; got it
20:32:44 <ed> Agenda: http://lists.w3.org/Archives/Public/public-svg-wg/2013JulSep/0002.html
20:32:50 <Zakim> + +33.9.53.77.aacc
20:33:16 <Tav> zakim, aacc is me
20:33:16 <Zakim> +Tav; got it
20:33:28 <heycam> Zakim, who is making noise?
20:33:35 <Cyril> zakim, mute me
20:33:35 <Zakim> Cyril should now be muted
20:33:39 <Zakim> heycam, listening for 10 seconds I heard sound from the following: krit (4%), Cyril (4%), Rich_Schwerdtfeger (31%), ed (90%)
20:34:36 <ed> Zakim, who's here?
20:34:36 <Zakim> On the phone I see krit, heycam, Cyril (muted), Rich_Schwerdtfeger, ed, Tav
20:34:38 <Zakim> On IRC I see krit, Zakim, RRSAgent, richardschwerdtfeger, plh, thorton, Cyril, cabanier, Tav, stearns, glenn, trackbot, nikos, TabAtkins, pdr, jaseg, ed, plinss, heycam
20:35:17 <ed> chair: ed
20:35:20 <krit> zakim, pick a scribe
20:35:20 <Zakim> Not knowing who is chairing or who scribed recently, I propose krit
20:35:24 <krit> argh
20:35:35 <krit> ScribeNick krit
20:35:48 <heycam> ScribeNick: krit
20:35:58 <Zakim> +cabanier
20:36:47 <krit> topic: SVGDOM text takes textLength=0 into account?
20:36:48 <heycam> http://lists.w3.org/Archives/Public/www-svg/2013Jul/0003.html
20:36:51 <heycam> s/0//
20:37:19 <krit> heycam: text chaper doesn't say how they affect the SVGDOM
20:37:44 <nikos>  /me had a blank. what's the passcode?
20:38:05 <krit> heycam: explains mail of link
20:38:45 <Zakim> + +61.2.980.5.aadd
20:38:54 <krit> ed: for text computed length, not sure. you give textlength by setting text length
20:38:57 <nikos> Zakim, +61.2 is me
20:38:57 <Zakim> +nikos; got it
20:39:04 <krit> ed: not sure, but we should not return that value
20:39:13 <krit> ed: you want computed thing
20:39:27 <krit> heycam: should we have different values for text substring length?
20:39:40 <krit> ed: hm
20:39:58 <krit> ed: substringlength, how does it work?
20:40:03 <krit> ed: look
20:40:33 <krit> ed: same as textcomuputelength but not all the length
20:40:52 <krit> heycam: yes, should work on scaled glyoh?
20:41:06 <krit> s/glyoh/glpoh/
20:41:21 <krit> s/glyoh/glyph/
20:41:42 <krit> heycam: tesxt comp length the only one that differs
20:42:18 <krit> ed: should we have two dfferent methods?
20:42:20 <krit> heycam: maybe?
20:42:39 <krit> ed: haven;t used substringlength, so don't konw
20:42:51 <krit> s/substringlength/substringlength that much/
20:42:57 <krit> heycam: have no strong feeling
20:43:22 <krit> ed: what do UAs do?
20:43:27 <krit> heycam: doing it right now
20:43:46 <krit> heycam: FF substrlength works on original length
20:43:55 <krit> heycam: seems unclear
20:44:11 <krit> heycam: chrome also returns original unscaled length of substring
20:44:42 <heycam> http://mcc.id.au/temp/tl.svg
20:45:30 <krit> krit: Safari 22
20:45:36 <krit> krit: IE10 99.999
20:45:42 <krit> heycam: well then...
20:46:16 <krit> krit: presto has 22 as well
20:47:04 <krit> heycam: Batik 100.5
20:47:22 <krit> heycam: think prefer unscaled
20:47:25 <krit> ed: yeah
20:48:18 <krit> krit: do you get the 100 somehow else?
20:48:24 <krit> heycam: is the value of textLength
20:48:32 <krit> krit: then I am in favor for 22
20:49:31 <krit> RESOLUTION: getSubstringLength does not take other text metrics into account and returns unscaled text length
20:50:20 <krit> ACTION: heycam will make getSubstringLength not take other text metrics into account and returns unscaled text length in spec
20:50:20 <trackbot> Created ACTION-3510 - Will make getSubstringLength not take other text metrics into account and returns unscaled text length in spec [on Cameron McCormack - due 2013-07-18].
20:50:37 <krit> topic: should textLength=0 disable rendering
20:50:43 <krit> heycam: yes
20:51:15 <krit> heycam: spec does not explicitly say what happens for textlengh=0. stop rendering? ignore attribute?
20:51:43 <krit> heycam: 2 options 1) disable rendering 2) normal text length
20:52:00 <krit> heycam: or third one: not disable rendering but really scale to one dimension
20:52:27 <krit> krit: do we also scale stroke?
20:52:44 <krit> heycam: think spec is not clear but would expect stroke not scale
20:52:53 <krit> krit: have an example?
20:53:00 <krit> heycam: not right now, but can make one
20:53:14 <krit> Tav: discussion is silly
20:53:42 <krit> Tav: it is meant to be for small changes on text length, not for extreme values, just for small corrections
20:53:50 <krit> heycam: think you are right
20:54:00 <krit> krit: we could still specify edge cas
20:54:02 <krit> e
20:54:21 <heycam> http://mcc.id.au/temp/tl2.svg
20:54:21 <ed> http://jsfiddle.net/95QSD/
20:55:34 <heycam> heycam has left #svg
20:55:37 <heycam> heycam has joined #svg
20:55:46 <krit> krit: examples show that stroke is not scaled
20:56:49 <krit> heycam: Tavwould be in favor to scale down to 1D
20:56:54 <heycam> s/Tav/Tab /
20:56:54 <krit> heycam: think I agree
20:57:17 <krit> Tav: agree as well
20:57:42 <krit> RESOLUTION: Scale text to 1 dimension on textLength=0
20:58:06 <krit> ACTION: heycam modify spec to Scale text to 1 dimension on textLength=0
20:58:06 <trackbot> Created ACTION-3511 - Modify spec to Scale text to 1 dimension on textLength=0 [on Cameron McCormack - due 2013-07-18].
20:58:47 <krit> topic: behavior lengthAdjust=spacing wehn glyphs are wider as specified text length
20:59:24 <krit> heycam: odd behavior when engthAdjust=spacing when text length less than widest glyph
20:59:49 <krit> heycam: in FF 10 we ended up positioning other glyphs to first one
20:59:59 <krit> heycam: think Chrome did it as well
21:00:06 <krit> heycam: it ends up shifting glyphs
21:00:15 <krit> heycam: but don't think it is useful behavior
21:01:07 <krit> heycam: ddaly suggested setting text length to width of widest glyph
21:01:13 <krit> ed: seems reasonable
21:01:25 <krit> heycam: all glyohs would be aligned right
21:01:38 <krit> heycam: like glyphs getting closer and closer
21:02:47 <krit> RESOLUTION: minumum textLength is the width of wides glyph whenlengthAdjust=spacing
21:02:57 <krit> s/whenlengthAdjust=spacing/when lengthAdjust=spacing/
21:03:22 <krit> ACTION: heycam to change spec to set minumum textLength to width of wides glyph whenlengthAdjust=spacing
21:03:22 <trackbot> Created ACTION-3512 - Change spec to set minumum textLength to width of wides glyph whenlengthAdjust=spacing [on Cameron McCormack - due 2013-07-18].
21:03:53 <krit> topic: thoughts on lengthAdjust modes
21:04:08 <krit> heycam: have 2
21:04:32 <heycam> http://lists.w3.org/Archives/Public/www-svg/2013Jul/0012.html
21:04:41 <krit> heycam: first scale text in both dimension instead just horizontal
21:05:22 <krit> heycam: it often might be preferable glyphs looking ok when scaled
21:05:31 <krit> Tav: not sure if that is the case
21:05:41 <richardschwerdtfeger> I need to answer a call. I will stay on IRC
21:05:50 <Zakim> -Rich_Schwerdtfeger
21:06:02 <krit> Tav: specially on buttons when you have different text length and the font size looks different then
21:06:10 <krit> heycam: you are right
21:06:31 <krit> ed: maybe we should specify a box and let text fit the box? might not help as well
21:06:45 <krit> heycam: sounds complicated
21:06:58 <krit> Tav: think this is a 5% max change
21:07:04 <krit> Tav: mainly dependent on font
21:07:17 <krit> Tav: don't see a need to change the height at all
21:07:37 <krit> heycam: you can get quite diffeent length from the same text but different length
21:07:48 <krit> Tav: you hope that the author has a good fallback
21:07:57 <heycam> http://mcc.id.au/2013/textLength.svg
21:07:58 <krit> Tav: you can find fonts that are quite different
21:08:55 <krit> Tav: at Chrome, right one looks fine
21:09:00 <krit> heycam: doesn't look bad
21:09:11 <krit> Tav: you just have an extreme example
21:09:14 <krit> heycam: ok
21:10:04 <krit> heycam: 2nd one was making textlength adjustment only to do when scaling down but not up
21:10:50 <krit> ed: sounds like a min max think
21:10:58 <krit> s/think/thing/
21:11:08 <krit> Tav: don't make it to complicated!!!
21:11:12 <krit> heycam: ok
21:11:36 <krit> s/to/too/
21:12:30 <krit> TOPIC: continuing (or not) to mint new integer constants for existing IDL attributes
21:12:32 <heycam> http://lists.w3.org/Archives/Public/www-svg/2013Jul/0019.html
21:12:47 <krit> heycam: discussed it on transforms
21:13:07 <krit> heycam: when ever we have new enumeration values, we wouldn't introduce new numeric constance
21:13:19 <krit> heycam: since that is a bit of an antipattern in he web
21:13:45 <krit> heycam: we decided to not introdcue new constant number and return unknown value for new types
21:13:57 <krit> heycam: and give an easier way to access to them
21:14:07 <krit> heycam: new marker orient value has the same
21:14:28 <krit> heycam: third would be unkonw instead of an constant value
21:14:39 <krit> heycam: seems awkward
21:15:41 <krit> heycam: Tab doesn't want new constants because this seems bad. not having it would authors force not to use it anymore
21:16:40 <krit> ed: are there alternatives?
21:17:29 <heycam>   readonly attribute SVGAnimatedEnumeration orientType;
21:17:30 <heycam>   readonly attribute SVGAnimatedAngle orientAngle;
21:17:55 <heycam>            attribute DOMString orient;
21:18:10 <krit> heycam: describes new attributes
21:18:28 <krit> heycam: that is the easier way to  get the types
21:18:40 <krit> heycam: I forgot that we already have an alternative
21:18:59 <krit> krit: means we don't want new constants?
21:19:16 <krit> heycam: yeah, just was thinking the other day that it might not be that bad to add
21:19:31 <krit> heycam: since there is oposition, we stay that course
21:20:03 <krit> ed: fine with me
21:20:23 <Cyril> q+
21:20:34 <krit> topic: filterRes attribute on <filter> element
21:20:57 <heycam> ScribeNick: heycam
21:21:14 <heycam> krit: filterRes can be specified by the author to reduce or increase resolution that the filter is operating in
21:21:30 <heycam> krit: usually it's done to reduce the resolution so it operates faster
21:21:34 <heycam> … I've never seen a real life use case
21:21:46 <heycam> … it's unlikely the author can predict the right resolution for a particular device, and for this to be future proof
21:21:52 <heycam> … the question is whether this does more harm than good
21:21:57 <heycam> … and whether we should remove it from the spec
21:22:10 <heycam> … from the implementation PoV, Opera/Blink/WebKit implement it correctly, Firefox not that much
21:22:23 <heycam> s/Opera/Presto/
21:22:33 <heycam> ed: I think I've only seen it used properly for making things faster
21:22:40 <heycam> … typically that looks pretty bad
21:22:47 <heycam> … as you say, it's hard to predict the resolution of the target device
21:22:56 <heycam> krit: all devices have different resolutions
21:23:07 <heycam> … the way to calculate the filter changes over time, from software to hardware, so it make not make sense at all to do it
21:23:14 <heycam> … it could block some implementations
21:23:33 <heycam> ed: so you're suggesting to deprecate or remove it?
21:23:47 <heycam> krit: I'm more in favour of removing it directly, but would understand if people want to deprecate first
21:24:15 <heycam> …roc suggests to remove it immediately
21:24:23 <Zakim> -Tav
21:24:37 <heycam> heycam: agree, if we think it's a bad thing, remove it straight away, not say we're going to remove it
21:24:50 <heycam> ed: which things does it affect? feColorMatrix?
21:24:56 <heycam> krit: feDisplacementMap maybe
21:24:58 <heycam> … and blur
21:24:58 <Zakim> +Tav
21:25:19 <heycam> … every filter primitive is affected by filter resolution, really
21:25:24 <heycam> ed: I was thinking of kernelUnitLength
21:25:46 <Cyril> zakim, unmute me
21:25:46 <Zakim> Cyril should no longer be muted
21:26:33 <heycam> krit: we could remove it from Filters, but have a note pointing to 1.1 and say that we removed it for this and this reason
21:26:40 <heycam> ed: wouldn't have a big impact on content, so would be fine to remove
21:26:45 <heycam> krit: with or without a note?
21:26:48 <heycam> Tav: I think you should put a note in
21:27:03 <heycam> heycam: sounds fine to me as well
21:27:34 <heycam> RESOLUTION: Remove filterRes from Filters spec, with a note pointing out why it was removed.
21:27:48 <heycam> ACTION: Dirk to remove filterRes.
21:27:48 <trackbot> Created ACTION-3513 - Remove filterRes. [on Dirk Schulze - due 2013-07-18].
21:28:15 <heycam> Topic: removing xmlns from the spec
21:28:25 <heycam> Cyril: I had an action to remove the xmlns prefix
21:28:37 <heycam> … it wasn't so obvious. please let at my email.
21:28:56 <krit> krit: ScribeNick
21:29:00 <Cyril> http://lists.w3.org/Archives/Public/www-svg/2013Jul/0023.html
21:29:07 <ed> ScribeNick: krit
21:29:25 <krit> Cyril: we have 3 attributes taking the xlink prefix
21:29:37 <krit> Cyril: one is deprected anyway
21:29:43 <krit> Cyril: for xml:base
21:29:57 <krit> Cyril: there is an issue in the draft talking about the base element in HTML
21:30:23 <krit> Cyril: in HTML it allows it in the HMTL namespace but just for XML element, for all others, the base attribute is used
21:30:38 <krit> Cyril: either we keep xml:base, do it HTML5 way
21:31:14 <krit> Cyril: or keep it in no ns
21:31:23 <krit> Cyril: see email for details
21:31:23 <Zakim> -Cyril
21:32:16 <Cyril> "conference is restricted at this time"
21:32:42 <Cyril> I'll continue on IRC
21:32:50 <Cyril> what do people think?
21:32:58 <Cyril> how should we clean the xml:base thing ?
21:32:59 <heycam> I think xml:base="" is not useful
21:33:07 <heycam> I don't think we should add a base=""
21:33:14 <heycam> if anything, add <base> like HTML
21:33:24 <Cyril> should we go the HTML way: keep xml:base and add base ?
21:33:25 <heycam> but even then I would avoid it unless people think it's useful :)
21:33:51 <Cyril> so you would prefer just having the <base> element?
21:34:01 <heycam> so there is a difference
21:34:05 <heycam> <base> applies to the entire document
21:34:11 <heycam> xml:base="" applies only to the subtree that it is on
21:34:21 <Cyril> yes, there can be only one <base> element
21:34:39 <heycam> I would be surprised if people are using xml:base="", to be honest
21:35:10 <Cyril> should we aks the HTML WG if they will keep it ?
21:35:19 <heycam> well
21:35:28 <heycam> I think maybe keeping xml:base="" behaviour, in XML documents, is needed
21:35:32 <heycam> since it's something the XML spec describse
21:35:49 <Cyril> so we would go for option d) in my email then?
21:36:08 <heycam> what about open e)
21:36:14 <heycam> *option
21:36:17 <heycam> leave xml:base=""
21:36:20 <heycam> don't introduce <base> :)
21:36:33 <heycam> forsake SVG-in-HTML users
21:37:03 <Cyril> ok
21:37:10 <krit> RRSAgent: make minutes
21:37:10 <RRSAgent> I have made the request to generate http://www.w3.org/2013/07/11-svg-minutes.html krit
21:37:26 <Cyril> can people also have a look at my other action: the use of Media Fragment identifiers ?
21:37:33 <Zakim> -ed
21:37:34 <Cyril> I've put it in the spec
21:37:34 <Zakim> -heycam
21:37:37 <Zakim> -Tav
21:37:38 <Zakim> -nikos
21:37:38 <Zakim> -cabanier
21:37:41 <Zakim> -krit
21:37:42 <Zakim> GA_SVGWG(SVG1)4:30PM has ended
21:37:42 <Zakim> Attendees were +2aaaa, [IPcaller], heycam, +33.9.80.39.aabb, Cyril, Rich_Schwerdtfeger, krit, ed, +33.9.53.77.aacc, Tav, cabanier, +61.2.980.5.aadd, nikos
22:12:49 <nikos1> nikos1 has joined #svg
22:53:19 <krit> heycam|away: so I learned that gecko can not blink: https://twitter.com/girlie_mac/status/355457936685932544/photo/1