20:25:38 RRSAgent has joined #svg 20:25:38 logging to http://www.w3.org/2016/06/09-svg-irc 20:25:40 RRSAgent, make logs public 20:25:42 Zakim, this will be GA_SVGWG 20:25:42 ok, trackbot 20:25:43 Meeting: SVG Working Group Teleconference 20:25:43 Date: 09 June 2016 20:26:08 Agenda: https://lists.w3.org/Archives/Public/www-svg/2016Jun/0009.html 20:26:10 Chair: nikos 20:26:14 present+ nikos 20:26:58 AmeliaBR has joined #svg 20:27:39 stakagi has joined #svg 20:36:29 present+ Tav 20:37:31 present+ AmeliaBR 20:37:37 present+ shepazu 20:37:40 present+ stakagi 20:40:00 Scribe: nikos 20:40:03 scribenick: nikos 20:54:20 Topic: Unknown elements behaving as g 20:54:37 nikos: There was a github isse about tidying this text up 20:55:49 ... Dirk pointed out that we may have removed this feature 20:55:52 ... I looked into the history 20:56:03 ... the latest resolution I could find was 2013 where we resolved to remove the feature 20:56:15 https://github.com/w3c/svgwg/issues/122 20:58:03 q+ 20:58:11 ... Erik remembers discussion after that where we decided to keep the feature 20:58:19 .... I don't mind putting it back in, won't be too much editing work 20:58:30 ... also think it wouldn't be too bad to just spec current browser behaviour 20:58:35 ... in terms of getting SVG 2 to CR 20:58:48 ... then look at web components and custom elements and what to do with unknown elements later 20:59:04 Tav: why do we want unknown elements to act as g? 20:59:17 AmeliaBR: the way unknown markup is treated in html is that it's just transparent 20:59:21 ... and you continue with child content 20:59:28 ... in svg the only element that behaves like that is g 21:00:03 ... it's useful because you can be a little more forward focused, if there's additional new markup that the current ua doesn't recognise 21:00:06 ... it can find the parts it does recognise 21:00:23 ... and generally try to make more robust features that could potentially be extended to custom elements 21:00:34 Tav: if I have an unkonwn element with a transform 21:00:39 ... it would act like g with a transform? 21:00:41 AmeliaBR: yes 21:00:55 ... and global attributes and styles could be applied 21:01:10 ... I know we discussed this recently because we were discussing implementation details 21:01:29 Tav: has anyone implement this? 21:01:43 nikos: I've tested Chrome, Safari, and FireFox and they don't render and use the SVGElement interface 21:02:09 Tav: From our point of view, if you have unknown elements, I don't think we would want to deal with them 21:02:27 ... we would have to parse it - say it's not a g but acts like a g 21:03:05 ... we would have to make sure we output as it originally was 21:03:35 nikos: what were the obvious problems with the html parser? 21:03:51 AmeliaBR: don't think they're unsurmountable, but if it gets to an element that isn't svg it'll insert a close tag 21:04:40 shepazu: My suggestion is if it's a roughly equal amount of work either way, is to add it to the spec, mark it at risk 21:04:44 ... the impact is pretty low one way or the other 21:04:56 ... I feel like if we add it to the spec and it gets dropped, it's not a tragedy 21:05:05 ... gives us a chance to get feedback from other people 21:05:22 ... turns out if it doesn't get implemented then we drop it 21:05:43 nikos: I'm happy with that 21:06:08 Tav: I'm indifferent, don't think we'd implement in the near future 21:07:43 nikos: ChrisL had raised concerns that if someone implemented an extension but put their custom elements in the svg namespace, then content could break 21:08:27 AmeliaBR: like replicate for instance 21:08:43 ... might not hurt in that case, but there's cases where we could break content 21:08:56 shepazu: think that's pretty theoretical 21:09:10 AmeliaBR: yeah, we don't have huge frameworks like html 21:09:46 nikos: Ok, lets add it back in, do the small edits that are needed and see what happens to it in CR 21:10:07 AmeliaBR: Don't see it as a feature that's at risk, but the error handling behaviour is different 21:11:20 RESOLUTION: SVG 2 will treat unknown elements as g for the purposes of rendering, and they will use the SVGUnknownElement interface 21:11:26 Tav: make sure to mark it at risk 21:12:05 https://rawgit.com/nikosandronikos/svg2-cr-issues/master/svg2-cr-issues.html 21:12:51 ACTION: Nikos to look at github issue #103 on Monday 21:12:52 Created ACTION-3846 - Look at github issue #103 on monday [on Nikos Andronikos - due 2016-06-16]. 21:13:11 Topic: Clarification on complex text shaping 21:13:14 https://github.com/w3c/svgwg/issues/65 21:13:28 Tav: This is basically about what breaks ligatures 21:13:45 AmeliaBR: there was discussion on www-style about this 21:13:52 ... they had some related questions 21:13:59 ... about line breaks and forced line breaks 21:14:25 Tav: my view is that we pass a block of text to css to layout, and we need to follow css rules for breaking ligatures at that piont 21:14:29 s/piont/point 21:14:46 Tav: then we come back and do dx, dy, and rotate, and I don't think we should break ligatures at that point 21:15:09 ... if you do want to break ligatures, we have font-variant-ligatures that can be used to break ligatures explicitly 21:15:34 nikos: I'm not an expert in that area, but sounds reasonable to me 21:15:41 ... is there anyone specific you'd like input from? 21:16:16 Tav: there was some discussion when one font has ligatures and one doesn't, if you substitute and get ligatures there might be problems 21:16:26 AmeliaBR: sensible point is to allow them and author can turn them off if appropriate 21:17:12 ... we can't judge what looks good so it has to be down to an author on that 21:17:44 RESOLUTION: We will keep SVG 1.1 behaviour wrt to ligatures allowed on text on a path 21:18:21 Tav: rotate will apply to the glyph, not to individual characters 21:18:40 AmeliaBR: no matter how large and awkward that is 21:18:44 ... we can treat this as authoring advice 21:18:52 Tav: I'll add a note explaining how to turn them off 21:19:44 Tav: Also about lengthAdjust=spacing 21:19:49 ... if you put a non zero space it breaks ligatures 21:19:53 AmeliaBR: that's a css rule 21:20:06 Tav: what about textLength ? 21:20:19 ... e.g. textLength="..." lengthAdjust="spacing 21:20:24 AmeliaBR: I would suggest to leave it simple 21:20:55 RESOLUTION: lengthAdjust=spacing will not break ligatures. Ligatures must be explicitly broken. 21:21:15 AmeliaBR: sometimes textLength will have negligible affect, but breaking ligatures will have a much larger effect on the text length 21:21:24 https://github.com/w3c/svgwg/issues/102 21:21:33 Topic: Cleaning up title and desc 21:21:58 AmeliaBR: jarek created issue that elements are a bit arbitrary about whetehr they allow title and desc 21:22:07 ... it's part of a larger issue of inconsistency in the spec 21:22:18 ... want to see if people agree that we allow it pretty much everywhere 21:22:28 ... even for pattern and stuff that is not accessible to a screen reader 21:22:48 ... there is a theoretical accessible use where you can use non rendered elements as part of a description of a shape 21:22:52 ... I've got an example of that 21:22:55 ... or it can be general metadata 21:23:03 ... I don't see a logical reason to prohibit that 21:23:09 ... current status in SVG 1.1 is somewhat random 21:23:27 nikos: I'm ok with that, obviously switch can't have it. Anything else? 21:23:33 AmeliaBR: that's the only one I have an issue with 21:23:43 ... html elements borrowed from html namespace wouldn't have them 21:24:22 RESOLUTION: title and desc can be a child of any svg namespaced element except switch 21:25:29 https://rawgit.com/nikosandronikos/svg2-cr-issues/master/svg2-cr-issues.html 21:29:36 RRSAgent, make minutes 21:29:36 I have made the request to generate http://www.w3.org/2016/06/09-svg-minutes.html nikos 21:52:49 AmeliaBR has left #svg 21:56:37 birtles has joined #svg 22:05:01 ed has joined #svg