- 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