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