20:29:29 <RRSAgent> RRSAgent has joined #svg
20:29:29 <RRSAgent> logging to http://www.w3.org/2014/02/13-svg-irc
20:29:30 <heycam> trackbot, start telcon
20:29:31 <trackbot> RRSAgent, make logs public
20:29:31 <Zakim> Zakim has joined #svg
20:29:33 <trackbot> Zakim, this will be GA_SVGWG
20:29:33 <Zakim> ok, trackbot, I see GA_SVGWG(SVG1)3:30PM already started
20:29:34 <trackbot> Meeting: SVG Working Group Teleconference
20:29:34 <trackbot> Date: 13 February 2014
20:29:36 <trackbot> RRSAgent, make logs public
20:29:38 <trackbot> Zakim, this will be GA_SVGWG
20:29:38 <Zakim> ok, trackbot, I see GA_SVGWG(SVG1)3:30PM already started
20:29:39 <trackbot> Meeting: SVG Working Group Teleconference
20:29:39 <trackbot> Date: 13 February 2014
20:30:42 <Zakim> +[IPcaller]
20:30:45 <nikos> nikos has joined #svg
20:30:47 <Zakim> +??P1
20:30:51 <Zakim> +[IPcaller.a]
20:30:54 <Zakim> +Doug_Schepers
20:30:56 <Zakim> -Doug_Schepers
20:31:05 <birtles> Zakim, [IPcaller] is me
20:31:05 <Zakim> +birtles; got it
20:31:07 <ed> Zakim, [IP is me
20:31:07 <Zakim> +ed; got it
20:31:17 <stakagi> zakim, ??P1 is me
20:31:17 <Zakim> +stakagi; got it
20:31:19 <Zakim> +[IPcaller]
20:31:20 <heycam> Zakim, [ is me
20:31:20 <Zakim> +heycam; got it
20:31:30 <ed> Agenda: http://lists.w3.org/Archives/Public/www-svg/2014Feb/0032.html
20:31:35 <Zakim> +??P6
20:31:41 <nikos> Zakim, ?P6 is me
20:31:41 <Zakim> sorry, nikos, I do not recognize a party named '?P6'
20:31:52 <Zakim> +Doug_Schepers
20:31:56 <nikos> Zakim, ??P6 is me
20:31:56 <Zakim> +nikos; got it
20:32:31 <heycam> Scribe: Cameron
20:32:33 <heycam> ScribeNick: heycam
20:32:53 <heycam> Topic: ISSUE-2454: What should the bbox of a path without a d attribute be?
20:33:07 <heycam> shepazu: should it be a point? (0,0,0,0)?
20:33:10 <heycam> ed: I guess that is the question
20:33:11 <ed> https://www.w3.org/Graphics/SVG/WG/track/issues/2454
20:33:23 <heycam> ... if you load up the issue, I've copy/pasted in the results from a couple different browsers
20:33:26 <heycam> ... it's slightly consistent
20:33:37 <Zakim> +krit
20:33:46 <heycam> ... both with regards to what bbox empty shapes have, and how it affects getBoundingClientRects
20:33:58 <heycam> ... I would like this to be defined such that all of the implementations can align on one of them
20:34:06 <heycam> ... I don't think there's any single implementation that is exactly the same at this stage
20:34:10 <Zakim> +Tav
20:34:20 <heycam> shepazu: did you also test rectangles with width/height of 0?
20:34:21 <heycam> ed: yes
20:34:36 <heycam> ... so the test case that's linked from the issue is testing path elements, all the basic shapes
20:34:44 <heycam> ... <line> twice, as one is a diagonal and one is in one direction
20:34:50 <heycam> ... both result in slightly different results
20:35:02 <heycam> shepazu: you might want to add vertical/horizontal in there
20:35:15 <heycam> ... they might have different results
20:35:20 <heycam> ed: would be surprised if they did, but yeah
20:35:30 <heycam> shepazu: I encountered some different behaviour when testing in the past
20:35:39 <heycam> ed: the spec says return (0,0,0,0) for bboxes of such empty elements
20:35:54 <heycam> ... the followup question then is do they contribute to parent bbox
20:36:20 <heycam> Smailus: what should the bbox be when all four corners are the same point?
20:36:34 <heycam> ed: the question is do you take those into account?
20:36:45 <heycam> Smailus: in the CGM spec a circle with radius zero is treated as a point
20:36:49 <heycam> shepazu: my intuition is similar to that
20:36:53 <heycam> ... I think it should contribute
20:37:02 <heycam> ... we might have animated content, where a circle is growing and shrinking
20:37:09 <heycam> ... but it's still somehow there when the radius is 0
20:37:15 <heycam> ... so I think it should contribute to the larger bbox
20:37:21 <heycam> ... it'd be inconsistent otherwise
20:37:29 <ed> <g><path/><path d="M10,10h100v100h-100z"/></g>
20:37:34 <heycam> ... I think shapes that don't have any dimension should contribute to the parent's bbox
20:37:39 <heycam> ed: what's the position of the point in this?
20:37:49 <heycam> ... the first path has no d="" attribute, so there's no natural position
20:38:01 <heycam> Tav: I think that's a different case
20:38:59 <heycam> heycam: there's a consistency issue, if you call getBBox on the d-less attribute, that needs to return something like (0,0,0,0), but should that contribute to the parent?
20:39:47 <heycam> shepazu: I think paths/polygoins with d/points should behave consistently with shapes with no width/height
20:40:11 <heycam> ... there are shapes with a position but no dimension, rect/ellipse/circle/(star in the future)
20:40:23 <heycam> ... and ones that have neither position nor dimension, path/polygon/polyline without d/points
20:40:34 <heycam> Tav: I'd say a path without a d shouldn't be included, but if it has a moveto without anything else then it would be included
20:40:48 <heycam> shepazu: that seems more complex
20:41:05 <heycam> heycam: I guess that's the difference
20:41:16 <heycam> ... whether the path really has a "default position" like rect when you leave off x/y
20:41:25 <heycam> Smailus: if there's no default position, then I think we'd want to require that something is defined for the path
20:41:53 <heycam> shepazu: if I have a rect and I just set x="", no other attributes, that is effectively a point at (10, 0); so it does have a default
20:42:06 <heycam> ... if I take away that x="", and just have <rect/> with no attributes, it's a point at (0,0)
20:42:18 <heycam> ... and if I added width/height, it would have a width/height and the rect starts at (0,0)
20:42:35 <heycam> ... so I think for consistency, path/polygon/polyline should work the same way
20:42:51 <heycam> Tav: I feel like <path> without a d="" is more like a malformed element
20:43:02 <heycam> ... what's the default value of d="" if you don't specify it?
20:43:06 <heycam> shepazu: a path at 0,0
20:43:33 <heycam> Tav: if you're talking about animating a <rect> that goes down to zero ...
20:43:47 <heycam> ed: markers/linecaps would get rendered on the default (0,0) path?
20:44:08 <heycam> shepazu: if you put width/height 0 then it doesn't render, explicitly
20:44:15 <heycam> ... same with circle with 0 radius
20:44:38 <heycam> nikos: I remember we discussed this at a previous telcon
20:45:06 <heycam> shepazu: I just don't see why we should have a class of elements that under certain circumstances contribute to the parent bbox but in others don't
20:45:24 <heycam> ... if I encountered that behaviour, I'd find that confusing
20:46:06 <heycam> nikos: what if we take away the restriction that you need to start the path with a M, then you could say there's an implicit M0,0
20:46:10 <heycam> shepazu: I don't think you need to go that far
20:46:57 <heycam> nikos: mesh gradients for example don't require a moveto
20:47:23 <heycam> shepazu: ok, so then there would be a consistent behaviour
20:47:36 <heycam> Smailus: sounds like for path it inherits its position from its ancestor/parent?
20:47:58 <heycam> nikos: you'd need to look into this into more detail
20:49:36 <heycam> heycam: [talking about an empty <g> returning (0,0,0,0) and how that should not contribute to a parent's bbox]
20:51:14 <heycam> ed: I think a <path> without d="" shouldn't contribute to the parent bbox
20:51:21 <heycam> shepazu: we're talking about an error condition here
20:51:31 <heycam> Tav: that's how I view it, and beacuse it's an error it shouldn't contribute
20:51:33 <heycam> shepazu: there are two cases
20:51:40 <heycam> ... one we have an error condition, where someone screwed up
20:52:01 <heycam> ... but in a dynamic document, maybe the author is checking bbox while building a shape, or something is being animated
20:52:10 <heycam> ... the thing doesn't have dimensions, but does have position
20:52:18 <heycam> Tav: you can't animate something that doesn't have a d="" on it
20:52:23 <heycam> ... since you need same length path segment lists
20:52:27 <heycam> shepazu: for circle I'm saying
20:52:33 <heycam> ... you can animate a circle with radius of 0
20:53:00 <heycam> ... if you have script generated content, and I don't know necessarily what the contnet was
20:53:04 <heycam> ... but I want to know what's there
20:53:25 <heycam> ... it feels really wrong for some geometry elements to behave one way, but others another way
20:53:34 <heycam> Tav: a circle without a radius isn't an error in my view
20:53:38 <heycam> shepazu: why?
20:53:43 <heycam> Tav: because you can animate down from some radius to 0
20:53:48 <heycam> ... an empty d you can't animate
20:53:55 <heycam> shepazu: what if you had a d="M 0,0"
20:54:00 <heycam> Tav: that's more iffy
20:54:08 <heycam> shepazu: the boundary is hazy right
20:54:21 <heycam> ... what about d="M 0,0 L 0,0"
20:54:40 <ed> stroke-linecap: round would also work
20:55:02 <ed> <path d="M0 0" stroke-linecap="round"/>
20:55:07 <heycam> heycam: I think d="M 0,0" would render a marker
20:55:17 <heycam> krit: yes that changed in SVG 1.1SE
20:55:36 <heycam> Tav: if you have an empty d="" do you have a marker at 0,0?
20:55:50 <heycam> shepazu: you would if you followed through on this
20:56:03 <heycam> ... I think having a lacuna value for d="" seems more consistent
20:56:15 <heycam> Tav: it's a mistake as the spec is written now
20:56:22 <heycam> ed: but you might be wanting to fill in the d="" later on
20:56:58 <heycam> Tav: if the lacuna value is M0,0 then it should have geometry
20:58:32 <heycam> heycam: it would be consistent with other shapes to not render the implicit M0,0
20:58:49 <heycam> heycam: otoh, there'd be a difference between implicit M0,0 and explicit M0,0
20:59:08 <heycam> shepazu: I would think users coming to SVG would find this to be an inconsistency
20:59:31 <heycam> Tav: if I were coming from outside I would expect <path> without a d="" to be a mistake and not contribute
20:59:43 <heycam> shepazu: I wonder what HTML does with getClientRect
20:59:56 <heycam> ... an empty <p> would contribute to the element
21:00:22 <heycam> krit: I think you can't compare them, given they have different things like margin/padding/...
21:00:45 <heycam> ... I think if you don't have d="" you don't have a path
21:01:30 <heycam> Smailus: I would say logically if you use the default values of <circle> then you don't really have a circle either
21:01:43 <heycam> shepazu: we're talking about a default for d="" here
21:01:52 <heycam> ... it feels much more consistent
21:02:33 <heycam> [talk about shapes that exist but aren't visible and v.v.]
21:02:48 <heycam> shepazu: so if we set default values for points/d, then they do
21:03:07 <heycam> ... I'm arguing for a system where the presence of default values is consistent
21:03:20 <heycam> nikos: the element exists, and it's up to the system to define what that means
21:03:43 <heycam> shepazu: it'd be consistent to have defaults for all geometry attributes
21:03:45 <heycam> nikos: I agree
21:03:56 <heycam> Smailus: I agree
21:04:18 <heycam> shepazu: when you getBBox on the parent I think it should include this, but I could be persuaded out of that
21:04:42 <heycam> ... could say if you have a rect that doesn't have x/y/width/height, it should either contribute or not contribute in the same way that path without a d="" attribute
21:05:14 <heycam> ... I think it's more consistent with the way HTML does things
21:05:25 <heycam> ... (in terms of error recovery)
21:05:48 <heycam> ed: sounds like we won't get consensus here
21:05:58 <heycam> shepazu: take it to the list?
21:06:10 <heycam> nikos: I'll write something to the list to start the discussion
21:06:21 <heycam> ed: another thing is whether getBoundingClientRect takes stroke into account
21:06:27 <heycam> krit: btw that method is defined in CSS OM
21:07:22 <heycam> ACTION: Nikos to mail www-svg about bboxes of d-less path
21:07:22 <trackbot> Created ACTION-3590 - Mail www-svg about bboxes of d-less path [on Nikos Andronikos - due 2014-02-20].
21:07:40 <heycam> Topic: review on css3-backgrounds
21:07:51 <heycam> krit: in the latest changelog there is just a change on the background shorthand
21:08:03 <heycam> ... which relaxes the parsing
21:08:10 <heycam> ... the parsing restrictions
21:08:12 <heycam> ... same for box-shadow
21:08:23 <heycam> ... the most important part is that box-decoration-break is split out into another spec
21:08:27 <heycam> ... that doesn't affect SVG
21:08:36 <heycam> ... so from the SVG PoV there's nothing that needs feedback
21:09:06 <heycam> heycam: this spec has just gone back to LC from CR, so not many changes
21:09:19 <heycam> ed: should we reply to say we don't have any comments?
21:09:22 <heycam> krit: yese I can take an action to send the feedback mail
21:09:37 <heycam> ACTION: Dirk to reply to CSSWG with a no-feedback review of css3-background
21:09:37 <trackbot> Created ACTION-3591 - Reply to csswg with a no-feedback review of css3-background [on Dirk Schulze - due 2014-02-20].
21:09:56 <shepazu> q+
21:09:57 <heycam> Topic: update on Leipzig meeting venue
21:10:00 <heycam> Tav: I havne't heard back
21:10:11 <heycam> shepazu: I got an email this morning but it was just a forward on to another person
21:10:18 <heycam> s/shepazu/krit/
21:10:39 <heycam> shepazu: it turns out there will be a web apps and html joint F2F at paypal that same week in san jose
21:11:30 <heycam> krit: we could move the meeting before LGM?
21:11:37 <heycam> heycam: would still rather have it later
21:11:54 <heycam> shepazu: that'll conflict with W3C annotations workshop. which is fine, but there's going to be a conflict with something either way.
21:12:06 <heycam> ... there's also a TAG meeting going on the week before
21:13:52 <heycam> heycam: sounds like nobody was planning to go to the HTML/webapps meeting
21:14:24 <heycam> krit: the last day of LGM is the last day of holidays
21:14:45 <heycam> ... getting room might be difficult. if they did have place for us before LGM and not after, would we be ok with doing that?
21:14:47 <heycam> Tav: it doesn't matter to me
21:14:54 <heycam> nikos: it'd be much easier for me afterwards
21:14:55 <heycam> ed: same for me
21:15:37 <heycam> heycam: as a fallback we could do it in the paris office, though I haven't asked about this
21:15:47 <heycam> krit: I'll try to get information by next thursday
21:16:59 <heycam> Topic: ISSUE-2456: Clarify the url resolving behavior for when there are duplicate ids in a document
21:17:15 <heycam> heycam: the first one!
21:17:24 <heycam> ed: that's what getElementById does?
21:17:25 <heycam> Tav: yeah
21:17:27 <heycam> shepazu: sounds ok
21:18:04 <shepazu> q+
21:18:31 <heycam> ... this also has implications for <use>, gradients
21:18:35 <heycam> ed: yes this is what I meant
21:18:39 <heycam> ... getElementById is already defined
21:18:44 <heycam> ... if you have fill(#duplicateid)
21:18:50 <heycam> shepazu: ok yes, that's the important thing to define
21:19:00 <ed> also for xlink:href="#foo"
21:19:18 <heycam> ... this might be unintuitive to CSS people and how cascading works
21:20:27 <heycam> [how querySelector works with duplicate ids]
21:21:16 <heycam> RESOLUTION: Duplicate IDs resolve to the first element with the ID in document order.
21:21:30 <heycam> ACTION: Erik to clarify that duplicate IDs resolve to the first element with the ID in document order
21:21:30 <trackbot> Created ACTION-3592 - Clarify that duplicate ids resolve to the first element with the id in document order [on Erik Dahlström - due 2014-02-20].
21:21:56 <heycam> Topic: ISSUE-2455: Should 'id' attribute refer to DOM4?
21:22:07 <heycam> ed: currently ID is pointing to the XML spec
21:22:15 <heycam> ... do we keep that? or just refer to the DOM spec for how it's defined?
21:22:18 <heycam> ... what about the parsing?
21:22:34 <heycam> heycam: I think we should do what HTML does and allow more characters than the XML spec did
21:22:38 <heycam> ... i.e. refer to DOM
21:22:52 <heycam> ... DOM spec does define Element.id anyway, so it makes sense to follow
21:23:22 <heycam> id is already gone from https://svgwg.org/svg2-draft/types.html#InterfaceSVGElement
21:24:50 <heycam> [some talk of SVG in other XML languages like docbook, and whether this impacts it]
21:25:49 <heycam> shepazu: found many documents with people using id="2" for example
21:25:51 <heycam> RESOLUTION: Syntax of id attribute should match that of HTML/DOM.
21:26:06 <heycam> ACTION: Cameron to make the spec have id attributes be parsed just like in HTML/DOM.
21:26:07 <trackbot> Created ACTION-3593 - Make the spec have id attributes be parsed just like in html/dom. [on Cameron McCormack - due 2014-02-20].
21:26:51 <heycam> ed: multiple IDs?
21:27:00 <heycam> heycam: don't allow it
21:27:10 <heycam> shepazu: we've already agreed to kill xml:id, as it raises all these IDness issues
21:27:24 <heycam> ACTION-3593: Ensure you can't have multiple IDs on an element.
21:27:24 <trackbot> Notes added to ACTION-3593 Make the spec have id attributes be parsed just like in html/dom..
21:27:36 <shepazu> http://www.schepers.cc/xmlid/svgxmlid.html
21:28:05 <heycam> Topic: Removing forceRedraw, suspendRedraw, unsuspendRedraw from SVG2
21:28:12 <heycam> shepazu: these were almost hints anyway
21:28:18 <heycam> ed: I think most implementations just stub these out
21:28:22 <heycam> ... I'm proposing dropping them altogether
21:28:26 <heycam> shepazu: I agree
21:28:27 <Zakim> -Tav
21:29:52 <heycam> shepazu: are we deprecating?
21:29:59 <heycam> ed: think they're already deprecated in 1.1
21:30:24 <heycam> shepazu: if somebody runs into their old content that uses these methods, they should get an error so they can [ ... ]
21:31:08 <heycam> ed: i might be wrong, they're not deprecated in 1.1
21:31:17 <heycam> ... but as I said they're stubbed out
21:32:41 <ed> https://svgwg.org/svg2-draft/struct.html#__svg__SVGSVGElement__suspendRedraw
21:32:53 <heycam> heycam: looks like we deprecated them already in SVG 2
21:33:48 <heycam> krit: there were some blog posts mentioning these methods and how in theory you could use them
21:33:58 <heycam> ... I know that we/others responded to that saying not to use them
21:34:06 <heycam> ... I also think there's not likely to be any real usage
21:35:16 <heycam> heycam: how about remove them from blink and see how it goes
21:35:17 <heycam> ed: ok
21:36:55 <heycam> Topic: SVG-specific ARIA functionality
21:37:06 <heycam> shepazu: the PF group resolved to start a new document with SVG specific ARIA functionality
21:37:21 <heycam> ... should this be done as a taskforce between SVG and PFWG?
21:37:24 <heycam> heycam: I think that makes sense
21:37:29 <heycam> krit: yes
21:37:42 <heycam> shepazu: anyone else in the WG apart from me and rich interested in participating?
21:37:46 <heycam> krit: me
21:37:49 <heycam> heycam: I'd like to follow along yes
21:37:53 <heycam> ed: me too
21:38:46 <heycam> RESOLUTION: SVG WG is happy to have a taskforce with PFWG to jointly work on SVG-ARIA stuff.
21:40:59 <Zakim> -Doug_Schepers
21:41:00 <Zakim> -birtles
21:41:01 <Zakim> -stakagi
21:41:02 <Zakim> -heycam
21:41:02 <Zakim> -Thomas_Smailus
21:41:04 <Zakim> -krit
21:41:05 <Zakim> -ed
21:41:06 <Zakim> -nikos
21:41:06 <Zakim> GA_SVGWG(SVG1)3:30PM has ended
21:41:06 <Zakim> Attendees were Thomas_Smailus, Doug_Schepers, birtles, ed, stakagi, [IPcaller], heycam, nikos, krit, Tav