SVG Working Group Teleconference -- 25 Oct 2012

<trackbot> Date: 25 October 2012

<krit> give me a second

<scribe> scribenick: nikos

Percentage values for 'transform' on pattern, linear/radialGradient,

clipPath

krit: what does % on transform functions mean?
... is it relative to the bounding box of the object, i.e. a rect
... another possibility is user space, or the viewport
... so the percentage would be a percentage of the dimension of the viewport
... if you compare with transforms, it's relative to the bounding box
... I would like to do the same with resources, if you have clippath with a transform, it's relative to the bounding box

nikos: I agree with you

ed: It makes more sense to have it that way

Tav: for somethings, don't we allow the user to select?

krit: there is no way to select for transform
... it is also conformant with how we have done it in the psat

nikos: what about rotation?

krit: we don't accept percentage for rotate

Tav: using the bounding box is easier in the code
... just to be clear, we are talking about bounding box without markers or stroke?

krit: the object bounding box
... it does not include stroke or markers

resolution: percentage values on transform functions will be relative to the object bounding box of the referencing element

spreadMethod on gradients

<Tav> http://tavmjong.free.fr/SVG/RADIALGRAD/index.html

Tav: I started looking at the changes to gradients, I had a question
... what do we do for the different spread methods?
... what confused me, was the second figure (on that page)

krit: the big white circle should be filled with pad
... can we agree that spread methods are still useful?

Tav: well it would be inconsistent if you didn't have them

krit: what I really miss, is having spreadMethod none

Tav: I thought about that and was going to suggest it until I realised Canvas always does padding

krit: for gradients, I want it to be compatible with Canvas, doesn't mean we can't do more

Tav: I'm not sure how useful none is

ed: it would mean you wouldn't fill the shape potentially, I'm not sure how useful it is either

krit: the only graphics library I know that doesn't support none is core graphics, I think it could be useful

Tav: if you look at fig 5, I wanted to check if it's rendered correctly?

krit: it is

Tav: the only difference between SVG and Canvas, is what happens when the start and end circle are touching

krit: there shouldn't be a difference
... you mean fully overlapping right?

Tav: no I mean touching one point (fig 7)
... Canvas does not fill the entire plane, SVG does

krit: I'm not sure about that
... if you think about infinite big circles, the right side can never be filled

Tav: if you look at the SVG spec, it says you average the colours and fill the right part with the averaged value

krit: It should do exactly as you have drawn in fig7

Tav: it would be different if you had spreadMethod=reflect or repeat

ed: the spreadMethod is just how to repeat the colours, not the shape

krit: correct

<Tav> https://svgwg.org/svg2-draft/pservers.html#RadialGradientNotes

nikos: is there any difference if the focal circle touches the outer circle, or if the focal circle touches the outer circle?

krit: there should be no difference
... in Canvas the area to the right should be transparent
... mathematically it is transparent, but it could be specced to be filled
... do we want consistency?

ed: for CSS gradient the same problem applies, I think Tab was saying that the CSS group preferred the averaging
... we have discussed this before

krit: it's a question of whether we want to be compatible with CSS gradients or with HTML Canvas

ed: in general I find it nice if the paint servers fully fill the given shape

nikos: since we are allowing CSS gradient paint servers, why not spec the opposite in SVG, then you can select one or the other?

krit: for Webkit, I'm not sure if it would be implemented
... I'm not sure if this edge case is even implemented for CSS gradients

Tav: what is the status of the CSS spec? could they change it?

<scribe> ACTION: Krit to craft some test cases to compare the implementations of gradients in CSS/Canvas/SVG [recorded in http://www.w3.org/2012/10/25-svg-minutes.html#action01]

<trackbot> Sorry, couldn't find Krit. You can review and register nicknames at <http://www.w3.org/Graphics/SVG/WG/track/users>.

<scribe> ACTION: krit to craft some test cases to compare the implementations of gradients in CSS/Canvas/SVG [recorded in http://www.w3.org/2012/10/25-svg-minutes.html#action02]

<trackbot> Sorry, couldn't find krit. You can review and register nicknames at <http://www.w3.org/Graphics/SVG/WG/track/users>.

<scribe> ACTION: dirk to craft some test cases to compare the implementations of gradients in CSS/Canvas/SVG [recorded in http://www.w3.org/2012/10/25-svg-minutes.html#action03]

<trackbot> Created ACTION-3394 - Craft some test cases to compare the implementations of gradients in CSS/Canvas/SVG [on Dirk Schulze - due 2012-11-01].

<ed> http://dev.w3.org/csswg/css3-images/#radial-gradients

ed: look at 4.2.3 for degenerate cases

krit: in this case, CSS gradients don't have focal radius
... if they have a radius of zero, what do they paint?
... I don't think this is the use case we are looking for

<krit> http://dev.w3.org/csswg/css4-images/#conic-gradients

krit: CSS gradients doesn't matter, because you don't specify the bounds of the outer circle
... it's not specified in CSS 4 either

ed: so for existing content, it would mean that you would see through some parts of the shape?

krit: the problem is webkit and firefox always pushed the focal point inside the circle
... I think Opera is doing something similar

ed: I'm leaning towards aligning with Canvas, but I would like to see some testcases

krit: We could ask authors what they want? Maybe discuss on the mailing list

ed: do we want to wait for the test cases? or resolve on one of the options now?

Tav: I'd say wait

Publication schedule for SVG2

ed: I'm not sure if we decided when the next publication would happen
... but it would be good to have a date to work against
... so looking at the table of the current plan, we should have LC working draft in January

krit: it's a tough schedule

ed: that's what I'm thinking, I don't think we can take what we have now and go to LC

krit: we should have a F2F before LC
... so that would be February
... I would like to have a second WD before we go to LC

<richardschwerdtfeger> rich: I have some travel in Februaary

ed: so what dates would be realistic for a second working draft?

krit: after our F2F seems to be reasonable
... I think there's more to discuss, i.e. security concerns from Mozilla
... can we resolve that we won't publish in January? do we need to resolve on that?

ed: I think it would be good to have a resolution to point to

rich: was someone doing tab-index? what's the status of that?

krit: the question is how much we need to specify in SVG? maybe we can rely on the definition in HTML5

<ed> ACTION-3341?

<trackbot> ACTION-3341 -- Doug Schepers to is going to look into conflicts between the model of tab index and navigation -- due 2012-08-30 -- OPEN

<trackbot> http://www.w3.org/Graphics/SVG/WG/track/actions/3341

rich: I'm certainly going to use what we wrote up for ARIA in HTML5 because the wording was good

resolution: goal for next SVG 2 working draft is February - after F2F

<scribe> ACTION: ed to update SVG 2 publication schedule in wiki to note that the goal for next SVG 2 working draft is February, after the F2F [recorded in http://www.w3.org/2012/10/25-svg-minutes.html#action04]

<trackbot> Could not create new action (unparseable data in server response: 'ascii' codec can't decode byte 0xc3 in position 7: ordinal not in range(128)) - please contact sysreq with the details of what happened.

<scribe> ACTION: Erik to update SVG 2 publication schedule in wiki to note that the goal for next SVG 2 working draft is February, after the F2F [recorded in http://www.w3.org/2012/10/25-svg-minutes.html#action07]

<scribe> ACTION:ed to update SVG 2 publication schedule in wiki to note that the goal for next SVG 2 working draft is February, after the F2F [recorded in http://www.w3.org/2012/10/25-svg-minutes.html#action08]

ed: so that brings last call dates forward a bit, not sure by how much
... we'll have to adjust the dates to be later

rich: do we know when we are going to go to REC?

krit: end of next year (2013) for CR stage

rich: the reason I'm asking, is I'm working with ePub people, and they will want to know when the accessibility stuff will show up

<ed> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Commitments

ed: so looking at the commitments page, there are plenty of things that haven't been put in the spec
... all the ones that don't have commitment from anyone, are up for grabs if anyone is interested

<krit> http://www.w3.org/TR/filter-effects/

Filter Effects

<krit> http://www.w3.org/TR/filter-effects/

krit: filter effects WPD has been published
... can I remove relaxNG from the spec?
... do we need it ?
... if it's useful, who will write it ?

ed: we had a starting point from a previous draft of SVG 2
... so there are some files that may be ready
... I'm not really sure what state they are in

krit: how does relaxNG work with HTML5 and validating there?
... I would rather remove it, it's adding complexity that is not needed
... currently, we just have a note in the spec that we want to provide it

ed: I would be fine removing it
... if we don't have anyone who wants to do the work, we can remove it and if someone wants to do it later they can

krit: sounds good

- DRAFT -

SVG Working Group Teleconference

25 Oct 2012

Attendees

Contents

Percentage values for 'transform' on pattern, linear/radialGradient,

spreadMethod on gradients

Publication schedule for SVG2

Filter Effects

Summary of Action Items

Scribe.perl diagnostic output