See also: IRC log
<Tav> Calling in now.
<scribe> scribe: nikos
<scribe> scribenick: nikos
<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
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
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
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
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:[End of scribe.perl diagnostic output]