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

non-scaling dash patterns

<ed> -- 15min break --

New charter and priorities

<ed> http://www.w3.org/Graphics/SVG/2014/new-charter

<ed> https://www.w3.org/Graphics/SVG/WG/wiki/Roadmap

ed: this is the charter document

Rossen: I had a quick question

<Tav> 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> 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> 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 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].

New charter and priorities

Icon use problems

<shepazu> 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> http://www.w3.org/Graphics/SVG/2014/new-charter

<ed> 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> https://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Planning_Page

<ChrisL> 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 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 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> https://svgwg.org/svg2-draft/changes.html

Using HTML elements directly in SVG

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

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 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> 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: 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?

<ed> 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: http://www.cgmopen.org/technical/cgm-svg-20030508-2.htm

<Tav> http://tavmjong.free.fr/SVG/MITER_LIMIT/index.html

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