See also: IRC log
<trackbot> Date: 11 December 2014
<scribe> Scribe: nikos
<scribe> Scribenick: nikos
<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
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
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].
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
<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
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
+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> 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
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
This is scribe.perl Revision: 1.140 of Date: 2014-11-06 18:16:30 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/md/mid/ Succeeded: s/teh/the/g Succeeded: s/audo/audio/ Succeeded: s/tempalte/template/ Succeeded: s/eitehr/either/ Succeeded: s/concret/concrete/ Succeeded: s/ahs/has/ Found Scribe: nikos Inferring ScribeNick: nikos Found ScribeNick: nikos WARNING: No "Present: ... " found! Possibly Present: Doug_Schepers IPcaller Intro P0 P4 P5 P6 Rich_Schwerdtfeger Scribenick Smailus TabAtkins Tav Thomas_Smailus aaaa ed heycam https jcraig joined nikos richardschwerdtfeger shepazu stakagi svg trackbot You can indicate people for the Present list like this: <dbooth> Present: dbooth jonathan mary <dbooth> Present+ amy Regrets: Chris Agenda: http://lists.w3.org/Archives/Public/public-svg-wg/2014OctDec/0084.html Found Date: 11 Dec 2014 Guessing minutes URL: http://www.w3.org/2014/12/11-svg-minutes.html People with action items: doug[End of scribe.perl diagnostic output]