SVG Working Group Teleconference -- 12 Sep 2013

<trackbot> Date: 12 September 2013

<krit> heycam: Can not call in

<krit> heycam: just status update on Matrix

<krit> heycam: we (CSS WG) decided to prefix all new geometry APIs with DOM

<krit> heycam: means Matrix would be DOMMatrix

<heycam> krit, ok. good thing I haven't organised the document to be published yet. (sorry.)

<krit> heycam: I will update the spec today so that it is ready for publication

<scribe> scribenick: nikos

Merging Text chapter rewrite into SVG 2

tavmjong.free.fr/SVG/publish/text.html

Tav: I've restructured this chapter under the premise that SVG 2 will define text in terms of CSS
... in such a way that SVG 1.1 text is still valid
... SVG 1.1 text is a special case
... everything defined in terms of a content area (CSS term)
... SVG 1.1 the content area is an infinite rect
... introduction now reflects that
... and text layout sections
... I'd like people to comment whether this is the right direction
... and whether I should move my changes to the current ED

heycam: I'm in favour of this direction. It fits in well with my implementation
... you should do the merge
... I wonder if a bit more work is required before we publish next WD

Tav: I've marked lots of little issues
... which CSS levels do we reference, etc
... over the next few meetings it would be good to work through those issues

heycam: seems like a good approach

Tav: it's a very big chapter

heycam: I'm keen to reduce stuff in this chapter
... a lot of the properties don't need to be defined in this chapter
... we can refer to CSS
... mode, direction, unicode bidi, etc

Tav: I'd like a reader to be able to get an idea of what the property is about

heycam: it's fine to mention them, just not full definitions
... in favour of lots of examples

Tav: I'll work on getting more in
... the way CSS defines direction is different than SVG 1.1
... it's kind of reversed
... various little inconsistencies to be worked out

heycam: I don't think we've discussed the individual properties. We've just generally talked about referencing CSS
... I think it's a good idea to bring them up over future meetings

ed: I think the way that bidi works in SVG is not consistent across the various browsers so we don't risk breaking much if we change how it works
... that's my experience anyway

heycam: bidi text should be pretty good in Firefox now

Tav: If no other comments, I'll merge it into the ED when I get back to France

Connector syntax

http://tavmjong.free.fr/SVG/CONNECTORS/index.xhtml

Tav: I started on a connector proposal
... the proposal I have is fairly simple
... The main thing is the 'point' element
... we talked about this being standalone as well as for connectors
... you define connectors between the points
... what I'd like to do is to define the point inside a rectangle so I can use the bounding box of the rectangle to place the point
... InkScape implementation currently relies on groups so doesn't have this ability yet
... connector is just a straight line at the moment
... I think that's fine to start with
... start and end are specified by order not explicitly
... Next step is to have intermediate points
... This allows corners
... If you flip the connector over, the points will also flip
... sometimes you want to specify a path
... example 4 shows that
... the one major point I've found relates to using symbols
... it would be good to re-use symbols in a connected diagram like this
... how to you specify a point on a symbol?
... I don't have a solution at the moment
... I have an example of what I'd like to achieve
... Can you guys think of a way?
... I envision a 'level 2' spec with additional routing features
... a list of 'ports' which are points and the router decides the best to connect to

heycam: In the past we've talked about how far to go with routing. Possibly don't want too much automatic routing.

Tav: Another extension is to specify a radius that would control curve of the connection
... There isn't that much difference between connectors and paths
... you could do connectors with paths by specifying a connector-type and overriding the d attribute
... ultimately I'd like to not have a connector element, but to place the attributes on path
... enables fall back as well

heycam: maybe instead of having connector path attribute you could change the path data syntax to reference points
... that would destroy the fall back mechanism though

Tav: you get some of that by using relative path elements

heycam: The other thing that we've talked about was having more control regarding the automatic ports on a shape
... percentages work well for bounding box of rect, but not so much for circle

Tav: for circles, you describe the points relative to the transformed bounding box

heycam: Let's say you have two circles. You want the bottom right most point of one circle connecting to the top most point of the other
... You'd have to do some trig

Tav: one possible solution would be to define the point at the centre and tell the connector it stops at the edge of the object.
... I think it adds a level of complexity that will make implementing difficult initially

heycam: I think it will be a common use case

Tav: We should think of a way to do it but I don't think it should be in Level 1

heycam: Overall I think this looks like a good starting point

<TabAtkins> Forcing trig just to do one of the most common things in level 1 isn't great...

Tav: I'd like to get comments from Doug
... The one major problem I have is how to reference a point in a symbol

heycam: Maybe not using id within the symbol, using some exported name, and having a separate syntax inside the point
... The only place this might have come up in CSS is web components
... I think there's a way to have CSS connectors cross the boundary and reference things in the shadow tree
... maybe a selector based mechanism could work?

Tav: I'm not in favour of adding selector type stuff to the syntax

heycam: It would significantly complicate it
... Did you want to get comments from Doug before everyone decides whether this should be an ED?

Tav: I'm not sure what the next step is. Doug has a connectors draft also so want his input.

heycam: How about you ask Doug to give comments within the next week to see if the general direction fits in with his draft

<heycam> http://dev.w3.org/SVG/modules/connector/SVGConnector.html

Tav: how do people feel about defining point in another object?

heycam: makes sense to me

Tav: I'll email Doug

<scribe> ACTION: Tav to discuss with Doug and look at merging text from his connectors proposal in with Doug's proposal [recorded in http://www.w3.org/2013/09/12-svg-minutes.html#action01]

<trackbot> Created ACTION-3524 - Discuss with doug and look at merging text from his connectors proposal in with doug's proposal [on Tavmjong Bah - due 2013-09-19].

Planning Survey

<ed> http://lists.w3.org/Archives/Public/public-svg-wg/2013JulSep/0095.html

heycam: Cam posted to the mailing list. Just a reminder to please fill it out so that we can plan the coming year.

oops that was ed

New Name for Paint Order Property

<ed> http://lists.w3.org/Archives/Public/public-svg-wg/2013JulSep/0093.html

heycam: last I heard, the CSS WG didn't have a strong opinion on the name
... I don
... I don't think they out and out disliked it

Tav: CSS don't use the word paint. But the concept in SVG is very ingrained
... I'm not sure another word would be better
... CSS WG are worried about connection between z-order and paint-order

<heycam> http://www.w3.org/TR/CSS21/zindex.html talks about "Painting order", which includes painting parts of objects in a particular order (background, borders, etc.)

Tav: I'm inclined to ask CSS WG for more details on why they don't like 'paint-order'

heycam: CSS 2.1 defines a painting order which defines the painting of the whole subtree
... but also defines order within an object
... so painting order is already being used there to mean what I intended with 'paint-order'
... CSS WG might consider it confusing if their painting order includes order of elements as well

Tav: I'd like to make sure they are clear that we are not talking about z-order
... I'm not sure that was understood

heycam: none of the other suggested names have read as well as paint-order

<TabAtkins> We definitely know it's not about z-order.

heycam: I wonder if there's a CSS term for the parts of an element?

<heycam> like border, background, etc.?

ed: In general I think this could be applied to how CSS boxes are painted, but I'm not sure it's that interesting

heycam: shape-part-order?

nikos: what about something like in-shape-order to differentiate that it's within the element and not the scene

heycam: so how do we proceed?
... if we can't come up with a name that we all think is better?

Tav: I think we should go back to the CSS group

ed: We'll let them know we haven't come up with improved suggestions

heycam: Cameron to email the CSS WG regarding the naming of paint-order

<scribe> ACTION: Cameron to email the CSS WG regarding the naming of paint-order [recorded in http://www.w3.org/2013/09/12-svg-minutes.html#action02]

<trackbot> Created ACTION-3525 - Email the css wg regarding the naming of paint-order [on Cameron McCormack - due 2013-09-19].

Timeline for SVG 2

Tav: Is there anything major that hasn't gone in yet?

heycam: We should consult the wiki page

birtles: I still need to work on variable width stroke

<TabAtkins> Those "parts" are the boxes of the element.

<TabAtkins> Alternately: layers.

richardschwerdtfeger: The UI events spec is still changing constantly and we are referencing it
... for mouse events, keyboard, etc
... we took out mutation events but we're waiting for it to settle
... I don't know what their timeline is
... I'll email them

heycam: There's a couple of things that Doug wanted to do, like Catmull Rom curve

Tav: I've not seen progress so I don't know if we have time

heycam: That's one I really wanted to see in

birtles: There's also the outstanding work of integrating iframe and video
... Takagi-san has the action. I'll help him.

ed: Dirk is listed for video
... and for track
... but it's possible theres multiple actions for it
... I was wondering about the xlink namespace removal
... It's one of the bigger things that I'd like to see go in

heycam: That's on Chris
... my point in bringing up this topic is to propose that we have some cut off date where if progress hasn't been made on a feature, then we'll drop it
... a couple of months before release
... I'm proposing end of first quarter 2014

Tav: that should be plenty of time
... I would consider moving it up, since once the text is in there is still lots of discussion,etc required

heycam: I would consider that
... there are a bunch of non-feature things to do - cleaning up, referencing, etc
... that kind of work, I imagine, will be the last that we do before LCWD

Tav: I'd propose end of the year

heycam: I'd suggested LCWD in Q1
... which would make the cut off in January or December
... May co-inside with our first F2F of 2014
... have all feature stuff in by then
... if it's early we can have stuff added then spend F2F discussing issues
... then spend rest of quarter fixing up spec
... easiest to just say end of 2013 is feature cut off date

all: that's ok

RESOLUTION: End of 2013 will be cut off date for adding new features to SVG 2 draft

TPAC

birtles: I'd like to settle on a day for the combined CSS day so we can organise our travel

heycam: will either be Tuesday or Thursday or a combination of the two

birtles: if it's not going to be Monday then that's fine

- DRAFT -

SVG Working Group Teleconference

12 Sep 2013

Attendees

Contents