SVG Working Group Teleconference -- 20 Apr 2016

<scribe> Scribe: nikos

<scribe> Scribenick: nikos

<chaals> Meeting: SVG

Introduction chapter

https://github.com/w3c/svgwg/issues?utf8=%E2%9C%93&q=label%3A%22London+2016%22+

<LJWatson> In the sentence that starts "Sophisticated applications of ...", should the word "the" be inserted before the link to "SVG Document Object Model (DOM"?

<chaals> change "mixed with HTML5, it uses the HTML5 syntax [" to "SVG code is used inside HTML documents it uses the HTML syntax ["

<chaals> 1.2, list item 2, s/document/documents/

<chaals> 1.2 last item s/is compatible with W3C work on Web Accessibility/provides support for making accessible graphics./

nikos: Do you have the updated links to DOM specs?

<AmeliaBR> This is the new CSSOM, still a working draft: https://www.w3.org/TR/cssom-1/

<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.

<LJWatson> +1 Chaals.

<chaals> ( _underlined stuff_ links to accessibility chapter, which is going to get some more things in it…)

<chaals> in 1.1 p3 s/such as ‘https://svgwg.org/svg2-draft/interact.html#EventAttributes’ and ‘https://svgwg.org/svg2-draft/interact.html#EventAttributes’ //

<chaals> and s/Because of its https://svgwg.org/svg2-draft/intro.html#W3CCompatibility, features like//

<chaals> and change the rest of the sentence to "In a Web page, the same scripts can work on SVG and HTML elements."

<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.

<chaals> Don't sweat the links to DOM, but references will need to be updated as a final pass…

<chaals> [Nikos committed changes]

Rendering chapter

chaals: paragraph 3 of 2.2 isn't strictly true
... there are manipulations that you can make in terms of event handlers and changing styling
... I'd remove that paragraph

[Removed last sentence: However, they are always reflections of the original element, and are not directly manipulable by script or user interaction. ]

chaals: Is z-index implemented anywhere for svg?

AmeliaBR: no

chaals: Should remove it from the spec then, or mark it at risk

<AmeliaBR> Could encourage authors to put pressure on implementers, too.

<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."

<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.

<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."

<chaals> proposal for first section:

<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.

<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).

<chaals> err, s/are must/must/

<AmeliaBR> S 2.4 is problematic, confuses z-axis and z-index, which is quite different from z-axis in 3D transforms

<chaals> Need to explicitly write in "a shape can have filters applied, then clips applied, then masks"

<Tav> S 2.7 s/shapes/Shapes/

<chaals> please s/UA/User Agent/g#exceptWhereItDoesn'tMeanThat

<chaals> (e.g. note as lat para in this chapter)

<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

<AmeliaBR> Hi stakagi, feel free to follow along, we're doing a chapter-by-chapter review, just wrapping up Ch2

<stakagi> Thanks Amelia!

<chaals> [break. back at 10 past whatever is next]

<AmeliaBR> ACTION Amelia to review rendering chapter text re z-index to make compatible with 3D transforms

<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].

<chaals> scribe: chaals

<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

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.

<nikos> nikos: Added issue for user agent implementation requirements language - https://github.com/w3c/svgwg/issues/106

Chapter 3

CMN: 3.3 needs a pointer to what IEE finitie single presicions values are.

ABR: Do we use both EBNF and ABNF?
... language tag references ABNF

NA: We use EBNF

ABR: In path data…
... would be nice to reduce the number of ways we describe things.

NA: Think the annotation in 3.4.2 is "done" - we have methods.

CMN: What is the status of annotation 1 in 3.5.4?

[discussion about whether to use MathML, LaTeX or both…]

[conclusion: have MathML+mathjax for rendering, keep pointers to the LaTeX to simplify editing]

<nikos> transformToElement removal discussion https://www.w3.org/2015/06/09-svg-minutes.html#item01

ABR: What happened to that
... 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.

NA: Yes we have done the making SVGList* nicer. So status to "done"

<nikos> Tav: Here's previous discussion about marker:overflow remaining hidden - https://www.w3.org/2015/08/25-svg-minutes.html#item06

CMN: need to s/IDL attribute _reflects_/IDL attribute must _reflect_/g as a User Agent requirement
... I'll add that to #106
... IEEE link - https://www.w3.org/TR/2000/WD-xmlschema-2-20000407/#ieee754 ??
... 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?

TB: Everyone will use what their computer implements as single arithmetic.

CMN: So let's say that's OK and be done, no?

TB: sure.

CMN: raised as #109 https://github.com/w3c/svgwg/issues/109

ABR: 3.4.3 is where the path methods were moved. There should be a statement about Path or Equivalent path.
... I'm going to come up with an edit now.

<AmeliaBR> Remove "text" from 1st para of 3.4.3. Add sentence at end "For basic shapes, calculations use the equivalent path."

chapter 4 https://svgwg.org/svg2-draft/struct.html

CMN: Overview should note that standalone SVG must be XML.

[discussion about multiple svg elements]

ABR: the confusing bit is where you have foreignObject and inside that an svg element - that creates a new SVG fragment.

CMN: SVG-in-HTML example should have html tags to make it clearer ...
... in 4.1.2
... status of annotation 1- transform on svg element?

ABR: there are bugs

Tav: Only on non-standalone.
... is marker a structural element?

[no]

LJW: the "show" expansion thing doesn't play nicely with the screenreader.

ABR: Will raise an issue for that.

CMN: 4.3, annotation 2, should be status "done"

<AmeliaBR> Make first para: "An SVG document fragment consists of an ‘svg’ element and descendent 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."

Tav: should we remove "svg-enabled browsers only"?

[yes]

CMN: 4.4.1 refers to RFC3987 but the intro says we use whatwg URL for urls.
... defs are pumped out to the accessibility tree in implementations, and should not be.
... spec bug or implementation issue?

ABR: implementation bug - SVG AAM says the right thing.

<LJWatson> Suggest adding "can be" into the following sentence: "The attribute 'lang’ *can be* added to allow internationalization of the..."

[discussion of issue-63]

RESOLUTION: If you want something taht's not SVG to render, put it in foreignObject. Otherwise it doesn't - like the spec says already.

RATIONALE: defining anything else gets messy and painful for no known value.

Tav: what about properties on such elements? They don't render so who cares?

NA: If you have an unknown element with style attributes, are those inherited by children that are SVG?

CMN: What do implementations do here?

Tav: think we were going to define an explicit set of things that would work.

ABR: One reason for the question was to enable adding new elements without having documents fail.

NA: FF doesn't treat unknown elements as a group.

ABR: We describe lists of attributes that you can use anywhere. Can we have generic language that says any allowed SVG attributes can be applied.

CMN: which is the point of treating unknown elements as g

Tav: if we treat an unknown element as a g, they are a container.

NA: doesn't talk about interfaces, just tagnames.

CMN: what is the practical impact of the decision?

NA: We talk about container elements…

ABR: Think treating unknown elements as g does this

[agreed]

NA: simple thing is "replace the element name with a g". any downside to that?
... do we want to tell people not to make things up?

CMN: No, at some point we will have custom elements…

LJW: What's the story about tooltips on title?

ABR: I have an oustanding action to chase that up.

<nikos> https://github.com/w3c/svgwg/issues/101

ABR: as part of dealing with title, desc, …
... empty titles and descs are a pain. We'd like to have an authoring fail for doing that.
... needs to be must not for authoring tools.

CMN: That is in ATAG already, right?

ABR: another issue is for unknown or no language for title/desc content.
... e.g. <title lang="en">smile</title><title lang="fr">sourire</title><title lang="">:)</title>

<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..."

CMN: can we please put the elements defined in these blocks on the left, with the other text

NA: We probably need to do a rewrite to bikeshed and clean up the markup all over the place.
... Are annotation 4/5 on markers done?

CMN: seems so.

<Tav> https://www.w3.org/TR/2004/WD-SVG12-20041027/applications.html Tooltips

<nikos> https://github.com/w3c/svgwg/issues/102

[remove issue-20 marker. SVG 1.2 isn't the source of information we were looking for]

ABR: I'll edit the title of the issue to make it the more general one.
... Annotation 6 on use elements has been done.

Tav: What about issue-23, including namespaced content in desc?

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.
... 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.

ABR: Should be a warning about what happens when you add things - only plain-text content gets used in e.g. AAM

<scribe> 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. [recorded in http://www.w3.org/2016/04/20-svg-minutes.html#action01]

<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].

CMN: to return to Amelia's question, are we going to define use in terms of web components/shadow DOM in the SVG2 timeline

[metadata elements. They are useful as scatterable, but why only one in a specific place?]

ABR: We don't define what metadata *does* so why do we tell you where to put it?
... no reason to recommend one way or the other.

RESOLUTION: stop telling people where they should or shouldn't put metadata.

[lunch: Just going out. We may be some time]

<scribe> scribe: ?

<nikos> scribe: nikos

Defining use in terms of Shadow DOM

AmeliaBR: One of the benefits of the shadow dom architecture is that it's divided into many modules
... so we can have an SVG specific definition and then synchronised sections that use the other specs
... The way the shadow dom is created and the way that it is live linked to mutations in the source is SVG unique
... However, once we define a use element as being a shadow dom host, and the repeated content as the shadow dom
... then we can start using some of the CSS rules and some of the event handling rules
... and DOM interfaces
... For CSS, this helps address some of the issues we've had with defining what to do with styles in an external file
... Think currently we say this is undefined in the spec.
... So we treat files in the external file similarly to styles scoped within a web component
... The question is does that make sense.
... 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
... as far as matching actual shadow dom elements goes

<AmeliaBR> Shadow DOM spec: https://www.w3.org/TR/2015/WD-shadow-dom-20151215/

<AmeliaBR> CSS Scoping / Shadow Encapsulation: https://drafts.csswg.org/css-scoping/#shadow-dom

<AmeliaBR> pinging @TabAtkins if you're online yet, we'd love a translation of the shadow encapsulation cascading rules

AmeliaBR: maybe it just means that objects with the deep combinator match, but if it means that all do then that's a problem

<chaals> [ ->http://chaals.github.io/testcases/svg-multi-lang-title-manual.html testing for multilingual titles]

<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. https://jsbin.com/cunabarimu/edit?html,css,output

<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

<AmeliaBR> Firefox also renders the same, but probably for different reasons inside the implementation.

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

<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.

<TabAtkins> It'll be available today.

<TabAtkins> Do *not* depend on the current spec; it's based on the 2+ year-old version of Shadow DOM.

<AmeliaBR> OK. Do you think it will be compatible with <use>?

<AmeliaBR> Specifically, selectors in the main doc never match content the re-used content.

<TabAtkins> AmeliaBR: Yes, that's def true.

<TabAtkins> And inheritance goes thru the shadow boundary.

<AmeliaBR> 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.

<TabAtkins> Correct.

<AmeliaBR> That's fine, then. Not breaking backwards-compat

<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>.

<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.

<TabAtkins> Yeah, those are questions for annevk in Freenode#whatwg.

Reagent, make minutes

- DRAFT -

SVG Working Group Teleconference

20 Apr 2016

Attendees

Contents

Introduction chapter

Rendering chapter

Chapter 3

chapter 4 https://svgwg.org/svg2-draft/struct.html

Defining use in terms of Shadow DOM

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output