Minutes, London 2016 editor's meeting day 2

Minutes from day two are at:

And as text:


      [1] http://www.w3.org/

                               - DRAFT -

                    SVG Working Group Teleconference

20 Apr 2016

   See also: [2]IRC log

      [2] http://www.w3.org/2016/04/20-svg-irc


          Amelia, Chaals, LJWatson, Tav, nikos, stakagi


          nikos, chaals, ?


     * [3]Topics
         1. [4]Introduction chapter
         2. [5]Rendering chapter
         3. [6]Chapter 3
         4. [7]chapter 4 https://svgwg.org/svg2-draft/struct.html

         5. [8]Defining use in terms of Shadow DOM
     * [9]Summary of Action Items
     * [10]Summary of Resolutions

   <scribe> Scribe: nikos

   <scribe> Scribenick: nikos

   <chaals> Meeting: SVG

Introduction chapter


     [11] https://svgwg.org/svg2-draft/intro.html



     [12] 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:

     [13] 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

   ’ and

   ’ //

     [14] https://svgwg.org/svg2-draft/interact.html#EventAttributes

     [15] https://svgwg.org/svg2-draft/interact.html#EventAttributes

   <chaals> and s/Because of its

   features like//

     [16] https://svgwg.org/svg2-draft/intro.html#W3CCompatibility,

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

     [17] 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

   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

     [18] 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

   <nikos> Tav: Here's previous discussion about marker:overflow
   remaining hidden -

     [19] 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 -

   ... I mean
   [21]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?

     [20] https://www.w3.org/TR/2000/WD-xmlschema-2-20000407/#ieee754

     [21] http://standards.ieee.org/findstds/standard/754-1985.html

   TB: Everyone will use what their computer implements as single

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

   TB: sure.

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

     [22] 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

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

     [23] 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?


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

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


   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

   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

   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


   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> [24]https://github.com/w3c/svgwg/issues/101

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


   tml Tooltips

     [25] https://www.w3.org/TR/2004/WD-SVG12-20041027/applications.html

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

     [26] 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

     [27] 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:

     [28] https://www.w3.org/TR/2015/WD-shadow-dom-20151215/

   <AmeliaBR> CSS Scoping / Shadow Encapsulation:

     [29] 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


   nual.html testing for multilingual titles]

     [30] http://chaals.github.io/testcases/svg-multi-lang-title-manual.html

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

     [31] 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

   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.

     [32] https://drafts.csswg.org/css-scoping/#shadow-cascading

   <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

   Reagent, make minutes

Summary of Action Items

   [NEW] 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

     [33] http://www.w3.org/2016/04/20-svg-minutes.html#action01

Summary of Resolutions

    1. [34]If you want something taht's not SVG to render, put it
       in foreignObject. Otherwise it doesn't - like the spec says
    2. [35]stop telling people where they should or shouldn't put

   [End of minutes]

The information contained in this email message and any attachments may be confidential and may also be the subject to legal professional privilege. If you are not the intended recipient, any use, interference with, disclosure or copying of this material is unauthorised and prohibited. If you have received this email in error, please immediately advise the sender by return email and delete the information from your system.

Received on Thursday, 28 April 2016 01:08:34 UTC