- From: Nikos Andronikos <nikos.andronikos@cisra.canon.com.au>
- Date: Fri, 20 Sep 2013 07:34:22 +1000
- To: <www-svg@w3.org>
Minutes from this week's SVG WG telcon are below.
http://www.w3.org/2013/09/19-svg-minutes.html
[1]W3C
[1] http://www.w3.org/
- DRAFT -
SVG Working Group Teleconference
19 Sep 2013
[2]Agenda
[2] http://lists.w3.org/Archives/Public/public-svg-wg/2013JulSep/0100.html
See also: [3]IRC log
[3] http://www.w3.org/2013/09/19-svg-irc
Attendees
Present
+1.425.373.aaaa, [IPcaller], ed, +61.2.980.5.aabb,
thomas, nikos, birtles, +49.341.263.2.aacc,
+33.6.48.38.aadd, tav, cabanier, Doug_Schepers,
+33.9.53.77.aaee
Regrets
heycam, rich, chris
Chair
Erik
Scribe
nikos
Contents
* [4]Topics
1. [5]Replace feImage's xlink:href with href
2. [6]First F2F of 2014
3. [7]Mailing lists
4. [8]paint-order computed value
5. [9]non-scaling-stroke in patterns and markers, how
should it work
6. [10]treating U+000C as white space in attributes
7. [11]variable-width stroke syntax
8. [12]Parsing of URL, fetching undefined
9. [13]SVG hit testing
* [14]Summary of Action Items
__________________________________________________________
<trackbot> Date: 19 September 2013
<scribe> scribeNick: ed
Replace feImage's xlink:href with href
ed: heycam thought this was dealt with, did we have a
conclusion?
<nikos>
[15]http://www.w3.org/2013/09/05-svg-minutes.html#action01
[15] http://www.w3.org/2013/09/05-svg-minutes.html#action01
dirk: only the order wasn't decided, xlink:href or href first
nikos: correct, i think heycam took an action to figure it out
<nikos> scribe: nikos
First F2F of 2014
dirk: I'd like to get organisation started
... propose seattle after css meet
nikos: Canon can host in Sydney if we want to come here so I
can start organising that too
... depending on what the group want
ed: seems like it would be a good idea to meet with css wg
krit: it might be difficult to meet in last week of Jan and
meet with CSS as poll shows many people unavailable
[16]https://www.w3.org/2002/09/wbs/19480/SVGF2FPlanning2014/res
ults
[16] https://www.w3.org/2002/09/wbs/19480/SVGF2FPlanning2014/results
[17]http://doodle.com/kzd7fuw48t6ds4fn
[17] http://doodle.com/kzd7fuw48t6ds4fn
krit: not sure if the css wg want a joint meeting
... we can discuss on the mailing list
... I'll ask the CSS wg if they would be willing/available to
meet
<scribe> ACTION: Dirk to talk to CSS WG about whether they want
to meet with SVG at first F2F of 2014 [recorded in
[18]http://www.w3.org/2013/09/19-svg-minutes.html#action01]
<trackbot> Created ACTION-3526 - Talk to css wg about whether
they want to meet with svg at first f2f of 2014 [on Dirk
Schulze - due 2013-09-26].
Mailing lists
shepazu: when we first became a public group, we decided to
have 3 mailing lists
... original, www-svg, the public list that anyone can
subscribe and post to
... we already had the member list only wg members can
subscribe and read archives - member-svg-wg
... then we made the third list, public-svg. Anyone can read
archives, only wg members can subscribe/post to
... sort of transparent but people might be posting to wrong
list
ed: I'd prefer we use www-svg for everything we do if possible
shepazu: agree
... or we make public-svg open to anyone
... I think members post there without knowing that the public
don't have full access
... to promote more discourse with the public I suggest we shut
down public-svg and only have two lists
... better if we just do everything on www-svg
all: agree
shepazu: I'll send an email to the lists about this
<scribe> ACTION: Doug to email SVG mailing lists and propose
shutting down public-svg [recorded in
[19]http://www.w3.org/2013/09/19-svg-minutes.html#action02]
<trackbot> Created ACTION-3527 - Email svg mailing lists and
propose shutting down public-svg [on Doug Schepers - due
2013-09-26].
paint-order computed value
ed: computed value or computed style?
krit: computed value or computed style?
ed: just says specified value and I don't think that's the
right thing to put there
<ed> [20]https://svgwg.org/svg2-draft/painting.html#PaintOrder
[20] https://svgwg.org/svg2-draft/painting.html#PaintOrder
ed: definition of property says computed values are specified
... if you put paint-order normal you would get that as
computed value
... I'm proposing normalise the list to three values which is
the order that you draw things in
krit: even if i agree this is useful to the user, it would be
off from css
... in css wg we always use the specified value where possible
... because that's the computed value
... I think we shouldn't change that
... however the CSS WG is looking at a used value
... and I'd agree for 'used value'
ed: the reason you want to keep the specified value?
krit: consistency with other CSS properties
ed: do we have any others that expand to a list like this?
krit: we have some with special requirements
... eg url
... in general I'm not aware of other computed values that have
special values
... the general rule is that we should return the specified
value
ed: the used value for the property is not exposed anywhere
except to the UA
... I mean to the js DOM methods
... I guess I could live with keeping it like this for
consistency
... but I don't think its efficient
krit: computed value in general is not efficient
RESOLUTION: keep paint-order computed value as is
non-scaling-stroke in patterns and markers, how should it work
[21]http://jsfiddle.net/TfWqX/
[21] http://jsfiddle.net/TfWqX/
<ed>
[22]http://lists.w3.org/Archives/Public/public-svg-wg/2013JulSe
p/0101.html
[22] http://lists.w3.org/Archives/Public/public-svg-wg/2013JulSep/0101.html
krit: we had discussion at Adobe. Main issue is that it's very
hard to implement in pattern
... I don't think further specification is needed
... but it's hard to map original viewport co-ordinate system
to all elements you need to
ed: Yes its tricky, which I imagine is why some browsers don't
implement it
thomas: does this cover the dashed line cases?
... I'll add a separate agenda item later for stroke and dashed
lines
... what I've seen so far is that the dash line scales
cabanier: with non-scaling stroke you'd get that
ed: back to original question, I think the result is what you'd
expect
... but I don't agree that it's not something that needs more
specification
... because it's not defined in the spec at the moment
... think it needs to be pointed out, especially for those
cases
... that's regardless of how we decide to deal with it
... in Presto, I implemented it to compensate for all scale
factors
... don't think FireFox or Chrome do compensation in this case
... so easier to go with what implementations do, but I don't
think it's the right choice
krit: I agree but Adobe doesn't
Tav: I agree with Erik
ed: I could submit some test cases if that would help
... if we don't have consensus on one way or the other we'll
have to come back to the topic or deal with it on the mailing
list
<scribe> ACTION: Erik to submit test cases for
non-scaling-stroke/markers in patterns and mail the list
[recorded in
[23]http://www.w3.org/2013/09/19-svg-minutes.html#action03]
<trackbot> Created ACTION-3528 - Submit test cases for
non-scaling-stroke/markers in patterns and mail the list [on
Erik Dahlström - due 2013-09-26].
ed: I'd like more details on the objections from Adobe
<scribe> ACTION: Rik to query Adobe for concerns relating to
non-scaling-stroke/markers in patterns and mail the list
[recorded in
[24]http://www.w3.org/2013/09/19-svg-minutes.html#action04]
<trackbot> Created ACTION-3529 - Query adobe for concerns
relating to non-scaling-stroke/markers in patterns and mail the
list [on Rik Cabanier - due 2013-09-26].
treating U+000C as white space in attributes
krit: I'm for it
ed: sounds fine to me
Tav: me too
RESOLUTION: U+000C will be treated as white space in attributes
variable-width stroke syntax
<birtles>
[25]http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Variable_w
idth_stroke#Syntax_proposal
[25] http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Variable_width_stroke#Syntax_proposal
birtles: In June I proposed a syntax
... there was some feedback about that
... I've incorporated that into this updated proposal
... I think I'd like to get Tab in particular to have a look
<birtles>
[26]http://lists.w3.org/Archives/Public/www-svg/2013Sep/0022.ht
ml
[26] http://lists.w3.org/Archives/Public/www-svg/2013Sep/0022.html
birtles: There was also a proposal on the list for an element
based syntax
<birtles> ^ element-based syntax
birtles: what do people think of the updated proposal?
... there was one suggestion to specify the type of smoothing
per point
... I haven't incorporated that
... because I think we need to decide in general what options
we want for smoothing
... hasn't been resolved yet
... if no one has specific suggestions right now we can
continue on the list
... just wanted to bring it to your attention
... once we're happy with it then it's over to Rik or someone
to work on details of the algorithm
shepazu: do you have a sample page or script library that does
this?
birtles: no
shepazu: can I propose that we make a script library to emulate
this?
... I'd be happy to help
birtles: if you have time to do that it would be helpful
... I don't need a formal resolution on the syntax
... I just want to close the action
shepazu: this doesn't seem to include different widths on
different sides?
birtles: see the asymmetric section
shepazu: is that part of the initial proposal?
birtles: my suggestion is to do it from the start
shepazu: I have a feeling this is something that we are likely
to get wrong (from the users perspective) so I'd like us to
make a script library
birtles: I agree, and more than syntax, that will help us
decide on algorithms for smoothing and stuff
shepazu: If I start a script, can anyone help?
Tav: I could help
... I think it might be important to test handling of angles
and line joins
shepazu: I don't know if my implementation would be that
sophisticated
... let's see what we can do
birtles: that's a good next step
... if there's any feedback on my syntax or if anyone prefers
the element based syntax that would be useful now
shepazu: my initial reaction to the element based syntax was
that we'd get bigger bang for buck if we had a less verbose
syntax that is more like something you'd do with css
... was there anything you could do with element that you can't
do with the other?
birtles: easier to animate one point on the path
nikos: were there a few problems with the element syntax?
birtles: one is driving from CSS
<birtles> e.g. override just the repeat behavior, or use with
@supports etc.
ed: I agree it would be good to have a script library
shepazu: failing that, even just images would be nice
Parsing of URL, fetching undefined
krit: I was talking with Anne about security model
... we seem to rely on IRI specification
... it's not very explicit on how to parse
... also not clear how data URLs are parsed or accepted
... lots of other issues
... it's not clear how the about scheme would work
... it would be great if we could specify it but I don't know
if it's possible
shepazu: my question is why would SVG behave any differently
than HTML?
krit: HTML defines it
shepazu: so why don't we refer to HTML?
krit: HTML is talking about attributes, etc
... we would do it in the integration spec
shepazu: doesn't seem like that's in scope for SVG
... I think we should refer to something else
... I don't think we do anything special
... there was supposed to be a URI spec, why don't we refer to
that?
krit: URL just specifies URL, doesn't specify fetching model or
security model
... we need to define that for SVG
... I hope we can reference another document too
... it's part of Anne's URL specification, still early draft
and very much in flux
... we couldn't reference it
shepazu: wouldn't we just refer to what HTML does?
krit: still need to say that, at the moment we don't
shepazu: defining says more to me than just referring
... if you just mean we say 'we treat our stuff the same way
HTML treats their stuff'
... then that's fine
krit: that's why I would do
... I'm just saying we don't have anything at all in the spec
right now
shepazu: trivial to reference then
... I suggest we resolve by defining that we will refer to HTML
and only change if neccessary
... I don't think we should define security model or anything
... that seems way out of scope for SVG
RESOLUTION: Add definition to SVG 2 for the model of URLs,
referring to equivalent attribute values of HTML and only
change where neccessary
SVG hit testing
shepazu: I was wondering how SVG roots do hit testing
... we'll discuss next week
<shepazu> shepazu, talking more about SVG accessibility
Summary of Action Items
[NEW] ACTION: Dirk to talk to CSS WG about whether they want to
meet with SVG at first F2F of 2014 [recorded in
[27]http://www.w3.org/2013/09/19-svg-minutes.html#action01]
[NEW] ACTION: Doug to email SVG mailing lists and propose
shutting down public-svg [recorded in
[28]http://www.w3.org/2013/09/19-svg-minutes.html#action02]
[NEW] ACTION: Erik to submit test cases for
non-scaling-stroke/markers in patterns and mail the list
[recorded in
[29]http://www.w3.org/2013/09/19-svg-minutes.html#action03]
[NEW] ACTION: Rik to query Adobe for concerns relating to
non-scaling-stroke/markers in patterns and mail the list
[recorded in
[30]http://www.w3.org/2013/09/19-svg-minutes.html#action04]
[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.
Received on Thursday, 19 September 2013 21:34:54 UTC