SVG Working Group Teleconference -- 06 Mar 2014

<trackbot> Date: 06 March 2014

<scribe> scribe: nikos

<scribe> scribenick: nikos_

Shipping paint-order

heycam: last week Dirk brought up the issue of whether we should discuss things in the WG to ship new SVG 2 features in browsers
... I'm interested in paint-order
... do people think the definition of that property is stable enough for FF to ship in release build?

ed: I recently enabled it in stable releases for Blink

krit: you said it's up to each implementation

heycam: I thought it would be nice to bring up in the WG before we decide those things

krit: thought we'd decided for paint-order

heycam: I think paint-order is ready anyway

Tav: can we get notified of status? How can I try it out

heycam: available in Chrome Canary and FF nightly
... Webkit, dirk?

krit: patch in but not reviewed yet

Tav: I'd like to see announcements to the WG
... give a week or so to try it before we agree to release

krit: I wrote 11 reftests and some JS tests. I can upload the reftests

nikos: It would be good for non browser people to know in general when features are being added

Tav: I was thinking of what to add to InkScape

heycam: I don't need to ship it urgently in FF so if you want another week to play around that's fine

ed: Blink change hasn't trickled down to stable release yet, but it will at some point
... it's been in Canary for a couple of months behind a flag

heycam: sounds like there is time to test paint-order before it hits stable builds

Tav: I'm not too worried about paint-order but other features

heycam: I think we can keep trying to do this where we bring it up in the group

Reference box keywords for 'clip-path' and 'mask'

krit: simple one first...

<krit> http://dev.w3.org/fxtf/masking/#the-clip-path

krit: if you open link, you'll see we have two types of value for clip-path
... clip-source and geometry-box
... the question is, do we want to have these reference boxes for clip source as well?
... for instance, you have clip-path and clip path units object bounding box
... we may want to have a keyword for fill stroke view box that allows you to reference a different box
... fill would be redundant, but stroke or something would be interesting

heycam: may have discussed this before in the context of another element
... I feel the choice of which box is intrinsic to the definition of the resource element
... so having something in the property value where you are referencing it maybe isn't useful

krit: do we want new keywords for HTML elements and new keywords for SVG elements?
... I wouldn't add it to this level, but I think it needs discussing

heycam: the spec allows new keyword values to be specified in the property

krit: just allows for basic shapes

heycam: basic shapes don't support paths?
... paths were deferred?

krit: yes
... it got deferred

heycam: if we don't allow new values in clip-path-units it will be relevant to border box
... I don't know if we need to do this now

krit: I think this should be deferred until the next level anyway, but should be discussed now
... the behaviour should be consistent for all elements - gradient, clips, filters, etc

heycam: agree
... my feeling would be yes to adding new values to the attributes in general
... but might need to think about it more

krit: maybe we can discuss at the F2F
... anyone object to not having this in the first level of the spec?
... not being able to choose which reference box you use. SVG is always object bounding box or user space
... we agreed that we want it eventually
... but level 1 or later?
... later allows us to come up with a solution for all SVG elements

Tav: doesn't matter to me
... current bounding box doesn't include stroke?

heycam: no
... I don't think it's urgent enough to do in level 1 right now
... think we should decide more generally how to treat this

krit: anyone object?

ed: what is the default behaviour for HTML?
... what would be the equivalent?

krit: would be border-box for HTML elements

ed: that kind of is the same as the stroke bounding box

krit: not really, but if you want to compare SVG to HTML then yes

ed: trying to think of cases where you'd want to use the same thing. Taking a basic-shape and apply same box to HTML and SVG and have it behave the same

heycam: the keywords on the property at the moment, we decided that if you use an SVG specific keyword (e.g. fill) then that means the default box for HTML content?

krit: that's correct

heycam: would we be adding additional keywords for the HTML specific ones?
... in the geometry-box bit of the clipPath?

krit: we would use the same reference box

heycam: is that in the definition of shape-box?

krit: for polygon, inset, circle, ellipse

heycam: what about border-box, patter-box, margin-box? are they already supported in the property?

krit: yes

heycam: as Erik was pointing out. If you want to define a basic shape and have it apply to SVG and HTML

krit: it means the SVG or the HTML would fall back to the default
... you can only specify one

heycam: is that a problem?

krit: I haven't thought about that yet
... it's an interesting point
... don't know if it would be a problem

heycam: in practice, maybe using stroke-box in SVG and border-box in HTML is what you want 90% of the time

krit: if you don't want default values for both, then you need to have two classes

heycam: seems like something we could add later without problems
... if you think we should go that way
... coming back to your initial question of whether we should decide now

krit: we don't need to decide now, but if we don't I'd like to defer to next level

heycam: didn't hear anyone say that we need to solve it now

RESOLUTION: we will handle new box keywords in units attributes in level 2 of Masking

Renaming 'fill' and 'stroke' keywords to 'fill-box' and 'stroke-box'

krit: we discussed during the F2F
... decided we don't want -box at the end
... because what is a box, block, element, etc
... Erik brought up that it might make sense for usability
... we have box at the end of many things already
... CSS WG decided they want box at the end
... and it's up to the SVG WG to agree or reject the decision

heycam: I think one of the reasons I like fill and stroke as they are is that it matches the names of the properties you pass to extended getBBox()
... but not sure that needs to outweigh the issue

krit: it's always good to align the keywords
... can we use fill-box and stroke-box on getBBox?

heycam: possible, but would need to be camelCase
... the other thing, we have markers as a value in there

krit: even markers we'd have -box

heycam: I'd lean towards making it -box in the property and leave box off on getBBox

krit: agree

ed: I think it's fine as well

krit: do we rename property keywords to fill-box,stroke-box, etc?

RESOLUTION: fill and stroke keyword values in clip-path and mask property get renamed to fill-box and stroke-box

Bounding box of <path> without d=""

heycam: we brought discussion to the mailing list
... seemed like we had agreement

krit: so should path element without d attribute have a bounding box, and should it contribute to it's parent?

nikos: think we had consensus on what model to use
... just need to decide what happens for path without d

krit: do they render or not? A d attribute can have invalid syntax and it will draw up to that invalid point

heycam: the discussion went a bit into invalid or empty attributes would invoke some lacuna value
... which would be the way that something gets rendered

ed: think they're all a bit special with regards to lacuna values
... because broken paths do render up to last good data

krit: but for both you render right?

ed: unless the error is so early you don't render anythying

heycam: it doesn't make sense to have a lacuna value for d that causes rendering

all: agree

heycam: i don't think it makes sense to make a lacuna value an invalid value

nikos: an empty d is not invalid, it just doesn't render. There's a special bit of text

krit: can we change that?

nikos: I would have thought it might be too late

heycam: as long as it doesn't change the rendering behaviour

krit: to make things more confusing. the canvas path syntax doesn't require a moveto
... if you start with a lineto, it will behave as a moveto
... empty strings will not render anything

heycam: we can decide the issue of omitting the inital moveto separately
... do you think having an empty string and is analogous to a zero width/height rect ?
... I think everyone agrees that an empty path shouldn't render

nikos: so should a M0,0 render?

krit: a rect with zero width height shouldn't render

heycam: I have a feeling implementations render markers in that case

RESOLUTION: path/polygon/polyline with no data set (empty or zero valid commands) should not render

heycam: the next issue is what getBBox should return on path/polygon/polyline with empty or zero valid commands
... everyone in agreement that it should be [0,0,0,0] I think?
... would it be useful to distinguish a real empty bbox from an invalid one?
... I have a feeling we would need to return an actual box
... I think [0,0,0,0] is probably safer

ed: think that's what implementations do

RESOLUTION: getBBox for path/polygon/polyline with no data set (empty or zero valid commands) should return [0,0,0,0]

heycam: final thing is whether the [0,0,0,0] box contributes to ancestor getBBox calls

nikos: don't think it should

all: agree

heycam: I think this is similar to when display:none is set

RESOLUTION: Bounding box for path/polygon/polyline with no data set (empty or zero valid commands) should not contribute to ancestor bounding box

ed: when you have a d attribute which is broken half way through I think the bbox should represent the valid part of the path
... don't think we define that in the spec

krit: are you sure there's no error handling in the appendix?

ed: doesn't talk about the bbox. Just says you render up to that point

nikos: I think the bounding box should cover what is rendered

heycam: agree

RESOLUTION: bounding box for path with some invalid data following some valid data will include the data which is rendered

<scribe> ACTION: nikos to update specification with path/polyline/polygon resolutions regarding bounding box for missing data [recorded in http://www.w3.org/2014/03/06-svg-minutes.html#action01]

<trackbot> Created ACTION-3599 - Update specification with path/polyline/polygon resolutions regarding bounding box for missing data [on Nikos Andronikos - due 2014-03-13].

- DRAFT -

SVG Working Group Teleconference

06 Mar 2014

Attendees

Contents

Shipping paint-order

Reference box keywords for 'clip-path' and 'mask'

Renaming 'fill' and 'stroke' keywords to 'fill-box' and 'stroke-box'

Bounding box of <path> without d=""

Summary of Action Items

Scribe.perl diagnostic output