SVG Working Group Teleconference -- 23 Apr 2015

<trackbot> Date: 23 April 2015

<stakagi> i also

<stakagi> yes

<scribe> Scribe: Cameron

June F2F

ed: I'll be leaving Opera soon
... this won't have any effect on the June F2F
... so it'll take place as planned
... the details will be worked out; we'll still host
... I will be taking part
... I won't be representing Opera at the time
... I encourage everyone to register if you haven't already

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

<ed> https://www.w3.org/2002/09/wbs/19480/Linkoping2015

Telcon day

heycam: please fill in this form if you haven't already

http://doodle.com/8mfbynbh3rkr3myb

CORS in SVG

https://lists.w3.org/Archives/Public/www-svg/2015Mar/0139.html

ed: I was assigned a bug on someone requesting to be able to use the <use> element for referencing cross-origin resources
... and I looked at that, and checked how hard it would be to implement
... and did some preliminary work in Blink on that
... I'd like to propose that we add the crossorigin="" attribute on every element that loads external resources
... and enable CORS in SVG just like it is in HTML
... this would make it possible to reference external things in the <use> element if you have the crossorigin="" attribute on it

krit: feImage already has the crossorigin="" attribute as well

AmeliaBR: it allows cross origin references if the external file has the right HTTP headers, is that right?
... I'm not certain what the current state is. is this restating the default or adding a new option?

ed: yes you do need in some cases to add the attribuet and to have the corresponding header sent for the external resources
... for <use> I think it's a bit special, as no browser allows you to fetch cross origin references
... otoh <img> allows it by default
... so the defaults are different per element
... I don't think we want to allow cross origin <use> by default
... so we would require <use crossorigin=""> and for the HTTP header there

AmeliaBR: so the server and the author both have to opt in?

ed: yes
... script and image are two, feImage, use
... and for foreignObject we haven't decided if it has href, but if it does, then it would need the attribute too

AmeliaBR: what about other elements adopting from HTML like iframe?

ed: yes, the attribute is already there
... we shouldn't need to change anything there
... but for audio/video it already has the crossorigin attribute

heycam: a little wary of this with use / resource documents, but at first glance it seems ok

AmeliaBR: if you <use> an element, there are complications like defining whether script runs etc.

heycam: what's the next step?

ed: the attribute is added to some of these elements in Blink already, and it works, and I think we should make sure these work in SVG just like in HTML
... I did write up a few tests, but it's difficult to publish as you need the server side changes as well
... I could put some examples on my personal server
... so the next step should be adding text to the spec if we agree it's a good idea, and I'd be happy to do that

RESOLUTION: We'll add crossorigin attribute on script, image, use.

<scribe> ACTION: Erik to add spec text for crossorigin attribute on script, image, use. [recorded in http://www.w3.org/2015/04/23-svg-minutes.html#action01]

<trackbot> Created ACTION-3781 - Add spec text for crossorigin attribute on script, image, use. [on Erik Dahlström - due 2015-04-30].

Layout properties

krit: I won't have time in the next 2 months to look at this

ed: in Blink I implemented these, and enabled in Canary builds
... I didn't run in to any really troublesome issues
... there were a few things with nested SVG elements, but they were just Blink specific issues
... I think this chapter is fine

AmeliaBR: there is one issue in the spec that relates to how these apply to text elements; how have you dealt with that?

<AmeliaBR> https://svgwg.org/svg2-draft/geometry.html#issue1

krit: in WebKit I just made x/y properties not apply to text

ed: I did the same thing

AmeliaBR: I was looking forward to those being properties for text, but I can understand that it might not be the highest priority

krit: in Sydney we discussed this. I think it's safer for the moment not to treat them as presentation attributes for the moment on text.

AmeliaBR: my concern is that we don't want to get into any corners where that extension can't happen in the future
... don't want to make a multi value syntax break if we accept that in the future, though CSS error handling rules would cover that

krit: would need to check the F2F minutes
... I will check and bring it back up next week
... if we can reassign this chapter to someone else that'd be good

Rossen: I'll take the chapter for now
... there's only that one issue in the chapter at the moment

AmeliaBR: there is also the issue about width/height we discussed previously

Rossen: I believe I already have an action for that on me

<Rossen> https://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Chapter_Assessment

issues listed under "needing discussion"

Rossen: issue 8 in rendering.html

nikos: this was done, just haven't updated the wiki

Paths chapter issues

<Rossen> https://svgwg.org/svg2-draft/paths.html#issue4

Rossen: the issue is talking about limitations of line limits
... and whether or not this is even an issue
... anyone here produce tools? :)

Tav: we don't limit ourselves to 255 characters

AmeliaBR: the spec says there things for improving readability, but as for limitations I don't know

Rossen: currently we have normative text that says no line should exceed 255 characters
... and we are in 2015, so you would hope those limitations are lifted by now

<ed> I agree

krit: I didn't know we have this limitation. I know that illustrator does limit its output.
... there were some issues with ASV a long time ago

Rossen: one way to solve it is to just drop the restrictions

nikos: surely there is plenty of content that violates this already

Rossen: so let's resolve on removing that part of the sentence and then move on

AmeliaBR: keep the first bit about being able to break into lines?

krit: yes but we don't need normative text for that

RESOLUTION: Remove the requirement to limit line lengths to 255 characters.

<scribe> ACTION: Rossen to remove the 255 character line limit. [recorded in http://www.w3.org/2015/04/23-svg-minutes.html#action02]

<trackbot> Created ACTION-3782 - Remove the 255 character line limit. [on Rossen Atanassov - due 2015-04-30].

<Rossen> https://svgwg.org/svg2-draft/paths.html#issue6

Rossen: next is issue 6
... this is about allowing tension parameters to be specified in the catmull-rom splines

krit: didn't we resolve to put that in a separate spec about paths?

<AmeliaBR> https://lists.w3.org/Archives/Public/www-svg/2015Feb/0033.html

AmeliaBR: as it is in the spec at the moment, it's not implementable

<AmeliaBR> ACTION-3745 - Move catmull-rom to svg path module [on Cameron McCormack - due 2015-02-20]

heycam: I'll get on that action
... so let's not resolve the tension issue right now

AmeliaBR: I think the rest of the issues in the path chapter do all relate to catmull-rom

embedded content chapter

<Rossen> https://svgwg.org/svg2-draft/embedded.html#issue2

Rossen: there are three issues here

krit: the issue is asking about pAR in image, isn't that already supported?

AmeliaBR: it's the other ones like video, iframe, etc.
... but there is the object-fit property in CSS, that would duplicate / extend pAR

krit: I don't think we should add pAR to video, iframe

<ed> I agree with krit here

heycam: in light of our plan to use the HTML elements rather than import them into SVG, we shouldn't be adding pAR on them anyway

AmeliaBR: I like object-fit more than pAR anyway

birtles: we did discuss the differences though

Tav: would be odd for authors that image differs but iframe/video doesn't

heycam: we already have had this situation with SVG image differenting from HTML for ages

krit: but it is image vs HTML's img

heycam: I think someone needs to write a concrete proposal for how we're doing the HTML element integration here

<scribe> ACTION: Cameron to write up concrete proposal for handling embedded content HTML elements in SVG [recorded in http://www.w3.org/2015/04/23-svg-minutes.html#action03]

<trackbot> Created ACTION-3783 - Write up concrete proposal for handling embedded content html elements in svg [on Cameron McCormack - due 2015-04-30].

https://svgwg.org/svg2-draft/embedded.html#issue3

AmeliaBR: this is specific to image, and referencing of other SVG images

heycam: what's the general way that clip and clip-path interact?

krit: clip applies to viewport-creating elements

heycam: what happens when you use both on a viewport-creating element? they intersect?

krit: yes exactly

AmeliaBR: to address the issue about why clip being overridden makes sense, clip applies to the element region, while clip-path applies in the SVG coordinate system

krit: why would clip and clip-path take different coordinate systems?

AmeliaBR: I have no idea why you'd use clip on a root element anyway, but it applies to the region you're putting the SVG in

heycam: it'd be great to have some tests here to see whether clip actually works here

krit: clip doesn't do anything in WebKit or Blink for SVG elements

Rossen: it's currently specified to apply to viewport-establishing elements

krit: yes, but in WebKit we don't

<scribe> ACTION: Amelia to produce test cases for clip regarding embedded.html#issue3 [recorded in http://www.w3.org/2015/04/23-svg-minutes.html#action04]

<trackbot> Created ACTION-3784 - Produce test cases for clip regarding embedded.html#issue3 [on Amelia Bellamy-Royds - due 2015-04-30].

AmeliaBR: we should discourage the use of clip anyway

RRSAgent: make minutes

- DRAFT -

SVG Working Group Teleconference

23 Apr 2015

Attendees

Contents