SVG Working Group Teleconference -- 19 Sep 2013

<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> 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

https://www.w3.org/2002/09/wbs/19480/SVGF2FPlanning2014/results

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 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 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> 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

http://jsfiddle.net/TfWqX/

<ed> 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 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 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> 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> 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

- DRAFT -

SVG Working Group Teleconference

19 Sep 2013

Attendees

Contents