- 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