08:28:42 RRSAgent has joined #svg 08:28:42 logging to http://www.w3.org/2016/04/20-svg-irc 08:28:44 RRSAgent, make logs public 08:28:44 Zakim has joined #svg 08:28:46 Zakim, this will be GA_SVGWG 08:28:46 ok, trackbot 08:28:47 Meeting: SVG Working Group Teleconference 08:28:47 Date: 20 April 2016 08:28:50 chaals has joined #svg 08:29:03 Tav has joined #svg 08:30:27 rrsagent, draft minutes 08:30:27 I have made the request to generate http://www.w3.org/2016/04/20-svg-minutes.html chaals 08:30:41 rrsagent, make log public 08:30:47 Scribe: nikos 08:30:51 Scribenick: nikos 08:30:52 Meeting: SVG 08:30:57 present+ LJWatson 08:31:02 present+ nikos 08:31:11 chair: nikos 08:31:15 present+ Chaals, Amelia, Tav 08:31:15 present +Tav 08:31:21 present- tav 08:31:51 agenda+ Finish SVG 08:32:47 agenda+ bikesheds 08:33:06 rrsagent, draft minutes 08:33:06 I have made the request to generate http://www.w3.org/2016/04/20-svg-minutes.html chaals 08:33:21 Topic: Introduction chapter 08:33:23 https://svgwg.org/svg2-draft/intro.html 08:34:10 https://github.com/w3c/svgwg/issues?utf8=%E2%9C%93&q=label%3A%22London+2016%22+ 08:39:24 In the sentence that starts "Sophisticated applications of ...", should the word "the" be inserted before the link to "SVG Document Object Model (DOM"? 08:39:25 change "mixed with HTML5, it uses the HTML5 syntax [" to "SVG code is used inside HTML documents it uses the HTML syntax [" 08:41:49 1.2, list item 2, s/document/documents/ 08:43:30 1.2 last item s/is compatible with W3C work on Web Accessibility/provides support for making accessible graphics./ 08:46:47 nikos: Do you have the updated links to DOM specs? 08:47:03 This is the new CSSOM, still a working draft: https://www.w3.org/TR/cssom-1/ 08:48:24 proposed last para replacement for 1.1: SVG is useful for rich graphical presentation of information, including a number of _accessibility features that, used correctly_, ensure the content can be used by the widest possible audience. But a direct link to source data, where possible, is helpful for many people to understand the content provided. 08:50:44 +1 Chaals. 08:52:20 ( _underlined stuff_ links to accessibility chapter, which is going to get some more things in it…) 08:53:24 in 1.1 p3 s/such as ‘https://svgwg.org/svg2-draft/interact.html#EventAttributes’ and ‘https://svgwg.org/svg2-draft/interact.html#EventAttributes’ // 08:53:56 and s/Because of its https://svgwg.org/svg2-draft/intro.html#W3CCompatibility, features like// 08:55:11 and change the rest of the sentence to "In a Web page, the same scripts can work on SVG and HTML elements." 08:57:16 "terminology" is definitions, and these are scattered throughout. The RFC 2119 para is about "Conformance" - an maybe should be part of something more about the topic. 09:06:16 Don't sweat the links to DOM, but references will need to be updated as a final pass… 09:07:20 [Nikos committed changes] 09:11:47 Topic: Rendering chapter 09:12:00 chaals: paragraph 3 of 2.2 isn't strictly true 09:12:20 ... there are manipulations that you can make in terms of event handlers and changing styling 09:12:26 ... I'd remove that paragraph 09:14:32 [Removed last sentence: However, they are always reflections of the original element, and are not directly manipulable by script or user interaction. ] 09:19:49 chaals: Is z-index implemented anywhere for svg? 09:19:50 AmeliaBR: no 09:19:59 chaals: Should remove it from the spec then, or mark it at risk 09:21:45 Could encourage authors to put pressure on implementers, too. 09:22:28 Suggest changing "The elements in an SVG document are each either rendered or non-rendered at a given point in time." to "At any given time, an SVG element is either rendered or non-rendered." 09:25:51 2.7.1 para 5 should add "or vice versa", or just have the first bit up to "operations;" put at the beginning of para 4 and the rest thrown away. 09:29:05 Suggest changing "Non-rendered elements likewise have no counterpart in an accessible alternative view of the document." to "Non-rendered elements are not represented in the document accessibility tree." 09:29:31 proposal for first section: 09:29:33 Implementations of SVG are must implement the rendering model as described in this chapter, as modified in the appendix on conformance requirements which describes situations where an implementation may deviate. 09:29:33 09:29:33 In practice variability is allowed based on limitations of the output device (e.g. only a limited range of colors might be supported) and because of practical limitations in implementing a precise mathematical model (e.g. for realistic performance curves are approximated by straight lines, the approximation need only be sufficiently precise to match the conformance requirements). 09:29:51 err, s/are must/must/ 09:30:20 S 2.4 is problematic, confuses z-axis and z-index, which is quite different from z-axis in 3D transforms 09:35:17 Need to explicitly write in "a shape can have filters applied, then clips applied, then masks" 09:36:11 S 2.7 s/shapes/Shapes/ 09:37:03 please s/UA/User Agent/g#exceptWhereItDoesn'tMeanThat 09:37:25 (e.g. note as lat para in this chapter) 09:37:42 Need to more clearly describe each aspect of rendering process as an order of operations. And re-arrange if necessary, e.g. "how groups are rendered" should come after the "painting shapes & text" / "images" section 09:41:13 stakagi has joined #svg 09:41:34 present+ stakagi 09:42:40 Hi stakagi, feel free to follow along, we're doing a chapter-by-chapter review, just wrapping up Ch2 09:45:02 Thanks Amelia! 09:48:27 [break. back at 10 past whatever is next] 09:48:53 ACTION Amelia to review rendering chapter text re z-index to make compatible with 3D transforms 09:48:53 Created ACTION-3838 - Review rendering chapter text re z-index to make compatible with 3d transforms [on Amelia Bellamy-Royds - due 2016-04-27]. 10:15:55 AmeliaBR has joined #svg 10:16:51 LJWatson has joined #svg 10:18:53 scribe: chaals 10:19:16 nikos: Regarding issue 13 in the rendering chapter, this may be nice to have but not essential for CR, so I'm going to file a github issue and remove the issue from the spec 10:19:50 CMN: at the end of sections that describe e.g. filling and stroking and markers are independent and ordered according to X, there should be a "user agents must …" statement, that can be tested. 10:20:03 nikos: Added issue for that - https://github.com/w3c/svgwg/issues/106 10:20:39 s/that/user agent implementation requirements language/ 10:20:49 Topic: Chapter 3 10:22:29 CMN: 3.3 needs a pointer to what IEE finitie single presicions values are. 10:23:35 ABR: Do we use both EBNF and ABNF? 10:23:43 … language tag references ABNF 10:23:51 NA: We use EBNF 10:24:02 ABR: In path data… 10:24:32 … would be nice to reduce the number of ways we describe things. 10:26:13 NA: Think the annotation in 3.4.2 is "done" - we have methods. 10:28:49 CMN: What is the status of annotation 1 in 3.5.4? 10:31:07 [discussion about whether to use MathML, LaTeX or both…] 10:31:37 [conclusion: have MathML+mathjax for rendering, keep pointers to the LaTeX to simplify editing] 10:33:16 transformToElement removal discussion https://www.w3.org/2015/06/09-svg-minutes.html#item01 10:33:25 ABR: What happened to that 10:34:13 … thought we were going to add a warning about Dragons in implementations and hope CSS would solve it. Seems that they just got tossed out. 10:35:38 NA: Yes we have done the making SVGList* nicer. So status to "done" 10:35:48 Tav: Here's previous discussion about marker:overflow remaining hidden - https://www.w3.org/2015/08/25-svg-minutes.html#item06 10:37:01 CMN: need to s/IDL attribute _reflects_/IDL attribute must _reflect_/g as a User Agent requirement 10:37:57 … I'll add that to #106 10:40:30 CMN: IEEE link - https://www.w3.org/TR/2000/WD-xmlschema-2-20000407/#ieee754 ?? 10:41:26 … I mean http://standards.ieee.org/findstds/standard/754-1985.html - and you can buy this. Maybe we should use an altenative reference, or write this out in full? 10:42:44 TB: Everyone will use what their computer implements as single arithmetic. 10:42:55 CMN: So let's say that's OK and be done, no? 10:43:00 TB: sure. 10:45:11 CMN: raised as #109 https://github.com/w3c/svgwg/issues/109 10:45:59 ABR: 3.4.3 is where the path methods were moved. There should be a statement about Path or Equivalent path. 10:47:44 … I'm going to come up with an edit now. 10:48:10 Remove "text" from 1st para of 3.4.3. Add sentence at end "For basic shapes, calculations use the equivalent path." 10:50:00 Topic: chapter 4 https://svgwg.org/svg2-draft/struct.html 10:53:01 CMN: Overview should note that standalone SVG must be XML. 10:53:39 [discussion about multiple svg elements] 10:54:17 ABR: the confusing bit is where you have foreignObject and inside that an svg element - that creates a new SVG fragment. 10:55:20 CMN: SVG-in-HTML example should have html tags to make it clearer ... 10:55:26 … in 4.1.2 10:57:11 CMN: status of annotation 1- transform on svg element? 10:57:15 ABR: there are bugs 10:57:22 Tav: Only on non-standalone. 10:59:36 Tav: is marker a structural element? 10:59:38 [no] 11:00:00 LJW: the "show" expansion thing doesn't play nicely with the screenreader. 11:00:43 ABR: Will raise an issue for that. 11:02:48 CMN: 4.3, annotation 2, should be status "done" 11:02:56 Make first para: "An SVG document fragment consists of an ‘svg’ element and child content that uses the SVG layout model. Each SVG document fragment is rooted by an 'svg' element that is either the root element of the document or a child of an element that is not in the SVG namespace." 11:03:09 s/child content/descendent content/ 11:03:45 Tav: should we remove "svg-enabled browsers only"? 11:04:13 [yes] 11:04:43 CMN: 4.4.1 refers to RFC3987 but the intro says we use whatwg URL for urls. 11:10:23 CMN: defs are pumped out to the accessibility tree in implementations, and should not be. 11:10:38 … spec bug or implementation issue? 11:11:05 ABR: implementation bug - SVG AAM says the right thing. 11:12:01 Suggest adding "can be" into the following sentence: "The attribute 'lang’ *can be* added to allow internationalization of the..." 11:14:17 [discussion of issue-63] 11:14:56 rrsagent, pointer 11:14:56 See http://www.w3.org/2016/04/20-svg-irc#T11-14-56 11:14:59 RESOLUTION: If you want something taht's not SVG to render, put it in foreignObject. Otherwise it doesn't - like the spec says already. 11:15:22 RATIONALE: defining anything else gets messy and painful for no known value. 11:15:39 Tav: what about properties on such elements? They don't render so who cares? 11:16:18 NA: If you have an unknown element with style attributes, are those inherited by children that are SVG? 11:16:42 CMN: What do implementations do here? 11:17:02 Tav: think we were going to define an explicit set of things that would work. 11:17:28 ABR: One reason for the question was to enable adding new elements without having documents fail. 11:17:40 NA: FF doesn't treat unknown elements as a group. 11:18:13 ABR: We describe lists of elements that you can use anywhere. Can we have generic language that says any allowed SVG attributes can be applied. 11:18:26 CMN: which is the point of treating unknown elements as g 11:18:35 s/lists of elements/lists of attributes/ 11:18:41 Tav: if we treat an unknown element as a g, they are a container. 11:19:01 NA: doesn't talk about interfaces, just tagnames. 11:19:19 CMN: what is the practical impact of the decision? 11:19:30 NA: We talk about container elements… 11:19:42 ABR: Think treating unknown elements as g does this 11:19:46 [agreed] 11:20:15 NA: simple thing is "replace the element name with a g". any downside to that? 11:20:32 … do we want to tell people not to make things up? 11:20:44 CMN: No, at some point we will have custom elements… 11:21:59 LJW: What's the story about tooltips on title? 11:22:13 ABR: I have an oustanding action to chase that up. 11:22:35 https://github.com/w3c/svgwg/issues/101 11:22:37 … as part of dealing with title, desc, … 11:23:44 ABR: empty titles and descs are a pain. We'd like to have an authoring fail for doing that. 11:23:58 … needs to be must not for authoring tools. 11:24:08 CMN: That is in ATAG already, right? 11:27:06 ABR: another issue is for unknown or no language for title/desc content. 11:27:51 … e.g. smilesourire:) 11:29:42 4.5.1: "assistive technologies" should be "assistive technology" in the following sentence: "An author may also expose a hidden label on an element to an assistive technologies through..." 11:30:19 CMN: can we please put the elements defined in these blocks on the left, with the other text 11:36:00 NA: We probably need to do a rewrite to bikeshed and clean up the markup all over the place. 11:36:11 NA: Are annotation 4/5 on markers done? 11:36:14 CMN: seems so. 11:36:31 https://www.w3.org/TR/2004/WD-SVG12-20041027/applications.html Tooltips 11:37:05 https://github.com/w3c/svgwg/issues/102 11:39:13 [remove issue-20 marker. SVG 1.2 isn't the source of information we were looking for] 11:39:40 ABR: I'll edit the title of the issue to make it the more general one. 11:40:53 ABR: Annotation 6 on use elements has been done. 11:42:46 Tav: What about issue-23, including namespaced content in desc? 11:43:11 CMN: The use case is to allow for structured content in a desc - e.g. an overall description of a substantial image, which can't be well-described with flat text. 11:43:37 rrsagent, make minutes 11:43:37 I have made the request to generate http://www.w3.org/2016/04/20-svg-minutes.html nikos 11:43:43 … but there isn't much implementation support. The alternative is to have the structure as part of the SVG itself so the desc strings are just the leaf nodes at the end of that. 11:44:15 ABR: Should be a warning about what happens when you add things - only plain-text content gets used in e.g. AAM 11:45:19 ACTION: chaals to write up desc nodes being leaves in a structure that can be explored, since they are really only being exposed as plain text. 11:45:19 Created ACTION-3839 - write up desc nodes being leaves in a structure that can be explored, since they are really only being exposed as plain text. [on Charles McCathie Nevile - due 2016-04-27]. 11:46:46 CMN: to return to Amelia's question, are we going to define use in terms of web components/shadow DOM in the SVG2 timeline 11:48:23 [metadata elements. They are useful as scatterable, but why only one in a specific place?] 11:49:28 ABR: We don't define what metadata *does* so why do we tell you where to put it? 11:49:41 … no reason to recommend one way or the other. 11:51:06 RESOLUTION: stop telling people where they should or shouldn't put metadata. 11:59:36 [lunch: Just going out. We may be some time] 12:28:56 trackbot has joined #svg 13:30:22 chaals has joined #svg 13:32:07 LJWatson has joined #svg 13:53:05 AmeliaBR has joined #svg 14:47:23 scribe: ? 14:48:49 scribe: nikos 14:49:02 LJWatson has joined #svg 14:49:04 Topic: Defining use in terms of Shadow DOM 14:49:29 AmeliaBR: One of the benefits of the shadow dom architecture is that it's divided into many modules 14:49:40 ... so we can have an SVG specific definition and then synchronised sections that use the other specs 14:49:57 ... The way the shadow dom is created and the way that it is live linked to mutations in the source is SVG unique 14:50:14 ... However, once we define a use element as being a shadow dom host, and the repeated content as the shadow dom 14:50:24 ... then we can start using some of the CSS rules and some of the event handling rules 14:50:31 ... and DOM interfaces 14:50:46 ... For CSS, this helps address some of the issues we've had with defining what to do with styles in an external file 14:50:56 ... Think currently we say this is undefined in the spec. 14:51:12 ... So we treat files in the external file similarly to styles scoped within a web component 14:52:13 ... The question is does that make sense. 14:52:32 ... Ok so this might not work, in the CSS shadow dom scoping, rules defined in the main document override rules defined in the source content 14:52:41 ... as far as matching actual shadow dom elements goes 14:53:59 Shadow DOM spec: https://www.w3.org/TR/2015/WD-shadow-dom-20151215/ 14:54:20 CSS Scoping / Shadow Encapsulation: https://drafts.csswg.org/css-scoping/#shadow-dom 14:56:25 pinging @TabAtkins if you're online yet, we'd love a translation of the shadow encapsulation cascading rules 14:58:00 AmeliaBR: maybe it just means that objects with the deep combinator match, but if it means that all do then that's a problem 15:36:30 [ ->http://chaals.github.io/testcases/svg-multi-lang-title-manual.html testing for multilingual titles] 15:41:25 AmeliaBR has joined #svg 15:45:54 Chrome (which supports width/height as presentation attributes) currently treats non-auto values on the same as they would on a re-used SVG. https://jsbin.com/cunabarimu/edit?html,css,output 15:47:39 I recommended standardizing that behavior, re-writing that section (under use element s4.8) to refer to content that has a (default or specified) viewBox and non-auto values of width/height 15:54:17 Firefox also renders the same, but probably for different reasons inside the implementation. 16:08:16 AmeliaBR: I don't think we can define use in terms of web components now, but we should add a note stating that it may be done in future 16:13:49 AmeliaBR: I have a significant rewrite of the Shadow DOM section of CSS Scoping, which I'm just doing final fixup of right now. 16:13:55 It'll be available today. 16:14:21 Do *not* depend on the current spec; it's based on the 2+ year-old version of Shadow DOM. 16:14:40 OK. Do you think it will be compatible with ? 16:15:21 Specifically, selectors in the main doc never match content the re-used content. 16:19:30 LJWatson_ has joined #svg 16:36:08 AmeliaBR: Yes, that's def true. 16:36:23 And inheritance goes thru the shadow boundary. 16:50:14 TabAtkins: OK, text in https://drafts.csswg.org/css-scoping/#shadow-cascading wasn't clear, since it talks about rules from outer document taking precedence over rules from inside the shadow. But I guess that was in reference to "deep" selectors. 16:50:27 Correct. 16:50:47 That's fine, then. Not breaking backwards-compat 16:51:08 There's still some ways that rules in different trees can compete with each other, but they're specialized - like something in the light dom that is pulled into the shadow via . 16:52:43 Makes sense. But again, not a deal-breaker for . Now just need to figure out whether we can make sense of the event-handling/-retargetting rules. 16:55:11 Yeah, those are questions for annevk in Freenode#whatwg. 16:59:55 LJWatson_ has joined #svg 17:08:33 AmeliaBR has joined #svg 17:41:43 AmeliaBR has left #svg 19:00:17 Reagent, make minutes 19:00:39 Rrsagent, make minutes 19:00:39 I have made the request to generate http://www.w3.org/2016/04/20-svg-minutes.html nikos 22:11:27 shepazu_ has joined #svg 22:16:24 stakagi has joined #svg 22:24:43 Tav has joined #svg