W3C home > Mailing lists > Public > www-svg@w3.org > October 2016

Minutes, 27 October 2016 SVG WG telcon

From: Nikos Andronikos <nikos.andronikos@gmail.com>
Date: Fri, 28 Oct 2016 13:59:13 +1100
Message-ID: <CAHd9+n=E-YU3Lz5bh92VvtovQRhinD3v7HUQb=X+fexCyvDdyQ@mail.gmail.com>
To: www-svg@w3.org


      [1] http://www.w3.org/

                               - DRAFT -

                    SVG Working Group Teleconference

27 Oct 2016


      [2] https://lists.w3.org/Archives/Public/www-svg/2016Oct/0044.html

   See also: [3]IRC log

      [3] http://www.w3.org/2016/10/27-svg-irc


          nikos, stakagi, Smailus, AmeliaBR, Tav, shepazu




     * [4]Topics
         1. [5]Daylight savings switch
         2. [6]Discussing issues
         3. [7]SVGz in SVG 2
         4. [8]SVG MIME Type (image/svg+xml) is misleading to
         5. [9]Other Github issues
         6. [10]Spec synthesis of viewBox/preserveAspectRatio for
            viewBox-less SVGs in image contexts
     * [11]Summary of Action Items
     * [12]Summary of Resolutions

   presen+ shepazu

   <scribe> scribenick: nikos

   <scribe> scribe: Nikos

Daylight savings switch

   nikos: Last daylight savings switch happens this week or next

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

   nikos: My proposal is to leave the time as is


     [13] 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

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

     [14] 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

     [15] 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
   ... 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

     [16] 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

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

     [17] 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


     [18] 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!

     [19] 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 ):

     [20] 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

     [21] 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

     [22] 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

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


     [23] 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
   ... there's a path forward to not allowing code but allowing

   AmeliaBR: honestly, not sure mime types ar the way forward,
   content security policy seems to be the way these things are
   ... 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

     [24] 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> [25]https://github.com/w3c/svgwg/issues/249

     [25] https://github.com/w3c/svgwg/issues/249

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

     [26] 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
   ... 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
   ... 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

   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> [27]http://output.jsbin.com/siqufa/

     [27] http://output.jsbin.com/siqufa/

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


     [28] 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:

     [29] 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

     [30] 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].

Summary of Action Items

   [NEW] ACTION: Amelia to move Issue #249 to WICG [recorded in
   [NEW] ACTION: Nikos to make example PR for updating SVG 2 CR
   [recorded in
   [NEW] ACTION: Nikos to move SVG MIME Type issue to WICG
   [recorded in
   [NEW] ACTION: Nikos to set up a section in changes for changes
   since CR [recorded in
   [NEW] ACTION: Thomas to file Github issue regarding spec
   clarification for svgz [recorded in
   [NEW] ACTION: Thomas to submit tests for svgz [recorded in

     [31] http://www.w3.org/2016/10/27-svg-minutes.html#action06
     [32] http://www.w3.org/2016/10/27-svg-minutes.html#action02
     [33] http://www.w3.org/2016/10/27-svg-minutes.html#action05
     [34] http://www.w3.org/2016/10/27-svg-minutes.html#action01
     [35] http://www.w3.org/2016/10/27-svg-minutes.html#action04
     [36] http://www.w3.org/2016/10/27-svg-minutes.html#action03

Summary of Resolutions

    1. [37]For next telcon, change booking so that the UTC time
       doesn't change

   [End of minutes]
Received on Friday, 28 October 2016 02:59:47 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:55:06 UTC