- From: Erik Dahlstrom <ed@opera.com>
- Date: Fri, 13 Sep 2013 11:02:50 +0200
- To: www-svg@w3.org
Hi Luc, My personal irc log shows that I did attempt to add the regrets (using /me zakim, regrets+ ...), but I missed that zakim didn't accept that syntax. Would be nice if that syntax was supported, but anyway... Generally speaking, the most important aspect of sending in regrets is to inform the chairs, to save everyone's time in case we don't have enough people for a call. Ideally regrets should be sent in a day or more before a scheduled call, but late regrets are of course better than simply not attending. Noting who sent in regrets in the minutes is mostly just bookkeeping, but I'll gladly make an effort to improve that, if you feel it's important. Cheers /ed On Fri, 13 Sep 2013 09:51:12 +0200, AUDRAIN LUC <LAUDRAIN@hachette-livre.fr> wrote: > Hi, > > Thanks for the minutes. > Just one detail : people who sent regrets are not listed in "Regrets". > Is it your group current usage? > > Best regards, > Luc > > Le 13 sept. 2013 à 00:06, "Nikos Andronikos" > <nikos.andronikos@cisra.canon.com.au> a écrit : > >> Minutes from this week's SVG WG telcon are below. >> >> http://www.w3.org/2013/09/12-svg-minutes.html >> >> >> [1]W3C >> >> [1] http://www.w3.org/ >> >> - DRAFT - >> >> SVG Working Group Teleconference >> >> 12 Sep 2013 >> >> [2]Agenda >> >> [2] >> http://lists.w3.org/Archives/Public/public-svg-wg/2013JulSep/0091.html >> >> See also: [3]IRC log >> >> [3] http://www.w3.org/2013/09/12-svg-irc >> >> Attendees >> >> Present >> +1.425.373.aaaa, [IPcaller], birtles, ed, >> +1.612.789.aabb, heycam, nikos, TavAndro, Rich >> >> Regrets >> Chair >> SV_MEETING_CHAIR >> >> Scribe >> nikos >> >> Contents >> >> * [4]Topics >> 1. [5]Merging Text chapter rewrite into SVG 2 >> 2. [6]Connector syntax >> 3. [7]Planning Survey >> 4. [8]New Name for Paint Order Property >> 5. [9]Timeline for SVG 2 >> 6. [10]TPAC >> * [11]Summary of Action Items >> __________________________________________________________ >> >> <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 >> >> [12]http://tavmjong.free.fr/SVG/CONNECTORS/index.xhtml >> >> [12] 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> >> [13]http://dev.w3.org/SVG/modules/connector/SVGConnector.html >> >> [13] 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 >> [14]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> >> [15]http://lists.w3.org/Archives/Public/public-svg-wg/2013JulSe >> p/0095.html >> >> [15] >> 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> >> [16]http://lists.w3.org/Archives/Public/public-svg-wg/2013JulSe >> p/0093.html >> >> [16] >> 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> [17]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.) >> >> [17] http://www.w3.org/TR/CSS21/zindex.html >> >> 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 >> [18]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 >> >> Summary of Action Items >> >> [NEW] ACTION: Cameron to email the CSS WG regarding the naming >> of paint-order [recorded in >> [19]http://www.w3.org/2013/09/12-svg-minutes.html#action02] >> [NEW] ACTION: Tav to discuss with Doug and look at merging text >> from his connectors proposal in with Doug's proposal [recorded >> in [20]http://www.w3.org/2013/09/12-svg-minutes.html#action01] >> >> [End of minutes] >> >> >> The information contained in this email message and any attachments may >> be confidential and may also be the subject to legal professional >> privilege. If you are not the intended recipient, any use, interference >> with, disclosure or copying of this material is unauthorised and >> prohibited. If you have received this email in error, please >> immediately advise the sender by return email and delete the >> information from your system. >> -- Erik Dahlstrom, Core Technology Developer, Opera Software Co-Chair, W3C SVG Working Group Personal blog: http://my.opera.com/macdev_ed
Received on Friday, 13 September 2013 09:03:41 UTC