Re: Minutes, 11 December 2014 SVG WG telcon

Hello all,

Sorry I had to bail on last nights call. It sounds like it was an
interesting call. Some comments and clarifications:

Thursday, December 11, 2014, 10:45:18 PM, Nikos wrote:

> 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

Two things wrong with that. Firstly, its not that I *prefer* they
don't go to a Member-only list. Its is that our charter requires all
technical work to happen in public and this I object to sending them
to a member-only list. They must go to a publicly readable list.

Secondly, I don't at all want them going to www-svg! There is an
existing publicly-readable list which the group recently re-affirmed
to not use for discussion. It would be an obvious place to send such
github mails to.

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

Objection still stands to that proposal.

>    ... I don't think we want all changes and updates going to the
>    public list

If by "the public list" you mean www-svg then i agree (and wasn't
suggesting it)

>    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-svg
>    ... we could repurpose instead of closing it down

That was my exact suggestion

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

We can make a different list, yes. Its name still has to start public-

>    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

I'm ok with that.

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


> 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

Yes, it would be good to have that flexibility or authors and it would
allow implementations to optimise also.

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

Yes, it has always been defined in terms of a shadow tree (even before
that term existed).


>    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

Great.

>    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

I suspect Doug ws asking about event propagation, global attrs like
lang, and suchlike non-style inheritance.

And it sounds as if only style inheritance is being cut off.


-- 
Best regards,
 Chris Lilley, Technical Director, W3C Interaction Domain

Received on Friday, 12 December 2014 11:15:46 UTC