20:25:31 RRSAgent has joined #svg 20:25:31 logging to http://www.w3.org/2016/06/30-svg-irc 20:25:33 RRSAgent, make logs public 20:25:35 Zakim, this will be GA_SVGWG 20:25:35 ok, trackbot 20:25:36 Meeting: SVG Working Group Teleconference 20:25:36 Date: 30 June 2016 20:25:46 Agenda: https://lists.w3.org/Archives/Public/www-svg/2016Jun/0017.html 20:25:52 Chair: Nikos 20:25:56 present+ nikos 20:32:43 present+ stakagi 20:33:07 hello 20:33:21 present+ AmeliaBR 20:33:27 present+ Tav 20:33:43 scribe: nikos 20:33:46 scribenick: nikos 20:34:02 Topic: Publishing new drafts of SVG Accessibility specs 20:34:10 https://lists.w3.org/Archives/Public/www-svg/2016Jun/0016.html 20:34:44 AmeliaBR: Does anyone need to know anything not in the email? 20:34:55 ... We're looking to publish the three specs 20:35:17 ... The one that has the most interesting content from the SVG side is the SVG AM 20:35:29 ... which talks about how the basic svg semantics should be interpreted from an SVG perspective 20:35:36 ... the changes had to do with tricky little things 20:35:53 ... like if you have conflicting information from an author, which should you expose 20:36:14 ... a lot was based on implementer feedback 20:36:21 ... there's definitely still some open issues 20:36:28 ... the graphics spec is pretty innocuous 20:37:00 ... but the AAM spec has issues about use elements, view elements, and we've created new roles for graphics, but creating them for ARIA isn't enough - you have to have something in the OS API 20:37:09 ... so there's a lot of collaborative work to go on there 20:37:45 nikos: what's the timeline that you expect to get these to CR? 20:37:49 AmeliaBR: think the goal is this year 20:38:06 ... There's dependencies. The SVG AAM relies on changes being made to SVG 2 - especially wrt to use elements 20:38:19 ... similarly it's dependent on changes to ARIA 1.1, which we're trying to lock down this summer 20:38:33 ... once those two specs are CR it'll be easier to sort out the remaining issue 20:38:40 ... and there'll be more peple with more time to work on them 20:40:07 RESOLUTION: SVG WG agrees to publish FPWD of SVG Graphics API Mappings, and updated WD for WAI-ARIA Graphics Module and SVG Accessibility API Mappings 20:40:22 Topic: Avoiding camel case name for meshGradient 20:40:32 https://github.com/w3c/svgwg/issues/181 20:41:20 nikos: So we recently agreed that mesh gradients will be split into a geometry element and a paint server element 20:41:47 ... currently the paint server element is called meshGradient, but we've had complaints from implementers, particularly Tab 20:42:16 Tav: I'd like to get feedback from other implementers 20:42:28 AmeliaBR: I would like more feedback, but I'm not sure if we're going to get it 20:42:45 ... I personally don't think there's an optimal solution 20:42:49 nikos: I agree 20:43:01 AmeliaBR: we still have this situation where old elements are camel cased and new elements are not 20:43:15 Tav: my thinking is that if anyone besides Tab complains then I'd be willing to drop the camel case 20:43:19 ... and go with meshgradient 20:43:28 nikos: +1 to meshgradient 20:43:46 Tav: no one is going to be writing meshgradients by hand 20:43:58 AmeliaBR: Simple four patch gradients maybe? 20:44:08 Tav: I've done it but it's very tough 20:44:13 s/four patch/four point/ 20:45:02 AmeliaBR: there's other places where you get tripped up - not just writing SVG code. E.g. you might defining selectors 20:45:31 nikos: Having a quick look at an old conversation 20:45:32 https://www.w3.org/2015/02/11-svg-minutes.html#item03 20:46:02 ... looks like general consensus is for consistency 20:46:58 nikos: How about we try for more feedback. If we get feedback that camel case is bad, we'll make it gradientmesh, otherwise we'll keep it meshGradient and see what happens 20:47:08 ... it's only a very small spec change 20:48:01 ... at least we know what names we'll pick in each case 20:49:20 Topic: Better error handling for nested links 20:49:51 https://github.com/w3c/svgwg/issues/178 20:50:06 AmeliaBR: At the F2F I made some changes to allow nested links, because it seemed logical to allow them 20:50:22 ... got feedback that supporting it is a complete disaster 20:50:34 ... both in SVG and creating nested links via script 20:50:43 ... the HTML parser doesn't allow them, but they can be created in the DOM using JS 20:50:58 ... given there's no pressing need for nested links - you can still have sibling elements that visually interact 20:51:19 ... and there's no easy way to address the problems on the accessibility side - they just don't expect to find nested links 20:51:29 ... my argument is to revert that and go back to nested links being invalid 20:51:35 ... second part is the error handling 20:51:55 ... the way it's currently worded in SVG is that any element that appears when it shouldn't don't render at all 20:52:09 ... so for browsers that follow that, any nested link doesn't show 20:52:37 ... so along with unknown elements now rendering, we should allow nested links to at least render 20:53:12 Tav: For me the question is having nested links useful? 20:53:20 ... even having special forgiving behaviour is going to require chanes 20:53:32 AmeliaBR: anything is going to require changes somewhere - we don't have interop 20:53:40 Tav: so is having nested links something we'd want long term? 20:53:48 ... we had the example of tspan inside text 20:53:56 ... text links somewhere, tspan links somewhere else 20:54:16 ... if we have nested graphical elements, like circle inside a rectangle, then you might want to have nested links 20:54:26 ... I don't have a strong feeling for this 20:54:37 ... if we do allow fallback, it might prevent us having nested links in future 20:55:05 AmeliaBR: if we define it as an invalid case. It's not changing the handling of a valid document, it's changing error handling 20:55:32 ... if it was supported it could be useful, but I don't think it's essential 20:55:43 ... there's other ways to achieve the same effect 20:55:52 Tav: I'd prefer to leave things but won't object 20:56:26 nikos: I don't have a strong opinion either way. If we drop the href, they'd still be usable as an anchor 20:56:30 ... we'd need to be clear on that 20:56:48 AmeliaBR: yeah we wouldn't mess with the DOM 20:57:18 nikos: My thinking of not rendering it at all is that at least it's a clear indication that you're doing something wrong 20:57:38 AmeliaBR: I'm more concerned about accidental things - if you have an svg with a link inside and you put that inside a html link 20:57:50 Tav: I like immediate feedback 20:58:30 nikos: The other argument is that unknown elements currently render. That may change as it's at risk 20:58:42 AmeliaBR: are we talking nested links or nested a elements? Not all a elements are links 20:59:23 nikos: So all nested a elements should show. Only link a elements wouldn't function as links 21:00:36 AmeliaBR: we can mark it at risk and keep it in sync with unknown elements 21:00:44 nikos: Which implementations do what? 21:01:27 AmeliaBR: Blink and Webkit don't render. FF and Edge do - links work if you're clicking, but they're not effectively exposed to screen readers 21:01:46 ... I haven't tracked whether that's a browser issue, screen reader issue, or API issue 21:02:19 ... My preference is to allow rendering but require nested link functionality be ignore 21:03:31 RESOLUTION: Nested a elements will render but href attribute will be ignored. But if unknown elements (at risk) are changed to not render, a elements will also then not render. 21:03:55 Action: Amelia to make changes wrt nested a elements 21:03:55 Created ACTION-3847 - Make changes wrt nested a elements [on Amelia Bellamy-Royds - due 2016-07-07]. 21:04:05 AmeliaBR: I'll add an at risk note aslso 21:04:10 s/aslso/also 21:04:13 Topic: SVG 2 CR publishing plans 21:04:31 nikos: At the end of the Amsterdam F2F I said two more weeks to get everything we want done 21:04:41 ... how are people going for that? 21:05:02 Tav: I haven't had a chance. That was expected though. Will have time this week 21:06:02 nikos: I was having a look at the inline issues in the spec. Making sure no normative ones are in there. One biggish one with coords chapter, but I'll do that next week 21:06:10 ... also been looking into what I need to do to publish 21:06:37 ... should take me a day to work through the steps that Cameron wrote up 21:06:44 AmeliaBR: I just need to look at the use element stuff 21:07:28 nikos: The document structure had some inline issues so they should go when you do use element rewrite 21:08:09 ... ok so let's review progress at next week's telcon, then I'll publish the week after 21:08:38 AmeliaBR: we have a few issues that would be good to get more feedback. They're tagged 'needs resolution' in GH 21:09:12 nikos: I'll send an email to the group today and try to get wider input 21:09:41 "Needs WG input": https://github.com/w3c/svgwg/issues?q=is%3Aissue+is%3Aopen+label%3A%22Needs+WG+input%22 21:10:01 "Needs resolution": https://github.com/w3c/svgwg/issues?q=is%3Aissue+is%3Aopen+label%3A%22Needs+resolution%22 21:10:29 nikos: Add CR milestone too 21:10:40 ... to cut down the list 21:11:10 Topic: Restore SVGSVGElement.prototype.getElementById 21:11:24 AmeliaBR: I'm fine with it's a method that's widely supported and moderalyte useful so why not put it back in the spec 21:11:28 https://github.com/w3c/svgwg/issues/182 21:11:34 nikos: There was no question I was going to add it back into the spec 21:11:51 ... Just wanted to understand the WG thinking in the past 21:12:12 AmeliaBR: I like your suggestion of add it back in and suggest using other options 21:12:56 nikos: I was curious of the perf difference of getDocumentById vs querySelector for ids 21:13:12 ... jsperf is down =( 21:13:23 AmeliaBR: logically it shouldn't be that different for a simple id selector 21:14:05 Topic: Gradient stop colours with transparency values 21:14:05 https://github.com/w3c/svgwg/issues/180 21:14:20 AmeliaBR: We don't define what to do if gradient stop colour values have transparency 21:14:50 ... CSS specs say to premultiply so that the colour strength is proportional to the transparency 21:15:10 ... main reason to doing this is so that blue to transparent looks as people would expect - fading out blue rather than fading blue to transparent black 21:15:20 ... my argument is that we should follow those rules 21:15:36 ... problem with that is that there is still some debate on css side as to whether that's the best behaviour 21:15:45 ... also canvas gradients do the opposite 21:15:58 Tav: answer is what happens with opacity 0.99? 21:16:15 AmeliaBR: It's scaled - strength is proportional 21:16:25 Tav: I need to think about this 21:16:45 nikos: I want to do some testing too - I haven't had time so far 21:17:41 AmeliaBR: There's a little extra math for implementers if we go with this 21:17:47 ... my argument is for consistency 21:17:53 ... good for authors and hopefully good for implementers 21:18:24 ... but because we have three techs making gradients, and we're not going to have interop between all of them I'm feeling less strongly that we need to align with CSS rather than canvas 21:18:43 AmeliaBR: right now we have lots of implementations 21:19:30 nikos: I was also wondering if it's a platform dependent result rather than just a browser result 21:19:35 ... curious what Cairo does for example 21:19:48 http://codepen.io/AmeliaBR/pen/jrBOBv/ 21:19:49 ... would be good to try FF on linux and WebKit GTK 21:20:13 Tav: FF on linux, the top one matches the bottom one and the middle two match 21:20:28 AmeliaBR: so that's the same as what we get everywhere except for with WebKit 21:21:55 nikos: Let's leave as an open issue. We need more time to investigate. At least with multiple different implementations, we can align with the one we think is most correct 21:22:08 AmeliaBR: I'd like to get feedback from CSS as to how close they are to resolving this issue 21:22:54 Topic: Unknown elements behaving as g 21:22:59 https://github.com/w3c/svgwg/issues/179 21:23:11 AmeliaBR: We say unknown elements behave as the g element 21:23:17 ... but g isn't allowed everywhere 21:23:27 ... my suggestion is to make it an a without an href - that can go in more places 21:23:54 Tav: I don't think an a is a good model 21:25:04 Some fancy text 21:25:13 nikos: I think the point is that where it makes some sense to render, then we can render via g. If it doesn't make sense for g then it probably makes sense to actually ignore 21:25:16 AmeliaBR: use case is with text 21:25:27 ... so treat unknown as tspan inside text 21:26:14 RESOLUTION: Treat unknown elements as tspan when inside text. Presentation and inherited style apply, but nothing specific. 21:26:55 RRSAgent, make minutes 21:26:55 I have made the request to generate http://www.w3.org/2016/06/30-svg-minutes.html nikos 21:32:59 AmeliaBR has left #svg