- From: Nikos Andronikos <nikos.andronikos@gmail.com>
- Date: Fri, 28 Oct 2016 13:59:13 +1100
- To: www-svg@w3.org
- Message-ID: <CAHd9+n=E-YU3Lz5bh92VvtovQRhinD3v7HUQb=X+fexCyvDdyQ@mail.gmail.com>
https://www.w3.org/2016/10/27-svg-minutes.html
[1]W3C
[1] http://www.w3.org/
- DRAFT -
SVG Working Group Teleconference
27 Oct 2016
[2]Agenda
[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
Attendees
Present
nikos, stakagi, Smailus, AmeliaBR, Tav, shepazu
Regrets
Chair
Nikos
Scribe
Nikos
Contents
* [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
developers
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
week
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
[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
implementations
<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]
[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
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
[16]http://www.w3.org/2016/10/27-svg-minutes.html#action02]
[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
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 ->
[17]https://github.com/w3c/svgwg/wiki/Testing
[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-su
pport/
[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
[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
[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]
[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]
[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
2016-11-03].
SVG MIME Type (image/svg+xml) is misleading to developers
[23]https://github.com/w3c/svgwg/issues/266
[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
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
[24]http://www.w3.org/2016/10/27-svg-minutes.html#action05]
[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
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> [27]http://output.jsbin.com/siqufa/
[27] 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>
[28]https://jakearchibald.com/2016/svg-media-queries/
[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
[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]
[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
[31]http://www.w3.org/2016/10/27-svg-minutes.html#action06]
[NEW] ACTION: Nikos to make example PR for updating SVG 2 CR
[recorded in
[32]http://www.w3.org/2016/10/27-svg-minutes.html#action02]
[NEW] ACTION: Nikos to move SVG MIME Type issue to WICG
[recorded in
[33]http://www.w3.org/2016/10/27-svg-minutes.html#action05]
[NEW] ACTION: Nikos to set up a section in changes for changes
since CR [recorded in
[34]http://www.w3.org/2016/10/27-svg-minutes.html#action01]
[NEW] ACTION: Thomas to file Github issue regarding spec
clarification for svgz [recorded in
[35]http://www.w3.org/2016/10/27-svg-minutes.html#action04]
[NEW] ACTION: Thomas to submit tests for svgz [recorded in
[36]http://www.w3.org/2016/10/27-svg-minutes.html#action03]
[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