01:51:43 shepazu has joined #svg 07:08:25 chaals has joined #svg 07:58:29 stakagi has joined #svg 08:18:19 Tav has joined #svg 08:22:41 chaals has joined #svg 08:23:56 trackbot, start telcon 08:23:58 RRSAgent, make logs public 08:24:00 Zakim, this will be GA_SVGWG 08:24:00 ok, trackbot 08:24:01 Meeting: SVG Working Group Teleconference 08:24:01 Date: 21 April 2016 08:24:26 Meeting: SVG London 2016 08:24:30 chair: nikos 08:24:32 present+ nikos 08:24:41 present+ Tav 08:24:46 LJWatson has joined #svg 08:24:50 present+ AmeliaBR 08:24:56 present+ chaals 08:24:58 present+ LJWatson 08:26:49 Topic: Chapter 4: Document Structure 08:27:09 nikos: We got bogged down on this chapter yesterday, but would like to get it finished. Let's skip past use and go on 08:27:22 present+ stakagi 08:27:26 scribe: nikos 08:27:50 AmeliaBR: I'll look at rewriting use on the way home 08:28:40 AmeliaBR: The tricky part will be making use of x,y,width,height properties without lots of special casing 08:29:09 AmeliaBR has joined #svg 08:29:11 chaals: There's another issue with multilingual titles 08:29:25 ... if you have to use aria-label with title you can't do that with a multi lingual title 08:29:37 Demo comparing behavior of x+y attributes on versus image, rect, foreignObject: http://codepen.io/AmeliaBR/full/BFowL/ 08:30:08 ... if you say aria-labeledby you can't refer to one of the titles 08:30:17 AmeliaBR: aria is based on the assumption that you're probably using javascript 08:30:30 ... which is unfortunate because there's a lot that is good from a declarative point of view 08:30:44 chaals: unless you can find out what language the user agent is presenting... 08:31:14 AmeliaBR: the idea is that you shouldn't need an aria label attribute, that's a fall bcak for when there's no svg title element 08:31:33 ... in the svg mapping spec, we have wording that the correct name for the accessible name calculation is the title chosen 08:31:50 chaals: Think we should file an issue, point i18n at it and move on 08:32:35 nikos: let's jump to common attributes 08:32:36 https://svgwg.org/svg2-draft/struct.html#CommonAttributes 08:33:14 AmeliaBR: conditional processing needs a lot of discussion but we can skip it for now 08:33:33 ... back to 4.10, there has been discussion in CSS as to whether base should affect url notation 08:33:44 ... which affects a lot of svg properties 08:34:10 ... think browsers are consistent when base is set declarative, but get wonky when it's updated 08:34:38 ... we probably don't need to discuss now but may affect whether something needs to be taken out of CR if we don't have somehting stable and testable 08:38:50 -> https://github.com/w3c/svgwg/issues/116 issue on multilingual titles and aria 08:43:03 AmeliaBR: xml:lang is used in favour of lang, does anyone remember why we decided that? 08:43:23 nikos: In the past we said that lang favours xml:lang, not sure when that was reverted 08:43:38 ... Original discussion on lang vs xml:lang https://www.w3.org/2015/02/11-svg-minutes.html#item09 08:45:25 CMN: tabindex needs more information about how it works - I can provide a PR for that. 08:45:45 ACTION: CMN to expand the description of tabindex. 08:45:45 Error finding 'CMN'. You can review and register nicknames at . 08:45:56 ACTION: chaals to expand the definition of tabindex 08:45:56 Created ACTION-3840 - Expand the definition of tabindex [on Charles McCathie Nevile - due 2016-04-28]. 08:48:53 chaals: it's surprising that title and desc don't get a role, might be worth adding a note 08:59:18 stakagi_ has joined #svg 09:00:41 In 4.12.3, Remove the "Unlike..." phrase on strong native semantics, so that sentence starts "State and property attributes". 09:04:33 SVG-AAM Editor's Draft: https://w3c.github.io/aria/svg-aam/svg-aam.html 09:08:25 stakagi has joined #svg 09:13:53 Language is really confusing in 4.13.1 re partial implementation (for all SVG user agents) of the HTML-defined extensions to Document interface. Need to clarify that HTML-support user agents must implement full interface, others implement this limited set. 09:46:49 AmeliaBR has joined #svg 09:48:21 LJWatson has joined #svg 09:51:12 Topic: Chapter 5: Styling 09:55:46 AmeliaBR: Regarding the style element, SVG 2 is in sync with HTML5, but HTML51 adds the scoped attribute 09:55:51 ... would be good for SVG 09:56:10 ... it's included in HTML so you can import widgets with self contained files and that sort of thing 09:56:35 RESOLUTION: Add the scoped attribute from HTML51 style element to SVG's style element 10:04:36 chaals: Chrome removed support - said it was too complicated 10:04:51 ... I'm going to file an issue on HTML51 stating there isn't enough interop so it may get dropped from HTML51 10:11:34 Section 5.7, the prose describing the user stylesheet for transform-origin isn't quite correct. Parentheses should be "(except for root ‘svg’ elements and ‘svg’ elements that are the child of a ‘foreignObject’ element or an element in a non-SVG namespace; these elements must transform around their center)" 10:11:35 nikos: I filed an issue to track the scoped attribute - https://github.com/w3c/svgwg/issues/118 10:20:12 -> https://github.com/w3c/html/issues/231 HTML issue: should style scoped be removed 10:27:20 AmeliaBR: Anyone opposed to the for the presentation attributes with no name clashes, we make them valid on any element? 10:27:29 ... then we won't have to update this table anytime an element is created 10:28:16 ... we still need restrictions on geometry presentation attributes, otherwise things break 10:29:49 ... Chrome and Edge already do things that way 10:30:03 Based on quick tests, it looks like Chrome & Edge already implement it this way, recognizing a fill="red" presentation attribute on elements not in that list. 10:58:29 Chapter 6: Geometry properties 10:58:47 Re "illegal value", here is the CSS 2.1 reference of what that means: https://www.w3.org/TR/CSS21/syndata.html#illegalvalues 11:05:00 Issues re geometry property chapter 11:05:32 GH#74: https://github.com/w3c/svgwg/issues/74 "Initial value for the 'rx' and 'ry' properties" 11:13:35 AmeliaBR has joined #svg 11:43:08 stakagi_ has joined #svg 12:18:47 stakagi has joined #svg 13:00:54 AmeliaBR has joined #svg 13:12:33 Nikos notes that it says width & height of auto are used as 0, but that's not true of (used is 100%) 13:17:00 LJWatson has joined #svg 13:18:55 And is even more complicated (defaults are x/y -10%, width/height 120%, like filters). CSS masking defines them as attributes, not properties: https://drafts.fxtf.org/css-masking-1/#MaskElement 13:19:40 Agreed: remove the mention of from the geometry properties chapter. CSS masking can opt-in to upgrading attributes to properties (with necessary changes to user style sheets, etc.) later. 13:22:19 Images were also supposed to support proper "auto" sizing, as an SVG 2 requirement: https://svgwg.org/svg2-draft/embedded.html#ImageElement 13:25:55 CSS spec (ED) for auto-sizing replaced content: https://drafts.csswg.org/css-sizing-3/#auto-box-sizes 13:47:48 Not in the draft, but for this chapter, is GH#49 https://github.com/w3c/svgwg/issues/49, AKA, what to do with path data as a geometric property 13:51:49 scribe: nikos 13:52:05 AmeliaBR: There's lots of discussion in the github, some is things for the future, but some is stuff needed for SVG 2 13:53:33 Tav: Why do we need to solve this now? 13:53:43 AmeliaBR: there's a strong need for this in CSS animations and such 13:54:03 ... We have issues with the same or similar attributes with same name different effect, etc. 13:54:19 ... We need to have a consistent naming scheme so one property has a specific meaning regardless of the element 13:54:39 ... we are changing the syntax anyway because CSSWG baulked at the idea of having full svg path data as a series of tokens that needed to be parsed 13:54:51 ... svg path data parsing rules don't place nicely with css parsing rules 13:55:42 nikos: could you summarise the discussion so far? 13:55:45 AmeliaBR: d is not a good name 13:55:52 ... d is used for two different things, path and textPath 13:56:06 ... we also have polygon and polyline points which have the same effect as d does on path 13:56:15 ... but different syntax 13:56:25 ... difference in syntax can be resolved using css functions 13:56:31 ... the question is what is the name of that property 13:56:33 nikos: shape 13:56:41 AmeliaBR: other suggestion is geometry 13:56:52 ... with shape, we have shape-insdie and shape-outside 13:57:02 ... so having shape on its own makes it seem like a shorthand 13:57:14 ... though its logical 13:57:21 ... [missed a bit] 13:57:59 Tav: You have the problem that shape-inside can have multiple shapes and you flow from one to the next 13:58:44 ... shape-subtract is a bit different because it's our (SVG) way of setting exclusions 13:59:51 AmeliaBR: so if we leave shape for text stuff, geometry would be the other option 13:59:57 nikos: ok with geometry 14:00:17 Tav: It's going to be hard for us to implement css function notation 14:01:29 nikos: was it just the name we need to work out? 14:01:48 AmeliaBR: other thing is whether we make geometry the magic toggle for basic shapes 14:01:56 ... so geometry: circle looks at cx, cy, etc 14:02:50 ... there's nothing in the computed style that explains how the properties of the shape are worked out, it's based on the tag name 14:03:51 Tav: doesn't CSS already have a circle function where you have to provide the values in the right order? 14:03:58 AmeliaBR: yes, that's a complication 14:04:06 Tav: think this isn't something we should try to get into SVG 2 14:04:12 ... need to work it out with CSS 14:04:41 AmeliaBR: not sure there's anything we need to work out with css. 14:04:56 ... at the moment we have properties that describe the parameters of the shape, but the shape itself comes from the xml side 14:05:13 ... it's an incomplete model. We're half way into CSS but still have dependency on xml 14:05:19 Tav: whole point is to get path animation right? 14:05:22 AmeliaBR: yes 14:06:47 AmeliaBR: Chrome has deprecated SMIL and MS never implemented it. So there's strong demand from authors for path animation, and strong demand from browsers to do it in CSS 14:07:33 AmeliaBR: the reason to change it now is to define a logical model that is extensible in the future 14:08:06 Tav: I'm just worried it's going to be an awful lot of work and I don't want to see the animation of d stalled 14:08:26 ... I think it's a logical goal, just think it's too much for now 14:08:35 ... Chrome already has d ready to go, they just want a name 14:08:57 AmeliaBR: we can leave off keyword values, that's something that can be defined as an additional property 14:09:12 ... what we do need is one name for path data and polygon, polyline points 14:09:31 ... where the value between teh three will be distinguished by the css shape function 14:10:47 Tav: I don't see a need to animate polyline 14:11:12 AmeliaBR: with charts where you ahve lots of data in an array it's a lot easier 14:11:20 Tav: It's the same without the initial M 14:14:55 AmeliaBR: ok so we're ok with geometry as the name and have it effect path, polygon, and polyline, and define a new CSS shape polyline function somewhere in CSS? 14:15:25 chaals: Not going to move the spec fowards by inventing functionality without any implementer input 14:15:52 nikos: Google has been supportive of Amelia's proposal on github, but I agree we should focus on speccing the minumum now and extend further through a module 14:16:10 AmeliaBR: we need to change the name of the attribute on textPath so it doesn't use d 14:16:22 ... there are no implementations as far as I know so we 're not breaking anything 14:17:00 nikos: there's a few other places where we use path data. Somtimes without the inital moveto, that should be distinct 14:17:21 Tav: there's usage of a path attribute 14:19:13 RESOLUTION: Rename the d attribute on textPath to 'path'. It will just be an attribute for now. 14:19:32 Tav: if you want to animate textPath reference a path 14:19:42 Tav: I would just use 'd' for the presentation attribute for path data 14:19:48 AmeliaBR: value will just be a string 14:20:18 Tav: geometry can be added later to do what it needs to do 14:21:09 https://svgwg.org/svg2-draft/paths.html#DProperty 14:21:11 nikos: If Chrome want css functions they can provide a proposal 14:21:54 ... and we'll do that as a separate module 14:22:34 AmeliaBR: are we going to leave points as an attribute for now? 14:23:01 Tav: Can see that might cause some confusion 14:23:12 ... Can we make it a presentation attribute? 14:23:19 nikos: If we can make d a presentation attribute we can make points one 14:23:31 AmeliaBR: question is do we treate it as a string or a list of numbers? 14:24:28 RESOLUTION: d will become a presentation attribute (no name change) with path data string as a value and for now it only affects the path element 14:25:10 AmeliaBR: since it's only going to affect path elements we can leave it in the paths chapter rather than moving to geometry 14:26:44 rrsagent, pointer 14:26:44 See http://www.w3.org/2016/04/21-svg-irc#T14-26-44 14:26:54 rrsagent, make minutes 14:26:54 I have made the request to generate http://www.w3.org/2016/04/21-svg-minutes.html nikos 15:32:01 AmeliaBR has joined #svg 16:17:56 Hey y'all, the CSS Scoping spec is now updated to the current Shadow DOM model.