20:28:01 RRSAgent has joined #svg 20:28:01 logging to http://www.w3.org/2016/07/21-svg-irc 20:28:03 RRSAgent, make logs public 20:28:05 Zakim, this will be GA_SVGWG 20:28:05 ok, trackbot 20:28:06 Meeting: SVG Working Group Teleconference 20:28:06 Date: 21 July 2016 20:29:06 Agenda: https://lists.w3.org/Archives/Public/www-svg/2016Jul/0007.html 20:29:11 Chair: Nikos 20:29:13 present+ nikos 20:30:26 Scribe: Nikos 20:30:36 scribenick: nikos 20:30:39 Topic: Use element re-write & related changes 20:30:45 https://github.com/w3c/svgwg/pull/206 20:34:05 present+ stakagi 20:35:26 present+ Tav 20:35:35 present+ shepazu 20:35:58 present+ AmeliaBR 20:36:35 AmeliaBR: I have issues that came up from that PR 20:36:47 ... as I have it drafted x,y,width,height are simple attributes 20:36:52 ... think I"m just going to change it 20:37:04 ... one way or the other they're not going to behave nicely with css 20:37:14 ... we are going to have to say if the value computes to this then do that on the shadow element 20:37:31 ... 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 20:37:57 ... unless I have implementers saying not to do it I'll just go ahead and change them 20:38:03 +1 20:38:18 AmeliaBR: I wanted to remove the comment about things going in defs. I'll go ahead with that 20:38:20 +1 20:38:35 AmeliaBR: As far as resolving cross references, I have a large section on what you should actually do to find the referenced element 20:38:57 ... 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 20:39:05 ... browsers do that but it wasn't specced 20:39:13 ... and for external files say we are processing in secure static mode 20:39:21 ... so don't fetch additional resources 20:39:42 ... you may fetch those resources if they are referenced by an element in the shadow dom, but you don't just grab them all 20:39:53 ... wasn't clearly defined previously 20:40:08 ... the issue is that this should apply to filter and paint servers and other cross references 20:40:23 ... I'd like aresolution as to whether I should rewrite to make it more general 20:40:56 nikos: Sounds reasonable, can't think of anything it would break 20:41:06 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 20:41:43 AmeliaBR: we would have to adapt for which references are allowed to be cross referenced 20:41:45 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 20:42:07 AmeliaBR: After I wrote this I thought there should be a load event 20:42:27 ... Nikos suggested we deal with this as a future request 20:44:08 AmeliaBR: 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) 20:44:17 ... I feel it shouldn't but it needs to be clarified 20:44:34 ... think foreignObject should behave as image, which doesn't size 20:44:51 AmeliaBR: did anyone have a problem about use elements and animation being in this spec? 20:45:35 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 20:45:59 AmeliaBR: I would like to make sure implementors see this 20:46:38 AmeliaBR: One of the confusions with animations, is what to do if the animation element isn't cloned with the rest of the content 20:46:50 ... I've got a special rule about theoretically cloning something and it acts like it's in the shadow tree 20:47:14 ... if Brian or anyone else working on animations says it needs to change then thats fine otherwise I'll assume its ok for now 20:47:30 ... final points are relating to interface adjustments that I've got to fake backwards compat with SVGInstance 20:47:41 ... I've got something called SVGElementInstance but it's an extension to SVGElement 20:48:09 ... the way it is currently defined you wouldn't have an object called SVGElementInstance in the global namespace 20:48:18 ... didn't think there was any use having a separate interface object 20:48:38 ... final one is alittle trickier, the extension is that the element in the shadow dom will have a link to its source document 20:48:47 ... that's to mirror the previous functionality of the shadow instances 20:48:51 ... but useful for catching events 20:49:13 ... 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 20:49:24 ... you would have to maintain in memory the original DOM 20:50:18 nikos: Could you ask a note for now outlining the impact and ask for implementor feedback 20:50:22 AmeliaBR: I could do that 20:50:37 ... not sure if alternative is an error or if it acts as null. I can mention both options 20:50:47 ... then it will stand as a warning to authors 20:51:07 ... the other issue is redefining paint server cross references to use the same model 20:51:25 ... 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 20:51:43 ... that would affect style matching - it would use the shadow matching rules. That wasn't defined in SVG 1.1 20:51:58 ... think that's the only way that would change compliance requirements 20:52:09 ... but it's also having a consistent model that could be used for other edge cases 20:54:40 AmeliaBR: Tav did you look at my reply about how the changes to styling work? 20:54:57 Tav: I did look at your example in InkScape - the stroke is green on both circles 20:55:03 AmeliaBR: THat's the SVG 1.1. behaviour 20:55:11 Tav: We rely on that behaviour in some parts of our code 20:55:23 ... if you have a copy of the use element you only inherit from the use element if something is undefined 20:55:44 ... don't know if this breaks that or not 20:55:53 AmeliaBR: it may prohibit some optimisations 20:56:16 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 20:56:25 AmeliaBR: markers are different because they never inherit any styles 20:56:36 ... marker is treated like an image fragment 20:56:49 Tav: We now have currentColor and currentStroke 20:56:59 AmeliaBR: that changes things a bit where you can't just paint it once and reuse it 20:57:11 ... but we don't have inherited styles so you can still use the computed style and sub in the value 20:57:26 ... for use elements the computed styles were always adjusted 20:57:35 ... CSS has names for this - can't remember what they are 20:58:23 AmeliaBR: 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 20:58:32 Tav: I' worried it will break a lot of inkscape 20:58:52 AmeliaBR: my expectation is that no code that inkscape creates would trigger this problem 20:59:16 Tav: looking at AmeliaBR: it won't change anything - in my example I have the fill style set on the g element 20:59:34 ... that won't change behaviour 20:59:42 ... the styles on the g element don't inherit on the old model or the new model 21:00:01 Tav: Currently circle does inherit 21:00:08 AmeliaBR: it shouldn't - we're reusing the circle, not the g 21:00:39 Tav: I'm seeing that it is inheriting the green in inkscape 21:00:57 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 21:01:20 ... 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 21:01:41 ... pretty sure you'd never create that case in InkScape, but it could be created by hand and then things will change 21:01:59 Tav: I probably need to do a few more tests to understand. We don't write out selectors at all 21:02:24 nikos: It sounds like from Amelias understanding of what you do then everything is ok 21:02:35 ... can we assume that its ok and you'll do some more testing just to confirm that? 21:02:39 Tav: that's fine 21:02:55 AmeliaBR: I'll add this example to the spec and try to make it a bit more clear 21:03:29 AmeliaBR: that's all I have to talk about this. Pending those tweaks. No one else has any complaints? 21:03:49 ... I'll try to make those changes this weekend 21:03:59 Topic: Does conditional processing mute sound playback 21:04:04 https://github.com/w3c/svgwg/issues/44 21:04:13 AmeliaBR: This gets down to whether this is conditional processing or conditional display 21:04:19 ... if we make it conditional display then can we change the name? 21:04:21 ... we should be clear 21:04:36 ... in my mind processing means do scripts run and do you fetch external resources, etc 21:04:45 ... if we're only changing display then we should change it 21:05:28 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 21:05:44 ... but pragmatically at this point I think we should make it a synonym for MQ and display:none 21:06:18 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 21:06:49 nikos: My hope is that browsers optimise this internally and try to be clever 21:07:53 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 21:08:33 ... if we further make it a display control only that removes any reason for them existing other than conditional language processing 21:09:03 nikos: Does anyone else have any input on neutering switch? 21:09:26 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 21:10:39 shepazu: 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 21:10:54 ... so we inherited it from style, I wonder if we should do the minimal thing to not break it in SVG 2 21:11:19 ... 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 21:11:46 ... this comes up in accessibility. If someone makes a document that has switch for languages, whats the accessible name? 21:11:56 ... makes sense for title, but very few go to the effort 21:12:27 Tav: We had people request that last year 21:12:50 AmeliaBR: It's a useful function, but there's no way to control it from the user end without changing browser settings 21:13:07 ... for the feature support side as well, there's a strong move for declarative feature support testing features 21:13:21 ... bu they're being done in a way that isn't a direct extension of how it was done with switch 21:14:37 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 21:14:45 AmeliaBR: Are you ok with changing prose to call it conditional display? 21:14:47 nikos: think so 21:15:15 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? 21:15:34 AmeliaBR: question that came up is that now we have audio and video, should they play if they're in a turned off branch 21:15:43 ... if you have audio and video it does play 21:16:06 ... other issue is what to do with use element - do you fetch? 21:16:14 ... same with image element 21:17:33 nikos: I feel if someone has raise and explicit issue then we need to resolve it 21:17:45 RESOLUTION: Switch fill function as conditional display 21:17:55 ACTION: Nikos to update switch prose to make it conditional display 21:17:55 Created ACTION-3848 - Update switch prose to make it conditional display [on Nikos Andronikos - due 2016-07-28]. 21:18:24 Topic: Allow transforms on textPath 21:18:29 https://github.com/w3c/svgwg/issues/210 21:18:52 nikos: Think Tav is against adding transform to tspan and textpath 21:18:57 Tav: that's right 21:19:17 AmeliaBR: and then we ran across unclear behaviour if the path is transformed 21:19:31 Tav: There's an example in the spec that shows what it should be 21:19:39 AmeliaBR: it doesn't have a picture showing the output 21:20:28 ... 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 21:20:40 ... but that will break content - anyone who has been using the a element hack 21:20:52 Tav: I could not find any browser that supported that 21:21:41 http://tavmjong.free.fr/SVG/text_tspan_transform.svg 21:22:01 AmeliaBR: Not supported in Chrome or Edge 21:22:22 nikos: I propose we dont' allow transform on inline elements 21:22:24 AmeliaBR: let's go with that 21:22:45 RESOLUTION text and tspan are treated as inline elements and inline elements can't have transform 21:22:53 nikos: Is that how it's specced? 21:23:05 Tav: think tspan can have transform in SVG 2 21:23:44 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 21:23:51 ACTION: Nikos file issue on CSS Transforms 21:23:51 Created ACTION-3849 - File issue on css transforms [on Nikos Andronikos - due 2016-07-28]. 21:24:09 Action: Tav to update spec to reflect no transform on inline elements 21:24:09 Created ACTION-3850 - Update spec to reflect no transform on inline elements [on Tavmjong Bah - due 2016-07-28]. 21:24:42 Topic: Use CSS gradient rules for transitioning semi-transparent stop-colors 21:24:57 AmeliaBR: I filed this suggesting we should have consistent behaviour with CSS gradients. 21:25:08 ... but that would make use inconsistent with canvas 21:25:21 ... so not concerned one way or the other, but I want a clear definition that Safarai is wrong 21:25:38 ... so what happens if stop-color is a semi transparent colour - Safari ignores the alpha 21:26:00 Tav: Why is Safari wrong? 21:26:23 https://github.com/w3c/svgwg/issues/180 21:26:33 https://github.com/w3c/svgwg/issues/180#issuecomment-229147823 21:26:59 AmeliaBR: third one doesn't fade to transparent at all 21:27:14 ... it's an SVG gradient purely defined in terms of stop-color rather than using stop-opacity 21:27:44 ... final stop-color is a transparent colour and it's ignoring the alpha component 21:28:15 AmeliaBR: if you have a rgba fill and a separate opacity they get combined 21:28:48 Tav: So how do we factor it in? 21:29:06 AmeliaBR: there is debate on the CSS side. Canvas has it consistent with how other browsers implement SVG 21:29:12 ... I would say keep it how other browsers implement it 21:29:18 ... so going back to the screenshot at the top of the page 21:29:22 ... this is what other browsers do 21:30:09 ... 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 21:30:49 ... 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 21:30:59 q+ 21:31:27 AmeliaBR: to be clear, the top two are still options. You just have to set stop-color and stop-opacity yourself 21:31:47 ... I'm happy with speccing this to match implementations 21:31:51 ... and file a bug on webkit 21:31:54 nikos: +1 21:31:56 shepazu: +1 21:34:51 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 21:56:25 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 22:00:38 CR requirements: https://www.w3.org/2015/Process-20150901/#candidate-rec 22:08:04 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. 22:08:41 RRSAgent, make minutes 22:08:41 I have made the request to generate http://www.w3.org/2016/07/21-svg-minutes.html nikos 23:38:42 paradisaeidae has joined #svg 23:42:25 paradisaeidae has joined #svg