See also: IRC log
<trackbot> Date: 14 August 2014
<scribe> Scribe: Nikos
<scribe> scribenick: nikos_
<heycam> 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> 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
shepazu: there was a contradiction in the work statement
<shepazu> 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
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
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> 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> 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
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 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
This is scribe.perl Revision: 1.138 of Date: 2013-04-25 13:59:11 Check for newer version at 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: http://lists.w3.org/Archives/Public/public-svg-wg/2014JulSep/0035.html Found Date: 14 Aug 2014 Guessing minutes URL: http://www.w3.org/2014/08/14-svg-minutes.html People with action items: doug[End of scribe.perl diagnostic output]