presen+ shepazu

<scribe> scribenick: nikos

<scribe> scribe: Nikos

Daylight savings switch

nikos: Last daylight savings switch happens this week or next week

Tav: this week in Europe
... next week in USA

nikos: My proposal is to leave the time as is

https://www.timeanddate.com/worldclock/meetingtime.html?iso=20161110&p1=240&p2=80&p3=195&p4=207

scribe: But it's technically pegged to US time, so we'll change the booking and it will remain the same relative to UTC

RESOLUTION: For next telcon, change booking so that the UTC time doesn't change

Discussing issues

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

Tav: For now, yes

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.

nikos: We haven't come up with a process for that

shepazu_: the only substantive issues we should be making are those that revert things to previous wording
... if there's wording in the spec that doesn't have two implementations

<AmeliaBR> https://svgwg.org/svg2-draft/changes.html

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

AmeliaBR: even in changes, we want to note what has changed since the last SVG 2 CR

<scribe> ACTION: Nikos to set up a section in changes for changes since CR [recorded in http://www.w3.org/2016/10/27-svg-minutes.html#action01]

<trackbot> Created ACTION-3858 - Set up a section in changes for changes since cr [on Nikos Andronikos - due 2016-11-03].

AmeliaBR: we talked about doing everything as PR from now on in, so we could have someone review
... that could be a matter of creating a branch on the repository
... so that if it's just a fix typo, someone reviews and makes sure it's listed on the changes appendix
... and if it's substantive they can decide if its in scope

nikos: I like the idea of doing it that way - forgotten we had talked about that

<scribe> ACTION: Nikos to make example PR for updating SVG 2 CR [recorded in http://www.w3.org/2016/10/27-svg-minutes.html#action02]

<trackbot> Created ACTION-3859 - Make example pr for updating svg 2 cr [on Nikos Andronikos - due 2016-11-03].

SVGz in SVG 2

Smailus: assume that adding the clarifications won't be an issue?

AmeliaBR: Think it's ok to make that choice ourselves. It's a question of how much it affects implementation conformance
... what were the results of your tests?

Smailus: if I can get Mozilla and MS to support it using file protocol, that's my goal
... not sure if it's that the spec was misunderstood that resulted in interop issues
... there was an old thread from many years ago, that said if it comes via http with the appropriate heading

shepazu: Could you describe the use case?

Smailus: At Boeing, we have tons of diagrams. Compressed ones will take an order of magnitude less space
... we access them via the file url most often
... we use svg as a graphics format, so we have lots of html based applications that will get things from the local drive
... currently in IE11 and that version of Mozilla I referenced in the email, nothing displays

shepazu: I remember at the time there was a lot of controversy about whether there should be an svgz at all
... typically a server will serve something compressed already

Smailus: that only shrinks it during transmission, not at rest

shepazu: have you tried it with .zip?
... they may be able to deal with .zip files in a way that then is treated as svg

Smailus: no - same result

AmeliaBR: spec currently says that conforming viewers must support gzip encoded files
... then it says that it must support compressed header and actual file header gzipped
... problem is the file protocol isn't well defined
... if support is defined in terms of http headers, and browser makes guesses about headers with file protocols based on extension, etc

shepazu: So the wording in the spec is that it's for http? Doesn't say anything about file?

Smailus: that might be the confusion - it talks about it, but gives detail in terms of http

shepazu: and does IE11 or FF work via http?
... 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
... I suspect they just weren't thinking about the file case and forgot it
... spec says you have to support svgz
... we could clarify in the spec that this applies to file
... that should be taken up by whoever is in charge of the file api
... in the meantime, I would make a test for svgz and svg with both with http and file
... make them part of the test suite

nikos: how to contribute tests -> https://github.com/w3c/svgwg/wiki/Testing

shepazu: and I would file a bug on implementations that don't support this

Tav: that's a strange test

nikos: Most test harnesses run a web server for exactly this sort of test
... Feel free to add an entry to the matrix so we can track differences in implementations

https://nikosandronikos.github.io/svg2-info/svg2-feature-support/

shepazu: Please make sure you clearly outline Boeing's use case when filing bugs
... 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

<AmeliaBR> 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

Tav: Batik also supports reading from file svgz

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

<AmeliaBR> Alternative file (not served with correct HTTP headers ): https://s3-us-west-2.amazonaws.com/s.cdpn.io/91525/car.svgz

nikos: Safari doesn't seem to work with file protocol

AmeliaBR: think we can change first bullet point in the spec to clarify that it applies to 'data streams and files'
... and include a mention of svgz in particular
... and break it into a separate requirement for implementations that support http

shepazu: the least change we make, I'd be more comfortable with
... see where you're coming from, but I'd prefer a note

<scribe> ACTION: Thomas to submit tests for svgz [recorded in http://www.w3.org/2016/10/27-svg-minutes.html#action03]

<trackbot> Created ACTION-3860 - Submit tests for svgz [on Thomas Smailus - due 2016-11-03].

<scribe> ACTION: Thomas to file Github issue regarding spec clarification for svgz [recorded in http://www.w3.org/2016/10/27-svg-minutes.html#action04]

<trackbot> Created ACTION-3861 - File github issue regarding spec clarification for svgz [on Thomas Smailus - due 2016-11-03].

SVG MIME Type (image/svg+xml) is misleading to developers

https://github.com/w3c/svgwg/issues/266

nikos: Picked this issue for two reasons
... first, it sounds like a sensible suggestion, but it's also a good thing to suggest is taken to WICG

AmeliaBR: Yep, I can't see changing behaviour of existing mime type as something that will get support
... but adding new mime types with one being restricted and one not is something that could happen
... it's not an svg 2 issue - needs more discussion from people who know more about the mime type handling

shepazu: Someone emailed me a while ago and pointed me to this issue. I recommended that he raise it as a Github issue

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

shepazu: I actually like the idea of forking it to two mime types
... there's a path forward to not allowing code but allowing interactivity

AmeliaBR: honestly, not sure mime types ar the way forward, content security policy seems to be the way these things are done
... it's worth discussing, but not by us

shepazu: I'm fine with us deferring this to wicg

<scribe> ACTION: Nikos to move SVG MIME Type issue to WICG [recorded in http://www.w3.org/2016/10/27-svg-minutes.html#action05]

<trackbot> Created ACTION-3862 - Move svg mime type issue to wicg [on Nikos Andronikos - due 2016-11-03].

Other Github issues

AmeliaBR: I can make the change for #290 when we have the changes appendix organised

<AmeliaBR> https://github.com/w3c/svgwg/issues/249

<AmeliaBR> https://github.com/w3c/svgwg/issues/289

Spec synthesis of viewBox/preserveAspectRatio for viewBox-less SVGs in image contexts

AmeliaBR: these are about how you synthesize viewBox, etc when SVG is used as image types and in other contexts such as Canvas
... the issue is that there is SVG scaling, then normal image scaling
... you can take 10x10px png and draw it full screen and browser will scale it
... 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
... and all sorts of weird little details that aren't well defined
... so where should they be defined?
... is it something that needs to be in SVG 2? Or should we be resurrecting svg integration
... think no one has strong opinions on which is right, and we don't have consistency

Tav: Didn't the CSS WG deal with this at one of the joint meetings?

AmeliaBR: there was some clarification that did happen that went into SVG 2
... about how intrinsic aspect ratio and intrinsic size are interpreted in SVG?

Tav: Do you have a test?

<AmeliaBR> http://output.jsbin.com/siqufa/

AmeliaBR: For Canvas, it should be part of Canvas how that works
... the reason much of this is not defined is because it falls between the authority of differnet specs

<AmeliaBR> https://jakearchibald.com/2016/svg-media-queries/

shepazu: think given our status we should not try to solve this in svg 2 but in some css or html spec

AmeliaBR: Some of it CSS, some is HTMl, some is pure SVG

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

<AmeliaBR> A WHATWG HTML bug that Jake Archibald filed: https://github.com/whatwg/html/issues/1880

shepazu: so putting it into another group is the only way it's going to happen realistically
... I would suggest css

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

shepazu: I don't see an integration spec as a path forward

nikos: Sounds like we need to bring it up wherever we can get the most input, so CSS sounds like a good choice

AmeliaBR: we can bring it up in the scope of media queries

nikos: Could this be raised with TAG? Since it does sound like an architecture issue

shepazu: I think WICG. They're the most cross technology space

nikos: That was my other option

AmeliaBR: makes sense as a place to work out what we want the spec to be
... then make issues and PRs on particular specs

nikos: Makes sense to me - that will get most eyes onto it?
... Are you ok to do that AmeliaBR?

AmeliaBR: Yes, I need to get all the issues together

<scribe> ACTION: Amelia to move Issue #249 to WICG [recorded in http://www.w3.org/2016/10/27-svg-minutes.html#action06]

<trackbot> Created ACTION-3863 - Move issue #249 to wicg [on Amelia Bellamy-Royds - due 2016-11-03].

This is scribe.perl Revision: 1.148  of Date: 2016/10/11 12:55:14  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/performance/conformance/
Found ScribeNick: nikos
Found Scribe: Nikos
Inferring ScribeNick: nikos
Present: nikos stakagi Smailus AmeliaBR Tav
Agenda: https://lists.w3.org/Archives/Public/www-svg/2016Oct/0044.html
Found Date: 27 Oct 2016
Guessing minutes URL: http://www.w3.org/2016/10/27-svg-minutes.html
People with action items: amelia nikos thomas