20:29:15 RRSAgent has joined #svg 20:29:15 logging to http://www.w3.org/2016/10/27-svg-irc 20:29:17 RRSAgent, make logs public 20:29:19 Zakim, this will be GA_SVGWG 20:29:19 ok, trackbot 20:29:20 Meeting: SVG Working Group Teleconference 20:29:20 Date: 27 October 2016 20:29:59 Chair: Nikos 20:30:14 Agenda: https://lists.w3.org/Archives/Public/www-svg/2016Oct/0044.html 20:31:52 shepazu_ has joined #svg 20:34:31 present+ nikos 20:34:36 presen+ shepazu 20:34:38 present+ stakagi 20:34:43 present+ Smailus 20:34:50 present+ AmeliaBR 20:36:01 present+ Tav 20:36:05 scribenick: nikos 20:36:08 scribe: Nikos 20:36:21 Topic: Daylight savings switch 20:37:08 nikos: Last daylight savings switch happens this week or next week 20:37:13 Tav: this week in Europe 20:37:22 ... next week in USA 20:38:13 nikos: My proposal is to leave the time as is 20:38:13 https://www.timeanddate.com/worldclock/meetingtime.html?iso=20161110&p1=240&p2=80&p3=195&p4=207 20:40:31 ... But it's technically pegged to US time, so we'll change the booking and it will remain the same relative to UTC 20:40:54 RESOLUTION: For next telcon, change booking so that the UTC time doesn't change 20:41:15 Topic: Discussing issues 20:41:56 nikos: Broader question of are we happy to keep calling in each week to talk about issues? Given that we are probably not going to be doing much editing 20:42:07 Tav: For now, yes 20:42:34 AmeliaBR: Did we ever work out a process for marking up substantive vs editorial changes? Since now we're CR we need to be careful about that. 20:43:29 nikos: We haven't come up with a process for that 20:43:43 shepazu_: the only substantive issues we should be making are those that revert things to previous wording 20:44:00 ... if there's wording in the spec that doesn't have two implementations 20:45:10 https://svgwg.org/svg2-draft/changes.html 20:45:19 nikos: What about say the SVGUnitTypes change. It's going to be different to SVG 1.1 no matter what, and browser people are working out what they want to do - we want to follow them 20:45:40 AmeliaBR: even in changes, we want to note what has changed since the last SVG 2 CR 20:45:53 ACTION: Nikos to set up a section in changes for changes since CR 20:45:53 Created ACTION-3858 - Set up a section in changes for changes since cr [on Nikos Andronikos - due 2016-11-03]. 20:47:08 AmeliaBR: we talked about doing everything as PR from now on in, so we could have someone review 20:47:24 ... that could be a matter of creating a branch on the repository 20:47:50 ... so that if it's just a fix typo, someone reviews and makes sure it's listed on the changes appendix 20:48:03 ... and if it's substantive they can decide if its in scope 20:48:46 nikos: I like the idea of doing it that way - forgotten we had talked about that 20:48:56 ACTION: Nikos to make example PR for updating SVG 2 CR 20:48:56 Created ACTION-3859 - Make example pr for updating svg 2 cr [on Nikos Andronikos - due 2016-11-03]. 20:50:24 Topic: SVGz in SVG 2 20:50:32 q+ 20:50:32 Smailus: assume that adding the clarifications won't be an issue? 20:50:48 ack plh 20:50:51 AmeliaBR: Think it's ok to make that choice ourselves. It's a question of how much it affects implementation performance 20:51:01 ... what were the results of your tests? 20:51:14 s/performance/conformance/ 20:51:16 Smailus: if I can get Mozilla and MS to support it using file protocol, that's my goal 20:51:36 ... not sure if it's that the spec was misunderstood that resulted in interop issues 20:52:01 Smailus: there was an old thread from many years ago, that said if it comes via http with the appropriate heading 20:52:10 shepazu: Could you describe the use case? 20:52:30 Smailus: At Boeing, we have tons of diagrams. Compressed ones will take an order of magnitude less space 20:52:35 ... we access them via the file url most often 20:52:57 ... we use svg as a graphics format, so we have lots of html based applications that will get things from the local drive 20:53:16 ... currently in IE11 and that version of Mozilla I referenced in the email, nothing displays 20:53:42 shepazu: I remember at the time there was a lot of controversy about whether there should be an svgz at all 20:53:52 ... typically a server will serve something compressed already 20:54:03 Smailus: that only shrinks it during transmission, not at rest 20:54:15 shepazu: have you tried it with .zip? 20:54:35 ... they may be able to deal with .zip files in a way that then is treated as svg 20:54:39 Smailus: no - same result 20:54:55 AmeliaBR: spec currently says that conforming viewers must support gzip encoded files 20:55:21 ... then it says that it must support compressed header and actual file header gzipped 20:55:28 ... problem is the file protocol isn't well defined 20:56:12 ... if support is defined in terms of http headers, and browser makes guesses about headers with file protocols based on extension, etc 20:56:47 shepazu: So the wording in the spec is that it's for http? Doesn't say anything about file? 20:57:00 Smailus: that might be the confusion - it talks about it, but gives detail in terms of http 20:57:24 shepazu: and does IE11 or FF work via http? 20:58:36 ... I'm just trying to clarify things, but the SVG WG doesn't deal with the file protocol, so we don't need to make a normative change to the spec but we can hopefully support your need 20:58:53 shepazu: I suspect they just weren't thinking about the file case and forgot it 20:59:01 ... spec says you have to support svgz 20:59:07 ... we could clarify in the spec that this applies to file 20:59:21 ... that should be taken up by whoever is in charge of the file api 21:00:06 ... in the meantime, I would make a test for svgz and svg with both with http and file 21:00:10 ... make them part of the test suite 21:00:26 nikos: how to contribute tests -> https://github.com/w3c/svgwg/wiki/Testing 21:00:38 shepazu: and I would file a bug on implementations that don't support this 21:01:14 Tav: that's a strange test 21:02:23 nikos: Most test harnesses run a web server for exactly this sort of test 21:04:47 nikos: Feel free to add an entry to the matrix so we can track differences in implementations 21:05:40 https://nikosandronikos.github.io/svg2-info/svg2-feature-support/ 21:06:10 shepazu: Please make sure you clearly outline Boeing's use case when filing bugs 21:07:28 ... I'd further suggest, making an informative note which doesn't change conformance criteria, but clarifies that this should be for file as well as http, https, etc 21:07:29 PS, I finally found an example of SVGZ online with a server that sends the proper headers: w3.org! https://www.w3.org/2004/Talks/1211-Twente-IH/18.svgz 21:07:48 Tav: Batik also supports reading from file svgz 21:08:09 AmeliaBR: I just ran a quick test - if the http headers are correct, then Edge and FF have no problem with svgz coming from a web server 21:10:37 Alternative file (not served with correct HTTP headers ): https://s3-us-west-2.amazonaws.com/s.cdpn.io/91525/car.svgz 21:12:21 nikos: Safari doesn't seem to work with file protocol 21:13:21 AmeliaBR: think we can change first bullet point in the spec to clarify that it applies to 'data streams and files' 21:13:31 ... and include a mention of svgz in particular 21:13:44 ... and break it into a separate requirement for implementations that support http 21:13:59 shepazu: the least change we make, I'd be more comfortable with 21:14:09 ... see where you're coming from, but I'd prefer a note 21:14:43 ACTION: Thomas to submit tests for svgz 21:14:44 Created ACTION-3860 - Submit tests for svgz [on Thomas Smailus - due 2016-11-03]. 21:14:53 ACTION: Thomas to file Github issue regarding spec clarification for svgz 21:14:54 Created ACTION-3861 - File github issue regarding spec clarification for svgz [on Thomas Smailus - due 2016-11-03]. 21:15:13 Topic: SVG MIME Type (image/svg+xml) is misleading to developers 21:15:16 https://github.com/w3c/svgwg/issues/266 21:15:22 nikos: Picked this issue for two reasons 21:15:58 ... first, it sounds like a sensible suggestion, but it's also a good thing to suggest is taken to WICG 21:16:18 AmeliaBR: Yep, I can't see changing behaviour of existing mime type as something that will get support 21:16:32 ... but adding new mime types with one being restricted and one not is something that could happen 21:16:51 ... it's not an svg 2 issue - needs more discussion from people who know more about the mime type handling 21:18:00 shepazu: Someone emailed me a while ago and pointed me to this issue. I recommended that he raise it as a Github issue 21:19:01 nikos: I totally agree this should be a Github issue in our repo - but we should forward it to WICG and defer the issue until it's resolved there 21:19:15 shepazu: I actually like the idea of forking it to two mime types 21:19:28 ... there's a path forward to not allowing code but allowing interactivity 21:19:59 AmeliaBR: honestly, not sure mime types ar the way forward, content security policy seems to be the way these things are done 21:20:09 ... it's worth discussing, but not by us 21:20:46 shepazu: I'm fine with us deferring this to wicg 21:21:16 ACTION: Nikos to move SVG MIME Type issue to WICG 21:21:16 Created ACTION-3862 - Move svg mime type issue to wicg [on Nikos Andronikos - due 2016-11-03]. 21:21:31 Topic: Other Github issues 21:21:41 AmeliaBR: I can make the change for #290 when we have the changes appendix organised 21:21:48 https://github.com/w3c/svgwg/issues/249 21:21:54 https://github.com/w3c/svgwg/issues/289 21:22:19 Topic: Spec synthesis of viewBox/preserveAspectRatio for viewBox-less SVGs in image contexts 21:22:39 AmeliaBR: these are about how you synthesize viewBox, etc when SVG is used as image types and in other contexts such as Canvas 21:22:48 ... the issue is that there is SVG scaling, then normal image scaling 21:23:02 ... you can take 10x10px png and draw it full screen and browser will scale it 21:23:43 ... when you have an svg element it's got it's intrinsic width/height and weird edge case questions about what you do - whether you should scale based on intrinsic or scale size 21:23:53 ... and all sorts of weird little details that aren't well defined 21:23:57 ... so where should they be defined? 21:24:09 ... is it something that needs to be in SVG 2? Or should we be resurrecting svg integration 21:24:47 ... think no one has strong opinions on which is right, and we don't have consistency 21:25:03 Tav: Didn't the CSS WG deal with this at one of the joint meetings? 21:25:14 AmeliaBR: there was some clarification that did happen that went into SVG 2 21:25:28 q+ 21:25:37 ack shepazu_ 21:25:41 ... about how intrinsic aspect ratio and intrinsic size are interpreted in SVG? 21:25:56 Tav: Do you have a test? 21:26:13 http://output.jsbin.com/siqufa/ 21:26:55 AmeliaBR: For Canvas, it should be part of Canvas how that works 21:27:06 ... the reason much of this is not defined is because it falls between the authority of differnet specs 21:27:17 https://jakearchibald.com/2016/svg-media-queries/ 21:27:24 shepazu: think given our status we should not try to solve this in svg 2 but in some css or html spec 21:28:05 AmeliaBR: Some of it CSS, some is HTMl, some is pure SVG 21:28:27 shepazu: I'm thinking this is another of those issues that should be defined in SVG, but we've run out of time to handle in SVG 21:28:38 A WHATWG HTML bug that Jake Archibald filed: https://github.com/whatwg/html/issues/1880 21:28:43 ... so putting it into another group is the only way it's going to happen realistically 21:29:16 shepazu: I would suggest css 21:29:50 AmeliaBR: think it's a case of getting implementers together and getting agreement on what should happen, and then work out where it should be specced 21:30:23 shepazu: I don't see an integration spec as a path forward 21:30:51 nikos: Sounds like we need to bring it up wherever we can get the most input, so CSS sounds like a good choice 21:31:02 AmeliaBR: we can bring it up in the scope of media queries 21:31:39 nikos: Could this be raised with TAG? Since it does sound like an architecture issue 21:31:50 shepazu: I think WICG. They're the most cross technology space 21:31:58 nikos: That was my other option 21:32:07 AmeliaBR: makes sense as a place to work out what we want the spec to be 21:32:29 ... then make issues and PRs on particular specs 21:32:41 nikos: Makes sense to me - that will get most eyes onto it? 21:32:57 ... Are you ok to do that AmeliaBR? 21:33:09 AmeliaBR: Yes, I need to get all the issues together 21:33:44 ACTION: Amelia to move Issue #249 to WICG 21:33:44 Created ACTION-3863 - Move issue #249 to wicg [on Amelia Bellamy-Royds - due 2016-11-03]. 21:33:50 RRSAgent, make minutes 21:33:50 I have made the request to generate http://www.w3.org/2016/10/27-svg-minutes.html nikos 21:34:43 chaals1 has joined #svg 21:37:18 chaals2 has joined #svg