SVG Working Group Teleconference -- 11 Dec 2014

<trackbot> Date: 11 December 2014

<scribe> Scribe: nikos

<scribe> Scribenick: nikos

Confirming date for June 2015 F2F

<heycam> https://www.w3.org/Graphics/SVG/WG/wiki/F2F/Linkoping_2015

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

ed: wiki page created
... suggest we meet over 4 days
... 2nd June - 5th June is my suggestion
... if people would prefer to start on Monday we could do that

heycam: dates look ok for me
... looks like CSS are meeting mid to late May in US

ed: I was talking to a guy at a computer club around here and they might be interested in having a conference night

heycam: is it a general computer club or specific?

ed: not sure, but probably have connections over Sweden and if we organise with enough notice can send out an invite
... we've had conference nights before - seems like a good idea to me

heycam: agree

GitHub repo mails to www-svg

heycam: we changed this a few weeks ago after some discussion
... emails are currently going to the private list
... Chris prefers that they go to www-svg list
... when we discussed this last time, my feeling was that might make the public list too noisy
... but I'd like to hear other opinions

shepazu: Are you using Dom's script?
... I believe it lets you target different kinds of message to different lists
... so we could do something like have pull requests go to public list and changes to private?
... I don't think we want all changes and updates going to the public list

heycam: that was my initial thought as well
... at the moment we're only sending emails when changes are pushed

shepazu: let me talk to Dom and see what his tool can do
... I agree with Chris that feedback should be on public list
... but commit messages are kind of noisy and it might turn people off

heycam: yes that's a worry

shepazu: I was probably the main advocate for closing public-sv
... we could repurpose instead of closing it down
... to make it a public read/write list and have github messages go there and technical stuff go to www-svg

nikos: is it possible to rename it? think it would be good to point out that it's for bot messages and stuff

shepazu: don't know if it's possible but we could make a different list

heycam: I think we want a list that people can subscribe to but no one (members or public) can post to
... but owners can send administrative stuff to

shepazu: let me find out if that's possible

heycam: I think it would be good to rename it too
... so I think that's a good solution - if you could look into that
... don't know how hard it is to get just bots posting to the list but we'll see

shepazu: I'll get back to you guys with options
... just to be clear - you want a list (say public-svg-logs) that bots can post to, humans can not post to, but humans can subscribe to

heycam: yes and perhaps with a reply-to to www-svg

Shutting down public-svg-wg

shepazu: I haven't done that yet

heycam: I want to see if there's anything left to redirect elsewhere
... tracker already watches the public lists. Think notifications go to public-svg
... so that might be the only thing left to change

shepazu: which ml do you want issue messages go to?

heycam: the new logs one if we can create that

shepazu: I don't know of any other things that need redirecting

<scribe> ACTION: Doug to look at creating public-svg-logs which bots can post to but humans cannot [recorded in http://www.w3.org/2014/12/11-svg-minutes.html#action01]

<trackbot> Created ACTION-3690 - Look at creating public-svg-logs which bots can post to but humans cannot [on Doug Schepers - due 2014-12-18].

SVG Accessibility

shepazu: I want to remind anyone interested that the first meeting of the accessibility TF will be tomorrow (Friday) at 9am US eastern time
... svg people are welcome
... it would be useful for svg experts to be there to help inform from their perspective
... I will be doing a demo of an svg accessibility tool that I'm writing
... it might be of interest to you guys
... above and beyond the one you saw at TPAC

Spec annotations

<shepazu> http://www.w3.org/TR/2014/WD-annotation-model-20141211/

shepazu: I know some of you are interested in annotations in the spec
... This is the first WD of the annotations spec

<shepazu> https://notes.webplatform.org/

shepazu: you can create an account and add annotations
... if we want to make SVG specs annotatable we can do that

<shepazu> http://www.w3.org/community/spec-annotation/

shepazu: there's an annotations CG
... have a play and see if it's something we'd like to do with our specs

nikos: I think it would be a really good thing to be able to do this to SVG specs

shepazu: agree, it's really good for those leaving as well as those resolving the feedback
... it's still experimental but we hope to get it there

Making <use> style inheritance author controllable

heycam: this is not something I've thought properly about yet
... but we have a plan to rewrite the use element to use shadow trees to define it's behaviour
... and that's good, but then it means we lose any chance of optimising the implementation to avoid having separate shadow trees in memory for each instance of the thing being used
... so I'm wondering whether we can have an opt-in to a particular use instance
... or maybe on the thing being used
... to say don't create an explicit shadow tree and cut off the style inheritance that use allows
... that would give a more contained rendering
... that would be a lot easier to replay at different positions on the canvas

TabAtkins: I was under the impression that we were defining in terms of shadow trees
... but weren't exposing it - like forms and whatnot

heycam: might be, not sure

TabAtkins: if it is we can share stuff because we don't need to worry about people poking and changing

heycam: I think the style inheritance issue is a difficulty too
... each instance of the use could look different
... makes it hard to have a single cached rendering

TabAtkins: however, not that a flag already exists in shadow dom to cut off inheritance
... so having an opt-in switch on the use element itself sounds reasonable to me
... it doesn't rely on anything beyond what we already have in the spec
... so shouldn't be a problem

shepazu: when we say 'cut off inheritance', are we talking style only or anything?

TabAtkins: shadow dom has a flag where styles will not inherit into the tree
... you'll go back to initial styles on the shadow root

shepazu: that could get hairy
... is that what you're talking about cam or something deeper?

heycam: that's pretty much what I'm talking about

shepazu: anything we do needs to be compatible with shadow dom - so that sounds ok
... who's in charge of rewriting in terms of shadow dom?

heycam: either me or maybe Tab

ed: I did some edits but not finished yet
... we had quite a bit of feedback that we should allow styling of each instance
... so wondering if we should allow css selectors to push through the boundary

TabAtkins: if we want to allow exposing shadow tree directly, we could expose it just to css via the deep combinator

ed: yeah that's what I'm talking about

shepazu: what are the performance implications of exposing or disinheriting script access
... could you optimise and then flip when you want access?

TabAtkins: problem with script is interaction between use and the defining instance
... any time you change defininig instance it needs to carry over to use instances
... it's difficult to track everything and manage memory
... css part doesn't matter so much

shepazu: does that also apply to generated content?

TabAtkins: yes basically

shepazu: I'm thinking you may want five shapes
... each has a different label
... I was thinking of it in terms of params and variables
... and thinking that if you wanted to have a primitive (thinking in terms of connectors)
... use case: five shapes for flowcharts - each can have text
... I was thinking we could accomplish that by defining the shape
... saying where text would be in the shape
... defining the ports (using my model)
... and using some combination of all these things to change the label for each one
... so I might use something and pass in params text='blah'
... wouldn't be accessible by screen readers so might not work for generated content

<heycam> use.node /deep/ text::before { content: "My Label"; }

TabAtkins: there's been discussions regarding generated content being more accessible

heycam: is any of that compatible with what cam is proposing?

TabAtkins: if you lock down the instance then it would block
... if you could style individually you could use a variable to set up the value and use generated content inside of there
... the template element - once it works in svg - gives us a more modifiable version of use
... because it has it's own dom and you can touch instances
... so we don't need to worry about use so much because template will give an option for when you want to modify instances

shepazu: is template effectively use (declare and then use)? or is template the thing that is reused?

TabAtkins: it's use without the shadow dom
... you can put out instances that have their own dom

shepazu: so syntax might be <head><template></head><body><stamp></body>

TabAtkins: yeah pretty much

<TabAtkins> Intro: http://webcomponents.org/articles/introduction-to-template-element/ (link to spec is at the end)

TabAtkins: stuff inside template is inert - won't make requests or play audio
... instances do that

shepazu: is this something we want in SVG?

TabAtkins: there's already some bugs/issues around this
... do we just make it an HTML element in SVG or what ?
... we know the problems - just need to work out the solutions

shepazu: who would be interested in allowing certain HTML namespace elements to be allowed bare in SVG?
... and who wants SVG equivalents instead?

<TabAtkins> +1

shepazu: straw poll - if you would be interested in white listing certain HTML elements in SVG ?

<Tav> -1

<ed> +1

<heycam> +1

things like audio, video, template would be good in the white list

richardschwerdtfeger: you're not considering text elements and span are you?

<heycam> but would like to avoid duplicating the elements in the SVG namespace, as we got pushback about that

shepazu: thinking of elements that have complex behaviours

richardschwerdtfeger: my only concern is it complicates the mapping for accessibility

<richardschwerdtfeger> +1 tentative

Tav: how do we deal with this stuff in an authoring tool?

nikos: that's one of the benefits of the white list - you can be picky about which you allow

Tav: yeah a white list might end up being ok

shepazu: I'd expect in InkScape you could show a blank box using the dimensions

Tav: do you need to use JS for template?

TabAtkins: you can do it all declaratively

shepazu: another quick poll - who likes the idea of a white list as a possible solution?

richardschwerdtfeger: what does a Canvas element mean - what would the fall back be?

shepazu: I'd prefer to white list canvas and canvas would be in the HTML namespace
... and you'd establish a HTML context for the canvas

richardschwerdtfeger: I think that would be best

shepazu: if we white list certain elements we only have to define any specific behaviours that apply in svg
... we could also define general behaviour for all elements in the white list
... but it seems silly to redefine these elements

TabAtkins: it doesn't cause any parsing issues either
... if we do anything with stand alone parsing later we can make it more convenient, but it's not neccessary

shepazu: to me this makes a good interim solution
... we can learn how this will play out

<heycam> +1

TabAtkins: I agree, it's a good first step and we are limiting the potential damage

heycam: so going back to the first question - whether it's sensible to allow author controlled cutting off of styling

TabAtkins: the answer is yes. It's possible in shadow dom
... it's basically free so it's an easy decision to make

heycam: Erik what were the edits you made?

ed: i put in some notes and issues

<ed> https://svgwg.org/svg2-draft/struct.html#UseElement

ed: I did some changes to the event handling parts, to say that events are dispatched according to shadow tree dispatching algo
... there's some issues in there to point out what's not defined in terms of web components

heycam: alright well I might add an issue in the spec about the styling cut off behaviour
... I don't have anything syntax wise to suggest yet

SVG to png

shepazu: anyone know that status of an api that allows you to generate a static rendering of an svg?

heycam: think we kind of talked about this in London
... don't think Jonathon had a concrete proposal

<ed> this is basically how complex it is to do via canvas: http://xn--dahlstrm-t4a.net/svg/canvas/svg-to-jpeg.html

shepazu: I was specifically talking about selecting a tree and rasterising it for download
... so we wouldn't have to go through canvas
... ok so nobody knows the status
... we talked about it a long time ago - I'll try to propose something similar to what canvas has

- DRAFT -

SVG Working Group Teleconference

11 Dec 2014

Attendees

Contents