<Tav> Calling in now.

<scribe> scribe: nikos

<scribe> scribenick: nikos

SVG authoring guide

<AmeliaBR> http://w3c.github.io/svgwg/specs/svg-authoring/#intro

<shepazu> old SVG Accessibility Authoring Guide: 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 accessible.
... 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 svgwg.org
... 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 built

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

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

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

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 heree
... 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 order
... 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 painted

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 versions

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

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 2

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

This is scribe.perl Revision: 1.144  of Date: 2015/11/17 08:39:34  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Found Scribe: nikos
Inferring ScribeNick: nikos
Found ScribeNick: nikos
Present: nikos AmeliaBR Tav shepazu stakagi
Agenda: https://lists.w3.org/Archives/Public/www-svg/2016May/0001.html
Found Date: 12 May 2016
Guessing minutes URL: http://www.w3.org/2016/05/12-svg-minutes.html
People with action items: