minutes, 23 April 2015 SVG WG telcon

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