W3C home > Mailing lists > Public > public-svg-wg@w3.org > October to December 2014

Minutes SVG @ TPAC 2014 Day 2

From: Erik Dahlstrom <ed@opera.com>
Date: Fri, 31 Oct 2014 16:00:18 -0700
To: "www-svg@w3.org" <www-svg@w3.org>
Message-ID: <op.xol96sqcgeuyw5@meh>


as text:


       [1] http://www.w3.org/

                                - DRAFT -

                          SVG @ TPAC 2014 Day 2

31 Oct 2014



    See also: [3]IRC log

       [3] http://www.w3.org/2014/10/31-svg-irc


           mark_kilgard_(nvidia), rik, dirk, shane, brian, jun,
           nikos, thomas, takagi, tav, chris, ed


           birtles, nikos


      * [4]Topics
          1. [5]NVidia presentation
          2. [6]Deeper investigation of the accuracy of the
             coordinates on rendering
          3. [7]non-scaling dash patterns
          4. [8]New charter and priorities
          5. [9]predictable SVG raster output
          6. [10]New charter and priorities
          7. [11]Icon use problems
          8. [12]New charter and priorities
          9. [13]Using HTML elements directly in SVG
         10. [14]Putting SVG elements in HTML namespace
         11. [15]Demos
         12. [16]Demo from Mark Sadecki
         13. [17]Demo from Doug
         14. [18]Non-scaling line patterns
         15. [19]Minimal rendered stroke width
      * [20]Summary of Action Items

    <birtles> ed: where are you guys?

    <birtles> cyril? cabanier? krit?

    <cabanier> scribenick: cabanier

NVidia presentation

    mark: thank you for having me here
    ... these are various SVG files
    ... we've been working on making vector graphics fast
    ... for hires and tablets
    ... this is one of the testbeds
    ... we have and compare against cairo
    ... we render all text from outlines and it is super fast
    ... I work for NVidia and happen to be in town
    ... SVG is different from how OpenGL is done
    ... Used to think that 2D was iineffective but changed my mind
    ... (overview of history of 2D vs 3D graphics)
    ... most 3d works is moving 2d closer to 3d
    ... so most work has not been that successful
    ... MS has been making good progress
    ... path rendering is one of the areas that has seen
    ... 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
    ... 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

    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

    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)



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

    stakagi: the slider changes the zoom ratio by changing the CTM
    (via the viewBox)
    ... the setTileOffset field shifts the origin of the user space
    ... This is the coordinate transformation operation equivalent
    to tiling of this proposal.
    ... e.g. we can set it to 1000000000
    ... then you see that when we zoom in, the origin vibrates
    ... this demonstrates the error introduced
    ... but I made a polyfill that computes the origin with double
    precision which suppresses the error

    krit: would double-precision solve the issue?
    ... it is up to the implementation to do that
    ... the SVG 1.1 says that it's up to the implementation to use
    double or not
    ... so it's up to the implementation to use double or not

    shepazu: do our hardware requirements from 2001 still make
    sense today or should be reconsider these today?
    ... does those assumptions still make sense?

    krit: as far as I know, double-precision can still be up to 4
    times slower on mobile devices

    cabanier: DOMMatrix requires double

    ChrisLilley: stakagi was saying that we only need double for
    coordinating the CTM, not for rendering

    <cabanier> spec: [22]http://dev.w3.org/fxtf/geometry/#DOMMatrix

      [22] http://dev.w3.org/fxtf/geometry/#DOMMatrix

    ChrisLilley: I think that's useful to put in the spec
    ... I propose that we accept this

    <scribe> ACTION: Takagi-san to spec that calculation of CTMs
    should use double precision [recorded in

    <trackbot> Error finding 'Takagi-san'. You can review and
    register nicknames at

      [24] http://www.w3.org/Graphics/SVG/WG/track/users%3E.

    <scribe> ACTION: stakagi to spec that calculation of CTMs
    should use double precision [recorded in

    <trackbot> Created ACTION-3674 - Spec that calculation of ctms
    should use double precision [on Satoru Takagi - due

    <ChrisLilley> trackbot, status

non-scaling dash patterns

    <ed> -- 15min break --

New charter and priorities

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

      [26] http://www.w3.org/Graphics/SVG/2014/new-charter

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

      [27] https://www.w3.org/Graphics/SVG/WG/wiki/Roadmap

    ed: this is the charter document

    Rossen: I had a quick question

    <Tav> [28]https://www.w3.org/Graphics/SVG/WG/wiki/Topics

      [28] https://www.w3.org/Graphics/SVG/WG/wiki/Topics

predictable SVG raster output

    BogdanBrinza: we came to this topic after discussing at MS with
    our Office teams etc. with regards to how they think of icons /
    graphic assets
    ... Office has about 10k icons with various resolutions
    ... Visual Studio have about 3k
    ... they have a team that just manage icons, create raster
    icons from vector icons etc.
    ... we want them to use SVG end-to-end
    ... we've asked, "what is stopping you from doing this today?"
    ... what they provided as a prioritized list of reasons
    ... one of the first things is that as a designer it's
    impossible to control raster output
    ... they are producing office publications, desktop
    publications etc.
    ... they have a range of resolutions
    ... they have an SVG icon master, suppose they set scale factor
    ... 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 that later
    ... the second issue is lack of support in non-Web frameworks:
    ... the alternative is to use fonts which is where they're
    ... the advantage is that they work well with native and Web
    ... 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
    ... they cannot be combined with external resources for
    efficient workflows

    (keyframe animations meaning you need to put every frame in the

    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
    ... that blows up the set even more
    ... those hinting algorithms are proprietary to every platform

    BogdanBrinza: those hinting algorithms are proprietary to every
    ... 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



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

    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

    <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

    <trackbot> Created ACTION-3676 - Discuss this issue with the
    responsive image group [on Bogdan Brinza - due 2014-11-07].

New charter and priorities

Icon use problems

    <shepazu> [33]http://jeremie.astori.fr/svg_tests.html

      [33] http://jeremie.astori.fr/svg_tests.html

    shepazu: this is a slightly different set of problems
    ... this is someone who was working with the W3C
    ... he said he wanted to use SVG in his resume but had some
    ... discussion about how some of these problems can be fixed,
    e.g. using pointer-events

New charter and priorities

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

      [34] http://www.w3.org/Graphics/SVG/2014/new-charter

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

      [35] https://www.w3.org/Graphics/SVG/WG/wiki/Roadmap

    ChrisL: I changed the roadmap after it went out for review so
    that the dates were no longer in the past
    ... apart from that these are numbers I made up

    Rossen_: this was not my topic, but I had mostly questions
    ... I think about 6 months at the Leipzig meeting someone say
    we wanted to go to LC and lock down the spec
    ... at that time I wasn't following the spec too closely but I
    wasn't following too closely
    ... but at this point I don't see that
    ... nor do I see the kind of features / work that suggests we
    will get to a shipping state soon
    ... do we intend to ship? or just keep it open and work on it
    ... 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

    krit: yes, we want to ship SVG2
    ... the second part is that we should sign up to specific
    ... and we should take out features that are not ready


      [36] https://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Planning_Page


      [37] https://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input

    krit: we shouldn't worry about getting everything in just
    because it's the big "2"

    <krit> ack, krit

    Rossen_: if the priorities are set

    shepazu: we could focus on the particular problems each edition
    of the spec is going to solve
    ... e.g. this iteration was focussed on this set of problems,
    from a functional point of view

    Rossen_: in its current state, is there anything that is stable
    and ready to ship?

    shepazu: have you guys implemented non-scaling-stroke?

    Rossen_: is there a version of the spec we can have today that
    is stable
    ... if there's nothing in the spec that is stable, then that
    sends a message to implementors
    ... we should find the stable parts of the spec and ship that
    ... and keep working on the other parts in parallel

    <dbaron> +1 to shipping smaller releases, and not delaying them
    in order to get more things in

    Rossen_: I'm not necessarily arguing we should go more modules

    ChrisL: some features are hard to label, like cleaning up the
    namespace stuff
    ... not requiring xlink

    BlackCatkins: I agree with the general thrust with shipping the
    stable subset of SVG

    <Tav> +q

    BlackCatkins: but I want to know why we failed with
    modularization in SVG

    shepazu: I think we have not failed with modularization
    ... that's the stuff we're working on the FXTF
    ... but the problem is the monolithic main spec

    BlackCatkins: when we initially tried to do modularization part
    of the problem was knowing where everything was
    ... discoverability of specifications is poor
    ... we need to fix that

    Cyril: when we talk about SVG2, people have high expectations,
    so we should maybe drop the 2 and just publish more often

    <ChrisL> ACTION: ChrisL make all svg wg specifications
    discoverable, due december [recorded in

    <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

    <trackbot> Created ACTION-3678 - Drive the assessment of svg2
    to get it to lcwd by the february f2f [on Bogdan Brinza - due

    RESOLUTION: We will prepare SVG2 for LCWD by the February F2F

    shepazu: honestly, besides the things we need to clean up, for
    a lot of people, if all we fixed was xlink and wrapping text, I
    think a lot of people would be happy with that

    <nikos> scribe: nikos

    <scribe> scribenick: nikos

    <smailus> we are not moving the repo again are we?

    <Cyril> [40]https://svgwg.org/svg2-draft/changes.html

      [40] https://svgwg.org/svg2-draft/changes.html

Using HTML elements directly in SVG



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

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

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

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

    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

    birtles: other difference is the ns thing

    Cyril: fixing the fo problem by adding another element is
    ... 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
    ... 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

    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

    <scribe> ACTION: Brian to follow up on template - file bugs and
    investigate the stand alone case [recorded in

    <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

    <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

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

    <birtles> (HTML: element.className, SVG:

    shepazoOoOoOo: I know people are using legacy versions of
    jquery so we may not be able to ask them to change the

    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

    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

    <scribe> ACTION: Tab to try putting SVG elements in the HTML
    namespace in Blink and see what breaks [recorded in

    <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

    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
    ... 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
    ... 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
    ... 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
    ... 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
    ... 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
    ... 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
    ... 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
    ... I'd like to emphasize that you have to worry about your
    ... 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

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
    ... [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
    ... 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

    smailus: So here are some examples of how CGM renders text in a
    ... 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

    smailus: Yeah, you can author as you want.
    ... Now there's an effect called 'limited scaling stroke'.
    ... At this spot [on the graph] you've got some strokes that
    need to be maintained (non-scaling) so they're visible when
    super-zoomed out, but when you get zoomed in enough you want to
    switch back into normal scaling.

    Tav: So a min-stroke-width could do this part.

    <nikos> Non scaling dash array works as expected:
    [47]http://jsfiddle.net/ae062r9g/1/ (buggy in FF, OK in Safari
    and Chrome)

      [47] http://jsfiddle.net/ae062r9g/1/

    TabAtkins: No, coordinate space changes with the zoom, so it
    doesn't actually cange.

    smailus: So I suggest a "limited-scaling-stroke" value.

    TabAtkins: Maybe a better name to make it clear "no shrinking
    to invisibility"?

    shepazu: Are we really planning to do this via a
    'vector-effect' property?


      [48] https://svgwg.org/svg2-draft/painting.html#VectorEffectProperty

    clilley: Yes.

    smailus: Looks like the zomoAndPan attribute disappeared.
    ... In SVG2 draft there's a stronger commitment to "make sure
    panning and zooming are implemented".
    ... My rec is that we also add "rotate" to taht list of "things
    you need to support".

    TabAtkins: How is zoom and pan different from scrolling and

    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

    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
    ... Is this the entirety of what you think is necessary to
    replace CGM?

    smailus: We did a study 3 years ago of implementing a tech on
    top of CGM (so we could get away from CGM via ActiveX), there
    was still a ton of things missing and bugs, etc.
    ... We said "forget WebCGM, we'll go with SVG", it seemed to
    have a larger user-base and interest.
    ... So currently our CAD systems export to CGM.
    ... The 787 docs are currently being converted from being
    delivered in CGM to being delivered in SVG.
    ... So over the next year or two, in theory, everyone getting
    787 docs will get them in SVG, so they can use whatever
    browser/viewer they want.

    shepazu: I'd like for SVG2, then, to address all your cases for
    CGM, so we can say "SVG replaces CGM".
    ... So please make sure you figure out all the reqs, and tell
    them to us.

    smailus: I'm still trying to find all the diagrams and see what
    features are being used; they're all around.

    shepazu: I think it's a good goal to push forward with these as
    a goal.

    <nikos> Applicability of CGM versus SVG for technical graphics:

      [49] http://www.cgmopen.org/technical/cgm-svg-20030508-2.htm

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

      [50] http://tavmjong.free.fr/SVG/MITER_LIMIT/index.html

Summary of Action Items

    [NEW] ACTION: BogdanBrinza to discuss this issue with the
    Responsive Image Group [recorded in
    [NEW] ACTION: BogdanBrinza to drive the assessment of SVG2 to
    get it to LCWD by the February F2F [recorded in
    [NEW] ACTION: BogdanBrinza to publish hinting requirements
    document [recorded in
    [NEW] ACTION: Brian to follow up on template - file bugs and
    investigate the stand alone case [recorded in
    [NEW] ACTION: ChrisL make all svg wg specifications
    discoverable, due december [recorded in
    [NEW] ACTION: stakagi to spec that calculation of CTMs should
    use double precision [recorded in
    [NEW] ACTION: Tab to find someone at Blink to implement support
    for all html elements directly in svg [recorded in
    [NEW] ACTION: Tab to help Brian describe layout for HTML in SVG
    integration [recorded in
    [NEW] ACTION: Tab to try putting SVG elements in the HTML
    namespace in Blink and see what breaks [recorded in
    [NEW] ACTION: Takagi-san to spec that calculation of CTMs
    should use double precision [recorded in

    [End of minutes]

     Minutes formatted by David Booth's [61]scribe.perl version
     1.138 ([62]CVS log)
     $Date: 2014-10-31 22:58:11 $

      [61] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
      [62] http://dev.w3.org/cvsweb/2002/scribe/

Scribe.perl diagnostic output

    [Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.138  of Date: 2013-04-25 13:59:11
Check for newer version at [63]http://dev.w3.org/cvsweb/~checkout~/2002/

      [63] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/ltaer/later/
Succeeded: s/???/Mark/
Succeeded: s/important 20%/non-important 80%/
Succeeded: s/moderate that expectation/moderate that expectation by tell
ing them what the goal of the spec is, and iterating quickly/
Succeeded: s/when we talk about SVG2, people have high expectations/when
  we talk about SVG2, people have high expectations, so we should maybe d
rop the 2 and just publish more often/
Succeeded: s/SVG in HTML/HTML in SVG/
Succeeded: s/apst/past/
Succeeded: s/element.baseVal/element.className.baseVal/
Succeeded: s/the animated links/SVGAnimatedLength/
Succeeded: s/shans_/shepazu/
Succeeded: s/shans_/shepazu/
Succeeded: s/WebCGM/CGM/
Succeeded: s/screw/forget/
Found ScribeNick: cabanier
Found ScribeNick: birtles
Found Scribe: birtles
Inferring ScribeNick: birtles
Found Scribe: nikos
Inferring ScribeNick: nikos
Found ScribeNick: nikos
Found ScribeNick: TabAtkins
Scribes: birtles, nikos
ScribeNicks: cabanier, birtles, nikos, TabAtkins
Present: mark_kilgard_(nvidia) rik dirk shane brian jun nikos thomas tak
agi tav chris ed
Agenda: [64]https://www.w3.org/Graphics/SVG/WG/wiki/F2F/TPAC_2014/Agenda
Got date from IRC log name: 31 Oct 2014
Guessing minutes URL: [65]http://www.w3.org/2014/10/31-svg-minutes.html
People with action items: bogdanbrinza brian chrisl stakagi tab takagi-s

      [65] http://www.w3.org/2014/10/31-svg-minutes.html

    [End of [66]scribe.perl diagnostic output]

      [66] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm

Erik Dahlstrom, Web Technology Developer, Opera Software
Co-Chair, W3C SVG Working Group
Received on Friday, 31 October 2014 23:00:51 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:20:20 UTC