- 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>
Hi all,
Minutes from today’s telcon available at:
https://www.w3.org/2016/05/12-svg-minutes.html
And as text,
[1]W3C
[1] http://www.w3.org/
- DRAFT -
SVG Working Group Teleconference
12 May 2016
[2]Agenda
[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
Attendees
Present
nikos, AmeliaBR, Tav, shepazu, stakagi
Regrets
Chair
nikos
Scribe
nikos
Contents
* [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
<AmeliaBR>
[12]http://w3c.github.io/svgwg/specs/svg-authoring/#intro
[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
[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
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
[14]https://www.w3.org/2002/09/wbs/19480/amsterdam2016/
[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
<AmeliaBR_>
[15]https://events.withgoogle.com/progressive-web-app-dev-summi
t/
[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
[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
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
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