- From: Cameron McCormack <cam@mcc.id.au>
- Date: Fri, 24 Apr 2015 07:38:01 +1000
- To: www-svg@w3.org
Minutes from today’s telcon are below. http://www.w3.org/2015/04/23-svg-minutes.html [1]W3C [1] http://www.w3.org/ - DRAFT - SVG Working Group Teleconference 23 Apr 2015 [2]Agenda [2] https://lists.w3.org/Archives/Public/www-svg/2015Apr/0044.html See also: [3]IRC log [3] http://www.w3.org/2015/04/23-svg-irc Attendees Present Dirk, Thomas, Cameron, Erik, Satoru, Tav, Nikos, Amelia, Brian, Rossen Regrets Chair Cameron Scribe Cameron Contents * [4]Topics 1. [5]June F2F 2. [6]Telcon day 3. [7]CORS in SVG 4. [8]Layout properties 5. [9]issues listed under "needing discussion" 6. [10]Paths chapter issues 7. [11]embedded content chapter * [12]Summary of Action Items __________________________________________________________ <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> [13]http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Linkoping_2015 [13] http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Linkoping_2015 <ed> [14]https://www.w3.org/2002/09/wbs/19480/Linkoping2015 [14] https://www.w3.org/2002/09/wbs/19480/Linkoping2015 Telcon day heycam: please fill in this form if you haven't already [15]http://doodle.com/8mfbynbh3rkr3myb [15] http://doodle.com/8mfbynbh3rkr3myb CORS in SVG [16]https://lists.w3.org/Archives/Public/www-svg/2015Mar/0139.h tml [16] 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 [17]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> [18]https://svgwg.org/svg2-draft/geometry.html#issue1 [18] 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> [19]https://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Chapter_Assess ment [19] 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> [20]https://svgwg.org/svg2-draft/paths.html#issue4 [20] 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 [21]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> [22]https://svgwg.org/svg2-draft/paths.html#issue6 [22] 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> [23]https://lists.w3.org/Archives/Public/www-svg/2015Feb/0033.h tml [23] 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> [24]https://svgwg.org/svg2-draft/embedded.html#issue2 [24] 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 [25]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]. [26]https://svgwg.org/svg2-draft/embedded.html#issue3 [26] 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 [27]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 -- Cameron McCormack ≝ http://mcc.id.au/
Received on Thursday, 23 April 2015 21:38:29 UTC