SVG Working Group Teleconference

13 Feb 2014


See also: IRC log


Thomas_Smailus, Doug_Schepers, birtles, ed, stakagi, [IPcaller], heycam, nikos, krit, Tav


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

ISSUE-2454: What should the bbox of a path without a d attribute be?

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].

review on css3-backgrounds

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].

update on Leipzig meeting venue

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

ISSUE-2456: Clarify the url resolving behavior for when there are duplicate ids in a document

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].

ISSUE-2455: Should 'id' attribute refer to DOM4?

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

Removing forceRedraw, suspendRedraw, unsuspendRedraw from SVG2

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

SVG-specific ARIA functionality

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.

Summary of Action Items

[NEW] 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]
[NEW] 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]
[NEW] 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]
[NEW] ACTION: Nikos to mail www-svg about bboxes of d-less path [recorded in http://www.w3.org/2014/02/13-svg-irc]
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.137 (CVS log)
$Date: 2012-09-20 20:19:01 $