- From: Richard Schwerdtfeger <schwer@us.ibm.com>
- Date: Thu, 14 Aug 2014 10:12:14 -0500
- To: "www-svg@w3.org" <www-svg@w3.org>
- Message-ID: <OF8EFDB9FA.021ACB41-ON86257D34.0053597B-86257D34.00538430@us.ibm.com>
I spoke with Janina yesterday and there are no issues with joint publication with the SVG a11y task force. I think they knew you were asking for this prior to this morning's call. Rich Rich Schwerdtfeger From: Erik Dahlström <ed@opera.com> To: "www-svg@w3.org" <www-svg@w3.org> Date: 08/14/2014 08:54 AM Subject: Minutes, 14 August 2014 SVG telcon Minutes: http://www.w3.org/2014/08/14-svg-minutes.html and as text: [1]W3C [1] http://www.w3.org/ - DRAFT - SVG Working Group Teleconference 14 Aug 2014 [2]Agenda [2] http://lists.w3.org/Archives/Public/public-svg-wg/2014JulSep/0035.html See also: [3]IRC log [3] http://www.w3.org/2014/08/14-svg-irc Attendees Present birtles, ed, heycam, krit, nikos_, Doug_Schepers Regrets Chair ed Scribe Nikos Contents * [4]Topics 1. [5]New W3C Process document 2. [6]Accessibility TF 3. [7]New W3C Process document (continued) 4. [8]Polyfill for new SVG DOM proposal 5. [9]Using units and percentages with path * [10]Summary of Action Items __________________________________________________________ <trackbot> Date: 14 August 2014 New W3C Process document <scribe> Scribe: Nikos <scribe> scribenick: nikos_ <heycam> [11]http://www.w3.org/2014/Process-20140801/ [11] http://www.w3.org/2014/Process-20140801/ heycam: I forwarded an email about the new process which came into effect last week ... most visible change is in merging LC and CR ... that change has been discussed before - it's gone ahead now ... so that point is now when there is wider review of spec and when we ask for implementations <heycam> [12]http://lists.w3.org/Archives/Public/spec-prod/2014JulSep/00 57.html [12] http://lists.w3.org/Archives/Public/spec-prod/2014JulSep/0057.html heycam: here is another mail that has links to summaries of the changes ... also points out importantly that we have the option of publishing new versions of existing documents under this process if we want to ... for the next 2 years ... we can continue to publish works in progress under the old process if we want during that time ... it shouldn't affect us too much krit: I'd suggest we use the new proces s with new publications that we plan shepazu: to me, it's a a slightly more realistic process doc. CR was a period of time when you had to wait a month before going on - at least ... so people were sitting around in CR waiting for the time period to finish or they skipped CR ... now we skip a period of bureaucracy, so things should happen faster krit: on that note, CSS Masking has been CR for 1.5 months and is still not published ... Chris is taking care of it, but because of publication moratoriums, etc it hasn't happened yet shepazu: I wasn't aware of that ... Could you send me the details and I'll try to care care of it? ... although I'm not staff contact krit: to come back to the process, I think there's no objection here shepazu: one other thing ... with accessibility TF Accessibility TF shepazu: there was a contradiction in the work statement <shepazu> [13]http://www.w3.org/WAI/PF/svg-a11y-tf/work-statement [13] http://www.w3.org/WAI/PF/svg-a11y-tf/work-statement <shepazu> shepazu: in one place it says the SVG 2 to accessibility mapping guide will be considered a publication of the PFWG ... then down below it says the following documents are managed jointly, and that doc is included there ... so unlike FX the work statement says it's joint work but it's only published by PF ... we pushed back on that ... I want to confirm that we want jointly published deliverables? heycam: I think that's the conclusion we came to last time we discussed this shepazu: anyone disagree with joint publication? <silence> RESOLUTION: Joint deliverables from task forces shall be published by both working groups New W3C Process document (continued) ed: do we need resolution regarding which process we publish under? RESOLUTION: New documents, including new revisions of working drafts, will be published under the new W3C publication process Polyfill for new SVG DOM proposal heycam: last time we discussed the new DOM stuff was in Germany ... the result was that a couple of people were still unsure ... the idea of a polyfill was raised ... to let us try the new API ... to help bring us to a conclusion <heycam> [14]http://lists.w3.org/Archives/Public/www-svg/2014Aug/0008.ht ml [14] http://lists.w3.org/Archives/Public/www-svg/2014Aug/0008.html heycam: I've sent this mail linking to the polyfill ... it's a javascript file ... which runs in FF only ... because it uses features which aren't available everywhere yet ... but doesn't matter as it's only intended for us and others interested in design of the dom <heycam> [15]http://heycam.github.io/new-svg-dom/examples/ [15] http://heycam.github.io/new-svg-dom/examples/ heycam: not for general public to use ... here's some examples ... if you are running FF nightly with web components enabled in about:config ... then those should work ... please try examples and look at source ... I've pointed out the different approaches in the examples ... and we'll have a broader discussion at the F2F ... we can play with it live during the F2F to get a feel for it ... I just wanted to draw your attention krit: I've heard it mentioned that it might be better to use properties instead of getters and setters ... having something that returns pixel in all cases would be great shepazu: do you use chaining? heycam: I haven't introduced a big suite of new methods for constructing methods or anything like that ... the one situation where I could have added chaining was a method to set list of points for a js array ... or a list of path segments ... they could return the same object back again ... if that's a pattern thats becoming popular I don't mind that krit: one example is that we should not have element.getBBox() ... but a bbox property <general agreement> krit: that's just some general feedback I got, not necessarily my opinion <birtles> were we going to try and get input from Hixie before the F2F? or was that more related to mixing SVG and HTML elements? heycam: at last discussion from Germany, the sticking point wasn't the details ... but the broad question of whether we should do this at all ... so I'd like to solve the question of whether we go ahead ... I haven't gotten input from hixie or anyone else yet ... I think the proposal needs some changes - we probably need others agreements regarding ns changes ... maybe not important to get that feedback before we decided whether to push forward or not ... if we do go forward then I'll correspond ... if there are specific parts that I haven't implemented yet, but you'd like me to implement or you'd like specific examples, then let me know krit: was transforms part of the proposal? heycam: yes, but I haven't done an example for that ... I have implemented the thing where you have a get and set method to return an array of dictionary like things ... that have type and arguments from the objects ... instead of SVG transform list stuff ... I can make an example if you'd like krit: yeh sure ed: in the proposal do we have support for making your own objects and dictionaries and passing them into the SVG DOM? ... does that work or do you have to create custom SVG point or whatever? heycam: I haven't looked at that part of it ... the original proposal didn't look at those methods ... that take SVGPoint or SVGMatrix ... so polyfill doesn't look at that yet ... we should look at that in the context of the geometry spec ... for the get and set method for points attribute on polygon and polyline, they take an array of dictionary like objects krit: for length values ... did you spend time to look if it could be implemented more efficiently than with get and set attributes? heycam: I didn't look, but for us, assigning to an object with a type string should be the same as calling a method Using units and percentages with path shepazu: is there a good reason not to do this? heycam: it would cause problems for the SVG DOM methods ... the reasons for not doing it are not very good though ed: this could be implemented as a polyfill maybe? shepazu: yes krit: for relative segments, what does percentage mean? ... percentage of viewport? shepazu: that's something we'd have to resolve ed: the polyfill would let us identify questions like this shepazu: do people think this would be a good idea? krit: we discussed in Switzerland and decided it would be a good idea ... to have these units for path segments would be interesting ... I think there's some problems to solve, but in general I think this would be a good move shepazu: from an editor point of view, an SVG loaded that used this stuff would not work krit: if you assume we don't update our products ... the question is more how can tools make use during export rather than import ... that's tricky ... path segment is intuitive when hand editing, but not with tools ... tools tend to just export with basic path commands shepazu: a lot of content comes from script now heycam: what do you think about digging up the minutes and rehashing at the next F2F? shepazu: I can do that <scribe> ACTION: Doug to summarise what was discussed at Switzerland F2F regarding units and percentage values in path commands [recorded in [16]http://www.w3.org/2014/08/14-svg-minutes.html#action01] <trackbot> Created ACTION-3637 - Summarise what was discussed at switzerland f2f regarding units and percentage values in path commands [on Doug Schepers - due 2014-08-21]. <ed> trackbot, end telcon Summary of Action Items [NEW] ACTION: Doug to summarise what was discussed at Switzerland F2F regarding units and percentage values in path commands [recorded in [17]http://www.w3.org/2014/08/14-svg-minutes.html#action01] [End of minutes] __________________________________________________________ Minutes formatted by David Booth's [18]scribe.perl version 1.138 ([19]CVS log) $Date: 2014-08-14 13:49:18 $ __________________________________________________________ [18] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm [19] http://dev.w3.org/cvsweb/2002/scribe/ Scribe.perl diagnostic output [Delete this section before finalizing the minutes.] This is scribe.perl Revision: 1.138 of Date: 2013-04-25 13:59:11 Check for newer version at [20]http://dev.w3.org/cvsweb/~checkout~/2002/ scribe/ [20] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/stufff/stuff/ Found Scribe: Nikos Found ScribeNick: nikos_ Default Present: birtles, ed, heycam, krit, nikos_, Doug_Schepers Present: birtles ed heycam krit nikos_ Doug_Schepers Agenda: [21]http://lists.w3.org/Archives/Public/public-svg-wg/2014JulSep /0035.html Found Date: 14 Aug 2014 Guessing minutes URL: [22]http://www.w3.org/2014/08/14-svg-minutes.html People with action items: doug [21] http://lists.w3.org/Archives/Public/public-svg-wg/2014JulSep/0035.html [22] http://www.w3.org/2014/08/14-svg-minutes.html [End of [23]scribe.perl diagnostic output] [23] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm -- Erik Dahlstrom, Web Technology Developer, Opera Software Co-Chair, W3C SVG Working Group
Attachments
- image/gif attachment: graycol.gif
Received on Thursday, 14 August 2014 15:12:49 UTC