- From: Erik Dahlstrom <ed@opera.com>
- Date: Fri, 31 Oct 2014 16:00:18 -0700
- To: "www-svg@w3.org" <www-svg@w3.org>
Minutes:
http://www.w3.org/2014/10/31-svg-minutes.html
as text:
[1]W3C
[1] http://www.w3.org/
- DRAFT -
SVG @ TPAC 2014 Day 2
31 Oct 2014
[2]Agenda
[2]
https://www.w3.org/Graphics/SVG/WG/wiki/F2F/TPAC_2014/Agenda#Friday_09.00_-_10.30
See also: [3]IRC log
[3] http://www.w3.org/2014/10/31-svg-irc
Attendees
Present
mark_kilgard_(nvidia), rik, dirk, shane, brian, jun,
nikos, thomas, takagi, tav, chris, ed
Regrets
Chair
ed
Scribe
birtles, nikos
Contents
* [4]Topics
1. [5]NVidia presentation
2. [6]Deeper investigation of the accuracy of the
coordinates on rendering
3. [7]non-scaling dash patterns
4. [8]New charter and priorities
5. [9]predictable SVG raster output
6. [10]New charter and priorities
7. [11]Icon use problems
8. [12]New charter and priorities
9. [13]Using HTML elements directly in SVG
10. [14]Putting SVG elements in HTML namespace
11. [15]Demos
12. [16]Demo from Mark Sadecki
13. [17]Demo from Doug
14. [18]Non-scaling line patterns
15. [19]Minimal rendered stroke width
* [20]Summary of Action Items
__________________________________________________________
<birtles> ed: where are you guys?
<birtles> cyril? cabanier? krit?
<cabanier> scribenick: cabanier
NVidia presentation
mark: thank you for having me here
... these are various SVG files
... we've been working on making vector graphics fast
... for hires and tablets
... this is one of the testbeds
... we have and compare against cairo
... we render all text from outlines and it is super fast
... I work for NVidia and happen to be in town
... SVG is different from how OpenGL is done
... Used to think that 2D was iineffective but changed my mind
... (overview of history of 2D vs 3D graphics)
... most 3d works is moving 2d closer to 3d
... so most work has not been that successful
... MS has been making good progress
... path rendering is one of the areas that has seen
improvement
... nv_path_rendering
chrisl: so you can keep the path so you don't have to tesselate
or break beziers into lines
mark: yes.
... we're making GPUs smart about bezier curves
... there's another approach, paper is called:
massively-parallel vector graphics
... (overview of OpenGL pipeline)
... now there's a new path pipeline
... once you have a path object, we stencil the path to do the
winding
... this is different on different on different GPUs
... once stenciled, we put arbitrary geometry around it so it
can be passed to a stencil buffer
... one issues is that we flip between stenciling and drawing,
which is what makes it really slow unless you make the driver
aware of this
cabanier: how widely is this supported?
mark: all nvidia hardware from the last 6 years
... other vendors are not as open
... it's not important to their priorities
... it's a bad situation for the 2d industrt. other vendors
have the same capabilities but are wary to add them
cabanier: so the stencil swapping is slow, can you just
standardize that?
mark: ???
... Illustrator is now GPU accelerated
... and uses NVPath rendering
(overview how much faster it is)
scribe: overview: we can now stencil/cover very efficienty
... 700,000 paths per second
... from Maxwell on there are new GPU features specifically for
web and path rendering
... kepler for tegra was the first. Shield from NVidia, Nexus 9
(demos on the shield tablet)
scribe: Maxwell 2 has a complete feature set for accelerating
2D graphics
... blends modes are all in
... what is new in Maxwell 2: framebuffer configurations with
mixed samples
... 2d world doesn't care about depth buffer
... so now you don't need that any more
... with half the memory, you can do higher quality rendering
... the stencil test, you run 16 stencil tests on a pixel
... and you have 1 color
... so you have far less memory and better quality
... there are different configurations of coverage/stencil
samples per pixel
(overview that maxwell is faster and more memory efficient)
scribe: 1/4 to 1/6 of the memory of conventional multisampling
... all the 2d extensions are on opengl.org
ChrisL: can we have the PDF slides
Mark: yes
ChrisL: what is NVidia's story on cheap GPUs?
Mark: there used to be an idea that there was a feature set
difference between GPUs
... we don't do that anymore. all features are in all versions
of an architecture
ChrisL: you mention 4-6 years of compatibility will my laptop
work?
Mark: you can look this up on the nvidia website
... there are some demos there. We might need to update .exe
... look for NVPRSDK
krit: do we still need to calculate bounding box, etc on the
CPU?
mark: you once have an nvpath, you can get tight bbox bak.
... you can do path hit testing and path distance
... for stroke we give you a conservative bbox
krit: you can support variable strokes?
mark: we don't do that for now
... you can convert it to a path and fill it
krit: dash array?
mark: we support all that
krit: didn't mozilla try nvpath?
mark: very often the structure of a browser is very immediate,
so you can't reuse objects
... we're working on changing how they give data to the GPU
krit: how about meshes?
mark: yes, you can do those as well
krit: can you apply filters such as blur?
Mark: yes, during the cover stage
(shows an example)
(talk about paths)
<stakagi>
[21]https://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Better_CT
M_Computation
[21]
https://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Better_CTM_Computation
Deeper investigation of the accuracy of the coordinates on rendering
<birtles> scribenick: birtles
<scribe> scribe: birtles
stakagi: The coordinates accuracy of SVG is a fundamental theme
for the maps. We need at least 8 digits of precision which is
more than the range of a single floating point
(discussing summary on above-linked wiki)
stakagi: By providing a user coordinate system with an
appropriate origin to each tile, the effective digits increases
one digit in case of 10x10 tiling.
... However, these tiles must be precisely pasted on the user
coordinate system of the root which unifies them.
(presents proposal outlined in wiki)
stakagi: double precision computation should be performed for
the calculation of CTM by nested transformation to suppress
errors.
... On the other hand, single precision is enough as CTM and
the coordinate transformation computation. Therefore, single
precision computation by GPU is possible.
(demonstrates a test case for the precision of various
browsers)
stakagi: the slider changes the zoom ratio by changing the CTM
(via the viewBox)
... the setTileOffset field shifts the origin of the user space
... This is the coordinate transformation operation equivalent
to tiling of this proposal.
... e.g. we can set it to 1000000000
... then you see that when we zoom in, the origin vibrates
... this demonstrates the error introduced
... but I made a polyfill that computes the origin with double
precision which suppresses the error
krit: would double-precision solve the issue?
... it is up to the implementation to do that
... the SVG 1.1 says that it's up to the implementation to use
double or not
... so it's up to the implementation to use double or not
shepazu: do our hardware requirements from 2001 still make
sense today or should be reconsider these today?
... does those assumptions still make sense?
krit: as far as I know, double-precision can still be up to 4
times slower on mobile devices
cabanier: DOMMatrix requires double
ChrisLilley: stakagi was saying that we only need double for
coordinating the CTM, not for rendering
<cabanier> spec: [22]http://dev.w3.org/fxtf/geometry/#DOMMatrix
[22] http://dev.w3.org/fxtf/geometry/#DOMMatrix
ChrisLilley: I think that's useful to put in the spec
... I propose that we accept this
<scribe> ACTION: Takagi-san to spec that calculation of CTMs
should use double precision [recorded in
[23]http://www.w3.org/2014/10/31-svg-minutes.html#action01]
<trackbot> Error finding 'Takagi-san'. You can review and
register nicknames at
<[24]http://www.w3.org/Graphics/SVG/WG/track/users>.
[24] http://www.w3.org/Graphics/SVG/WG/track/users%3E.
<scribe> ACTION: stakagi to spec that calculation of CTMs
should use double precision [recorded in
[25]http://www.w3.org/2014/10/31-svg-minutes.html#action02]
<trackbot> Created ACTION-3674 - Spec that calculation of ctms
should use double precision [on Satoru Takagi - due
2014-11-07].
<ChrisLilley> trackbot, status
non-scaling dash patterns
<ed> -- 15min break --
New charter and priorities
<ed> [26]http://www.w3.org/Graphics/SVG/2014/new-charter
[26] http://www.w3.org/Graphics/SVG/2014/new-charter
<ed> [27]https://www.w3.org/Graphics/SVG/WG/wiki/Roadmap
[27] https://www.w3.org/Graphics/SVG/WG/wiki/Roadmap
ed: this is the charter document
Rossen: I had a quick question
<Tav> [28]https://www.w3.org/Graphics/SVG/WG/wiki/Topics
[28] https://www.w3.org/Graphics/SVG/WG/wiki/Topics
predictable SVG raster output
BogdanBrinza: we came to this topic after discussing at MS with
our Office teams etc. with regards to how they think of icons /
graphic assets
... Office has about 10k icons with various resolutions
... Visual Studio have about 3k
... they have a team that just manage icons, create raster
icons from vector icons etc.
... we want them to use SVG end-to-end
... we've asked, "what is stopping you from doing this today?"
... what they provided as a prioritized list of reasons
... one of the first things is that as a designer it's
impossible to control raster output
... they are producing office publications, desktop
publications etc.
... they have a range of resolutions
... they have an SVG icon master, suppose they set scale factor
0.8
... what they see as a result is not satisfactory
... they want to slightly modify it on a pixel level
<shepazu>
[29]http://www.w3.org/Talks/2014/schepers_invisible_visualizati
on/responsive.svg
[29]
http://www.w3.org/Talks/2014/schepers_invisible_visualization/responsive.svg
BogdanBrinza: it's fidelity at a pixel level
ChrisLilley: so it's not a crisp in the way they might want
smailus: we've seen the same problem at Boeing in that they
don't downsample correctly
... when you stick a raster in SVG stuff starts to disappear
shepazu: are you saying that the same image referenced in HTML
and SVG are not downsampled well in SVG?
smailus: in SVG it's not the same, and it's poor quality
BogdanBrinza: I'll talk about that later
... the second issue is lack of support in non-Web frameworks:
XAML/Cocoa
... the alternative is to use fonts which is where they're
heading
... the advantage is that they work well with native and Web
applications
... more importantly, fonts have a well-established mechanism
to control output through hinting
... all those problems are well understood in the font world
... from an SVG perspective, looking at fonts, they have major
disadvantages such as not being animatable except for keyframe
animations
... they cannot be combined with external resources for
efficient workflows
(keyframe animations meaning you need to put every frame in the
font)
Rossen_: one of the problems that icon designers face today is
that even though fonts are inherently interoperable, they're
not interoperable from the point of view of...
... for example, there's a variety of greyscale between
different devices/platforms
... so people will have different hints for fonts for different
platforms
... that blows up the set even more
... those hinting algorithms are proprietary to every platform
BogdanBrinza: those hinting algorithms are proprietary to every
platform
... but SVG should be cross-platform
... imagine three icons for Firefox, Chrome, and IE
... when we change the size we might just want to show the
outline of the Firefox icon
... for the Chrome icon, the position of the different parts
might be important
... so if we change the size the shapes might get out of line
... finally, for the IE icon designers want to preserve the
shape
<shepazu>
[30]http://www.w3.org/Talks/2014/schepers_invisible_visualizati
on/responsive.svg
[30]
http://www.w3.org/Talks/2014/schepers_invisible_visualization/responsive.svg
shepazu: I may have misunderstood but for this last point,
couldn't you use media queries?
(regarding level of detail)
scribe: see the link above, if you resize the browser the
detail changes
<smailus> Details: image is line-art (all black or white
pixels), the image (tiff) rendered directcly in the web
browser, when that image is downsampled into a small frame in a
web page, we see some browser downsample well. If we put that
rater data into an SVG as a png encoding, when that same image
is downsampled to fit into a small space, the downsampleing is
simplistic and drops pixels - so for line art lines (ie the
image) starts to disappear)
BogdanBrinza: right, for the Firefox icon example, before that
would be sufficient
smailus: continuing the discussion about hinting, the basic
problem is that when you scale down SVG, that is purposely used
for icons
... the crispness of the rendering is easily lost
... when small parts of the icon fall in mid-level pixel, you
start getting bad aliasing
... though media queries can be arguably used, to drop details
etc.
... as Bogdan pointed out, for the Firefox logo you can drop
details when it's scaled down
... but there may be parts you don't want to drop
... for the Chrome logo you don't want to drop, e.g. the white
circle around the blue
... what would make this circle better or worse is how it's
aligned with the pixel grid
... the more points you touch, arguably you'll have a crisper
circle
... talking with Boeing yesterday, they have some similar
problems where they have cases of line thickness preservation
regardless of scaling
... scaling up or down shouldn't change the stroke-width
birtles: we have that, that's implemented everywhere
shepazu: what specific proposals do you have for this?
BogdanBrinza: we spoke to font people about how they solve this
and they add instructions to font to push pixels around
ChrisLilley: we did look at hinting level 1 and those
instructions don't work at odd scale factors (7.3) or when
rotated
... and there were patent issues too
... and fonts are essentially using a black and white stencil
(even if they're coloured) but in this case you may need to
preserve contrast
BogdanBrinza: yes, we don't like instructions either
ChrisLilley: Microsoft often has a lot of experience with this
and knows that hinting takes a lot of time and money
... and it doesn't necessarily make sense for a simple graphic
(but it might for font that is used extensively)
BogdanBrinza: we might just want to specify some constraints
... font hinting through tooling is done by setting up
constraints and then the tool outputs the instructions
<smailus> shepazu, I'll get a usable example to show at a
future telecon. Its more a client implementation problem, than
an SVG standard problem .(I think)..
ChrisLilley: I pushed back on the word "fidelity" since
anti-aliasing preserves geometric fidelity and this actually
throws this away
BogdanBrinza: most mobile devices are low-resolutions
Mark: but they're often high display density
krit: by the time we spec and implement this and make it
interoperable, will we have higher display densities even on
cheap mobile devices?
... even on retina displays the resolution is not big enough
that you don't have this hinting issue
BogdanBrinza: even looking at your screen, there's a bunch of
situations where you have different sized resolutions
... I'd love to see a single icon used everywhere
... you still have rasters used everywhere
ed: is there a concrete proposal at this point?
BogdanBrinza: we probably want to follow up with a proposal,
today we just wanted to raise the issue
krit: is there anything new since what we discussed in London?
BogdanBrinza: no
Rossen_: there was a patch that was going to be landed in
Firefox to allow to inherit colors into icons
... then we had the discussion that we want to have packaged
icons
... besides resolving the rendering part, so the quality of
rendering is good across different devices
... we also wanted to have extension points so that you can
pass data
... and have a way of exposing declaratively the kind of
parameters that an icon accepts
... and then whoever is using the icon can externally push the
data
... where did that end up with?
ed: what do you want to get out of the discussion?
Rossen_: Dean and I discussed that and we agreed on most of
these pain points
... he's tired of tweaking SVG himself to get a good level of
quality
krit: last year we tried to push hinting for painting but there
wasn't much interest
Rossen_: who did that?
krit: cabanier
Rossen_: I know that Dean was interested in this
... I want to know who else was interested in this
krit: we could discuss this later, have a telcon
shepazu: make it an agenda item for the next telcon?
Rossen_: what is the time of the telcon
ed: it will change but we can discuss that on the list
Rossen_: our action from London was to talk to our font guys to
see if that hinting would be suitable for SVG
... at this point we think it's not
... we've learnt enough to convince ourselves that this is not
the direction we want to go
krit: do you know what direction we want this to go?
Rossen_: no but we have a good sense of the requirements
shepazu: we've discussed this for years
... we could leverage the interest from designers
ChrisL: we often discuss this and end up at the same point: we
need to solve this but we'll decide later how to do that
... some graphics systems define where 0,0 lies differently
(right in the middle of the pixel or not)
... we should just specify which it is
(discussion about whether we can fix this or not, note that
canvas is in the corner but 3D is typically in the center)
<scribe> ACTION: BogdanBrinza to publish hinting requirements
document [recorded in
[31]http://www.w3.org/2014/10/31-svg-minutes.html#action03]
<trackbot> Created ACTION-3675 - Publish hinting requirements
document [on Bogdan Brinza - due 2014-11-07].
<scribe> ACTION: BogdanBrinza to discuss this issue with the
Responsive Image Group [recorded in
[32]http://www.w3.org/2014/10/31-svg-minutes.html#action04]
<trackbot> Created ACTION-3676 - Discuss this issue with the
responsive image group [on Bogdan Brinza - due 2014-11-07].
New charter and priorities
Icon use problems
<shepazu> [33]http://jeremie.astori.fr/svg_tests.html
[33] http://jeremie.astori.fr/svg_tests.html
shepazu: this is a slightly different set of problems
... this is someone who was working with the W3C
... he said he wanted to use SVG in his resume but had some
troubles
... discussion about how some of these problems can be fixed,
e.g. using pointer-events
New charter and priorities
<ed> [34]http://www.w3.org/Graphics/SVG/2014/new-charter
[34] http://www.w3.org/Graphics/SVG/2014/new-charter
<ed> [35]https://www.w3.org/Graphics/SVG/WG/wiki/Roadmap
[35] https://www.w3.org/Graphics/SVG/WG/wiki/Roadmap
ChrisL: I changed the roadmap after it went out for review so
that the dates were no longer in the past
... apart from that these are numbers I made up
Rossen_: this was not my topic, but I had mostly questions
... I think about 6 months at the Leipzig meeting someone say
we wanted to go to LC and lock down the spec
... at that time I wasn't following the spec too closely but I
wasn't following too closely
... but at this point I don't see that
... nor do I see the kind of features / work that suggests we
will get to a shipping state soon
... do we intend to ship? or just keep it open and work on it
indefinitely?
... from an implementors point of view, even if it were a
reduced set of the current features
... or if we modularized it like other big specs
ChrisL: a few years ago we were pushing towards a big date but
that kind of went away
... and we've put most effort into the joint CSS specs
... at point we had a whole load of modules and then we
factored them into one spec: SVG2
... I agree that we should push things forward
... also people who are waiting for new features have been
waiting for a long time
... I think there's a reluctance to ship SVG 2 if it's just
basically SVG 1.1 3rd edition
... with simply tighter prose
... we have some nice new features but
... we went through all this list of features, and did this
analysis but that's kind of been lost
... not sure if the same people are still interested in the
same features
shepazu: I think what ChrisL said was correct
... but also I think there are things I want in the spec but
haven't had time to edit it into the spec
... and I think that's true with a lot of us
... I think there's a problem with motivation too
... when we hear browser vendors saying they're mostly
interested in removing SVG features
... it's demotivating
Rossen_: I'm interested in implementing features but only when
they're stable
... I'm not interested in implementing if we keep adding things
and changing our minds
... I think we often need to focus on the non-important 80%
shepazu: maybe next telcon we need to revisit what's actually
going to be in the spec
... rather than having a deadline for the whole spec, but do it
part-by-part
krit: yes, we want to ship SVG2
... the second part is that we should sign up to specific
deadlines
... and we should take out features that are not ready
<ChrisL>
[36]https://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Planning_Page
[36] https://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Planning_Page
<ChrisL>
[37]https://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_I
nput
[37] https://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input
krit: we shouldn't worry about getting everything in just
because it's the big "2"
<krit> ack, krit
Rossen_: if the priorities are set
shepazu: we could focus on the particular problems each edition
of the spec is going to solve
... e.g. this iteration was focussed on this set of problems,
from a functional point of view
Rossen_: in its current state, is there anything that is stable
and ready to ship?
shepazu: have you guys implemented non-scaling-stroke?
Rossen_: is there a version of the spec we can have today that
is stable
... if there's nothing in the spec that is stable, then that
sends a message to implementors
... we should find the stable parts of the spec and ship that
... and keep working on the other parts in parallel
<dbaron> +1 to shipping smaller releases, and not delaying them
in order to get more things in
Rossen_: I'm not necessarily arguing we should go more modules
ChrisL: some features are hard to label, like cleaning up the
namespace stuff
... not requiring xlink
BlackCatkins: I agree with the general thrust with shipping the
stable subset of SVG
<Tav> +q
BlackCatkins: but I want to know why we failed with
modularization in SVG
shepazu: I think we have not failed with modularization
... that's the stuff we're working on the FXTF
... but the problem is the monolithic main spec
BlackCatkins: when we initially tried to do modularization part
of the problem was knowing where everything was
... discoverability of specifications is poor
... we need to fix that
Cyril: when we talk about SVG2, people have high expectations,
so we should maybe drop the 2 and just publish more often
<ChrisL> ACTION: ChrisL make all svg wg specifications
discoverable, due december [recorded in
[38]http://www.w3.org/2014/10/31-svg-minutes.html#action05]
<trackbot> Created ACTION-3677 - Make all svg wg specifications
discoverable, due december [on Chris Lilley - due 2014-11-07].
Cyril: they expect many new features
shepazu: I understand what you're saying
... but I think we can moderate that expectation by telling
them what the goal of the spec is, and iterating quickly
Rossen_: who are you thinking about?
Cyril: end users
birtles: I think it's an issue, but I think we can deal with it
Rossen_: as long as we're open about it, and tell people how we
hope to ship more, they'll be more excited about that
Tav: when I've talked about SVG2 I've focussed on what is
already implemented, e.g. paint-order etc.
... yes we need to have SVG2, but we can also start
implementation once we have agreed something is stable
Rossen_: define what is stable
krit: first, we already agreed that if the WG already agrees to
ship something then implementations can ship that
... do we want to discuss now a LC date for SVG2 now?
ChrisL: I think it's too early. We need to have a better idea
of what we have, and what we need to fix
krit: I hear what you're saying, but we should have done that
BlackCatkins: can we just set the date of being ready for the
LCWD as next Feb's F2F
(all): yes
<scribe> ACTION: BogdanBrinza to drive the assessment of SVG2
to get it to LCWD by the February F2F [recorded in
[39]http://www.w3.org/2014/10/31-svg-minutes.html#action06]
<trackbot> Created ACTION-3678 - Drive the assessment of svg2
to get it to lcwd by the february f2f [on Bogdan Brinza - due
2014-11-07].
RESOLUTION: We will prepare SVG2 for LCWD by the February F2F
shepazu: honestly, besides the things we need to clean up, for
a lot of people, if all we fixed was xlink and wrapping text, I
think a lot of people would be happy with that
<nikos> scribe: nikos
<scribe> scribenick: nikos
<smailus> we are not moving the repo again are we?
<Cyril> [40]https://svgwg.org/svg2-draft/changes.html
[40] https://svgwg.org/svg2-draft/changes.html
Using HTML elements directly in SVG
<birtles>
[41]https://www.w3.org/Graphics/SVG/WG/wiki/F2F/London_2014/Age
nda/HTML_integration
[41]
https://www.w3.org/Graphics/SVG/WG/wiki/F2F/London_2014/Agenda/HTML_integration
birtles: starting with the first topic on that page
(summarising the wiki)
birtles: can't use template in SVG at the moment - it must be
wrapped in FO
... there may be other web components elements as well
... using iframe, button, or canvas is less straight forward
<smailus> it went from hg to git recently with the wiki still
refering to hg, so I've been chasing where to edit it for a
month (took some time to get hg hooked up behind my corp
firewall)... I"m hoping the spec repo is going to be stable
going forward and the wiki instructions are updated to indicate
how to connect to it. If thats wiki update has already
happened, then sorry.
birtles: iframe issue: you need to manage two viewports
... fo is long and ugly and increases file size
... fo in stand alone svg docs means you need to tag the
children with a ns
ChrisL: can we get rid of namespace on the root of standalone
svg at the same time as xlink?
ed: not if we use xml
... have to move to the html parser
birtles: if we were to try to allow iframe, button, canvas etc
directly in svg
... for the case where svg is embedded in html we run into the
problem that html parser when it sees html in svg
... will close the svg automatically
... algorithm describes this - it's for compatibility with some
pages
... we talked about this at last f2f
... we caught up with hixie this week
... I've outlined a few options
... for template it's straight forward, we should fix that and
it shouldn't cause trouble
ChrisL: why won't putting template in svg cause closing?
birtles: it will, we can fix that
... we'll file a bug on the parser
... hixie agreed we should fix the template thing and it's not
an issue
... for the others it's less clear
... there's a few options
... 1. just allow divs which would contain the html
shepazoOoOoOo: why not any html container?
birtles: it would just minimise the number of backwards
compatible issues we might hit
... in particular with layout
... just doing div is a minimal change
ChrisL: would div shrink wrap?
birtles: yes
... the advantage of going with div is the change is so small
... an extension to that is to white list the elements that we
think would be useful in svg
... i've given a sample
... I'm not a fan of the white list approach
Cyril: there's already a chapter outlining embedded elements in
svg
birtles: the trouble is when we went to implement we discovered
that the way it's specced results in an svg version of each of
these elements
... it's a bad idea to do that
... this solution tries to fix that problem and have html in
svg
... another approach is to say everything in html can be used
in svg
... not sure about non flow content
ChrisL: that approach, where you can dump any element in seems
hard to test and hard to spec
BlackCatkins: what's the problem? children of circle won't
render
birtles: I'm not sure that we'd have to spec a lot of cases
... I think there's a set of simple rules we could follow
ChrisL: I don't agree
... and the auto closing thing would need to be gotten rid of
birtles: I don't think there's an issue defining a lot of edge
cases
... one of the issues that comes up is the backwards
compatibility issue
(shows example with two divs and an open svg)
birtles: if we didn't close the svg it raises questions
... how are the divs rendered?
... in svg which uses absolute positioning they would all stack
on top of each other, which wouldn't be helpful
... and the svg if it doesn't have a width would be 300 and
content would be clipped
nikos: we resolved to make svg overflow:visible didn't we?
birtles: yes, and ie already does that
BlackCatkins: we do a box model fix up in several places in css
so we could say that a run of html elements in svg could be
wrapped in a block
... result wouldn't be too terrrible
... this is just error handling for when auto closing used to
do something useful
birtles: display stuff may be solvable but it will need some
work
... one other approach if this all proves to hard is to
introduce a new element - like box
... which is basically a fo but shrink wraps it's content
ChrisL: how long has it been specced whether fo shrink wraps or
not?
BlackCatkins: fo has always had a width and height
birtles: won't render if width and height not set
... hixie didn't seem to like the idea of using html instead of
box
... not sure why
BlackCatkins: there's parsing issues
birtles: the approach of adding a new element to svg would also
set the namespace of it's children to html
... so you'd avoid the problem with fo
Tav: maybe html_box - box sounds too much like rect
birtles: so there's three broad approaches to all of this
... 1. fix template and don't worry about fo
... 2. allow html directly in svg
... 3. add a wrapper to make it easier to use html in svg but
not allow html directly
... I'd like to know which you think is the best?
Cyril: you'd still need an element in the third approach?
birtles: yes. e.g. <html_box><video/></html_box>
BlackCatkins: I think we should allow all in svg and see if it
works
... if it doesn't work, i'm not super happy about a white list
... makes the language incosistent
... maybe we could just say replaced elements?
... might be reasonable, I'm not sure
... otherwise I'd go with a wrapper element
birtles: one nice thing about wrapper element - if we used div
we might not be able to add x and y
BlackCatkins: that would be fine for div
... can't add x and y to all elements because some already
define x and y
... with shrink wrap the box is the viewport
... percentages are resolved against the box size
... if you don't specify a width percentages go to auto width
instead
... it's the same as putting a float in your document now -
percentages can sometimes be resolved and sometimes not
birtles: we could try and remove width and height on fo and see
if anything breaks?
Cyril: I don't see how removing a restriction would break
anything
birtles: if someone has not specified width and height and
relies on that disabling rendering then it would break
ed: initial value for width on fo is currently auto
... there is an issue noting that we need to define what that
means
birtles: other difference is the ns thing
Cyril: fixing the fo problem by adding another element is
pfffft
... I would prefer using an existing element, like div
... or fixing fo
birtles: i think if we introduced box we'd deprecate fo
BlackCatkins: i agree the verbosity argument is important here
birtles: I think the ns issue is significant too
... having to remember the xhtml ns is a real pain
... so Tab you prefer allowing html elements direclty?
BlackCatkins: yes
ed: me too
<ChrisL> I prefer having a new, shrink wrapping element to put
html stuff in
shans__: I don't know if this is worth considering, but you
could allow one html element without a container. And require a
container for more
birtles: not sure about usability for that
... e.g. adding a second div would break things and confuse
people
... any other votes of preference?
ChrisL: I like the new shrink wrap element
... deals with a lot of simple cases well
... don't have to decide in advance how big it is is nice
Cyril: I would prefer reusing an existing element
... for end users learning a new element is a pain
ChrisL: but you're saying instead of adding a new element they
need to learn new behaviour of an existing element
Cyril: why can't you use a div directly?
birtles: that's one of the proposals
... but we need to fix the layout if we choose that one
ChrisL: it's overloading it in a way that some people may find
objectionable
BlackCatkins: and it's the same as teaching a new element
birtles: i don't know that too many people are familiar with fo
... and we'd be deprecating it so the number of elements would
be the same
Cyril: do we have metrics on fo?
BogdanBrinza: we have not seen it really used on the web
... though we did get a substantial amount of requests from
people who use it on intranets
... got a lot of requests to implement
birtles: if we pursue allowing html elements in svg I'll need
help with the layout stuff
BlackCatkins: i can do that
birtles: Chris and Tav prefer the box approach.
Tav: for InkScape it's good because a box isolates the region
BogdanBrinza: from our perspective it doesn't matter
birtles: seems evenly divided - which way should we pursue?
... could try to spec the layout for direct integration and see
how it goes?
BlackCatkins: it's no harder one way or the other
... and it's not difficult to do
ed: I prefer direct integration - it feels more natural to use
html elements directly
... box feels like just a fo light
krit: I think we'll break a lot of content so I prefer box
BlackCatkins: we should try direct integration and see what
feedback we get
ed: i think that's fine
krit: me too
birtles: sounds like we should try direct integration and see
what happens
Cyril: what about template?
birtles: I'll follow up and file bugs
shans__: you want to use template for svg right? it's different
than using the html template
birtles: in the stand alone case what would we do with a
template in the svg document?
... would it be in the svg ns?
BlackCatkins: depends if we're xml or not
... if xml then it goes in svg ns
... we should stop being xml
birtles: the ns stuff is the next topic
Tav: there are a lot of people that integrate svg in other
things
<scribe> ACTION: Brian to follow up on template - file bugs and
investigate the stand alone case [recorded in
[42]http://www.w3.org/2014/10/31-svg-minutes.html#action07]
<trackbot> Created ACTION-3679 - Follow up on template - file
bugs and investigate the stand alone case [on Brian Birtles -
due 2014-11-07].
birtles: is Blink willing to try the all elements option?
BlackCatkins: yes
<scribe> ACTION: Tab to find someone at Blink to implement
support for all html elements directly in svg [recorded in
[43]http://www.w3.org/2014/10/31-svg-minutes.html#action08]
<trackbot> Created ACTION-3680 - Find someone at blink to
implement support for all html elements directly in svg [on Tab
Atkins Jr. - due 2014-11-07].
<scribe> ACTION: Tab to help Brian describe layout for HTML in
SVG integration [recorded in
[44]http://www.w3.org/2014/10/31-svg-minutes.html#action09]
<trackbot> Created ACTION-3681 - Help brian describe layout for
svg in html integration [on Tab Atkins Jr. - due 2014-11-07].
birtles: if that doesn't work out we can try adding a new
element
... that's all for that topic
Putting SVG elements in HTML namespace
birtles: i thought we resolved to do that in the past
... but I can't find the resolution
... when we spoke to hixie he didn't seem to enthusiastic
... that ship had sailed and if we try to move svg into html ns
we'd get lots of bugs
BlackCatkins: scripts look at ns to decide code paths
... if you're looking for an svg element examining the ns is
the most efficient way to do it and that will break
shepazoOoOoOo: do people look for the svg ns on just the svg
element or on all elements?
BlackCatkins: don't know
... would be interesting to investigate
... you would still need to use createElementNS on the root
birtles: so suggestion is to just leave the svg element in the
svg namespace?
BlackCatkins: we can try and see what breaks - it's not
something we can test ahead of time
... most libraries that do dom stuff have some special paths
for svg
birtles: one example is the classname property, if you want to
manipulate it you'll investigate the ns and use
element.className.baseVal....
<birtles> (HTML: element.className, SVG:
element.className.baseVal)
shepazoOoOoOo: I know people are using legacy versions of
jquery so we may not be able to ask them to change the
behaviour
BlackCatkins: it's more a case of can we get away with it
shepazoOoOoOo: maybe that content breaks
birtles: you might get lucky in some cases
... if we change the IDL at the same time those scripts will
keep working by luck
shepazoOoOoOo: I think we should think about trying it
BlackCatkins: I'm less sure this would work but it would be
interesting to try putting everything into the html ns and see
what breaks
shans__: what happened about the graphics element being a
switch?
birtles: that's issue three
... it hasn't had much support
BlackCatkins: didn't get support from hixie
birtles: the last point on the issue is that we should at least
fix createElement
Cyril: would it be ok to define createSVGElement
BlackCatkins: that's a good idea
... if nothing else works we should at least make it easier to
create svg elements in that way
Cyril: would that impact the parsing of the html in svg stuff?
BlackCatkins: not really, if there's problems with people
assuming the svg element will close
birtles: sounds like we need to do another experiment in Blink
BlackCatkins: not certain I can convince people but I'd like to
try
<scribe> ACTION: Tab to try putting SVG elements in the HTML
namespace in Blink and see what breaks [recorded in
[45]http://www.w3.org/2014/10/31-svg-minutes.html#action10]
<trackbot> Created ACTION-3682 - Try putting svg elements in
the html namespace in blink and see what breaks [on Tab Atkins
Jr. - due 2014-11-07].
<ed> -- lunchbrëak --
<BlackCatkins> I was just wondering that as well, when I saw
the <meshGradient> change come through.
<BlackCatkins> Can we just lowercase them now?
<BlackCatkins> ScribeNick: TabAtkins
<birtles>
[46]https://www.w3.org/Graphics/SVG/WG/wiki/F2F/TPAC_2014/HTML_
integration_again#Issue_3:_Adding_a_new_top-level_graphics_elem
ent_to_switch_to_a_new_DOM
[46]
https://www.w3.org/Graphics/SVG/WG/wiki/F2F/TPAC_2014/HTML_integration_again#Issue_3:_Adding_a_new_top-level_graphics_element_to_switch_to_a_new_DOM
birtles: We had a proposal from Cam to introduce a new
<graphics> element to switch over to a new DOM.
... Hixie wasn't particularly enthusiastic about it. He
considers it to be a mode switch, and said that historically
mode switches haven't worked.
... If we follow that advice, we're left with 2 outcomes:
... 1) If Dirk's experiment with removing the old SVG DOM
succeeds, we'll be free to put a new one in,
... 2) If it doesn't, we'll have to try to augment the old DOM;
decrement some parts, change some parts, and generally fix
things in-place.
... We can follow that up with Cameron when he gets back.
... And wait to see what Dirk finds out from hsi experiment.
ed: Status from the Blink part is that I added Use Counters.
... Haven't been through a full cycle yet, so no accurate data
yet, but we'll have it in a few weeks.
... They're not very fine-grained, but... we'll see what they
say.
birtles: All right, let's wait for that data before we proceed.
ed: I'd like to drop animVal/baseVal. That'd go a long way.
... But I'm not sure if it'll break too much content.
... But on the other hand, the longer we wait, the harder it
will be to make that change.
birtles: At the end of the bit on the wiki I wrote a rough idea
of how we could deal with that; augmenting SVGAnimatedLength
while deprecating animVal. There may be some possiblities.
Demos
Fred: I'm from PF, and I"ll be demoing chart
accessibility/graphics/etc.
... We have WCAG, guidelines for a11y.
... It's important because if you're a bank and not doing a11y
stuff, you can get sued and fined by the government.
... There's a UN protocol on this, and only 11 nations that
haven't signed it.
... There's 3 aspects to chart a11y.
... We have a charting widget, it's a component.
... Original impetus was to make a single charting component
work on all platforms: Java, Android, iOS, web.
... You give a JSON spec.
... It started with dojo, so it started all the renderers dojo
did: silverlight, canvas, svg.
... But now our scene graph sits on SVG and you don't need to
use dojo.
... 3 most important parts is contrast of text/background, zoom
text to 200%, and if there is color, there has to be
alternative way to provide that information (text, shape, etc)
... I'm showing you the first aspect. The second is keyboard
a11y - must be able to interact solely through keyboard.
... Third is support for blind users. Typically people ahve
said "I'll give you a text description, or etc.". But now if
you have a decision tree, how does the text description work?
Hard to make equivalent accommodation.
... But first phase I want to talk about is color.
... There are two chart widgets [on screen], exactly the same.
... On right is the native spec.
... [describes spec options]
... We give it to the widget, and widget figures things out.
... We find it's *imperative* we don't leave this to authors.
... Some products like ACtiveReport gives "authoring tools".
Customers can make reports, etc, but making the accommodations
work is hard.
... Instead we just make it simple and deal with it in the
user's environment.
... We can, for example, ask for more space.
... For things like axises, in small space things tend to get
abbreviated.
... So it's nice to have a larger size that can do full text.
... [shows a totally different chart]
... Works on any chart.
... If you pick a color combo that won't match the contrast
reqs, we'll override the colors you ask for.
... [describes the text a11y reqs]
... [shows a pie chart]
... First, it's got "normal colors".
... If I switch to black background, the colors are still
visible.
... But if I show text, the yellow text doesn't have enough
contrast with the pie colors.
... So we color shift. We try to maintain hue.
... [chart darkens the pie colors so yellow text is visible on
it]
... We think this needs to be automated, so it works reliably;
can't rely on authors.
... Also, you can share the chart between multiple people, and
based on your personal requirements you can all see it well.
... Now chart navigation.
... I want to emphasize, tab-index is not the way to go.
... We do chart navigation in a specific order.
... [NOAM] came up with a specific order that is accessible.
... I'm using the arrow keys to move around, because that's how
people think.
... Now when I get to the data, the natural way of navigating
is with arrow keys.
... If you tell people "keep tabbing, you'll eventually get
there", they wont' think it's reasonable.
... [show sierpinksi triangle graph]
... Here we're on node 17, and using arrow keys is easy.
... To handle large gaps, you can use Shift+arrow to increase
the size of the gap-jumping.
shepazu: I think tab-idnex is still okay for simple charts,
like bar charts.
Fred: [shows a stacked bar chart]
... Here you need to navigate to each stacked bar, then drill
down to the individual bars.
... The other kind of navigation we have is through
relationships. SVG's <connector> story.
... When we have indicated relationships, we have alternatives
on where to go. You can cycle through alternates, then pick
which one you want to go.
... We let the product choose how to highlight, but by default
we highlight "going forward" and "going back" differently.
... [shows a complex grid with connections between items
snaking all around]
... I think directions don't work great when there are
ocnnectors here. We just treat them like a list.
... Now that's what we do for sighted users.
... [shows a clustered bar chart]
... So we make a shadow dom for them, and try to make a chart
description.
... 3 ways
... Author can provide a description in the chart data. Best
option, but most dont' bother.
... Second is to decompose and try to recognize the important
features.
... This says it's a bar chart, finds the tuples, and tells
what's indicated both by aesthetic and position. It also tells
you max/min values in the chart, as most people care about
that.
... Then they can nav with the arrow keys.
... PgUp/PgDn jump 20 items, Home/End jump to beginning/end of
list. Works on any chart.
... [shows flowing relationships of charts]
... Chart like this is hard. Lots of different semantics in the
different charts.
... [shows two charts in one graphic]
... Here you can move between the charts, then you can move
within the data of each. There's a hierarchy of graphs in your
visualization.
... I'd like to emphasize that you have to worry about your
hierarchy.
... We use metadata that may not be available to you. We can
work out the relationships/etc.
... One other quirk that might affect SVG is when you have,
say, a scatterplot. You can have three groups on the chart with
slightly different behavior. Dunno if SVG can do z-orders.
TabAtkins: You can now.
Fred: If you have the bubbles above/below/intersecting the
axis, do you want to draw axis on top of the bubbles? ETc.
TabAtkins: Should be easy now, no need to mess with data
organization.
Demo from Mark Sadecki
Mark: I'm former W3C staff.
... I recently took a position at EdX.
... Doing MOOCs.
... We recently launched an analytics project.
... Devs came up to me, worried about the a11y.
... Wondered if they just show the raw data in a table, if it
would work.
... And yeah, technically.
... First I said, why not just display:none the SVG, so it's
not shown the a11y API.
... So we fixed the UI.
... Then I thought about it a bit.
... I just added like ten lines of <title> and some ARIA.
... [demonstrates voiceover on the graph]
... Moving between items, it reads out not just the value, but
also the increaase/decrease.
... I thought about what sighted users would get from the
graph, and would be harder to get just from the raw data.
... Just took 10 minutes, and made it way more explorable.
Demo from Doug
shepazu: Some of you have seen my Sonifier before.
... I worked with Benetech to apply this to a graphing
calculator.
... [shows simple parabola graph]
... I press "p"...
... [tone rises and falls as a line passes through the values,
corresponding to value]
... So I'm walking this "cursor" along and finding the
intercept with the graph line.
... I know that this graph is the relevant line; in SVG we'd
want to mark this as the relevant line.
... I use WebAudio to make an oscillator, and change the
frequency based on the value of the intersection.
... And when they hit enter, I use the Web Speech API to read
out the current value.
... Code is out there on GitHub now.
... We still need a way to properly indicate, for example, that
these numbers are the axises, etc.
Non-scaling line patterns
smailus: We talked about this before.
... As you zoom in and out, the line pattern scales with it.
... If we're including the non-scaling line stuff in SVG2...
Tav: The length of dash patterns should be determined by the
stroke width, so if the stroke is non-scaling, it should keep
the dash the same.
smailus: Does that apply to patterns?
Tav: No.
smailus: Okay, so we need some vector effects for that.
... [shows example of hatch pattern]
... Want this pattern to stay the same appearance when you zoom
in/out.
... Also possibly an a11y issue - if you zoom out enough, a
hatch can disappear and just look grayish.
ACTION smailus to add non-scaling patterns to the spec
<trackbot> Created ACTION-3683 - Add non-scaling patterns to
the spec [on Thomas Smailus - due 2014-11-07].
ACTION ed to add "how to edit the spec" to the wiki
<trackbot> Created ACTION-3684 - Add "how to edit the spec" to
the wiki [on Erik Dahlström - due 2014-11-07].
smailus: I think the textLength stuff is going to be in CSS
now, right?
... There's an issue about how textLength is applied when it's
on <text> and on <tspan>.
TabAtkins: The text-fit stuff will go into the Text module of
CSS.
smailus: So here are some examples of how CGM renders text in a
box.
... In particular, "box-cap" and "box-all" mode, so you can
more easily control that text should exactly fill the box, with
descenders in/out of the box.
Minimal rendered stroke width
smailus: We have a vector effect that puts the stroke width in
user space (non-scaling).
... In this diagram, the original image was *enormous*, and
when you shrink it down to the size of this page, the lines are
all so small they disappear (less than a fractional pixel).
... So with the vector effect on, you can see the relevant
parts of the diagram.
TabAtkins: So that effect is only applied to *some* of the
lines - the important ones that should be visible at small
scale?
smailus: Yeah, you can author as you want.
... Now there's an effect called 'limited scaling stroke'.
... At this spot [on the graph] you've got some strokes that
need to be maintained (non-scaling) so they're visible when
super-zoomed out, but when you get zoomed in enough you want to
switch back into normal scaling.
Tav: So a min-stroke-width could do this part.
<nikos> Non scaling dash array works as expected:
[47]http://jsfiddle.net/ae062r9g/1/ (buggy in FF, OK in Safari
and Chrome)
[47] http://jsfiddle.net/ae062r9g/1/
TabAtkins: No, coordinate space changes with the zoom, so it
doesn't actually cange.
smailus: So I suggest a "limited-scaling-stroke" value.
TabAtkins: Maybe a better name to make it clear "no shrinking
to invisibility"?
shepazu: Are we really planning to do this via a
'vector-effect' property?
<ed>
[48]https://svgwg.org/svg2-draft/painting.html#VectorEffectProp
erty
[48] https://svgwg.org/svg2-draft/painting.html#VectorEffectProperty
clilley: Yes.
smailus: Looks like the zomoAndPan attribute disappeared.
... In SVG2 draft there's a stronger commitment to "make sure
panning and zooming are implemented".
... My rec is that we also add "rotate" to taht list of "things
you need to support".
TabAtkins: How is zoom and pan different from scrolling and
Ctrl-+?
shepazu: Ctrl-+ zoom is usually limited to a max/min value, and
scrolling only goes to the edges of the image.
smailus: So what should I do with this?
clilley: Write a test for it.
ACTION smailus to write a test on zoomAndPan
<trackbot> Created ACTION-3685 - Write a test on zoomandpan [on
Thomas Smailus - due 2014-11-07].
ACTION shepazu to put together a tutorial telcon for spec and
test editting for next telcon.
<trackbot> Created ACTION-3686 - Put together a tutorial telcon
for spec and test editting for next telcon. [on Doug Schepers -
due 2014-11-07].
smailus: Want an easy way to print the "current view" - what's
on the screen when you've panned/zoomed.
TabAtkins: We can put a rec in the spec, but that's just up to
the UA to offer a Print Dialog option.
smailus: Next is having multiple "pictures" in a single file,
and only displaying one of them at a time.
clilley: SVG has had "named views" for forever, that give
default zoom/pan when you link into a particular view.
TabAtkins: And today you just hide all fo them, and show one
with the :target pseudo-class.
smailus: Might be interesting to have an actual element for
this.
shepazu: I think having a bunch of use-cases spelled out would
be useful.
... Like "if I zoom out, do I see all of them?" is useful.
... It sounds like a slideshow, but maybe it's wider than that.
... Bring up printing - printing just one, or maybe you want to
print all of them sequentially.
... Maybe talk to Dave Cramer from Hachette for details on CSS
integration.
... Is this the entirety of what you think is necessary to
replace CGM?
smailus: We did a study 3 years ago of implementing a tech on
top of CGM (so we could get away from CGM via ActiveX), there
was still a ton of things missing and bugs, etc.
... We said "forget WebCGM, we'll go with SVG", it seemed to
have a larger user-base and interest.
... So currently our CAD systems export to CGM.
... The 787 docs are currently being converted from being
delivered in CGM to being delivered in SVG.
... So over the next year or two, in theory, everyone getting
787 docs will get them in SVG, so they can use whatever
browser/viewer they want.
shepazu: I'd like for SVG2, then, to address all your cases for
CGM, so we can say "SVG replaces CGM".
... So please make sure you figure out all the reqs, and tell
them to us.
smailus: I'm still trying to find all the diagrams and see what
features are being used; they're all around.
shepazu: I think it's a good goal to push forward with these as
a goal.
<nikos> Applicability of CGM versus SVG for technical graphics:
[49]http://www.cgmopen.org/technical/cgm-svg-20030508-2.htm
[49] http://www.cgmopen.org/technical/cgm-svg-20030508-2.htm
<Tav> [50]http://tavmjong.free.fr/SVG/MITER_LIMIT/index.html
[50] http://tavmjong.free.fr/SVG/MITER_LIMIT/index.html
Summary of Action Items
[NEW] ACTION: BogdanBrinza to discuss this issue with the
Responsive Image Group [recorded in
[51]http://www.w3.org/2014/10/31-svg-minutes.html#action04]
[NEW] ACTION: BogdanBrinza to drive the assessment of SVG2 to
get it to LCWD by the February F2F [recorded in
[52]http://www.w3.org/2014/10/31-svg-minutes.html#action06]
[NEW] ACTION: BogdanBrinza to publish hinting requirements
document [recorded in
[53]http://www.w3.org/2014/10/31-svg-minutes.html#action03]
[NEW] ACTION: Brian to follow up on template - file bugs and
investigate the stand alone case [recorded in
[54]http://www.w3.org/2014/10/31-svg-minutes.html#action07]
[NEW] ACTION: ChrisL make all svg wg specifications
discoverable, due december [recorded in
[55]http://www.w3.org/2014/10/31-svg-minutes.html#action05]
[NEW] ACTION: stakagi to spec that calculation of CTMs should
use double precision [recorded in
[56]http://www.w3.org/2014/10/31-svg-minutes.html#action02]
[NEW] ACTION: Tab to find someone at Blink to implement support
for all html elements directly in svg [recorded in
[57]http://www.w3.org/2014/10/31-svg-minutes.html#action08]
[NEW] ACTION: Tab to help Brian describe layout for HTML in SVG
integration [recorded in
[58]http://www.w3.org/2014/10/31-svg-minutes.html#action09]
[NEW] ACTION: Tab to try putting SVG elements in the HTML
namespace in Blink and see what breaks [recorded in
[59]http://www.w3.org/2014/10/31-svg-minutes.html#action10]
[NEW] ACTION: Takagi-san to spec that calculation of CTMs
should use double precision [recorded in
[60]http://www.w3.org/2014/10/31-svg-minutes.html#action01]
[End of minutes]
__________________________________________________________
Minutes formatted by David Booth's [61]scribe.perl version
1.138 ([62]CVS log)
$Date: 2014-10-31 22:58:11 $
__________________________________________________________
[61] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[62] http://dev.w3.org/cvsweb/2002/scribe/
Scribe.perl diagnostic output
[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.138 of Date: 2013-04-25 13:59:11
Check for newer version at [63]http://dev.w3.org/cvsweb/~checkout~/2002/
scribe/
[63] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/
Guessing input format: RRSAgent_Text_Format (score 1.00)
Succeeded: s/ltaer/later/
Succeeded: s/???/Mark/
Succeeded: s/important 20%/non-important 80%/
Succeeded: s/moderate that expectation/moderate that expectation by tell
ing them what the goal of the spec is, and iterating quickly/
Succeeded: s/when we talk about SVG2, people have high expectations/when
we talk about SVG2, people have high expectations, so we should maybe d
rop the 2 and just publish more often/
Succeeded: s/SVG in HTML/HTML in SVG/
Succeeded: s/apst/past/
Succeeded: s/element.baseVal/element.className.baseVal/
Succeeded: s/the animated links/SVGAnimatedLength/
Succeeded: s/shans_/shepazu/
Succeeded: s/shans_/shepazu/
Succeeded: s/WebCGM/CGM/
Succeeded: s/screw/forget/
Found ScribeNick: cabanier
Found ScribeNick: birtles
Found Scribe: birtles
Inferring ScribeNick: birtles
Found Scribe: nikos
Inferring ScribeNick: nikos
Found ScribeNick: nikos
Found ScribeNick: TabAtkins
Scribes: birtles, nikos
ScribeNicks: cabanier, birtles, nikos, TabAtkins
Present: mark_kilgard_(nvidia) rik dirk shane brian jun nikos thomas tak
agi tav chris ed
Agenda: [64]https://www.w3.org/Graphics/SVG/WG/wiki/F2F/TPAC_2014/Agenda
#Friday_09.00_-_10.30
Got date from IRC log name: 31 Oct 2014
Guessing minutes URL: [65]http://www.w3.org/2014/10/31-svg-minutes.html
People with action items: bogdanbrinza brian chrisl stakagi tab takagi-s
an
[64]
https://www.w3.org/Graphics/SVG/WG/wiki/F2F/TPAC_2014/Agenda#Friday_09.00_-_10.30
[65] http://www.w3.org/2014/10/31-svg-minutes.html
[End of [66]scribe.perl diagnostic output]
[66] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
--
Erik Dahlstrom, Web Technology Developer, Opera Software
Co-Chair, W3C SVG Working Group
Received on Friday, 31 October 2014 23:00:51 UTC