Re: Minutes, 8 December 2016 SVG WG telcon

Hi Paul (& everyone),

For community members wanting to move SVG forward, I think we have three

   1. Create a comprehensive test suite that clearly represents how new
   *and* old features should work.
   2. Create JS polyfills, wherever possible, to generate correct rendering
   of new features from SVG 2-compatible markup.
   3. Submit actual implementation patches to the open source rendering

The first two points could be pursued at the same time; the third might
need to wait on those two.  I suspect that any pull requests on the browser
engines won't get much traction until there is, at least, a definitive test
to compare it against, and ideally some examples of content creators
already trying to use the feature.

It didn't make it to the published minutes, but we tentatively agreed to
spend next week's call discussing the test suite.  Even if no new major
features are ever implemented, there are countless little details which
weren't well covered in the SVG 1.1 test suite (resulting in incompatible
renderings), and there are SVG 2 features like paint-order and
non-scaling-stroke which already have wide implementations.

Test suite creation will probably need to be community-driven. Perhaps
through a W3C community group, which have fewer barriers to participation
compared to the full working group.  Nikos has been working on trying to
convert the SVG 1.1 tests to the Web Platform Tests framework (, so we're starting to get an
idea of what the roadblocks are likely to be.

The same community group might be a good forum for coordinating any
SVG-feature polyfills the individuals are working on.  I don't expect there
to be many new features where JS polyfills will be a practical,
high-performance solution for rendering, but they will certainly help as
test implementation & to increase interest & feedback from content creators.

And of course, I don't want to discourage anyone from working on actual

If that's your interest, get in touch with the teams working on them.  The
lists of what each team intends to support were almost certainly limited by
available human resources.  If they get an influx of new devs who are eager
to improve SVG rendering, that might change things considerably. And if any
companies or groups want to sponsor development (e.g., as Bloomberg
sponsored CSS Grid implementations), I'm sure talented developers could be


On 8 December 2016 at 21:32, Paul LeBeau <> wrote:

> Well that makes for depressing reading. :(
> What would be the best way to get the vendors interested in implementing
> SVG 2 features?  Is it at the point where it is going to be up to motivated
> third parties to submit patches?
> Would they become more interested if an SVG 2 polyfill resulted in lots of
> content being produced?
> Paul
> On 9 December 2016 at 13:20, Nikos Andronikos <
>> wrote:
>>    [1]W3C
>>       [1]
>>                                - DRAFT -
>>                     SVG Working Group Teleconference
>> 08 Dec 2016
>>    [2]Agenda
>>       [2]
>>    See also: [3]IRC log
>>       [3]
>> Attendees
>>    Present
>>           nikos, stakagi, AmeliaBR, Tav, shepazu
>>    Regrets
>>    Chair
>>           Nikos
>>    Scribe
>>           nikos
>> Contents
>>      * [4]Topics
>>          1. [5]SVG 2 feature feedback
>>      * [6]Summary of Action Items
>>      * [7]Summary of Resolutions
>>      __________________________________________________________
>>    <scribe> scribe: nikos
>> SVG 2 feature feedback
>>    [8]
>>    FG2sjaJ8V8TCP5rWLZK0AxA/edit?usp=sharing
>>       [8]
>> FG2sjaJ8V8TCP5rWLZK0AxA/edit?usp=sharing
>>    nikos: We have feedback from MS, Google, and FireFox
>>    ... it's not very promising. Lots of 'don't support'
>>    ... I would like to get some context - is this we won't ever
>>    support, or we don't have time to work in the next year
>>    Tav: I think I'm going to end my involvement. This is basically
>>    nothing
>>    ... InkScape will probably move away from SVG too
>>    shepazu: Just because Microsoft won't implement things, doesn't
>>    mean we won't get other implementations
>>    AmeliaBR: As you said Nikos, we need to get clarification if
>>    this is just this year or ever
>>    ... certainly not supporting text in shape is rather strange
>>    when some browsers already support shape-text in css
>>    shepazu: not supporting text-orientation? That's weird
>>    AmeliaBR: that's already been fully implemented in places
>>    Tav: yeah I guess it should be clarified. But this basically
>>    says SVG 2 is dead as far as I can tell
>>    ... there's really almost nothing in here
>>    AmeliaBR: it looks like they've gone through and marked what
>>    they are actually working on
>>    ... I think text-transform is already supported in all browsers
>>    and has been marked as a X
>>    nikos: Seems like next stage is to have a discussion with the
>>    people who gave feedback
>>    AmeliaBR: The problem we have is the people who are
>>    representatives are not the people who use or implement SVG
>>    ... we see it on GitHub where the people filing issues are not
>>    the people who are representatives
>>    <stakagi> We are now developing to implement the implementation
>>    of vector-effect and embedded content to firefox.
>>    AmeliaBR: having people who are graphically involved with the
>>    authoring process is important for understanding the pain
>>    points, etc
>>    ... it needs to be said, without browser support for advanced
>>    SVG. Is the SVG spec naturally going to fork? Is there still a
>>    desire for an open format for vector graphics?
>>    ... if you can't use those vector graphics in web sites?
>>    ... We would basically need specialised graphics software -
>>    Adobe and possibly others, to get involved
>>    ... is there support for going ahead with standardisation of a
>>    version of SVG with advanced graphical features?
>>    ... and is there enough support in the W3C to continue that?
>>    ... or is SVG as an advanced graphics language dead? And all
>>    that is useful at this point is to standardise it as it is
>>    currently supported in web browsers
>>    ... and clean up cross browser incompatibilities without adding
>>    new features
>>    nikos: My feeling is that you would be looking at a different
>>    set of W3C members to support SVG as a general open format for
>>    vectors
>>    Tav: I had an interesting discussion with someone - was talking
>>    about a mesh gradient poly fill in Canvas. He noted that Canvas
>>    has great support and could see where SVG is hitting a wall
>>    shepazu: The browsers have for a long time wanted to reduce
>>    features and optimise for polyfills and script implementation
>>    of features
>>    ... their attitude towards SVG seems to reflect taht
>>    ... I heard discussions about this at TPAC. They were oblivious
>>    to the fact that without script none of these features work
>>    ... and all these features using script reduces performance
>>    client side
>>    ... and the fidelity and ability of the language
>>    ... I'm very disappointed by these results
>>    ... To be frank, I don't think they're thinking very deeply
>>    about the problems on the web. Developers rather than browsers
>>    are leading the way
>>    nikos: The things the browser vedors seem to want to work on
>>    are based on what the engineers want and the code they know
>>    well and that's pretty sad
>>    Tav: In terms of manpower. Where are we? We have two people
>>    leaving at the end of the year.
>>    shepazu: W3C will put a staff contact on if there's interest
>>    from the browsers in getting the cleaned up version of SVG 2
>>    completed
>>    nikos: I'd be willing to put in my own time if there's interest
>>    in new features and not just butchering the spec. There's
>>    little motivation for me to do that.
>>    AmeliaBR: what I expect would happen is move SVG under CSSWG
>>    and the spec will be a tiny fraction of what we've been working
>>    on
>>    shepazu: I'm not totally pessimistic. Think there's a chance
>>    for some CSS related features to be pushed forward.
>>    nikos: Ok so let's talk about what our plan is now
>>    shepazu: Tav has made it pretty clear what his plan is
>>    Tav: I will definitely go ahead and do SVG 2 text - the way I
>>    wrote it there's SVG 1.1 fallback
>>    ... so that will get done and will replace SVG 1.2 text
>>    ... mesh gradients are going to be released
>>    nikos: Good. I think InkScape totally following the SVG spec is
>>    unnecessary. It should push ahead
>>    Tav: It will - carefully
>>    shepazu: If things are to move to incubation. There's a
>>    possibility of doing some stuff in an incubator group
>>    ... maybe it's time for developers to look at it from a
>>    polyfill perspective and take control of SVG, because the
>>    browsers don't seem to be leading on it
>>    <stakagi> +1
>>    Tav: I had problems with mesh gradients because there's no way
>>    to embed a canvs in an svg shape
>>    shepazu: Think we could get traction with that because that's
>>    the direction they want to go in
>>    Tav: I came across bugs in Chrome and Firefox that blocked me
>>    ... haven't documented them yet - was going to bring them up
>>    with the group
>>    shepazu: When you get the chance, you should file some bugs
>>    nikos: Houdini custom paint is promising. I have a feeling it
>>    may not be powerful enough for that sort of pixel bashing.
>>    ... It's something we should have a go at so we can provide
>>    feedback
>>    Tav: I can provide some topics for next week if we want to talk
>>    about this
>>    nikos: Ok. It's worth documenting them
>>    ... Let's call the meeting there
>>    RRSAgent: make minutes
>> Summary of Action Items
>> Summary of Resolutions
>>    [End of minutes]
>> The information contained in this email message and any attachments may
>> be confidential and may also be the subject to legal professional
>> privilege. If you are not the intended recipient, any use, interference
>> with, disclosure or copying of this material is unauthorised and
>> prohibited. If you have received this email in error, please immediately
>> advise the sender by return email and delete the information from your
>> system.

Received on Friday, 9 December 2016 17:43:39 UTC