See also: IRC log
<birtles> ed: where are you guys?
<birtles> cyril? cabanier? krit?
<cabanier> scribenick: cabanier
mark: thank you for having me
... 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
chrisl: so you can keep the path so you don't have to tesselate or break beziers into lines
... 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?
... 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
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
... 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
... 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)
<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
... 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: 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 http://www.w3.org/2014/10/31-svg-minutes.html#action01]
<trackbot> Error finding 'Takagi-san'. You can review and register nicknames at <http://www.w3.org/Graphics/SVG/WG/track/users>.
<scribe> ACTION: stakagi to spec that calculation of CTMs should use double precision [recorded in 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
<ed> -- 15min break --
ed: this is the charter document
Rossen: I had a quick question
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
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
... 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: 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?
Rossen_: there was a patch that
was going to be landed in Firefox to allow to inherit colors
... 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?
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
... 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 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 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].
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
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
... 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
... the second part is that we should sign up to specific deadlines
... and we should take out features that are not ready
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
... 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
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 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
... 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
... 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
<scribe> ACTION: BogdanBrinza to drive the assessment of SVG2 to get it to LCWD by the February F2F [recorded in 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?
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
... 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?
... 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
... 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
... having to remember the xhtml ns is a real pain
... so Tab you prefer allowing html elements direclty?
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
... e.g. adding a second div would break things and confuse people
... any other votes of preference?
ChrisL: I like the new shrink
... 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
... 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
... 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 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?
<scribe> ACTION: Tab to find someone at Blink to implement support for all html elements directly in svg [recorded in 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 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
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
... 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
... 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
... 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 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: 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.
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
... 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.
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.
shepazu: Some of you have seen my
... 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.
smailus: We talked about this
... 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?
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.
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
... 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: http://jsfiddle.net/ae062r9g/1/ (buggy in FF, OK in Safari and Chrome)
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?
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
... 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: http://www.cgmopen.org/technical/cgm-svg-20030508-2.htm
This is scribe.perl Revision: 1.138 of Date: 2013-04-25 13:59:11 Check for newer version at 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 telling 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 drop 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 takagi tav chris ed Agenda: 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: http://www.w3.org/2014/10/31-svg-minutes.html People with action items: bogdanbrinza brian chrisl stakagi tab takagi-san[End of scribe.perl diagnostic output]