Minutes, 11 December 2014 SVG WG telcon

Formatted minutes are at:
    www.w3.org/2014/12/11-svg-minutes.html<http://www.w3.org/2014/12/11-svg-minutes.html>

As text:

   [1]W3C

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

                               - DRAFT -

                    SVG Working Group Teleconference

11 Dec 2014

   [2]Agenda

      [2] http://lists.w3.org/Archives/Public/public-svg-wg/2014OctDec/0084.html

   See also: [3]IRC log

      [3] http://www.w3.org/2014/12/11-svg-irc

Attendees

   Present
   Regrets
          Chris

   Chair
          Cameron

   Scribe
          nikos

Contents

     * [4]Topics
         1. [5]Confirming date for June 2015 F2F
         2. [6]GitHub repo mails to www-svg
         3. [7]Shutting down public-svg-wg
         4. [8]SVG Accessibility
         5. [9]Spec annotations
         6. [10]Making <use> style inheritance author controllable
         7. [11]SVG to png
     * [12]Summary of Action Items
     __________________________________________________________

   <trackbot> Date: 11 December 2014

   <scribe> Scribe: nikos

   <scribe> Scribenick: nikos

Confirming date for June 2015 F2F

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

     [13] https://www.w3.org/Graphics/SVG/WG/wiki/F2F/Linkoping_2015

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

     [14] 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
   [15]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>
   [16]http://www.w3.org/TR/2014/WD-annotation-model-20141211/

     [16] 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> [17]https://notes.webplatform.org/

     [17] 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> [18]http://www.w3.org/community/spec-annotation/

     [18] 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:
   [19]http://webcomponents.org/articles/introduction-to-template-
   element/ (link to spec is at the end)

     [19] http://webcomponents.org/articles/introduction-to-template-element/

   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

   +1

   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> [20]https://svgwg.org/svg2-draft/struct.html#UseElement

     [20] 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:
   [21]http://xn--dahlstrm-t4a.net/svg/canvas/svg-to-jpeg.html

     [21] 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

Summary of Action Items

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

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