21:01:06 <RRSAgent> RRSAgent has joined #svg
21:01:06 <RRSAgent> logging to http://www.w3.org/2013/01/17-svg-irc
21:01:08 <trackbot> RRSAgent, make logs public
21:01:08 <Zakim> Zakim has joined #svg
21:01:10 <trackbot> Zakim, this will be GA_SVGWG
21:01:10 <Zakim> ok, trackbot, I see GA_SVGWG(SVG1)4:00PM already started
21:01:11 <trackbot> Meeting: SVG Working Group Teleconference
21:01:11 <trackbot> Date: 17 January 2013
21:01:56 <birtles> Zakim, who is here?
21:01:56 <Zakim> On the phone I see [IPcaller], krit
21:01:58 <Zakim> On IRC I see RRSAgent, Cyril, birtles, Tav, richardschwerdtfeger, thorton, cabanier, krit, pdr, glenn, trackbot, stearns, nikos, ed, plinss, heycam
21:02:04 <birtles> Zakim, IPcaller is me
21:02:04 <Zakim> +birtles; got it
21:03:44 <Zakim> + +33.9.80.39.aaaa
21:03:51 <Cyril> zakim, aaaa is me
21:03:51 <Zakim> +Cyril; got it
21:03:57 <Zakim> +[IPcaller]
21:04:08 <ed> Zakim, [IP is me
21:04:08 <Zakim> +ed; got it
21:04:26 <Zakim> +[IPcaller]
21:04:29 <heycam> Zakim, [IPcaller] is me
21:04:29 <Zakim> +heycam; got it
21:04:42 <Zakim> +nikos
21:04:52 <Zakim> +Rich
21:05:01 <heycam> Zakim, who is on the call?
21:05:01 <Zakim> On the phone I see birtles, krit, Cyril, ed, heycam, nikos, Rich
21:05:19 <heycam> Chair: Cameron
21:05:22 <heycam> Agenda: http://lists.w3.org/Archives/Public/public-svg-wg/2013JanMar/0015.html
21:05:42 <Cyril> scribe: Cyril
21:05:46 <Cyril> scribeNick: Cyril
21:05:56 <Cyril> heycam: F2F is coming up
21:06:10 <Cyril> ... bring your agenda requests for the week
21:06:16 <birtles> http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Sydney_2013/Agenda_proposals
21:07:08 <richardschwerdtfeger> need to add an agenda item on applying aria attributes to attribute reference.
21:07:39 <Cyril> cyril: alex said there is no special rate with the hotel indicated on the wiki page
21:08:32 <Cyril> brian: have we decided which day will be half a day
21:08:48 <Cyril> heycam: I imagine we will be working in the morning and the afternoon is off
21:09:12 <Cyril> s/which day will be half a day/which half-day will be off/
21:09:19 <Cyril> Topic: Combining SVGLocatableElement and SVGTransformableElement in SVG 2
21:09:34 <Zakim> +cabanier
21:09:43 <heycam> https://docs.google.com/drawings/d/1DjmqGOk71JATh5ysZtnFe0Nxvox-g6mZ-M02jLA9aOc/edit?pli=1
21:09:56 <Zakim> +Tav
21:10:03 <Cyril> dirk: left side is SVG 1.1 inheritance tree and right one is SVG 2
21:10:37 <Cyril> ... the circle shows that SVG 2 has the locatable only has transformable as child
21:10:53 <Cyril> heycam: in SVG 1.1 the SVGElement was locatable but not transformable
21:11:06 <Cyril> ... we changed that in sVG 2 so that you could put transform on it
21:11:30 <Cyril> ... so there is no longer a concrete element that inherits just from locatable element
21:11:44 <Cyril> ... I'm fine with combining those 2
21:12:47 <Cyril> ... we have someone at mozilla converting SVG interfaces to WebIDL
21:13:12 <pdr> [not on call] for implementation reasons, the presentation editor uses paths for text
21:13:18 <Cyril> zakim, mute me
21:13:18 <Zakim> Cyril should now be muted
21:13:54 <Cyril> heycam: is there any concern in combining these 2 interfaces ?
21:14:01 <Cyril> cyril: what's the benefit ?
21:14:26 <Cyril> heycam: one less prototype object to go up when you look at properties
21:14:33 <Cyril> dirk: simplifies implementation also
21:14:50 <Cyril> ... you would combine them anyway in a implementation
21:15:03 <Cyril> ed: I agree it would be simpler
21:15:24 <Cyril> heycam: ok hearing no objection
21:15:39 <Cyril> resolution: SVG 2 will combine the SVGLocatable and SVGTransformable interfaces
21:16:03 <Cyril> Topic: Should SVGTextContentElement inherit from SVGGraphicsElement or SVGGeometryElement?
21:16:45 <Cyril> heycam: graphics is for things that render, in the normal rendering tree, that includes g, shapes and images ...
21:16:56 <Cyril> ... geometry is for elements that define a shape
21:17:37 <Cyril> ... we've added some DOM methods on SVG Geometry elements to determine if the click is inside the fill or the stroke
21:17:54 <Cyril> ... my thinking is that it make sense to call that on geometry elements, including text
21:18:03 <Cyril> ... to see if the click is in the glyph or not
21:18:31 <Cyril> dirk: the font rendering is out of the rendering system in WebKit, due to Core Graphics restriction
21:18:36 <Zakim> -ed
21:18:41 <Cyril> ... to emulate that that would make it very slow
21:19:36 <Zakim> +[IPcaller]
21:20:11 <Cyril> heycam: there is no other functionality in SVG that require to have access to the glyph ?
21:20:37 <Cyril> dirk: I would be unhappy to block the feature but some port of WebKit (Safari) would not support that
21:20:49 <Cyril> ... you don't get the details of the glyph
21:21:53 <Cyril> heycam: I'll be ok with having SVG Text elements inherit from SVG graphical elements
21:22:03 <Cyril> ed: how is it different from pointer events handling on text ?
21:22:14 <Cyril> dirk: this is not implemented that way on Safari
21:22:23 <Cyril> ... right now you just get the bounding box
21:22:47 <Cyril> heycam: right, the spec does not require you to get the acual shape of the glyph for pointer events
21:23:22 <Cyril> ed: that's right, it's only the character cell according to the spec
21:23:38 <Cyril> ... in that case, that's fine not to have those additional methods for text
21:23:53 <Cyril> dirk: I would be ok with having a note saying that they might apply on text in the future
21:24:04 <Cyril> ... we could also formulate it with a "should"
21:24:34 <Cyril> ... that would allow implementation that can't do it to do something different
21:24:59 <Cyril> heycam: it might make the methods not useful if you can't rely on them
21:25:14 <Cyril> ... I am ok with having them on shapes at the moment
21:25:53 <Cyril> zakim, unmute me
21:25:53 <Zakim> Cyril should no longer be muted
21:26:23 <Cyril> resolution: SVG text elements will inherit from graphical elements
21:26:43 <Cyril> ... and ispointonfill or ispointonstroke won't be called on text
21:26:58 <Cyril> Topic:  Should SVGClipPathElement inherit from SVGElement?
21:27:45 <Cyril> heycam: right now SVG clip path element inherits from SVGTransformable element to allow the transform attribute
21:28:17 <Cyril> ... the problem is that SVG Transformable Element inherits from SVG Locatable element
21:28:45 <Cyril> ... which allows methods like getScreenCTM on clipPath elements but that's not the case for gradients, ...
21:28:54 <Cyril> ... why is it the case for clipPaths ?
21:29:00 <Cyril> s/heycam:/dirk:/
21:29:17 <Cyril> heycam: my guess is that the clipPath transform attribute is just called transform
21:29:26 <Cyril> ... but mask isn't transformable
21:29:43 <Cyril> ... gradients have gradientTransform not the standard transform attribute
21:30:27 <Cyril> ... it's a bit to call getScreenCTM on the clipPAth because the transform on the parent of the clipPath don't matter
21:30:49 <Cyril> s/it's a bit/it's a bit weird/
21:31:05 <Cyril> ... does it make sense to call getBBox on the clipPath
21:31:13 <thorton> thorton has joined #svg
21:31:23 <Cyril> dirk: no it doesn't make sense
21:31:29 <Cyril> ed: yes it's a bit strange
21:31:48 <Cyril> ... on the one hand it's like a g (a container) but it's also linked to where it is used
21:31:58 <Cyril> heycam: what else is on SVGLocatable ?
21:31:58 <heycam> https://svgwg.org/svg2-draft/types.html#InterfaceSVGLocatableElement
21:32:14 <Cyril> ... Bounding box, CTM, transform
21:32:34 <Cyril> ... all these methods only make sense on elements that exist in their parent coordinate space
21:33:27 <Cyril> ... I would be alright with having clipPath elements inherit from SVGElement
21:34:08 <heycam> https://svgwg.org/svg2-draft/types.html#InterfaceSVGTransformableElement
21:34:21 <heycam> still need to have that one IDL attribute on SVGClipPathElement
21:34:29 <heycam> which gives DOM access to transform=""
21:34:48 <Cyril> ... we are keeping the ability to have the transform attribute on the clipPath element
21:35:30 <Cyril> ... we could just copy the transform attribute on the element that use it
21:37:01 <Cyril> ... is everybody happy not to have the locatable thing?
21:37:26 <Cyril> resolution: SVG 2 will make SVGClipPathElement inherit from SVGElement and give it its own IDL attribute to access the transform
21:37:52 <Cyril> Topic:  Percentage values for basic shapes on 'clip-path' relative to objectBoundingBox or strokeRect
21:38:04 <Cyril> heycam: are they relative to the object bounding box or the stroke rect
21:38:16 <krit> https://dvcs.w3.org/hg/FXTF/raw-file/tip/masking/index.html#the-clip-path
21:38:43 <Cyril> dirk: we have the new short-hand for clip paths
21:38:54 <Cyril> rect, circle, ellipse ...
21:39:01 <Cyril> but they take % values
21:39:19 <Cyril> ... do they get resolved according to the stroke or object
21:39:29 <Cyril> ... at the previous F2F we were not sure
21:39:38 <Cyril> ... we did not decide
21:39:56 <Cyril> heycam: currently Webkit is relative to the object bounding box
21:39:58 <Cyril> dirk: right
21:41:04 <Cyril> heycam: it would be a bit strange to have some new bounding box rectangles just for this clipPath property because we don't have it on other elements
21:41:12 <Cyril> ... maybe it would be useful on other elements
21:41:31 <Cyril> dirk: we could add a property in the future to indicate which bounding box you use
21:41:37 <Cyril> ... in the next level
21:41:55 <Cyril> heycam: when you don't use %, are they user space length
21:42:11 <Cyril> dirk: lenght of 0 is 0px which is different from 0% ?
21:42:39 <Cyril> heycam: I think this way is probably the way we should have done from the beginning
21:43:38 <krit> <rect x="20" y="20" widyh="200" height="200"/>
21:44:20 <Cyril> dirk: 0% 0% is resolved to 20px 20px
21:44:33 <Cyril> ... but 0 0 is resolved to 0px 0px
21:45:59 <Cyril> heycam: I'll be ok with deferring to the next level the control to which bounding box it's relative to
21:46:15 <Cyril> ed: yes that would make sense to have the control in CSS
21:46:41 <Cyril> dirk: CSS has something like that for boxes but they are not applicable to SVG (
21:47:18 <Cyril> heycam: but it's not the same property
21:47:34 <ed> I meant for e.g clipPathUnits, that we could have clipPathUnits="strokedBoundingBox"
21:47:51 <ed> and that there would be something reflected in CSS
21:48:02 <Cyril> heycam: I would say at this level it's objectBoundingBox because that's the only one we have in SVG
21:48:28 <Cyril> dirk: clipPathUnits can just be applied on the clipPath element, not on the property
21:48:41 <Cyril> heycam: disagreement ?
21:49:14 <Cyril> resolution: the shape in the clip-path property will have percentages resolved against the object bounding box
21:50:27 <heycam> background-clip
21:50:30 <Cyril> heycam: what is the default box used for percentages resolution in background-clip
21:50:44 <krit> https://dvcs.w3.org/hg/FXTF/raw-file/tip/masking/index.html#the-mask-clip
21:51:06 <heycam> https://developer.mozilla.org/en-US/docs/CSS/background-clip
21:51:06 <Cyril> dirk: the border box, which is the same as the layout box which is the same as the stroke
21:51:34 <Cyril> ... it should be the painting box but it's not yet define
21:51:54 <Cyril> dirk: the exclusion specification uses the border box
21:53:03 <Cyril> ... it might make sense to have the stroke box for compatibility reasons
21:53:25 <Zakim> -Cyril
21:54:06 <Zakim> +Cyril
21:55:19 <cabanier> * I think it's just you :-) *
21:55:45 <Cyril> tav: it is possible to have the masking behavior changed
21:57:05 <krit> krit: We could modify the UA style sheet to use content-box on SVG
21:57:15 <Cyril> tav: that would make sense to me
21:57:19 <krit> krit: Then the default value on mask-clip does not need to change
21:57:40 <Cyril> heycam: that would still lead to some inconsistentcies
21:59:31 <Cyril> dirk: what do you think is less inconsistent
21:59:44 <Zakim> -Tav
21:59:52 <Cyril> heycam: maybe to have clippath default to including the stroke
22:00:27 <Cyril> ... we could add a new value in the units attribute
22:00:35 <Zakim> +Tav
22:02:03 <heycam> I am happy with clip-path defaulting to stroke bounding box if we add strokeBoundingBox or similar values to maskContentUnits="", gradientUnits="" etc.
22:02:16 <Zakim> -birtles
22:02:21 <heycam> so that there is not a new bounding box that clip-path uses that all our other definition elements can't use.
22:02:33 <heycam> Then clip-path's default matches the default of mask-clip, background-clip, etc.
22:03:21 <Cyril> tav: it's strange in SVG that the clipPath changes if you change the stroke width
22:03:33 <Cyril> ... changing the style shouldn't change what's being clipped
22:04:16 <Cyril> dirk: I think I agree with tav
22:04:44 <Cyril> heycam: yes, changing any style does not change now the clipping, but it could be useful, if it's not the default
22:05:12 <Cyril> tav: useful, but that's not what I would naturally expect
22:05:46 <Cyril> heycam: any concern with the consistency of other property
22:05:57 <Cyril> tav: I have to think about it
22:06:31 <Cyril> heycam: I'm not that unhappy to have it be objectBoundingBox
22:06:45 <Cyril> ... I think it's probably ok
22:07:02 <Cyril> ... dirk, you have it implemented, did you try with some content
22:07:57 <Cyril> tav: how would you handle different kinds of line join
22:08:19 <Cyril> dirk: we rely on the graphics library to get the bounding box
22:08:25 <Cyril> ... this is not done by WebKit
22:08:48 <Cyril> ed: objectBoundingBox is not affected by the line join right?
22:08:57 <Cyril> dirk: no, strokeBoundingBox is
22:09:11 <Cyril> heycam: yes, maybe strokeBoundingBox needs more thoughts
22:11:32 <Cyril> Topic:  Review request of CSS Masking spec before going to LC
22:11:48 <Cyril> dirk: I asked the same request in the CSS WG
22:11:57 <Cyril> ... it would be great to have review early
22:12:24 <Cyril> ... the review I had from CSS was that the spec should rely on the background spec as much as possible
22:12:33 <Cyril> ... I will rewrite the spec
22:12:51 <Cyril> ... and get feedback from the group, for instance during the F2F
22:13:02 <Cyril> heycam: when do you want to get it to LC
22:13:10 <Cyril> dirk: when the review is finished
22:13:36 <Cyril> Topic: text-shadow on <text>, <tspan>, <tref>, etc.
22:14:01 <Cyril> heycam: dirk said text-shadow should apply to text
22:14:05 <shepazu> shepazu has joined #svg
22:14:16 <Cyril> dirk: I think text-decoration should apply to text
22:14:34 <krit> http://www.w3.org/TR/css-text-decor-3/
22:14:40 <Cyril> tav: SVG has different colors
22:14:44 <heycam> http://dev.w3.org/csswg/css-text-decor-3/
22:14:48 <Cyril> ... how does that this apply
22:15:16 <Cyril> tav: I agree it's better to have unification
22:15:46 <Cyril> ... I don't know if there is a problem with text-decoration
22:16:04 <Cyril> heycam: I think we should have the same rules as HTML elements
22:16:19 <Tav> http://www.w3.org/Graphics/SVG/Test/20110816/svg/text-deco-01-b.svg
22:16:51 <Cyril> dirk: we already use these properties
22:16:59 <Cyril> ... it's really a matter of normative reference
22:17:06 <Cyril> tav: and it handles the variation of colors
22:17:21 <Cyril> dirk: we already have stroke and fill on HTML text
22:18:30 <Cyril> tav: text-shadow does it apply to text-decoration ?
22:18:41 <Cyril> dirk: good question, CSS WG is still discussing it
22:18:49 <Cyril> ed: not very well defined yet
22:20:19 <ed> s/ not very well defined yet/how text-decorations affect the boundingbox is not defined yet/
22:20:20 <Cyril> tav: I would expect that the shadow apply on the decoration
22:20:39 <Cyril> heycam: I like the idea of text-shadow applying to SVG text in general
22:22:26 <Cyril> resolution: in SVG 2, text-shadow will apply to svg text
22:23:13 <Cyril> Topic:  getStrokeBBox behaviour and naming
22:23:20 <heycam> http://lists.w3.org/Archives/Public/www-svg/2013Jan/0057.html
22:23:48 <Cyril> heycam: we have getStrokeBBox in the DOM, the definition is slightly off in the text
22:24:12 <Cyril> ... it include the stroke in the marker but not the fill which is a bit strange
22:24:32 <Cyril> ... but the real issue is the name 'stroke' if it includes the marker as well
22:25:17 <heycam> getBBox({ fill: true, stroke: false, markers: true })
22:25:19 <Cyril> ... the dictionnary BBoxOption means that you can pass an object
22:26:25 <Cyril> dirk: if you put two values to true, then you would get the union of both
22:26:28 <Cyril> heycam: yess
22:28:20 <Cyril> dirk explaining an example of the strokebbox being smaller than the fillbox
22:28:50 <Cyril> with the use of dashes not present at corners
22:28:59 <Cyril> tav: dashes should not matter for the bbox
22:30:11 <Cyril> dirk: I think the style doesn't matter on the stroke box
22:36:17 <Cyril> tav: what's useful is having the 3 options and having them additive
22:36:35 <Cyril> heycam: perhaps three different methods
22:36:53 <Zakim> -nikos
22:36:54 <Zakim> -[IPcaller]
22:37:00 <Zakim> -krit
22:37:04 <Zakim> -Tav
22:37:10 <Cyril> rrsagent, generate minutes
22:37:10 <RRSAgent> I have made the request to generate http://www.w3.org/2013/01/17-svg-minutes.html Cyril
22:37:12 <Zakim> -cabanier
22:37:29 <Cyril> rrsagent, make minutes public
22:37:29 <RRSAgent> I'm logging. I don't understand 'make minutes public', Cyril.  Try /msg RRSAgent help
22:37:49 <Zakim> -Cyril
22:42:42 <Zakim> -Rich
22:42:44 <Zakim> -heycam
22:42:44 <Zakim> GA_SVGWG(SVG1)4:00PM has ended
22:42:44 <Zakim> Attendees were krit, birtles, +33.9.80.39.aaaa, Cyril, ed, heycam, nikos, Rich, cabanier, Tav, [IPcaller]
22:44:07 <thorton_> thorton_ has joined #svg
23:18:49 <birtles> birtles has joined #svg
23:57:15 <cabanier> cabanier has joined #svg