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

Minutes, 12th May 2016 telcon

From: Nikos Andronikos <Nikos.Andronikos@cisra.canon.com.au>
Date: Fri, 13 May 2016 00:06:00 +0000
To: www-svg <www-svg@w3.org>
Message-ID: <DBF0CE1A-D2AC-484A-AAFE-CC615C905738@cisra.canon.com.au>
Hi all,

Minutes from today’s telcon available at:

And as text,


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

                               - DRAFT -

                    SVG Working Group Teleconference

12 May 2016


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

   See also: [3]IRC log

      [3] http://www.w3.org/2016/05/12-svg-irc


          nikos, AmeliaBR, Tav, shepazu, stakagi




     * [4]Topics
         1. [5]SVG authoring guide
         2. [6]Amsterdam F2F
         3. [7]Define overflow:visible behavior for pattern tiles
         4. [8]Github labels
         5. [9]Doug's questions about SVG 2
     * [10]Summary of Action Items
     * [11]Summary of Resolutions

   <Tav> Calling in now.

   <scribe> scribe: nikos

   <scribe> scribenick: nikos

SVG authoring guide


     [12] http://w3c.github.io/svgwg/specs/svg-authoring/#intro

   <shepazu> old SVG Accessibility Authoring Guide:


     [13] https://w3c.github.io/writing-accessible-svg/accessible-svg.html

   shepazu: This other document gives some context. The SVG A11y
   TF wanted to do an SVG accessibility authoring guide.

   Wanted to make something that would have wider appeal

   scribe: so this is about all of SVG. Tips and tricks for
   authoring good documents, as well as how to make them properly
   ... basically the approach is to talk about how authors and
   tools can optimise SVG to be portable, work well, etc
   ... accessibility is just a part of that.
   ... I'd like to expand this across the board. Want people in
   and out of the group to be able to contribute so we can get the
   best tips and tricks in one place
   ... would be good if you could read it and provide feedback.
   ... Important to know I used the gh-pages branch.
   ... I would suggest we move everything to gh-pages and make
   that the default
   ... gh-pages is a special kind of branch. If you put something
   on gh-pages it's visible on w3c.github.io

   AmeliaBR: it's complicated by the compiled source. The benefit
   of gh-pages is that you can view a source file as HTML in the
   browser. That only works if the file in the repo is what you
   want to see.
   ... with svg we have build scripts that puts things on
   ... all the specs that SVG host require a build script to
   generate the output

   shepazu: It's slightly misleading if people go to the
   uncompiled pages, but it's not harmful
   ... you're correct that it would only show the uncompiled
   version of the spec
   ... but for specs like this one it does help, and for other
   stand alone specs, then it will help with that
   ... so I would suggest we move to the gh-pages branch

   AmeliaBR: I'm happy to use gh-pages but I would like to make
   sure we still have master vs built version
   ... which is what ARIA is moving to, and what CSS does
   ... so have a master version and a gh-pages version that is

   shepazu: But I'd like to move to gh-pages and I think we should

   nikos: I'd like to do some investigation before I decide if
   that's a good idea or not
   ... thought it was funny that the text on path example is an
   image so I can't select the text - which the guide says is one
   of the benefits of text path

   shepazu: good point, I'll make it an iframe

   AmeliaBR_: make it an object instead. It scales like image
   ... that's another good tip for the guide
   ... it'll match the internal size of the svg
   ... iframe sizing is completely determined by the external
   ... so iframe sizing is determined by the styles in the HTML
   page, it does not use the intrinsic sizing of the SVG page

   nikos: link to a11y email list is wrong

Amsterdam F2F


     [14] https://www.w3.org/2002/09/wbs/19480/amsterdam2016/

   nikos: We found a host at CWI. They can do Monday - Wednesday
   ... I propose still meeting up on Sunday if people are in town
   ... we can do something more informal

   Tav: I'll plan to arrive Sunday morning

   AmeliaBR_: I expect to be around those days
   ... there's also a Chrome hosted conference Monday and Tuesday
   in Amsterdam on progressive web apps
   ... don't know if Google folks will be around and would like to
   carry over an extra day



     [15] https://events.withgoogle.com/progressive-web-app-dev-summit/

   nikos: So for this meeting I'm hoping we can get most of the
   issues that need editorial fixes done beforehand so we can
   focus on review

Define overflow:visible behavior for pattern tiles


     [16] https://github.com/w3c/svgwg/issues/129

   AmeliaBR_: SVG 1.1 had text that overflow is default and if
   overflow is visible, the rendering is undefined
   ... I would like to make it defined in SVG 2
   ... there are lots of times when authoring that you have a non
   rectangular repeating pattern
   ... the drawing objects don't fit in the repeating rectangle
   ... so it seems logical that overflow:visible would be useful
   ... doesn't work in any browser UAs that I've tested
   ... discussion so far has been that it would be nice, but what
   are the practical problems
   ... two issues - first how do tiles get stacked in the painting
   ... that's not controversial
   ... second issue is the limit on how far overflow can go
   ... and what effect that will have on the cost of computing the
   final bitmap for the repeating tile

   Tav: in InkScape we don't support overflow, but I'd like to
   change that because it comes up often
   ... we can simulate it by using our tiling
   ... it makes copies using the use element
   ... it's still very fast
   ... I don't see a huge perf penalty by not limiting the size of
   the tiling

   AmeliaBR_: that's certainly how I do it as an author

   Tav: I would like to simply state that overflow should be

   AmeliaBR_: as far as perf impacts, we wouldn't be changing
   default behaviour

   nikos: Regarding the perf problem, Cameron's example was far
   more complex than examples given so far

   Tav: if an author is silly enough to do that then it's expected

   AmeliaBR_: if an author wants to push the limit then that's ok
   ... there's lots of crazy css that can do that
   ... it's just a trade off

   nikos: my concern is for users, there's already ways to make
   slow svg, but it can be unfriendly to users if an author is
   developing on a fast machine and doesn't realise there are perf
   problems with their page

   shepazu: I'm sympathetic to amelia's position. At the same time
   I don't think this is a priority for SVG 2
   ... don't know how likely it is that if we specified something
   that it would get implemented in a timely way
   ... would result in an at risk feature

   Tav: this is afive minute spec change

   shepazu: I'm worried about time to change implementations, come
   to agreement, etc

   Tav: I'd write tests

   shepazu: you'd need to change browsers too

   nikos: I agree. Think it will take some time to get agreement
   from browsers about which direction to go with

   AmeliaBR_: we're not going to define as pattern overflow will
   never work
   ... better to put a note that it may be defined in future

   Tav: why don't we put it in and put it at risk and get

   shepazu: I have a feeling the five minute change may take
   several hours that could be better used on other things

   nikos: I would suggest we leave it undefined for now. If you
   really want to make the spec change do it after all other
   actions are finished.
   ... Think it's best to leave it undefined. Don't want to close
   the door on the feature, but it's not going to make it into SVG

Github labels

   nikos: The labels I picked were an experiment. Label was done
   by state - where an issue is up to at the moment. E.g.
   'Resolved', 'Editing', etc
   ... think it would be better to change to label by the the
   issue needs - 'Needs discussion', 'Needs editing', etc

   AmeliaBR_: I'm ok with that. Would like to see colour schemes
   used more effectively too

   nikos: There's a milestone I made for SVG 2 CR, I might update
   the issues under there at some point

Doug's questions about SVG 2

   shepazu: What's the status of xlink:href?

   AmeliaBR_: just href is ok

   shepazu: text wrapping?

   Tav: that's in there

   shepazu: markers inheriting colours?

   AmeliaBR_: probably still issues, but it's there

   Tav: what's missing?

   AmeliaBR_: clearly defining how those keywords work.

   nikos: It might be that we don't have a definition for what the
   context is that those attributes talk about

   shepazu: Those are three things that I think would make SVG
   more usable
   ... Think we should also point out the things that will make it
   easier for people to author SVG
   ... we should broadcast those when SVG is put out
   ... What other features?

   nikos: marker auto-start-reverse is small but nice for authors

   AmeliaBR_: I got lots of outrage when I tweeted about z-index
   being at-risk. People want that
   ... we need to update the what's changed appendix, but it would
   be useful to write up a "what's new" guide at the same time

   Tav: text on a shape is nice

   nikos: I'll make a wiki page on github, people can add stuff as
   they think of them

   shepazu: another feature is that we've moved many SVG features
   into CSS so they're more broadly supported

   AmeliaBR_: geometry in CSS is something authors really want

   Tav: paint-order is big with InkScape users

   shepazu: we should make a demo page with all these features

   AmeliaBR_: wiki page sounds good

   nikos: There's a lot we can expand it to - implementation
   status, etc
   ... we'll start small and build it up

Summary of Action Items

Summary of Resolutions

   [End of minutes]

The information contained in this email message and any attachments may be confidential and may also be the subject to legal professional privilege. If you are not the intended recipient, any use, interference with, disclosure or copying of this material is unauthorised and prohibited. If you have received this email in error, please immediately advise the sender by return email and delete the information from your system.
Received on Friday, 13 May 2016 00:06:37 UTC

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