SVG Working Group Teleconference -- 21 Jul 2016

<scribe> Scribe: Nikos

<scribe> scribenick: nikos

Use element re-write & related changes

AmeliaBR: I have issues that came up from that PR
... as I have it drafted x,y,width,height are simple attributes
... think I"m just going to change it
... one way or the other they're not going to behave nicely with css
... we are going to have to say if the value computes to this then do that on the shadow element
... and we're not going to be able to define it nicely in css, but we can define them as presentation attributes and use the final computed value on the use element
... unless I have implementers saying not to do it I'll just go ahead and change them

AmeliaBR: I wanted to remove the comment about things going in defs. I'll go ahead with that

AmeliaBR: As far as resolving cross references, I have a large section on what you should actually do to find the referenced element
... the important thing is if a cross reference references an element that doesn't exist, but that is created later, then you should listen and react to it
... browsers do that but it wasn't specced
... and for external files say we are processing in secure static mode
... so don't fetch additional resources
... you may fetch those resources if they are referenced by an element in the shadow dom, but you don't just grab them all
... wasn't clearly defined previously
... the issue is that this should apply to filter and paint servers and other cross references
... I'd like aresolution as to whether I should rewrite to make it more general

nikos: Sounds reasonable, can't think of anything it would break

<AmeliaBR> Proposed Resolution: Move the resolving cross-references section ( https://ameliabr.github.io/svgwg/build/publish/struct.html#UseHref ) to linking chapter & make general for all cross-references

AmeliaBR: we would have to adapt for which references are allowed to be cross referenced

RESOLUTION: Move the resolving cross-references section ( https://ameliabr.github.io/svgwg/build/publish/struct.html#UseHref ) to linking chapter & make general for all cross-references

AmeliaBR: After I wrote this I thought there should be a load event
... Nikos suggested we deal with this as a future request
... I had a comment about width and height on the use element affecting symbol and whether it should affect width and height of other used elements (e.g. foreignObject)
... I feel it shouldn't but it needs to be clarified
... think foreignObject should behave as image, which doesn't size
... did anyone have a problem about use elements and animation being in this spec?

nikos: Since this applies to how to animate this and it's general to CSS and SVG animations it makes sense to have it here rather than in the SVG animations spec

AmeliaBR: I would like to make sure implementors see this
... One of the confusions with animations, is what to do if the animation element isn't cloned with the rest of the content
... I've got a special rule about theoretically cloning something and it acts like it's in the shadow tree
... if Brian or anyone else working on animations says it needs to change then thats fine otherwise I'll assume its ok for now
... final points are relating to interface adjustments that I've got to fake backwards compat with SVGInstance
... I've got something called SVGElementInstance but it's an extension to SVGElement
... the way it is currently defined you wouldn't have an object called SVGElementInstance in the global namespace
... didn't think there was any use having a separate interface object
... final one is alittle trickier, the extension is that the element in the shadow dom will have a link to its source document
... that's to mirror the previous functionality of the shadow instances
... but useful for catching events
... that could have a perf impact because you're if you're pointing to an element in another document you have to hold onto that document
... you would have to maintain in memory the original DOM

nikos: Could you ask a note for now outlining the impact and ask for implementor feedback

AmeliaBR: I could do that
... not sure if alternative is an error or if it acts as null. I can mention both options
... then it will stand as a warning to authors
... the other issue is redefining paint server cross references to use the same model
... when you have a pattern that has an href to another pattern, then you create a shadow dom for that pattern with the child content
... that would affect style matching - it would use the shadow matching rules. That wasn't defined in SVG 1.1
... think that's the only way that would change compliance requirements
... but it's also having a consistent model that could be used for other edge cases
... Tav did you look at my reply about how the changes to styling work?

Tav: I did look at your example in InkScape - the stroke is green on both circles

AmeliaBR: THat's the SVG 1.1. behaviour

Tav: We rely on that behaviour in some parts of our code
... if you have a copy of the use element you only inherit from the use element if something is undefined
... don't know if this breaks that or not

AmeliaBR: it may prohibit some optimisations

Tav: My understanding from way back is if something is referenced it is defined at the point where it is inserted in the svg file

AmeliaBR: markers are different because they never inherit any styles
... marker is treated like an image fragment

Tav: We now have currentColor and currentStroke

AmeliaBR: that changes things a bit where you can't just paint it once and reuse it
... but we don't have inherited styles so you can still use the computed style and sub in the value
... for use elements the computed styles were always adjusted
... CSS has names for this - can't remember what they are
... the main justification for changing this is that 1. interactive styles become useful instead of a big mess 2. the other is so the browsers can implement it with the same rules that they're using with shadow dom

Tav: I' worried it will break a lot of inkscape

AmeliaBR: my expectation is that no code that inkscape creates would trigger this problem

Tav: looking at <g class="special" supposing I put a style element on that

AmeliaBR: it won't change anything - in my example I have the fill style set on the g element
... that won't change behaviour
... the styles on the g element don't inherit on the old model or the new model

Tav: Currently circle does inherit

AmeliaBR: it shouldn't - we're reusing the circle, not the g

Tav: I'm seeing that it is inheriting the green in inkscape

AmeliaBR: it's not inheriting hte green, the green is being set on the circle that isa child of the elemnt with a special class
... it's being set on css on the circle, the circle is getting that style, but it's getting its style from the dom tree
... pretty sure you'd never create that case in InkScape, but it could be created by hand and then things will change

Tav: I probably need to do a few more tests to understand. We don't write out selectors at all

nikos: It sounds like from Amelias understanding of what you do then everything is ok
... can we assume that its ok and you'll do some more testing just to confirm that?

Tav: that's fine

AmeliaBR: I'll add this example to the spec and try to make it a bit more clear
... that's all I have to talk about this. Pending those tweaks. No one else has any complaints?
... I'll try to make those changes this weekend

Does conditional processing mute sound playback

https://github.com/w3c/svgwg/issues/44

AmeliaBR: This gets down to whether this is conditional processing or conditional display
... if we make it conditional display then can we change the name?
... we should be clear
... in my mind processing means do scripts run and do you fetch external resources, etc
... if we're only changing display then we should change it

nikos: not creating the tree is definitely more useful and if we were writing this from scratch that's how I'd want to do it
... but pragmatically at this point I think we should make it a synonym for MQ and display:none

AmeliaBR: If we have it so switch effecst are only display:none then we lose the ability to extend switch to have behviour of the picture element, where it allows decision on what resource to download

nikos: My hope is that browsers optimise this internally and try to be clever

AmeliaBR: for me, someone decided script and style shouldn't be affected because that's how we implemented it the first time. That really limits their effectiveness
... if we further make it a display control only that removes any reason for them existing other than conditional language processing

nikos: Does anyone else have any input on neutering switch?

shepazu: I have mixed feeling about switch. I wonder how much it is used and I worry about browsers spending too much effort on switch that isn't going to be implemented and used
... if you think about its origins, what was it used for ? It came from SMIL. SMIL was a very specific community of authors and processors and I don't think that's what people are doing today with web content for the most part
... so we inherited it from style, I wonder if we should do the minimal thing to not break it in SVG 2
... if we want to do declarative conditional processing outside of CSS we should reexamine the use cases and see what we're trying to accomplish
... this comes up in accessibility. If someone makes a document that has switch for languages, whats the accessible name?
... makes sense for title, but very few go to the effort

Tav: We had people request that last year

AmeliaBR: It's a useful function, but there's no way to control it from the user end without changing browser settings
... for the feature support side as well, there's a strong move for declarative feature support testing features
... bu they're being done in a way that isn't a direct extension of how it was done with switch

nikos: At this point I'm going to propose we make it conditional for display and move on. Think we are reluctantly agreeing on this

AmeliaBR: Are you ok with changing prose to call it conditional display?

nikos: think so

shepazu: we're talking about changing switch, what is so broken about switch now? What is so broken now that it demands change in SVG 2?

AmeliaBR: question that came up is that now we have audio and video, should they play if they're in a turned off branch
... if you have audio and video it does play
... other issue is what to do with use element - do you fetch?
... same with image element

nikos: I feel if someone has raise and explicit issue then we need to resolve it

RESOLUTION: Switch fill function as conditional display

<scribe> ACTION: Nikos to update switch prose to make it conditional display [recorded in http://www.w3.org/2016/07/21-svg-minutes.html#action01]

<trackbot> Created ACTION-3848 - Update switch prose to make it conditional display [on Nikos Andronikos - due 2016-07-28].

Allow transforms on textPath

https://github.com/w3c/svgwg/issues/210

nikos: Think Tav is against adding transform to tspan and textpath

Tav: that's right

AmeliaBR: and then we ran across unclear behaviour if the path is transformed

Tav: There's an example in the spec that shows what it should be

AmeliaBR: it doesn't have a picture showing the output
... for tspan and textpath being transformable - we're dealing with css saying an inline text element is not transformable. we're treating these in svg as inline
... but that will break content - anyone who has been using the a element hack

Tav: I could not find any browser that supported that

<Tav> http://tavmjong.free.fr/SVG/text_tspan_transform.svg

AmeliaBR: Not supported in Chrome or Edge

nikos: I propose we dont' allow transform on inline elements

AmeliaBR: let's go with that

RESOLUTION text and tspan are treated as inline elements and inline elements can't have transform

nikos: Is that how it's specced?

Tav: think tspan can have transform in SVG 2

AmeliaBR: CSS transforms defines transformable elements and we'll need to change that to get rid of that paragraph so it's based on block vs inline elements

<scribe> ACTION: Nikos file issue on CSS Transforms [recorded in http://www.w3.org/2016/07/21-svg-minutes.html#action02]

<trackbot> Created ACTION-3849 - File issue on css transforms [on Nikos Andronikos - due 2016-07-28].

<scribe> ACTION: Tav to update spec to reflect no transform on inline elements [recorded in http://www.w3.org/2016/07/21-svg-minutes.html#action03]

<trackbot> Created ACTION-3850 - Update spec to reflect no transform on inline elements [on Tavmjong Bah - due 2016-07-28].

Use CSS gradient rules for transitioning semi-transparent stop-colors

AmeliaBR: I filed this suggesting we should have consistent behaviour with CSS gradients.
... but that would make use inconsistent with canvas
... so not concerned one way or the other, but I want a clear definition that Safarai is wrong
... so what happens if stop-color is a semi transparent colour - Safari ignores the alpha

Tav: Why is Safari wrong?

<AmeliaBR> https://github.com/w3c/svgwg/issues/180

<AmeliaBR> https://github.com/w3c/svgwg/issues/180#issuecomment-229147823

AmeliaBR: third one doesn't fade to transparent at all
... it's an SVG gradient purely defined in terms of stop-color rather than using stop-opacity
... final stop-color is a transparent colour and it's ignoring the alpha component
... if you have a rgba fill and a separate opacity they get combined

Tav: So how do we factor it in?

AmeliaBR: there is debate on the CSS side. Canvas has it consistent with how other browsers implement SVG
... I would say keep it how other browsers implement it
... so going back to the screenshot at the top of the page
... this is what other browsers do
... talking about the third case, you are doing it all with rgba colours and the destination colour is rgba transparent black - aka the transparent keyword
... stop-color transitions to black and opacity transitions to zero. What they don't do is modify the ipmact of the colour so that if it has zero alpha it has zero influence on the colour
... to be clear, the top two are still options. You just have to set stop-color and stop-opacity yourself
... I'm happy with speccing this to match implementations
... and file a bug on webkit

nikos: +1

shepazu: +1

<AmeliaBR> Preposed Resolution: partially transparent stop-opacity should be factored in to gradients, multiplicative with any change in stop-opacity; color blending uses non-pre-multiplied colors

RESOLUTION: partially transparent stop-opacity should be factored in to gradients, multiplicative with any change in stop-opacity; color blending uses non-pre-multiplied colors

<AmeliaBR> CR requirements: https://www.w3.org/2015/Process-20150901/#candidate-rec

RESOLUTION: Publish SVG 2 CR, pending updates to Amelia's use element rewrite and the new text changes. Will put a call for additional resolution comments to the mailing list with one week to respond.

- DRAFT -

SVG Working Group Teleconference

21 Jul 2016

Attendees

Contents

Use element re-write & related changes

Does conditional processing mute sound playback

Allow transforms on textPath

Use CSS gradient rules for transitioning semi-transparent stop-colors

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output