IRC log of svg on 2016-04-20

Timestamps are in UTC.

08:28:42 [RRSAgent]
RRSAgent has joined #svg
08:28:42 [RRSAgent]
logging to
08:28:44 [trackbot]
RRSAgent, make logs public
08:28:44 [Zakim]
Zakim has joined #svg
08:28:46 [trackbot]
Zakim, this will be GA_SVGWG
08:28:46 [Zakim]
ok, trackbot
08:28:47 [trackbot]
Meeting: SVG Working Group Teleconference
08:28:47 [trackbot]
Date: 20 April 2016
08:28:50 [chaals]
chaals has joined #svg
08:29:03 [Tav]
Tav has joined #svg
08:30:27 [chaals]
rrsagent, draft minutes
08:30:27 [RRSAgent]
I have made the request to generate chaals
08:30:41 [chaals]
rrsagent, make log public
08:30:47 [nikos]
Scribe: nikos
08:30:51 [nikos]
Scribenick: nikos
08:30:52 [chaals]
Meeting: SVG
08:30:57 [LJWatson]
present+ LJWatson
08:31:02 [nikos]
present+ nikos
08:31:11 [nikos]
chair: nikos
08:31:15 [chaals]
present+ Chaals, Amelia, Tav
08:31:15 [Tav]
present +Tav
08:31:21 [chaals]
present- tav
08:31:51 [chaals]
agenda+ Finish SVG
08:32:47 [chaals]
agenda+ bikesheds
08:33:06 [chaals]
rrsagent, draft minutes
08:33:06 [RRSAgent]
I have made the request to generate chaals
08:33:21 [nikos]
Topic: Introduction chapter
08:33:23 [nikos]
08:34:10 [nikos]
08:39:24 [LJWatson]
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 [chaals]
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 [chaals]
1.2, list item 2, s/document/documents/
08:43:30 [chaals]
1.2 last item s/is compatible with W3C work on Web Accessibility/provides support for making accessible graphics./
08:46:47 [nikos]
nikos: Do you have the updated links to DOM specs?
08:47:03 [AmeliaBR]
This is the new CSSOM, still a working draft:
08:48:24 [chaals]
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 [LJWatson]
+1 Chaals.
08:52:20 [chaals]
( _underlined stuff_ links to accessibility chapter, which is going to get some more things in it…)
08:53:24 [chaals]
in 1.1 p3 s/such as ‘’">’ and ‘’ //
08:53:56 [chaals]
and s/Because of its, features like//
08:55:11 [chaals]
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 [chaals]
"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 [chaals]
Don't sweat the links to DOM, but references will need to be updated as a final pass…
09:07:20 [chaals]
[Nikos committed changes]
09:11:47 [nikos]
Topic: Rendering chapter
09:12:00 [nikos]
chaals: paragraph 3 of 2.2 isn't strictly true
09:12:20 [nikos]
... there are manipulations that you can make in terms of event handlers and changing styling
09:12:26 [nikos]
... I'd remove that paragraph
09:14:32 [nikos]
[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 [nikos]
chaals: Is z-index implemented anywhere for svg?
09:19:50 [nikos]
AmeliaBR: no
09:19:59 [nikos]
chaals: Should remove it from the spec then, or mark it at risk
09:21:45 [AmeliaBR]
Could encourage authors to put pressure on implementers, too.
09:22:28 [LJWatson]
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 [chaals]
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 [LJWatson]
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 [chaals]
proposal for first section:
09:29:33 [chaals]
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 [chaals]
09:29:33 [chaals]
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 [chaals]
err, s/are must/must/
09:30:20 [AmeliaBR]
S 2.4 is problematic, confuses z-axis and z-index, which is quite different from z-axis in 3D transforms
09:35:17 [chaals]
Need to explicitly write in "a shape can have filters applied, then clips applied, then masks"
09:36:11 [Tav]
S 2.7 s/shapes/Shapes/
09:37:03 [chaals]
please s/UA/User Agent/g#exceptWhereItDoesn'tMeanThat
09:37:25 [chaals]
(e.g. note as lat para in this chapter)
09:37:42 [AmeliaBR]
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]
stakagi has joined #svg
09:41:34 [stakagi]
present+ stakagi
09:42:40 [AmeliaBR]
Hi stakagi, feel free to follow along, we're doing a chapter-by-chapter review, just wrapping up Ch2
09:45:02 [stakagi]
Thanks Amelia!
09:48:27 [chaals]
[break. back at 10 past whatever is next]
09:48:53 [AmeliaBR]
ACTION Amelia to review rendering chapter text re z-index to make compatible with 3D transforms
09:48:53 [trackbot]
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]
AmeliaBR has joined #svg
10:16:51 [LJWatson]
LJWatson has joined #svg
10:18:53 [chaals]
scribe: chaals
10:19:16 [nikos]
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 [chaals]
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]
nikos: Added issue for that -
10:20:39 [chaals]
s/that/user agent implementation requirements language/
10:20:49 [chaals]
Topic: Chapter 3
10:22:29 [chaals]
CMN: 3.3 needs a pointer to what IEE finitie single presicions values are.
10:23:35 [chaals]
ABR: Do we use both EBNF and ABNF?
10:23:43 [chaals]
… language tag references ABNF
10:23:51 [chaals]
NA: We use EBNF
10:24:02 [chaals]
ABR: In path data…
10:24:32 [chaals]
… would be nice to reduce the number of ways we describe things.
10:26:13 [chaals]
NA: Think the annotation in 3.4.2 is "done" - we have methods.
10:28:49 [chaals]
CMN: What is the status of annotation 1 in 3.5.4?
10:31:07 [chaals]
[discussion about whether to use MathML, LaTeX or both…]
10:31:37 [chaals]
[conclusion: have MathML+mathjax for rendering, keep pointers to the LaTeX to simplify editing]
10:33:16 [nikos]
transformToElement removal discussion
10:33:25 [chaals]
ABR: What happened to that
10:34:13 [chaals]
… 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 [chaals]
NA: Yes we have done the making SVGList* nicer. So status to "done"
10:35:48 [nikos]
Tav: Here's previous discussion about marker:overflow remaining hidden -
10:37:01 [chaals]
CMN: need to s/IDL attribute _reflects_/IDL attribute must _reflect_/g as a User Agent requirement
10:37:57 [chaals]
… I'll add that to #106
10:40:30 [chaals]
CMN: IEEE link - ??
10:41:26 [chaals]
… I mean - and you can buy this. Maybe we should use an altenative reference, or write this out in full?
10:42:44 [chaals]
TB: Everyone will use what their computer implements as single arithmetic.
10:42:55 [chaals]
CMN: So let's say that's OK and be done, no?
10:43:00 [chaals]
TB: sure.
10:45:11 [chaals]
CMN: raised as #109
10:45:59 [chaals]
ABR: 3.4.3 is where the path methods were moved. There should be a statement about Path or Equivalent path.
10:47:44 [chaals]
… I'm going to come up with an edit now.
10:48:10 [AmeliaBR]
Remove "text" from 1st para of 3.4.3. Add sentence at end "For basic shapes, calculations use the equivalent path."
10:50:00 [chaals]
Topic: chapter 4
10:53:01 [chaals]
CMN: Overview should note that standalone SVG must be XML.
10:53:39 [chaals]
[discussion about multiple svg elements]
10:54:17 [chaals]
ABR: the confusing bit is where you have foreignObject and inside that an svg element - that creates a new SVG fragment.
10:55:20 [chaals]
CMN: SVG-in-HTML example should have html tags to make it clearer ...
10:55:26 [chaals]
… in 4.1.2
10:57:11 [chaals]
CMN: status of annotation 1- transform on svg element?
10:57:15 [chaals]
ABR: there are bugs
10:57:22 [chaals]
Tav: Only on non-standalone.
10:59:36 [chaals]
Tav: is marker a structural element?
10:59:38 [chaals]
11:00:00 [chaals]
LJW: the "show" expansion thing doesn't play nicely with the screenreader.
11:00:43 [chaals]
ABR: Will raise an issue for that.
11:02:48 [chaals]
CMN: 4.3, annotation 2, should be status "done"
11:02:56 [AmeliaBR]
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 [AmeliaBR]
s/child content/descendent content/
11:03:45 [chaals]
Tav: should we remove "svg-enabled browsers only"?
11:04:13 [chaals]
11:04:43 [chaals]
CMN: 4.4.1 refers to RFC3987 but the intro says we use whatwg URL for urls.
11:10:23 [chaals]
CMN: defs are pumped out to the accessibility tree in implementations, and should not be.
11:10:38 [chaals]
… spec bug or implementation issue?
11:11:05 [chaals]
ABR: implementation bug - SVG AAM says the right thing.
11:12:01 [LJWatson]
Suggest adding "can be" into the following sentence: "The attribute 'lang’ *can be* added to allow internationalization of the..."
11:14:17 [chaals]
[discussion of issue-63]
11:14:56 [nikos]
rrsagent, pointer
11:14:56 [RRSAgent]
11:14:59 [chaals]
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 [chaals]
RATIONALE: defining anything else gets messy and painful for no known value.
11:15:39 [chaals]
Tav: what about properties on such elements? They don't render so who cares?
11:16:18 [chaals]
NA: If you have an unknown element with style attributes, are those inherited by children that are SVG?
11:16:42 [chaals]
CMN: What do implementations do here?
11:17:02 [chaals]
Tav: think we were going to define an explicit set of things that would work.
11:17:28 [chaals]
ABR: One reason for the question was to enable adding new elements without having documents fail.
11:17:40 [chaals]
NA: FF doesn't treat unknown elements as a group.
11:18:13 [chaals]
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 [chaals]
CMN: which is the point of treating unknown elements as g
11:18:35 [AmeliaBR]
s/lists of elements/lists of attributes/
11:18:41 [chaals]
Tav: if we treat an unknown element as a g, they are a container.
11:19:01 [chaals]
NA: doesn't talk about interfaces, just tagnames.
11:19:19 [chaals]
CMN: what is the practical impact of the decision?
11:19:30 [chaals]
NA: We talk about container elements…
11:19:42 [chaals]
ABR: Think treating unknown elements as g does this
11:19:46 [chaals]
11:20:15 [chaals]
NA: simple thing is "replace the element name with a g". any downside to that?
11:20:32 [chaals]
… do we want to tell people not to make things up?
11:20:44 [chaals]
CMN: No, at some point we will have custom elements…
11:21:59 [chaals]
LJW: What's the story about tooltips on title?
11:22:13 [chaals]
ABR: I have an oustanding action to chase that up.
11:22:35 [nikos]
11:22:37 [chaals]
… as part of dealing with title, desc, …
11:23:44 [chaals]
ABR: empty titles and descs are a pain. We'd like to have an authoring fail for doing that.
11:23:58 [chaals]
… needs to be must not for authoring tools.
11:24:08 [chaals]
CMN: That is in ATAG already, right?
11:27:06 [chaals]
ABR: another issue is for unknown or no language for title/desc content.
11:27:51 [chaals]
… e.g. <title lang="en">smile</title><title lang="fr">sourire</title><title lang="">:)</title>
11:29:42 [LJWatson]
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 [chaals]
CMN: can we please put the elements defined in these blocks on the left, with the other text
11:36:00 [chaals]
NA: We probably need to do a rewrite to bikeshed and clean up the markup all over the place.
11:36:11 [chaals]
NA: Are annotation 4/5 on markers done?
11:36:14 [chaals]
CMN: seems so.
11:36:31 [Tav] Tooltips
11:37:05 [nikos]
11:39:13 [chaals]
[remove issue-20 marker. SVG 1.2 isn't the source of information we were looking for]
11:39:40 [chaals]
ABR: I'll edit the title of the issue to make it the more general one.
11:40:53 [chaals]
ABR: Annotation 6 on use elements has been done.
11:42:46 [chaals]
Tav: What about issue-23, including namespaced content in desc?
11:43:11 [chaals]
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 [nikos]
rrsagent, make minutes
11:43:37 [RRSAgent]
I have made the request to generate nikos
11:43:43 [chaals]
… 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 [chaals]
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 [chaals]
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 [trackbot]
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 [chaals]
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 [chaals]
[metadata elements. They are useful as scatterable, but why only one in a specific place?]
11:49:28 [chaals]
ABR: We don't define what metadata *does* so why do we tell you where to put it?
11:49:41 [chaals]
… no reason to recommend one way or the other.
11:51:06 [chaals]
RESOLUTION: stop telling people where they should or shouldn't put metadata.
11:59:36 [chaals]
[lunch: Just going out. We may be some time]
12:28:56 [trackbot]
trackbot has joined #svg
13:30:22 [chaals]
chaals has joined #svg
13:32:07 [LJWatson]
LJWatson has joined #svg
13:53:05 [AmeliaBR]
AmeliaBR has joined #svg
14:47:23 [chaals]
scribe: ?
14:48:49 [nikos]
scribe: nikos
14:49:02 [LJWatson]
LJWatson has joined #svg
14:49:04 [nikos]
Topic: Defining use in terms of Shadow DOM
14:49:29 [nikos]
AmeliaBR: One of the benefits of the shadow dom architecture is that it's divided into many modules
14:49:40 [nikos]
... so we can have an SVG specific definition and then synchronised sections that use the other specs
14:49:57 [nikos]
... 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 [nikos]
... However, once we define a use element as being a shadow dom host, and the repeated content as the shadow dom
14:50:24 [nikos]
... then we can start using some of the CSS rules and some of the event handling rules
14:50:31 [nikos]
... and DOM interfaces
14:50:46 [nikos]
... 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 [nikos]
... Think currently we say this is undefined in the spec.
14:51:12 [nikos]
... So we treat files in the external file similarly to styles scoped within a web component
14:52:13 [nikos]
... The question is does that make sense.
14:52:32 [nikos]
... 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 [nikos]
... as far as matching actual shadow dom elements goes
14:53:59 [AmeliaBR]
Shadow DOM spec:
14:54:20 [AmeliaBR]
CSS Scoping / Shadow Encapsulation:
14:56:25 [AmeliaBR]
pinging @TabAtkins if you're online yet, we'd love a translation of the shadow encapsulation cascading rules
14:58:00 [nikos]
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 [chaals]
[ -> testing for multilingual titles]
15:41:25 [AmeliaBR]
AmeliaBR has joined #svg
15:45:54 [AmeliaBR]
Chrome (which supports width/height as presentation attributes) currently treats non-auto values on <symbol> the same as they would on a re-used SVG.,css,output
15:47:39 [AmeliaBR]
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 [AmeliaBR]
Firefox also renders the same, but probably for different reasons inside the implementation.
16:08:16 [nikos]
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 [TabAtkins]
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 [TabAtkins]
It'll be available today.
16:14:21 [TabAtkins]
Do *not* depend on the current spec; it's based on the 2+ year-old version of Shadow DOM.
16:14:40 [AmeliaBR]
OK. Do you think it will be compatible with <use>?
16:15:21 [AmeliaBR]
Specifically, selectors in the main doc never match content the re-used content.
16:19:30 [LJWatson_]
LJWatson_ has joined #svg
16:36:08 [TabAtkins]
AmeliaBR: Yes, that's def true.
16:36:23 [TabAtkins]
And inheritance goes thru the shadow boundary.
16:50:14 [AmeliaBR]
TabAtkins: OK, text in 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 [TabAtkins]
16:50:47 [AmeliaBR]
That's fine, then. Not breaking backwards-compat
16:51:08 [TabAtkins]
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 <slot>.
16:52:43 [AmeliaBR]
Makes sense. But again, not a deal-breaker for <use>. Now just need to figure out whether we can make sense of the event-handling/-retargetting rules.
16:55:11 [TabAtkins]
Yeah, those are questions for annevk in Freenode#whatwg.
16:59:55 [LJWatson_]
LJWatson_ has joined #svg
17:08:33 [AmeliaBR]
AmeliaBR has joined #svg
17:41:43 [AmeliaBR]
AmeliaBR has left #svg
19:00:17 [nikos]
Reagent, make minutes
19:00:39 [nikos]
Rrsagent, make minutes
19:00:39 [RRSAgent]
I have made the request to generate nikos
22:11:27 [shepazu_]
shepazu_ has joined #svg
22:16:24 [stakagi]
stakagi has joined #svg
22:24:43 [Tav]
Tav has joined #svg