Sydney 2016 F2F
05 Feb 2016

  See also: [2]IRC log

     [2] http://www.w3.org/2016/02/05-svg-irc

Attendees

  Present
  Regrets
  Chair
         Nikos

  Scribe
         heycam, birtles, nikos

Contents

    * [3]Topics
        1. Resolving on Presentation Attribute Strategy
        2. Status Update
        3. [4]SVG Integration spec
        4. [5]coordinate precision in generated content
        5. [6]SVG stroke/corner demo
        6. [7]Future F2Fs
        7. [8]SVG feature interest from implementors
        8. [9]SVGZoomEvent
        9. [10]Exclusion shapes for text
    * [11]Summary of Action Items
    * [12]Summary of Resolutions
    __________________________________________________________

Resolving on presentation attribute strategy

heycam: some f2f ago, I took an action to present options about what to do about presentation attributes
... I'd like to discuss if we need to change our approach
... I added a big table to the styling chapter

<heycam> https://svgwg.org/svg2-draft/styling.html#PresentationAttributes

heycam: about which properties have presentation attributes and on which elements they're supported
... it's basically the set of SVG 1.1 properties plus about 3 new ones
... paint-order, vertical-align, whitespace
... they're the new ones I think
... plus the other ones we've promoted to properties
... it's a pretty ad-hoc set of properties
... but I don't want to require that every property that implementations support have a corresponding presentation attributes
... since many of those properties won't have any effect
... so I wonder if we can say that all properties that have some sort of effect in SVG have presentation attributes
... is that a good idea?
... and if it is, how would we state that

shane: what do you mean about "have some sort of effect"?

heycam: yeah, that makes it difficult to define the set
... an example might be something like text properties
... that are orthogonal to anything we define in SVG but still have an effect
... so people don't have to think that font-style is a presentation attributes but font-variants-ligatures is not...
... we don't need to say anything about font-variants... in SVG, it should just work

Tav: I think that idea is actually pretty good
... from our perspective, anything that is a property is automatically a presentation attributes
... we support anything that changes the rendering as a presentation attribute

AmeliaBR: the main concern I have is making if forwards-compatible
... we could say that anything that could apply to an SVG element could be specified as a presentation attribute
... then if it doesn't have an effect it doesn't have an effect
... but the complication there is name conflicts
... we could never add an SVG attribute that might overlap with any existing or future CSS property

shane: is the situation with presentation attributes, the value of the pres attribute is fed through the CSS cascade
... could we just add an automatic pathway for every attribute SVG defined and feed it into the cascade

(some confusion)

correction: every attribute that is *not* defined by SVG as an attribute would be fed into the cascade

<Zakim> shepazu, you wanted to ask about xlink:href and to

shepazu: I think this is pragmatic, but there is the complication that it pollutes the infoset
... we'd have to find some way of framing this so that we're not defining them but they're part of the schema

heycam: we have some prose that covers whether the document is valid or not

AmeliaBR: regarding whether only properties that have an effect are allowed or all properties are allowed
... that could be an implementation detail
... what about inheritance and foreignObject
... if you set some sort of CSS layout property on an SVG element as a presentation attribute
... then you have a descendent foreignObject the cascade has to work in a predictable way
... I understand you might want to expose some properties as presentation attributes
... projecting all of CSS into SVG will create a very difficult maintenance problem
... for variations of...
... discoverability and detectability will be a problem in the case where you have, e.g. @supports
... you don't have that discoverability on the SVG layer
... saying that we will future-proof SVG by saying that all properties from now on, if applicable, will affect SVG
... but in general it applies to all elements
... and this works for HTML because it doesn't have these attributes
... so we have a fairly clean separation of the two module
... here the line is not so clear
... the bijection of these two sets is not clean
... you have properties in CSS that don't apply to SVG, and attribute in SVG that don't apply to CSS

heycam: underlying what you were saying, is "presentation attributes aren't a great tool, and you can't @supports etc."
... if people agree on that then we should be encouraging people to always use style attributes and style stylesheets

Rossen: precisely
... if you are going to take a dependency on CSS then take a dependency on CSS
... in that case I would argue we are going to reduce the set of attributes as much as possible
... anything magical is a path to disaster

shepazu: I find Rossen's argument persuasive
... I don't agree with the part about reducing the number of attributes
... looking at this from a different lens
... if there are people who are used to using attributes, is this a best practice
... I think it makes things a bit simpler if don't add presentation attributes

shane: I think Rossen is right that we should be doubling down on using CSS for SVG
... not because it's more technically right etc.

Rossen: we have quite a bit of history here that we can look back on
... we didn't try to bind the type systems together
... if this is a module where we want to take a dependency, then we should take the dependency

<heycam> birtles: one question is are you then suggesting that authors type <rect style="width: 100px; height: 100px">

<heycam> ... I think the cat's out of the bag

<heycam> ... we have attributes already for things like width

<heycam> ... we decided to make them into properties

<heycam> ... and now it sounds like people should only use properties. I'm just speaking from the perspective of an SVG author

<heycam> ... if you're telling me now I need to put everything in a style="" attribute, that's not fun

<heycam> Rossen: we did that with HTML, it worked out well

<heycam> ... as soon you step into HTML, you don't have attributes

<heycam> ... if you want to integrate closer to HTML/CSS, let's do it

<heycam> ... if you want to keep away, then we have to keep away and continue down the path of attributes

<heycam> shane: it's also not true that geometry is not fundamental to CSS

<heycam> Tav: but it's styling

<heycam> shane: people say that, but you need it to get something onto the screen

<heycam> ... I think we have to get over presentation/content separation

<heycam> birtles: maybe we don't need to go into the philosophy of HTML and SVG too much

<heycam> ... I'm just saying there will be some difficulty in selling this to authors I think

<heycam> ... just from an author's point of view, it looks like a backwards step in terms of ergonomics

<heycam> shepazu: I don't think we need to make the decision now, abotu whether we're going to deprecate all of the attributes

<heycam> Rossen: i'm not asking for that

<heycam> Rossen: that reasonates with me really well

<heycam> shepazu: href for example

<heycam> ... second, I want to respond to something that Cameron said

<heycam> ... I don't think it's the most common practice these days to make things as attributes

<heycam> ... I think with scripting libraries they increasingly rely on CSS, so I don't think this will be confusing to them

<scribe> scribenick: birtles

AmeliaBR: I agree we shouldn't deprecate the presentation attributes in the near future
... regarding the original issue when it comes to formatting text and fonts we have limited subset
... can we clarify in that chapter: "here's the list of properties that can be used a presentation attributes"
... and within that context of styling text to say that using CSS is preferable
... and to say that there are other properties that can't be used as presentation attributes

heycam: I think that would make sense since there tend to be a lot of text properties that get added
... there is a set of presentation attributes in the style chapter already
... so that table of presentation attributes which has the existing presentation attributes plus the 3 new ones
... should we talk about those 3 new ones
... should we rip them out?

Rossen: yes

heycam: ok I'll see if I can unship them

Rossen: I'll help you out with authoring this chapter
Status update

<nikos> https://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Chapter_Assessment

nikos: 6 chapters still marked as "in progress"
... first is document structure

ed: no update, I haven't had time to update it
... it's fairly ready to go, just minor changes
... readiness 4

(no issues to discuss, just editorial)

Rossen: next is styling

heycam: I haven't updated the wiki, but now that we've discussed the presentation attribute, it's readiness 5
... just a few more tweaks

nikos: next is coordinate system, lots of changes here
... changes might not be finished by the end of the weekend but we know what we need to do
... should be done by the end of next week

Tav: for text, probably needs about a month to make the changes

Rossen: we can help

AmeliaBR: there are some issues with underspecified behavior of textPath
... I will try to coordinate as closely as possible

heycam: the main thing that Tav was waiting was the text-layout algorithm
... I wrote up most of that in a wiki page which hopefully Tav can translate into spec text

nikos: can that work be split up?

Tav: not really

heycam: that algorithm bit is pretty independent from the rest of the chapter
... so once my notes are ready someone else could do that

AmeliaBR: the only problem is trying to avoid having separate parallel definitions

Rossen: is that the main blocker for that chapter

Tav: I was also blocked by some of the issues we discussed at the FXTF two days ago
... but now I know I can rip some of the sections out

Rossen: I was just wondering how we can help

Tav: it's possible someone else could do the algorithm
... the rest I probably need to do and it takes time since I need to check stuff against the SVG 1.1 spec

AmeliaBR: I'll take a look at textPath

(Rossen and Tav will discuss the exclusions section)

heycam: the paint chapter is readiness 5 as of this morning

(applause)

Tav: I need to address the fallback for the arcs linejoin, however
... I need to find out what the preferred fallback is

AmeliaBR: re the paint chapter, what's the plan of integrating this with the proposal of fantasai
... where specifying the shorthand which will, in future, we subdivided into longhands

heycam: we can ignore that for now

BogdanBrinza: interactivity chapter: there a lot of changes we can do now

shepazu: whatever we do with focus, we should make sure we run it by the SVG accessibility community

AmeliaBR: there are issues with respect to what counts as a rendered element

shepazu: I think it would be a useful exercise to see... which things get put into the accessibility tree is different to HTML

BogdanBrinza: I think this should not be defined in this chapter but in the accessibility mapping
... the focus is there but I expect it should be the same as HTML

AmeliaBR: there are issues such as putting a tabindex on a gradient element and that shouldn't have any effect
... so, as shepazu said, we should go through the HTML chapter and look for exceptions
... it should be basically HTML plus exceptions

shepazu: I suggest we have a dedicated telcon for this

BogdanBrinza: fair but I don't think it belongs in this chapter

heycam: in the interactivity chapter, what needs to be talked about is how the tabindex attribute is defined to work
... from my looking at it, it should work in the same way as the HTML definition
... shepazu's question about what should be focussable is a good question
... I'm not sure where that's defined
... but regarding just tabindex, it seems to me the HTML definition is sufficient

Rossen: is there anything that talks about the embedded case?
... is tabindex re-ordered?
... I have an <svg> with tabindex 5 and inside there, there is further tabindex

heycam: for inline <svg>?
... if so, I would expect it to use the same ordering as the rest of the document
... it's the same single document

shepazu: I'm not just talking about people who use AT, but also anyone who uses a keyboard
... I agree with heycam's suggestion that tabindex that follows the HTML definition
... I don't know about building components
... SVG has a lot of nesting
... you have a dashboard, if it has the focus, you may or may not want to drill down into it
... how does HTML handle that?

Rossen: you talking about app layer constraints which doesn't belong in the platform
... platform is about exposing enough constructs that you can realise those things in the app layer
... authors who are accessibility-responsible can annotate their content so that it navigable
... SVG data visualizations are heavily nested, you're asking how you can support focusability and navigability

shepazu: not just SVG but HTML too
... doing it with javascript doesn't seem acceptable

Rossen: that's how people do it

shepazu: not every data visualization should need to be scripted in order to be navigable

Rossen: it doesn't need to be scripted but it need to be annotated with ARIA roles etc.

shepazu: I think we're talking past each other and should take this offline
... aria assumes people are using AT and I'm concerned about people who aren't using AT
... but that's not going into SVG2 and not what we're discussing today
... we're talking about the specific case of tabindex
... and can we simply tear that section out and refer to HTML?
... I think we need to do a careful review of the section we're referring to and check it makes sense in the context of SVG
... and check if we need to add any exceptions to the text we're referring

heycam: we can do that during editing time this afternoon
... I've done a quick check but we can check again this afternoon

shepazu: just concerned that many of the accessibility experts (like Rich Schwerdtfeger) are not here

Rossen: I agree and we care about accessibility and are not taking it lightly

shepazu: we need to make sure Rich is looped-in

<AmeliaBR> Here's the thread I started with the SVG Accessibility Task Force regarding this section: https://lists.w3.org/Archives/Public/public-svg-a11y/2016Jan/0021.html

<scribe> ACTION: BogdanBrinza to do thorough check on focus and tabIndex in HTML and circle back with ARIA group on the results [recorded in http://www.w3.org/2016/02/04-svg-irc]

heycam: we haven't talked about appendices
... they were deferred while we were waiting for other changes
... since those changes are mostly done we can probably update them now
... that's on me


SVG Integration spec

  nikos: Bogdan will be an editor of this spec

  BogdanBrinza: there are a few issues that might be worth
  discussing and knocking out
  ... might be more of an FYI

  <BogdanBrinza> [13]https://svgwg.org/specs/integration/

    [13] https://svgwg.org/specs/integration/

  <BogdanBrinza> [14]https://svgwg.org/specs/integration/#issue1

    [14] https://svgwg.org/specs/integration/#issue1

  BogdanBrinza: first issue is all the different scenarios of SVG
  integration
  ... foreignObject, CSS context
  ... the thing that is mostly concerned for CSS/SVG
  implementaors is sizing SVG documents in CSS, sizing HTML
  content in foreignObject
  ... can you give me a sense of the relative priority of other
  things?
  ... metadata?

  heycam: not important, focus on the sizing

  BogdanBrinza: so with initial containing block with
  foreignObject viewport, I don't think this is an issue
  ... for CSS sizing I have half of the change in progress, still
  working on that
  ... don't think anything else in issue 1 needs talking now

  <BogdanBrinza> [15]https://svgwg.org/specs/integration/#issue2

    [15] https://svgwg.org/specs/integration/#issue2

  BogdanBrinza: issue 2, this talks about referencing the Fetch
  algorithm

  heycam: this is about CORS etc.

  BogdanBrinza: not sure how this applies to referencing modes
  though

  heycam: sounds like it might be better to reference the Fetch
  spec from different places in the SVG spec then, e.g. in the
  <image> definition etc.

  ed: agreed

  AmeliaBR: maybe we'd want to use Anonymous mode for resource
  documents for example

  BogdanBrinza: sounds likes an extension of the referencing mode
  rather than something about the Fetch algorithm

  AmeliaBR: I don't think we have any referencing modes where
  Anonymous mode is explicitly mentioned

  <BogdanBrinza> [16]https://svgwg.org/specs/integration/#issue3

    [16] https://svgwg.org/specs/integration/#issue3

  BogdanBrinza: issue #3 now

  AmeliaBR: animations in resource documents

  BogdanBrinza: just looking at the issue and the context around
  the issue, I don't think anything int he current wording
  suggests they shouldn't run

  AmeliaBR: an example is using content from another file, and
  that file has declarative animations, then should your reused
  copy of that reflect those animations

  BogdanBrinza: why not?

  AmeliaBR: I don't see an issue

  BogdanBrinza: so you define the resource, as part of the
  definition there are some animations
  ... saying there shouldn't be any animations running doesn't
  make sense to me

  AmeliaBR: one issue that has come up before which we have
  waffle language in SVG 2 about is that resource documents don't
  have a medium, so has problems with media queries, resolving
  percentages

  Rossen: 300x150!

  heycam: yes, why not

  BogdanBrinza: so if the resource references percentages how do
  they get resolved

  ed: right

  BogdanBrinza: similar to background-image?

  AmeliaBR: this is SVG resources

  ed: say you referenced an external gradient file
  ... fill: url(externalfile.svg#gradient)

  Rossen: how is this different frmo use?

  ed: it's not, but it's not defined well there

  AmeliaBR: percentages come up in use elements. in same document
  use elements, percentages are resolved on the original document
  not the referncing element

  Rossen: not for us

  AmeliaBR: right now if you have an SVG file with nested
  viewBoxes, and you want to reuse content into the local
  viewBox, it doesn't adjust to the local definition of what 100%
  is

  Rossen: is this based on implemnetations or spec?

  AmeliaBR: I'm pretty sure it's in the spec, not necessarily
  intentionally
  ... but it is consistent everywhere we tested it
  ... the other thing is that most implementations don't run CSS
  in resource documents, so if you have a <style> they don't have
  any effect on the reused content
  ... again that's not specced, just what implementations do

  ed: do you see it as an external document or as nodes being
  cloned?

  Rossen: use is basically copy-on-write
  ... you have a hosting context
  ... if your <g> element everything inside depends on where it's
  being hosted, with percentages, if you need to
  recreate/restyle/recalc the subtree that's in the g element,
  then you only do it in those contexts
  ... for external referenced documents I wouldn't expect
  different behaviour
  ... at the very least in terms of sizing and percentages
  ... it's a separate discussion about animations/transitions
  running
  ... so in CSS we have two separate cases where people may or
  may not expect aniamtions to run
  ... there is the case of something that is not visible on the
  screen and do run, and there is the case where it's not on the
  screen that they don't run
  ... that's the difference between display:none subtree, with
  animations suppressed, and visibility:hidden, in which
  animations do run
  ... so to compare the question we have at hand here, we should
  ask whether we're considering external documents as
  display:none case or similar to visibility:hidden case

  heycam: for me I don't think about it as a display:none
  document

  Rossen: in general we try to load and run as few things as
  possible, for perf and power
  ... running animations would be wasteful
  ... I don't want to make this problem worse
  ... so if we can help it, I'd be in support of not running
  animations

  BogdanBrinza: then the style example maps nicely to that. if
  you have <style> in your referenced resources you don't want
  them to affect the outer document
  ... the more I think about it the more I think it makes sense
  to think about them as display:none

  <AmeliaBR> Worth looking at our current text in SVG 2:
  [17]https://svgwg.org/svg2-draft/struct.html#UseElement
  Starting "The element referenced by ‘use’ may be in a separate
  document."

    [17] https://svgwg.org/svg2-draft/struct.html#UseElement

  AmeliaBR: a good compromise would be resolving styles in that
  resource document, they only apply to that document, but that
  document does not have an animation timeline
  ... and the other issue was if you're resolving styles you need
  to resolve media queries
  ... the logical approach is set a default size, or to say use
  the media dimensions of the referencing element

  Rossen: that would apply you'd need to resolve properties twice
  ... once in the lwoer document and once in the host document
  ... and that would be bad
  ... you could go a step further and say resolving styles
  shouldn't happen, but that would prevent sharing too

  shepazu: I'm sympathetic to what Rossen said
  ... I think it seems most consistent/performant
  ... I think we should make clear what things are referenceable,
  what are not
  ... if animations can'tb e expected to be run, authors should
  understand why that is

  heycam: I'd love to see tests but happy to go with not running
  animations for now

  AmeliaBR: for styles and CSS animations afaik nobody resolves
  styles except inline styles on external use

  BogdanBrinza: the way to spec is that things that are context
  dependent, we just don't have the context for the referenced
  document
  ... when did the timeline start?

  <BogdanBrinza> [18]https://svgwg.org/specs/integration/#issue4

    [18] https://svgwg.org/specs/integration/#issue4

  BogdanBrinza: next one, issue 4

  RESOLUTION: Animations do not run in resource documents.

  BogdanBrinza: should CSS Variables that map palette colours be
  mapped into the document here too?
  ... issue suggests removing this issue, so let's do that

  <BogdanBrinza> [19]https://svgwg.org/specs/integration/#issue5

    [19] https://svgwg.org/specs/integration/#issue5

  BogdanBrinza: issue 5, this one I've made the changes to this
  section
  ... the changes I made are something Cameron mentioned earlier,
  CORS applying
  ... the current state of things is that as far as I tried,
  Chrome does apply CORS, Edge has same domain restriction,
  Firefox allows any reference

  heycam: I'd be happy for that to be tightened up

  BogdanBrinza: this would be a good test case

  <Zakim> AmeliaBR, you wanted to add a new issue re the "font
  document" section

  AmeliaBR: it's not currently marked as an issue but there's a
  lot of stuff in that font document section that uses these
  context-* values, which we're no logner defining in SVG 2

  heycam: context-fill,stroke are in the SVG 2 spec,
  context-value might not be though
  ... I'll figure out where those other things should be defined,
  since the OpenType spec is referencing this for the UA style
  sheet

  BogdanBrinza: so that's a requirement and it sounds like the
  course of action is to ask the OT people to update this?

  heycam: I'll write up some text for this

  BogdanBrinza: we have this issue about protecting infinite
  reference cycles
  ... Chrome/Edge/Safari limit to one level
  ... Firefox has no limit

  heycam: happy to align on the same number of levels

  BogdanBrinza: I think ti's the interoperable behaviour we'd
  want anyway
  ... the other part is the URL standard reference, it's just
  editorial

  <BogdanBrinza> [20]https://svgwg.org/specs/integration/#issue6

    [20] https://svgwg.org/specs/integration/#issue6

  BogdanBrinza: issue 6 is about "Animated mode", should we
  remove this

  <AmeliaBR> This is the section of SVG 2 that currently defines
  which resources may be in external elements:
  [21]https://svgwg.org/svg2-draft/linking.html#processingURL

    [21] https://svgwg.org/svg2-draft/linking.html#processingURL

  BogdanBrinza: oh I propose changing "external references" to
  "references to external resources"

  heycam: it's not being referenced by anything, so let's remove
  it

  nikos: does the OT spec still reference "secure animated mode"?

  heycam: maybe

  BogdanBrinza: soudns like there was some attempt to address the
  CORS concerns

  AmeliaBR: to clarify, the "secure" modes are currently used
  ... when you embed SVG as an image, you're using this "secure
  animated mode"
  ... we don't have uses where no scripts, but do support
  external files
  ... so 3.3 Animated mode there aren't any uses of that

  BogdanBrinza: sounds fair

  AmeliaBR: there are static renderers that do support external
  references, so there's a benefit for recognising that his
  extists
  ... don't know if it's needed in this context

  BogdanBrinza: for external resources, you only have a single
  level of depth, and there is no script in those resources
  ... it sounds like we're talking about policies, rather than
  modes
  ... and the modes references policies

  shepazu: that's what it's doing

  BogdanBrinza: there is some slight different

  shepazu: sounds fine to fix that

  AmeliaBR: the purpose of having these modes is that other specs
  can reference these and clearly say that e.g. HTML can SVGs
  will run in "secure animated mode", and this spec defines that
  ... so some other spec for some XML format could reference a
  static mode where the image is static, animations don't run,
  but external fonts and other embeds are allowed
  ... I don't see anything wrong with efining all the different
  combiantoisn and giving them names
  ... so that other specs can clearly reference them and have a
  clear definition

  BogdanBrinza: that is what I propose
  ... they should be defined as single entities, but currently
  modes try to explain more than just the policies, but they
  should be purely about the policies
  ... if needed we can expand with new policies, but still keep
  the same modes

  RESOLUTION: Keep the modes, define them in terms of policies,
  basically as a table mapping modes to specific policies.

  <BogdanBrinza> [22]https://svgwg.org/specs/integration/#issue7

    [22] https://svgwg.org/specs/integration/#issue7

  BogdanBrinza: next, issue 7

  AmeliaBR: that's the same

  <BogdanBrinza> [23]https://svgwg.org/specs/integration/#issue8

    [23] https://svgwg.org/specs/integration/#issue8

  BogdanBrinza: issue 8 and 9 are about HTML in foreignObject
  ... issue 9 is editorial, add examples
  ... issue 8 I'm not sure I understand it. "what should we say
  about when to rasterize the content?"
  ... pixellated form controls?

  AmeliaBR: I think that's an obsolete issue
  ... this was like transforms/filters applied to SVG content
  with forms in foreignObject
  ... but now we have transforms/filters applied to HTML content

  <BogdanBrinza> [24]https://jsfiddle.net/pscu8wLq/

    [24] https://jsfiddle.net/pscu8wLq/

  BogdanBrinza: looks like implementations don't pixellate now
  ... last issue, 10, this is a todo for defining SVG in
  foreignObject

  AmeliaBR: I think I'd like to see here, in general to
  HTML/SVG/MathML, a sentence that says what the effect of
  viewport is on child content, but that's not quite correct
  (it's not a separate document)
  ... but that's where it becomes an issue, what's the parent
  size / coordinate system that that foreignObject creates, and
  just to have a sentence about the content of the foreignObject
  being drawn into a container that has the width/height and
  coordinate system established by the foreignObject

  BogdanBrinza: sounds like this is defined in section 4.1

  AmeliaBR: that's part of it

  BogdanBrinza: so SVG viewports establish the containing block
  for HTML, and vice versa -- using SVG in HTML context, then the
  containing block establishes the viewport

  AmeliaBR: so maybe generalise that rule and not make it
  specific to HTML, for one thing it's anything CSS-styled
  content that could be some other XML language who knows

  BogdanBrinza: yes that's CSS context, not HTML

  AmeliaBR: then if you put an <svg> inside a <foreignObject>
  then we can treat the <svg> has having a CSS box parent

  BogdanBrinza: yes
  ... there's nothing special about <svg> in <foreignObject> that
  we need to specify

  ed: right

  <paradisaeidae> Wow, had never though of such a thing: <svg>
  inside a <foreignObject>

  AmeliaBR: the key thing is that a foreignObject creates a CSS
  box, and any content you put inside it that requires a CSS box
  layout concept of a container/parent would then use that

  BogdanBrinza: I have a feeling we discussed this in Paris for
  some of the other chapters, coords?
  ... we talked about interactions between viewports and
  containing lbocks
  ... I think that's the same as we're discussing right now

  AmeliaBR: are you ok with rewriting this just to make a single
  generic description?

  BogdanBrinza: I'd imagine we have something somewhere in SVG 2?
  ... to point to

  ed: the initial continaing block?

  BogdanBrinza: how ICB maps to viewport and vice versa

  ed: section 4.1

  <nikos> [25]https://jsfiddle.net/dodgeyhack/nnztjw7s/

    [25] https://jsfiddle.net/dodgeyhack/nnztjw7s/

  nikos: just going back, this example is pixellated in firefox

  <AmeliaBR> I think this is the section Bogdan is referring to:
  [26]https://svgwg.org/svg2-draft/coords.html#ViewportSpace

    [26] https://svgwg.org/svg2-draft/coords.html#ViewportSpace

  heycam: don't think it's an issue that needs to be in the spec

coordinate precision in generated content

  stakagi: this was an issue Chris Little brought up
  ... he wanted content for technical drawings, maps. I prepared
  a wiki page
  ... with current implementation status
  ... in this wiki page, in the Conformance chapter of SVG 2 I
  think that there is no requirement to add normative language

  <AmeliaBR> Wiki page:
  [27]https://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Better_CT
  M_Computation#Improving_Significant_Figures_by_Transformation_a
  nd_Tiling

    [27] https://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Better_CTM_Computation#Improving_Significant_Figures_by_Transformation_and_Tiling

  stakagi: but for more convenience for content creators I want
  to add an explanation from this wiki page

  AmeliaBR: it's been an issue we brought up a couple of times
  ... that people are annoyed when they translate data and come
  up agains the single precision flaot numeric precision
  ... and for perf reasons nobody wants to require better than
  single precision floats
  ... so it's a nice compromise to have authoring (tool) guidance
  on how to deal with the limitations of the single precision
  coord system
  ... whether that's a separate authoring guidance spec or an
  appendix I don't mind

  stakagi: one point, I added Conformance Criteria, the viewer
  must use double for CTMs, but the TM itself need only be single

  <stakagi>
  [28]https://svgwg.org/svg2-draft/conform.html#ConformingSVGView
  ers

    [28] https://svgwg.org/svg2-draft/conform.html#ConformingSVGViewers

  heycam: is there an existing appendix where it would make
  sense?

  AmeliaBR: maybe in Conform where we have conformance class for
  authoring tools?

  <scribe> ACTION: stakagi to add non-normative authoring
  guidance about content precision to conform.html [recorded in
  [29]http://www.w3.org/2016/02/05-svg-minutes.html#action01]

    [29] http://www.w3.org/2016/02/05-svg-minutes.html#action01]

  <trackbot> Created ACTION-3836 - Add non-normative authoring
  guidance about content precision to conform.html [on Satoru
  Takagi - due 2016-02-12].

SVG stroke/corner demo

  <ed>
  [30]http://xn--dahlstrm-t4a.net/svg/experimental/svg-dashcorner
  /examples/simplerect.html

    [30] http://xn--dahlstrm-t4a.net/svg/experimental/svg-dashcorner/examples/simplerect.html

  ed: I wanted to experiment with this from the SVG Strokes
  module
  ... I created a simple polyfill using dash arrays to emulate
  corner behaviour
  ... if you look at this link, which should work in any browser,
  you see I've highlighted the corners using this feature
  ... the first polyfill version doesn't handle rounded rect
  corners, which turned out to be a bit more difficult
  ... but the spec has noted this as an issue
  ... where corners should be drawn, all over the arcs?
  ... this does depend on path length computation methods
  ... but it does show a way to do a polyfill that could work
  before browsers implement this
  ... I also went ahead and did a second demo, where you can
  specify several corner lengths

  <ed>
  [31]http://xn--dahlstrm-t4a.net/svg/experimental/svg-dashcorner
  /examples/multidash.html

    [31] http://xn--dahlstrm-t4a.net/svg/experimental/svg-dashcorner/examples/multidash.html

  shepazu: what is the shape with the rectangle with something in
  it?

  ed: that's a polyline
  ... I chose not to draw corners on each side, just highlighting
  the corners not the end points

  shepazu: why wouldn't this work in Edge?

  AmeliaBR: it's an XHR error

  ed: in the second demo I use multiple lengths for the different
  corners
  ... in the middle rect, you can see two corners have longer
  dashing
  ... and looking at the star I used more different lengths
  ... so with multiple corners you repeat similarly to dasharrays

  shepazu: how does stroke-dashcorner array with
  stroke-dasharray?

  Tav: [stole my question!]

  ed: hopefully should be defined in the spec
  ... I didn't mix in the dasharrays that might exist on elements
  in this demo
  ... the way it's meant to work is you spread the dasharray
  between the corners
  ... and adjust the gaps so that it looks nice, with
  stroke-dashadjust

  AmeliaBR: the way we spec it is you dash the corners first,
  then dash each line segment independnetly with these extra
  properties to make it look properly

  shepazu: what it sounds a bit like with this collection of
  features that it's approaching shorrthands/longhands
  ... might be good to think about it like that

  Tav: this deals with corners, what about paths? drawing a map,
  when you want to have intersections with 3 different regions
  look nice

  ed: in this first simple impl, this uses the new path api
  polyfill
  ... it provides you with getting the normalized path seg data
  out from the path
  ... I'm just looking for lineto elements

  heycam: I think something else would be needed to solve the map
  intersection case

  ed: there are a few issues in the Strokes spec I noted down
  ... one is issue 8, which says that the points at which the
  dashcorner are painted include the start/end points of every
  segment
  ... I think we shouldn't do that

  <ed> [32]https://svgwg.org/specs/strokes/#issue8

    [32] https://svgwg.org/specs/strokes/#issue8

  ed: another thing I noticed is that one thing that makes it
  hard to polyfill is that dasharrays start over again for new
  subpaths
  ... it's difficult to get the dasharrays positioned properly
  ... you have to break it apart into several path elements
  ... if the dahsarray starts over, then you can't do anything
  custom for that one

  AmeliaBR: as in your might need a half dash?

  ed: you want a new dasharray per subpath

  AmeliaBR: your polyfill will have to define every single dash
  in the whole path

  ed: I know we decided that's the way it works
  ... I think you can still break up the element if you need to

  heycam: pretty sure dashing works like that everywhere

  AmeliaBR: if the worst we can say is that the polyfill is less
  performant that's ok

Future F2Fs

  nikos: TPAC is in September, Graphical Web is early November
  ... CSSWG is meeting in May 2nd week in US
  ... I feel like we're a bit constrained by Invited Experts who
  might not be able to travel far/often
  ... so we should try to go where they are instead

  shepazu: meeting with CSS is usually productive
  ... I would hope that Amelia could attend in the US?

  AmeliaBR: I can't make promises unless someone finds a grant
  for me

  shepazu: Tav, could you travel in May to the US?

  Tav: might be difficult
  ... I'll have some money, have a designated budget, but it
  would exhaust it

  shepazu: I think it would be useful to have a F2F with CSS but
  I understand the constraints
  ... do we need to schedule a F2F?

  nikos: lots of us can only dedicate time to SVG around F2Fs
  ... it's more a case of where and when
  ... so TPAC and Graphical Web are close together, a month apart
  ... we've been invited to meet at Graphical Web

  Tav: that would be much more practical for two reasons
  ... one, for me, the one time I attended TPAC the day and a
  half we spent wasn't much
  ... a long way to go for 1.5 days
  ... two, I will probably be going to Graphical Web
  ... so it would be a small incremental cost to stay for a WG
  meeting

  nikos: I feel similarly about TPAC
  ... quite short, good but we tend to get more done at other
  dedicated WG meetings

  shepazu: I think the point of TPAC is to coordinate with other
  WGs
  ... and if we don't find we need to coorindate with groups
  other than CSS...

  Rossen: I agree that meeting with CSS is awesome, whenever we
  have the opportunity to do it
  ... the one other thing I wanted to put on the table, would we
  having any specific goals in May or whenever?
  ... one of the specific goals we had as a WG from Linkoping,
  was to come here and be ready to have CR
  ... we are underdelivering on that goal
  ... one thing reasonated with me is that nobody is putting
  efforts outside of F2Fs, so if F2Fs are a forcing function for
  spec writing, then I would be in favour of meeting
  ... as long as we can find a place and time
  ... but I'm trying to explore options where we can still make
  progress without needing to meet F2F

  shepazu: I think Rossen raises a great point
  ... I think we should set a goal for May, if we thought that
  we're close enough to get something done by May it might
  indicate some dedicated speccing days-- we've tried to do that
  in the past, it's only worked sometimes
  ... having weekly goals towards May
  ... since that's not far away
  ... regarding Graphical Web vs TPAC, I'm really busy at TPAC
  ... as much as I would like to have SVG at TPAC, pragmatically
  it's not practical for me to do all my WG stuff at TPAC

  nikos: a crazy idea might be to meet sooner than May

  AmeliaBR: there is the April Libre Graphics conference
  ... there's a chance I'll be there but can't promise
  ... that's London early April
  ... 15-18 April

  Tav: I will most likely be there
  ... Inkscape will have a hackfest before that

  <shepazu> [33]http://libregraphicsmeeting.org/2016/

    [33] http://libregraphicsmeeting.org/2016/

  Rossen: if we're organising around community engagement
  opportunities, it would be cool we could brag about shipping
  SVG 2
  ... the other thing, attracting implementor interest
  ... if and when we're done with this CR stage, it would be
  great to start talking about where we go next
  ... and how do we rev all the impls
  ... I've stated this before, as an implementor I am waiting for
  this to be stable and rubber stamped before I put resources
  onto this

  Tav: that confuses me a little, as you're talking about
  modularization with CSS

  Rossen: and I'm waiting for this module to be done
  ... I think I made some attempts to modularize other things out
  of it
  ... and yes I want to see what will happen with the next
  modules

  Tav: you would consider implementing some of the stable parts?

  Rossen: if it's in a stable SVG 2? yes
  ... I cannot commit on implementations/releases of products,
  what I can say is: if/when the spec is stable, we'll have a lot
  better chance of attracting implementation
  ... much easier to implement, particuarly if it's a gap,
  against a stable spec that's not going to keep going back/forth
  ... so, when are we going to ship?
  ... if F2F is a forcing function, I would be in favour of
  having it whenever/whereever
  ... but there needs to be more -- to justify the expense -- we
  need more data to say that's actually going to happen
  ... or if we're pretty much there and just need to nail down a
  few things
  ... which was our assumption coming here

  nikos: part of the issue with this F2F is that's early in the
  year and with Christmas/breaks people weren't spending time on
  it

  AmeliaBR: so the question is, if another F2F is set up in
  April/May, can people commit to working for the next few months
  to get a publication ready spec

  nikos: so Text and Cooridnates need to get fixed

  Tav: I would hope to get Text done in a month

  nikos: so is it worth having a F2F at Libre Graphics?

  AmeliaBR: if you organise it I will come

  nikos: for me I could get there if it's after Libre Graphics

  ed: it would be easier for me, being there

  Rossen: my vote would certainly be May since I'll be at
  CSS/Houdini
  ... could I come in April? don't know

  BogdanBrinza: it would be challening for me to attend in April

  nikos: one advantage to getting a few people together, we could
  VC with other people if any issues come up for discussion
  ... for May...

  shane: 9-11 CSS, 12-13 Houdini
  ... need to let us know as soon as possible if SVG wants to
  meet there

  Rossen: if the goal of meeting is to write specs, perhaps you
  should go with April, the people most involved in spec work can
  summit
  ... that's good for Erik, Tav, Amelia can maybe attend too
  ... other option is: if we're meeting as a WG, if we need to
  work on open issues, then you want a bigger quorum. seems like
  May in US is a better option for that.

  shepazu: a hybrid option is to have an editor's meeting at
  Libre Graphics and then have a F2F in May with CSS

  AmeliaBR: so April will be clean everything up so in May we
  have a document we agree with shipping?

  nikos: I could come to both, if that's what needs to be done
  ... I think if we got together in London, it would be pretty
  productive
  ... if people could commit to telcons until then for talking
  about issues, we'll have a lot of stuff ticked off to get
  finished at that spec meeting

  <birtles> scribenick: birtles

  Rossen: SF will be busy at that time

  nikos: we'll go with April and discuss May after the break

  <lunch break 1h>

  <nikos> AmeliaBR: we're mostly back

  <heycam> ScribeNick: heycam

  nikos: I think if we have a meeting in April, and Tav, myself,
  Amelia and maybe Erik get together, that would be a productive
  meeting
  ... in terms of reviewing and finishing off the spec text
  ... not for talking about issues
  ... if we meet in May it's in the US, where we're likely to
  have Rossen, myself, Shane, Bogdan maybe
  ... if we get the spec done at the April meeting, issues will
  start getting raised as we make our way through the test suite
  ... if we met in May even without the April meeting, what would
  be on the agenda for May?
  ... so meeting later than May, to discuss issues that arose
  from test writing sounds better
  ... so let's have the small meet in April to get the spec
  finished, then plan a meet mid-year once we've had some time to
  work on tests and collecting issues from that
  ... so something like July, don't know where though

  RESOLUTION: Spec editors will meet in April adjacent to Libre
  Graphics, no meeting in May, organising SVG meeting July or so
  later.

SVG feature interest from implementors

  shane: as an implementor, best bet for getting new SVG features
  in browsers is to make them relevant
  ... so they need to integrate well with HTML
  ... I don't have any specific advice, but the extent to which
  SVG interopates well with HTML will affect how likely it is
  these are implemented

  AmeliaBR: some of these features are make SVG behave more like
  HTML

  Tav: there are a variety of things that already work in HTML,
  and we just need to make sure they work in SVG
  ... like text-orientation, the font features, so we just have
  to make sure when they're implemented for HTML they work in SVG
  too
  ... the filter shorthands for example work in HTML in Chrome
  but not in SVG

  ed: that's right

  Tav: so that should be low hanging fruit to pick up

  shane: that might be low hanging fruit, but there has to be
  demand
  ... if you want to think like an implementor, they're going to
  be looking at what the general webdev public demands
  ... if there's no demand from authors then it won't be
  prioritised

  Tav: it's a chicken and egg problem
  ... what I'm going to do, is I'll start enabling some things in
  Inkscape output

  nikos: we could start tracking what features are actually
  implemented
  ... so we can get a handle on what is starting to be
  implemented

  Rossen: also, as an implementor, I want something that is
  stable
  ... if it's not stable I'm not going to look atit
  ... when I talk to my management, they don't want to know about
  SVG until there's something which you can print and you don't
  have reprint many times
  ... it's the door-opener
  ... I have spoken to some other implementations that have large
  adoption, and they have similar feedback

  shepazu: so you're saying stabilise, then we'll pay attention

  Rossen: yes, that's what I've been saying for 15 months

  shepazu: because SVG is a large spec, is stabilising chapters a
  reasonable thing? or it has to be the whole thing?

  Rossen: can we break these chapters into their own modules and
  say this thing is CR?

  AmeliaBR: at this point that would slow things down

  Rossen: it seems like the spec is going in the right direction
  though
  ... here's a simple kind of conversation that will happen in a
  company like ours
  ... you look at the history you see a spec that has been in
  development for the last 12 years, in order to have faith in
  this work you need to see the rubber stamp
  ... as an implementor I want to go and do that work, but can't,
  because I'm resource bound
  ... when someone looks at a spec that has been going on for
  that long, how do they know it's not going to keep going for
  another 13 years?
  ... that the message this WG must be able to send, to say it's
  done
  ... to say it's stable and ready for implementation
  ... it's just this really long timeline that is holding us back
  ... we did the same thing with CSS, at least in IE
  ... until 2.1 was stable there wasn't a good reason to go and
  implement it

  alex: from Chrome's PoV, my experience in SVG and standards I
  agree with Rossen
  ... with the 1.2T timeframe, JSR226, there are other standards
  bodies that want a stable spec before looking at it
  ... from Chrome's impl PoV it's irrelevant, but from a
  standards PoV yes

  birtles: I think what I'd be interested in is if SVG 2 feels
  like a lot, if there were some sort of subsets of low hanging
  fruit or things other implementors agreed or community votes,
  smaller packages of work available, that might be an easier
  sell

  Rossen: but this is what CR is for

  birtles: not talking about the process
  ... we hate html5tests, it just counts the number of APIs you
  implement, but if you have things like that it's a package of
  work to say it's a goal to get this to pass
  ... saying the goal is "SVG 2" is a big sell

  alex: I think the point of W3C process, CR is the thing to get
  things out the door

  birtles: nothing to do with standardisation, I'm saying if
  someone else as an independent effort to say we think these 3
  features are the most important ones out of SVG 2, we're going
  to make up a matrix...

  Rossen: sure, but at this point how do you know these will be
  the same features by the time the spec is in CR?
  ... there's a Rec process for a reason
  ... so going out there and saying that you know these features
  are going to be the way they are...
  ... there is a formalised standardisation process which serves
  at least one thing that's good, which is "this is a stable
  spec"

  birtles: I'm just saying, as an implementor something that
  would be helpful is, after CR, to narrow the scope of what we
  do first

  Rossen: prioritisation?

  birtles: yes
  ... trying to say "lets do all of SVG 2" is an overwhelmingly
  big task
  ... if someone wants to prioitise and agree on how to
  prioritise that's an easier sell

  Rossen: then you get into 80/20 problem

  <Zakim> AmeliaBR, you wanted to recast discussion: which parts
  of the spec are stable enough to start building tests?

  AmeliaBR: these all sound like good points, and I think Rossen
  has clearly argued that it's no use asking for impls until we
  get the rubber stamp
  ... but for our own purposes, we can still start breaking
  things down into individual components as Brian was saying,
  certain things are going to be different priority for users
  ... and the other thing is testing
  ... even if some of us are still rewriting the Text chapter, if
  another chapter is stable and people have time to write tests
  they can move ahead with that
  ... and so that from that perspective it's still useful to have
  a matrix of our own to keep track of which new features have
  been introduced and we're confident it's not going to change

  nikos: the other topic is marking features at risk for CR
  ... i don't really know the process for that sort of thing

  alex: I think you just get implementor feedback about what
  things are likely to be implemented

  shepazu: we mark features at risk if we feel they're not going
  to be implemented
  ... with the new process, going back to CR which used to be
  more painful, is streamlined
  ... so Process2015 streamlines with how you iterate on a spec
  ... It hink we should be resonbile without we try to portray
  issues
  ... it's not as useful to identify these at risk features
  before CR now with the new process

  BogdanBrinza: I might repeat Rossen's view in a pragmatic way
  ... there have been features implemented in other browsers,
  Inkscape; we'll gladly implement things we feel we need to
  implement
  ... features that are being used out there
  ... support in other browsers is great, and it shows the
  pipeline
  ... we're #3 or #4 browser now, so we're under no pressure to
  implement
  ... we will show our interest and implement things we have to

  nikos: at the April editor's meeting we can enumerate all the
  SVG 2 feature, as a basis for tracking implementation, what
  needs tests, and as a communication tool with implementors
  ... for now let's just get the text in coords/text chapters
  finished

SVGZoomEvent

  <nikos> [34]https://github.com/w3c/svgwg/issues/21

    [34] https://github.com/w3c/svgwg/issues/21

  nikos: the question was raised by chromium folks, about whether
  SVGZoomEvent is needed
  ... whether anyone uses it
  ... it wasn't clear to them from reading the spec how it should
  work
  ... when currentScale changes the event should be fired, I
  think
  ... there was some history with Opera Presto which had a
  control to scale SVG content within the page

  ed: apparently SVGZoomEvent doesn't work in Chrome
  ... so I think they're looking to see whether they can drop it
  ... not sure if people are trying to dependent on this

  BogdanBrinza: are there use counters?

  nikos: no mention of them

  <paradisaeidae> Please don't drop SVGZoomEvent

  AmeliaBR: I suspect it's very poorly used just because there no
  active implementations right now have user controlled pan and
  zoom options
  ... so I'm not sure whether anybody fires this event for pinch
  zoom etc.
  ... so it's certainly an edge case

  <paradisaeidae> Use counters are not
  potentialUseContersWhenUseIsUnderstoodCounters

  Rossen: was the zoom event raised on user zoom or pinch zoom?

  AmeliaBR: SVG used to have zoomAndPan, which users coul use to
  zoom in/out

  <paradisaeidae> This is an area I did not have time to put to
  the panel last night.

  AmeliaBR: and then authors could listen to this event to
  respond to these zooms

  Rossen: you say there's interactivity where the user is
  interacting with SVG content, based on which other SVG
  content...

  AmeliaBR: the idea was the browser would show zoom UI
  ... but nobody does that
  ... (since Opera Presto was dropped)

  Rossen: today we're hiding the interaction between pinch
  zooming and viewport more and more

  <paradisaeidae> SVGZoomEvent can signal the level of detail to
  be rendered.

  Rossen: so that you can implement efficient zooming in the GPU

  shepazu: there's a difference between optical zoom and
  functional zoom. we're not talking about making the thing
  bigger, talking about drilling down into more details

  Rossen: these things work well today in response to touch
  events, etc.
  ... zooming is a user instantiated action which is controlled
  on the app layer most of the time
  ... in that case, you know how your application should behave
  ... there's no reason to have another event to say the user did
  a pinch gesture
  ... this is your app, you know what that gesture means
  ... without needing another event which means your zooming
  ... what Amelia said makes sense, if the browser was allowing
  zoom in a script-undetectable way, then it makes sense

  <paradisaeidae> is pinch the only way zooming can be signalled?

  shepazu: there's any number of ways users can initiate these
  things
  ... however they did it, it's like an INDIE UI thing
  ... letting the page know that the user zoomed, the page reacts

  Rossen: if this is the case, why doesn't HTML have the same
  thing?

  <stakagi>
  [35]https://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Investiga
  tion_of_APIs_for_Level_of_detail#Events_for_start.2C_end_and_du
  ring_transition_of_zooming_and_panning.

    [35] https://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Investigation_of_APIs_for_Level_of_detail#Events_for_start.2C_end_and_during_transition_of_zooming_and_panning.

  shepazu: the kinds of apps you build with HTML are different

  Rossen: we have a semantic zoom to say you can double tap to
  different menus, categories, different levels of HTML layers
  ... nothing to do with CSS
  ... so I'm questioning the need for the necessity for this
  event

  alex: should put a use counter on it

  <stakagi> Regardless of SVG, the event about zoom on web
  browsers is made confused.

  nikos: according to the bug it's not implemented but it can be
  feature detected

  AmeliaBR: it was implemented in the Adobe viewer which had
  those controls
  ... I would argue against what some of what Rossen said, I'd
  love to see a semantic zoom event
  ... the user did an input which normally means zoom on their
  system, but I don't see the use of having an SVG specific event

  BogdanBrinza: looking at Chromium source it's declared but not
  used

  nikos: sounds like there might be good use cases for this but
  it's not specced properly

  AmeliaBR: we could for wording tie it into the znp control
  wording

  nikos: sounds like this could be removed and looked at in a
  wholistic way later on

  shepazu: just noting that INDIE UI hasn't been updated in a
  year or so, they seem to have something called zoomrequest but
  dropped in interest of spec speed

  RESOLUTION: Remove SVGZoomEvent from SVG 2.

  <nikos> scribenick: nikos

Exclusion shapes for text

  Tav: The spec right now uses shape-outside
  ... It doesn't really match the CSS concept of shape-outside
  ... which is to specify a region that an object is shrunk by

  Rossen: Here's a scenario: you have a text element. The number
  one thing you want to do is say wrap this text inside a shape
  (e.g. circle)
  ... and here are two or three other shapes, that if they
  intercept with the shape inside, they subtract geometry from
  the shape
  ... a nice term for describing this might be shape-subtract, or
  shape-exclude
  ... shape-subtract further changes the shape specified fro
  shape-inside if there's an intersection

  <ed> BogdanBrinza, heycam: do you both agree with
  [36]https://svgwg.org/svg2-draft/interact.html#issue6
  suggestion not to list events from DOM Events / HTML?

    [36] https://svgwg.org/svg2-draft/interact.html#issue6

  Rossen: shape-outside was confusing and the wrong thing to use
  because of it's ability to change the geometry of the shape
  that is used for the exclusion (as opposed to the shape that is
  rendered)
  ... we can use shape-outside in SVG 2 in the future but we have
  to use it for the exact same purpose as in CSS, and that's not
  the case with the current description of shape-outside

  RESOLUTION: Rename shape-outside to shape-subtract to reflect
  that the way it is specified is different than shape-outside in
  CSS.

Summary of Action Items

  [NEW] ACTION: stakagi to add non-normative authoring guidance
  about content precision to conform.html [recorded in
  [37]http://www.w3.org/2016/02/05-svg-minutes.html#action01]

    [37] http://www.w3.org/2016/02/05-svg-minutes.html#action01

Summary of Resolutions

   1. [38]Animations do not run in resource documents.
   2. [39]Keep the modes, define them in terms of policies,
      basically as a table mapping modes to specific policies.
   3. [40]Spec editors will meet in April adjacent to Libre
      Graphics, no meeting in May, organising SVG meeting July or
      so later.
   4. [41]Remove SVGZoomEvent from SVG 2.
   5. [42]Rename shape-outside to shape-subtract to reflect that
      the way it is specified is different than shape-outside in
      CSS.

  [End of minutes]
    __________________________________________________________


   Minutes formatted by David Booth's [43]scribe.perl version
   1.144 ([44]CVS log)
   $Date: 2016/02/05 04:43:22 $
    __________________________________________________________

    [43] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
    [44] http://dev.w3.org/cvsweb/2002/scribe/

Scribe.perl diagnostic output

  [Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.144  of Date: 2015/11/17 08:39:34
Check for newer version at [45]http://dev.w3.org/cvsweb/~checkout~/2002/
scribe/

    [45] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/... there are/AmeliaBR: there are/
Succeeded: s/people are ignored/people are annoyed/
Succeeded: s/?//
Found ScribeNick: heycam
Found ScribeNick: birtles
Found ScribeNick: heycam
Found ScribeNick: nikos
Inferring Scribes: heycam, birtles, nikos
Scribes: heycam, birtles, nikos
ScribeNicks: heycam, birtles, nikos

WARNING: No "Present: ... " found!
Possibly Present: AmeliaBR BogdanBrinza Rossen Tav alex birtles ed heyca
m https nikos paradisaeidae scribenick shane shepazu stakagi trackbot
You can indicate people for the Present list like this:
       <dbooth> Present: dbooth jonathan mary
       <dbooth> Present+ amy


WARNING: No meeting title found!
You should specify the meeting title like this:
<dbooth> Meeting: Weekly Baking Club Meeting


WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Got date from IRC log name: 05 Feb 2016
Guessing minutes URL: [46]http://www.w3.org/2016/02/05-svg-minutes.html
People with action items: stakagi

    [46] http://www.w3.org/2016/02/05-svg-minutes.html


  [End of [47]scribe.perl diagnostic output]

    [47] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm

G_TITLE

05 Feb 2016

  See also: [2]IRC log

     [2] http://www.w3.org/2016/02/05-svg-irc

Attendees

  Present
  Regrets
  Chair
         SV_MEETING_CHAIR

  Scribe
         heycam, birtles, nikos

Contents

    * [3]Topics
        1. [4]SVG Integration spec
        2. [5]coordinate precision in generated content
        3. [6]SVG stroke/corner demo
        4. [7]Future F2Fs
        5. [8]SVG feature interest from implementors
        6. [9]SVGZoomEvent
        7. [10]Exclusion shapes for text
    * [11]Summary of Action Items
    * [12]Summary of Resolutions
    __________________________________________________________

  <birtles> <break 15min>

  <nikos> AmeliaBR: ping we're back

  <heycam> ScribeNick: heycam

SVG Integration spec

  nikos: Bogdan will be an editor of this spec

  BogdanBrinza: there are a few issues that might be worth
  discussing and knocking out
  ... might be more of an FYI

  <BogdanBrinza> [13]https://svgwg.org/specs/integration/

    [13] https://svgwg.org/specs/integration/

  <BogdanBrinza> [14]https://svgwg.org/specs/integration/#issue1

    [14] https://svgwg.org/specs/integration/#issue1

  BogdanBrinza: first issue is all the different scenarios of SVG
  integration
  ... foreignObject, CSS context
  ... the thing that is mostly concerned for CSS/SVG
  implementaors is sizing SVG documents in CSS, sizing HTML
  content in foreignObject
  ... can you give me a sense of the relative priority of other
  things?
  ... metadata?

  heycam: not important, focus on the sizing

  BogdanBrinza: so with initial containing block with
  foreignObject viewport, I don't think this is an issue
  ... for CSS sizing I have half of the change in progress, still
  working on that
  ... don't think anything else in issue 1 needs talking now

  <BogdanBrinza> [15]https://svgwg.org/specs/integration/#issue2

    [15] https://svgwg.org/specs/integration/#issue2

  BogdanBrinza: issue 2, this talks about referencing the Fetch
  algorithm

  heycam: this is about CORS etc.

  BogdanBrinza: not sure how this applies to referencing modes
  though

  heycam: sounds like it might be better to reference the Fetch
  spec from different places in the SVG spec then, e.g. in the
  <image> definition etc.

  ed: agreed

  AmeliaBR: maybe we'd want to use Anonymous mode for resource
  documents for example

  BogdanBrinza: sounds likes an extension of the referencing mode
  rather than something about the Fetch algorithm

  AmeliaBR: I don't think we have any referencing modes where
  Anonymous mode is explicitly mentioned

  <BogdanBrinza> [16]https://svgwg.org/specs/integration/#issue3

    [16] https://svgwg.org/specs/integration/#issue3

  BogdanBrinza: issue #3 now

  AmeliaBR: animations in resource documents

  BogdanBrinza: just looking at the issue and the context around
  the issue, I don't think anything int he current wording
  suggests they shouldn't run

  AmeliaBR: an example is using content from another file, and
  that file has declarative animations, then should your reused
  copy of that reflect those animations

  BogdanBrinza: why not?

  AmeliaBR: I don't see an issue

  BogdanBrinza: so you define the resource, as part of the
  definition there are some animations
  ... saying there shouldn't be any animations running doesn't
  make sense to me

  AmeliaBR: one issue that has come up before which we have
  waffle language in SVG 2 about is that resource documents don't
  have a medium, so has problems with media queries, resolving
  percentages

  Rossen: 300x150!

  heycam: yes, why not

  BogdanBrinza: so if the resource references percentages how do
  they get resolved

  ed: right

  BogdanBrinza: similar to background-image?

  AmeliaBR: this is SVG resources

  ed: say you referenced an external gradient file
  ... fill: url(externalfile.svg#gradient)

  Rossen: how is this different frmo use?

  ed: it's not, but it's not defined well there

  AmeliaBR: percentages come up in use elements. in same document
  use elements, percentages are resolved on the original document
  not the referncing element

  Rossen: not for us

  AmeliaBR: right now if you have an SVG file with nested
  viewBoxes, and you want to reuse content into the local
  viewBox, it doesn't adjust to the local definition of what 100%
  is

  Rossen: is this based on implemnetations or spec?

  AmeliaBR: I'm pretty sure it's in the spec, not necessarily
  intentionally
  ... but it is consistent everywhere we tested it
  ... the other thing is that most implementations don't run CSS
  in resource documents, so if you have a <style> they don't have
  any effect on the reused content
  ... again that's not specced, just what implementations do

  ed: do you see it as an external document or as nodes being
  cloned?

  Rossen: use is basically copy-on-write
  ... you have a hosting context
  ... if your <g> element everything inside depends on where it's
  being hosted, with percentages, if you need to
  recreate/restyle/recalc the subtree that's in the g element,
  then you only do it in those contexts
  ... for external referenced documents I wouldn't expect
  different behaviour
  ... at the very least in terms of sizing and percentages
  ... it's a separate discussion about animations/transitions
  running
  ... so in CSS we have two separate cases where people may or
  may not expect aniamtions to run
  ... there is the case of something that is not visible on the
  screen and do run, and there is the case where it's not on the
  screen that they don't run
  ... that's the difference between display:none subtree, with
  animations suppressed, and visibility:hidden, in which
  animations do run
  ... so to compare the question we have at hand here, we should
  ask whether we're considering external documents as
  display:none case or similar to visibility:hidden case

  heycam: for me I don't think about it as a display:none
  document

  Rossen: in general we try to load and run as few things as
  possible, for perf and power
  ... running animations would be wasteful
  ... I don't want to make this problem worse
  ... so if we can help it, I'd be in support of not running
  animations

  BogdanBrinza: then the style example maps nicely to that. if
  you have <style> in your referenced resources you don't want
  them to affect the outer document
  ... the more I think about it the more I think it makes sense
  to think about them as display:none

  <AmeliaBR> Worth looking at our current text in SVG 2:
  [17]https://svgwg.org/svg2-draft/struct.html#UseElement
  Starting "The element referenced by ‘use’ may be in a separate
  document."

    [17] https://svgwg.org/svg2-draft/struct.html#UseElement

  AmeliaBR: a good compromise would be resolving styles in that
  resource document, they only apply to that document, but that
  document does not have an animation timeline
  ... and the other issue was if you're resolving styles you need
  to resolve media queries
  ... the logical approach is set a default size, or to say use
  the media dimensions of the referencing element

  Rossen: that would apply you'd need to resolve properties twice
  ... once in the lwoer document and once in the host document
  ... and that would be bad
  ... you could go a step further and say resolving styles
  shouldn't happen, but that would prevent sharing too

  shepazu: I'm sympathetic to what Rossen said
  ... I think it seems most consistent/performant
  ... I think we should make clear what things are referenceable,
  what are not
  ... if animations can'tb e expected to be run, authors should
  understand why that is

  heycam: I'd love to see tests but happy to go with not running
  animations for now

  AmeliaBR: for styles and CSS animations afaik nobody resolves
  styles except inline styles on external use

  BogdanBrinza: the way to spec is that things that are context
  dependent, we just don't have the context for the referenced
  document
  ... when did the timeline start?

  <BogdanBrinza> [18]https://svgwg.org/specs/integration/#issue4

    [18] https://svgwg.org/specs/integration/#issue4

  BogdanBrinza: next one, issue 4

  RESOLUTION: Animations do not run in resource documents.

  BogdanBrinza: should CSS Variables that map palette colours be
  mapped into the document here too?
  ... issue suggests removing this issue, so let's do that

  <BogdanBrinza> [19]https://svgwg.org/specs/integration/#issue5

    [19] https://svgwg.org/specs/integration/#issue5

  BogdanBrinza: issue 5, this one I've made the changes to this
  section
  ... the changes I made are something Cameron mentioned earlier,
  CORS applying
  ... the current state of things is that as far as I tried,
  Chrome does apply CORS, Edge has same domain restriction,
  Firefox allows any reference

  heycam: I'd be happy for that to be tightened up

  BogdanBrinza: this would be a good test case

  <Zakim> AmeliaBR, you wanted to add a new issue re the "font
  document" section

  AmeliaBR: it's not currently marked as an issue but there's a
  lot of stuff in that font document section that uses these
  context-* values, which we're no logner defining in SVG 2

  heycam: context-fill,stroke are in the SVG 2 spec,
  context-value might not be though
  ... I'll figure out where those other things should be defined,
  since the OpenType spec is referencing this for the UA style
  sheet

  BogdanBrinza: so that's a requirement and it sounds like the
  course of action is to ask the OT people to update this?

  heycam: I'll write up some text for this

  BogdanBrinza: we have this issue about protecting infinite
  reference cycles
  ... Chrome/Edge/Safari limit to one level
  ... Firefox has no limit

  heycam: happy to align on the same number of levels

  BogdanBrinza: I think ti's the interoperable behaviour we'd
  want anyway
  ... the other part is the URL standard reference, it's just
  editorial

  <BogdanBrinza> [20]https://svgwg.org/specs/integration/#issue6

    [20] https://svgwg.org/specs/integration/#issue6

  BogdanBrinza: issue 6 is about "Animated mode", should we
  remove this

  <AmeliaBR> This is the section of SVG 2 that currently defines
  which resources may be in external elements:
  [21]https://svgwg.org/svg2-draft/linking.html#processingURL

    [21] https://svgwg.org/svg2-draft/linking.html#processingURL

  BogdanBrinza: oh I propose changing "external references" to
  "references to external resources"

  heycam: it's not being referenced by anything, so let's remove
  it

  nikos: does the OT spec still reference "secure animated mode"?

  heycam: maybe

  BogdanBrinza: soudns like there was some attempt to address the
  CORS concerns

  AmeliaBR: to clarify, the "secure" modes are currently used
  ... when you embed SVG as an image, you're using this "secure
  animated mode"
  ... we don't have uses where no scripts, but do support
  external files
  ... so 3.3 Animated mode there aren't any uses of that

  BogdanBrinza: sounds fair

  AmeliaBR: there are static renderers that do support external
  references, so there's a benefit for recognising that his
  extists
  ... don't know if it's needed in this context

  BogdanBrinza: for external resources, you only have a single
  level of depth, and there is no script in those resources
  ... it sounds like we're talking about policies, rather than
  modes
  ... and the modes references policies

  shepazu: that's what it's doing

  BogdanBrinza: there is some slight different

  shepazu: sounds fine to fix that

  AmeliaBR: the purpose of having these modes is that other specs
  can reference these and clearly say that e.g. HTML can SVGs
  will run in "secure animated mode", and this spec defines that
  ... so some other spec for some XML format could reference a
  static mode where the image is static, animations don't run,
  but external fonts and other embeds are allowed
  ... I don't see anything wrong with efining all the different
  combiantoisn and giving them names
  ... so that other specs can clearly reference them and have a
  clear definition

  BogdanBrinza: that is what I propose
  ... they should be defined as single entities, but currently
  modes try to explain more than just the policies, but they
  should be purely about the policies
  ... if needed we can expand with new policies, but still keep
  the same modes

  RESOLUTION: Keep the modes, define them in terms of policies,
  basically as a table mapping modes to specific policies.

  <BogdanBrinza> [22]https://svgwg.org/specs/integration/#issue7

    [22] https://svgwg.org/specs/integration/#issue7

  BogdanBrinza: next, issue 7

  AmeliaBR: that's the same

  <BogdanBrinza> [23]https://svgwg.org/specs/integration/#issue8

    [23] https://svgwg.org/specs/integration/#issue8

  BogdanBrinza: issue 8 and 9 are about HTML in foreignObject
  ... issue 9 is editorial, add examples
  ... issue 8 I'm not sure I understand it. "what should we say
  about when to rasterize the content?"
  ... pixellated form controls?

  AmeliaBR: I think that's an obsolete issue
  ... this was like transforms/filters applied to SVG content
  with forms in foreignObject
  ... but now we have transforms/filters applied to HTML content

  <BogdanBrinza> [24]https://jsfiddle.net/pscu8wLq/

    [24] https://jsfiddle.net/pscu8wLq/

  BogdanBrinza: looks like implementations don't pixellate now
  ... last issue, 10, this is a todo for defining SVG in
  foreignObject

  AmeliaBR: I think I'd like to see here, in general to
  HTML/SVG/MathML, a sentence that says what the effect of
  viewport is on child content, but that's not quite correct
  (it's not a separate document)
  ... but that's where it becomes an issue, what's the parent
  size / coordinate system that that foreignObject creates, and
  just to have a sentence about the content of the foreignObject
  being drawn into a container that has the width/height and
  coordinate system established by the foreignObject

  BogdanBrinza: sounds like this is defined in section 4.1

  AmeliaBR: that's part of it

  BogdanBrinza: so SVG viewports establish the containing block
  for HTML, and vice versa -- using SVG in HTML context, then the
  containing block establishes the viewport

  AmeliaBR: so maybe generalise that rule and not make it
  specific to HTML, for one thing it's anything CSS-styled
  content that could be some other XML language who knows

  BogdanBrinza: yes that's CSS context, not HTML

  AmeliaBR: then if you put an <svg> inside a <foreignObject>
  then we can treat the <svg> has having a CSS box parent

  BogdanBrinza: yes
  ... there's nothing special about <svg> in <foreignObject> that
  we need to specify

  ed: right

  <paradisaeidae> Wow, had never though of such a thing: <svg>
  inside a <foreignObject>

  AmeliaBR: the key thing is that a foreignObject creates a CSS
  box, and any content you put inside it that requires a CSS box
  layout concept of a container/parent would then use that

  BogdanBrinza: I have a feeling we discussed this in Paris for
  some of the other chapters, coords?
  ... we talked about interactions between viewports and
  containing lbocks
  ... I think that's the same as we're discussing right now

  AmeliaBR: are you ok with rewriting this just to make a single
  generic description?

  BogdanBrinza: I'd imagine we have something somewhere in SVG 2?
  ... to point to

  ed: the initial continaing block?

  BogdanBrinza: how ICB maps to viewport and vice versa

  ed: section 4.1

  <nikos> [25]https://jsfiddle.net/dodgeyhack/nnztjw7s/

    [25] https://jsfiddle.net/dodgeyhack/nnztjw7s/

  nikos: just going back, this example is pixellated in firefox

  <AmeliaBR> I think this is the section Bogdan is referring to:
  [26]https://svgwg.org/svg2-draft/coords.html#ViewportSpace

    [26] https://svgwg.org/svg2-draft/coords.html#ViewportSpace

  heycam: don't think it's an issue that needs to be in the spec

coordinate precision in generated content

  stakagi: this was an issue Chris Little brought up
  ... he wanted content for technical drawings, maps. I prepared
  a wiki page
  ... with current implementation status
  ... in this wiki page, in the Conformance chapter of SVG 2 I
  think that there is no requirement to add normative language

  <AmeliaBR> Wiki page:
  [27]https://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Better_CT
  M_Computation#Improving_Significant_Figures_by_Transformation_a
  nd_Tiling

    [27] https://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Better_CTM_Computation#Improving_Significant_Figures_by_Transformation_and_Tiling

  stakagi: but for more convenience for content creators I want
  to add an explanation from this wiki page

  AmeliaBR: it's been an issue we brought up a couple of times
  ... that people are annoyed when they translate data and come
  up agains the single precision flaot numeric precision
  ... and for perf reasons nobody wants to require better than
  single precision floats
  ... so it's a nice compromise to have authoring (tool) guidance
  on how to deal with the limitations of the single precision
  coord system
  ... whether that's a separate authoring guidance spec or an
  appendix I don't mind

  stakagi: one point, I added Conformance Criteria, the viewer
  must use double for CTMs, but the TM itself need only be single

  <stakagi>
  [28]https://svgwg.org/svg2-draft/conform.html#ConformingSVGView
  ers

    [28] https://svgwg.org/svg2-draft/conform.html#ConformingSVGViewers

  heycam: is there an existing appendix where it would make
  sense?

  AmeliaBR: maybe in Conform where we have conformance class for
  authoring tools?

  <scribe> ACTION: stakagi to add non-normative authoring
  guidance about content precision to conform.html [recorded in
  [29]http://www.w3.org/2016/02/05-svg-minutes.html#action01]

    [29] http://www.w3.org/2016/02/05-svg-minutes.html#action01]

  <trackbot> Created ACTION-3836 - Add non-normative authoring
  guidance about content precision to conform.html [on Satoru
  Takagi - due 2016-02-12].

SVG stroke/corner demo

  <ed>
  [30]http://xn--dahlstrm-t4a.net/svg/experimental/svg-dashcorner
  /examples/simplerect.html

    [30] http://xn--dahlstrm-t4a.net/svg/experimental/svg-dashcorner/examples/simplerect.html

  ed: I wanted to experiment with this from the SVG Strokes
  module
  ... I created a simple polyfill using dash arrays to emulate
  corner behaviour
  ... if you look at this link, which should work in any browser,
  you see I've highlighted the corners using this feature
  ... the first polyfill version doesn't handle rounded rect
  corners, which turned out to be a bit more difficult
  ... but the spec has noted this as an issue
  ... where corners should be drawn, all over the arcs?
  ... this does depend on path length computation methods
  ... but it does show a way to do a polyfill that could work
  before browsers implement this
  ... I also went ahead and did a second demo, where you can
  specify several corner lengths

  <ed>
  [31]http://xn--dahlstrm-t4a.net/svg/experimental/svg-dashcorner
  /examples/multidash.html

    [31] http://xn--dahlstrm-t4a.net/svg/experimental/svg-dashcorner/examples/multidash.html

  shepazu: what is the shape with the rectangle with something in
  it?

  ed: that's a polyline
  ... I chose not to draw corners on each side, just highlighting
  the corners not the end points

  shepazu: why wouldn't this work in Edge?

  AmeliaBR: it's an XHR error

  ed: in the second demo I use multiple lengths for the different
  corners
  ... in the middle rect, you can see two corners have longer
  dashing
  ... and looking at the star I used more different lengths
  ... so with multiple corners you repeat similarly to dasharrays

  shepazu: how does stroke-dashcorner array with
  stroke-dasharray?

  Tav: [stole my question!]

  ed: hopefully should be defined in the spec
  ... I didn't mix in the dasharrays that might exist on elements
  in this demo
  ... the way it's meant to work is you spread the dasharray
  between the corners
  ... and adjust the gaps so that it looks nice, with
  stroke-dashadjust

  AmeliaBR: the way we spec it is you dash the corners first,
  then dash each line segment independnetly with these extra
  properties to make it look properly

  shepazu: what it sounds a bit like with this collection of
  features that it's approaching shorrthands/longhands
  ... might be good to think about it like that

  Tav: this deals with corners, what about paths? drawing a map,
  when you want to have intersections with 3 different regions
  look nice

  ed: in this first simple impl, this uses the new path api
  polyfill
  ... it provides you with getting the normalized path seg data
  out from the path
  ... I'm just looking for lineto elements

  heycam: I think something else would be needed to solve the map
  intersection case

  ed: there are a few issues in the Strokes spec I noted down
  ... one is issue 8, which says that the points at which the
  dashcorner are painted include the start/end points of every
  segment
  ... I think we shouldn't do that

  <ed> [32]https://svgwg.org/specs/strokes/#issue8

    [32] https://svgwg.org/specs/strokes/#issue8

  ed: another thing I noticed is that one thing that makes it
  hard to polyfill is that dasharrays start over again for new
  subpaths
  ... it's difficult to get the dasharrays positioned properly
  ... you have to break it apart into several path elements
  ... if the dahsarray starts over, then you can't do anything
  custom for that one

  AmeliaBR: as in your might need a half dash?

  ed: you want a new dasharray per subpath

  AmeliaBR: your polyfill will have to define every single dash
  in the whole path

  ed: I know we decided that's the way it works
  ... I think you can still break up the element if you need to

  heycam: pretty sure dashing works like that everywhere

  AmeliaBR: if the worst we can say is that the polyfill is less
  performant that's ok

Future F2Fs

  nikos: TPAC is in September, Graphical Web is early November
  ... CSSWG is meeting in May 2nd week in US
  ... I feel like we're a bit constrained by Invited Experts who
  might not be able to travel far/often
  ... so we should try to go where they are instead

  shepazu: meeting with CSS is usually productive
  ... I would hope that Amelia could attend in the US?

  AmeliaBR: I can't make promises unless someone finds a grant
  for me

  shepazu: Tav, could you travel in May to the US?

  Tav: might be difficult
  ... I'll have some money, have a designated budget, but it
  would exhaust it

  shepazu: I think it would be useful to have a F2F with CSS but
  I understand the constraints
  ... do we need to schedule a F2F?

  nikos: lots of us can only dedicate time to SVG around F2Fs
  ... it's more a case of where and when
  ... so TPAC and Graphical Web are close together, a month apart
  ... we've been invited to meet at Graphical Web

  Tav: that would be much more practical for two reasons
  ... one, for me, the one time I attended TPAC the day and a
  half we spent wasn't much
  ... a long way to go for 1.5 days
  ... two, I will probably be going to Graphical Web
  ... so it would be a small incremental cost to stay for a WG
  meeting

  nikos: I feel similarly about TPAC
  ... quite short, good but we tend to get more done at other
  dedicated WG meetings

  shepazu: I think the point of TPAC is to coordinate with other
  WGs
  ... and if we don't find we need to coorindate with groups
  other than CSS...

  Rossen: I agree that meeting with CSS is awesome, whenever we
  have the opportunity to do it
  ... the one other thing I wanted to put on the table, would we
  having any specific goals in May or whenever?
  ... one of the specific goals we had as a WG from Linkoping,
  was to come here and be ready to have CR
  ... we are underdelivering on that goal
  ... one thing reasonated with me is that nobody is putting
  efforts outside of F2Fs, so if F2Fs are a forcing function for
  spec writing, then I would be in favour of meeting
  ... as long as we can find a place and time
  ... but I'm trying to explore options where we can still make
  progress without needing to meet F2F

  shepazu: I think Rossen raises a great point
  ... I think we should set a goal for May, if we thought that
  we're close enough to get something done by May it might
  indicate some dedicated speccing days-- we've tried to do that
  in the past, it's only worked sometimes
  ... having weekly goals towards May
  ... since that's not far away
  ... regarding Graphical Web vs TPAC, I'm really busy at TPAC
  ... as much as I would like to have SVG at TPAC, pragmatically
  it's not practical for me to do all my WG stuff at TPAC

  nikos: a crazy idea might be to meet sooner than May

  AmeliaBR: there is the April Libre Graphics conference
  ... there's a chance I'll be there but can't promise
  ... that's London early April
  ... 15-18 April

  Tav: I will most likely be there
  ... Inkscape will have a hackfest before that

  <shepazu> [33]http://libregraphicsmeeting.org/2016/

    [33] http://libregraphicsmeeting.org/2016/

  Rossen: if we're organising around community engagement
  opportunities, it would be cool we could brag about shipping
  SVG 2
  ... the other thing, attracting implementor interest
  ... if and when we're done with this CR stage, it would be
  great to start talking about where we go next
  ... and how do we rev all the impls
  ... I've stated this before, as an implementor I am waiting for
  this to be stable and rubber stamped before I put resources
  onto this

  Tav: that confuses me a little, as you're talking about
  modularization with CSS

  Rossen: and I'm waiting for this module to be done
  ... I think I made some attempts to modularize other things out
  of it
  ... and yes I want to see what will happen with the next
  modules

  Tav: you would consider implementing some of the stable parts?

  Rossen: if it's in a stable SVG 2? yes
  ... I cannot commit on implementations/releases of products,
  what I can say is: if/when the spec is stable, we'll have a lot
  better chance of attracting implementation
  ... much easier to implement, particuarly if it's a gap,
  against a stable spec that's not going to keep going back/forth
  ... so, when are we going to ship?
  ... if F2F is a forcing function, I would be in favour of
  having it whenever/whereever
  ... but there needs to be more -- to justify the expense -- we
  need more data to say that's actually going to happen
  ... or if we're pretty much there and just need to nail down a
  few things
  ... which was our assumption coming here

  nikos: part of the issue with this F2F is that's early in the
  year and with Christmas/breaks people weren't spending time on
  it

  AmeliaBR: so the question is, if another F2F is set up in
  April/May, can people commit to working for the next few months
  to get a publication ready spec

  nikos: so Text and Cooridnates need to get fixed

  Tav: I would hope to get Text done in a month

  nikos: so is it worth having a F2F at Libre Graphics?

  AmeliaBR: if you organise it I will come

  nikos: for me I could get there if it's after Libre Graphics

  ed: it would be easier for me, being there

  Rossen: my vote would certainly be May since I'll be at
  CSS/Houdini
  ... could I come in April? don't know

  BogdanBrinza: it would be challening for me to attend in April

  nikos: one advantage to getting a few people together, we could
  VC with other people if any issues come up for discussion
  ... for May...

  shane: 9-11 CSS, 12-13 Houdini
  ... need to let us know as soon as possible if SVG wants to
  meet there

  Rossen: if the goal of meeting is to write specs, perhaps you
  should go with April, the people most involved in spec work can
  summit
  ... that's good for Erik, Tav, Amelia can maybe attend too
  ... other option is: if we're meeting as a WG, if we need to
  work on open issues, then you want a bigger quorum. seems like
  May in US is a better option for that.

  shepazu: a hybrid option is to have an editor's meeting at
  Libre Graphics and then have a F2F in May with CSS

  AmeliaBR: so April will be clean everything up so in May we
  have a document we agree with shipping?

  nikos: I could come to both, if that's what needs to be done
  ... I think if we got together in London, it would be pretty
  productive
  ... if people could commit to telcons until then for talking
  about issues, we'll have a lot of stuff ticked off to get
  finished at that spec meeting

  <birtles> scribenick: birtles

  Rossen: SF will be busy at that time

  nikos: we'll go with April and discuss May after the break

  <lunch break 1h>

  <nikos> AmeliaBR: we're mostly back

  <heycam> ScribeNick: heycam

  nikos: I think if we have a meeting in April, and Tav, myself,
  Amelia and maybe Erik get together, that would be a productive
  meeting
  ... in terms of reviewing and finishing off the spec text
  ... not for talking about issues
  ... if we meet in May it's in the US, where we're likely to
  have Rossen, myself, Shane, Bogdan maybe
  ... if we get the spec done at the April meeting, issues will
  start getting raised as we make our way through the test suite
  ... if we met in May even without the April meeting, what would
  be on the agenda for May?
  ... so meeting later than May, to discuss issues that arose
  from test writing sounds better
  ... so let's have the small meet in April to get the spec
  finished, then plan a meet mid-year once we've had some time to
  work on tests and collecting issues from that
  ... so something like July, don't know where though

  RESOLUTION: Spec editors will meet in April adjacent to Libre
  Graphics, no meeting in May, organising SVG meeting July or so
  later.

SVG feature interest from implementors

  shane: as an implementor, best bet for getting new SVG features
  in browsers is to make them relevant
  ... so they need to integrate well with HTML
  ... I don't have any specific advice, but the extent to which
  SVG interopates well with HTML will affect how likely it is
  these are implemented

  AmeliaBR: some of these features are make SVG behave more like
  HTML

  Tav: there are a variety of things that already work in HTML,
  and we just need to make sure they work in SVG
  ... like text-orientation, the font features, so we just have
  to make sure when they're implemented for HTML they work in SVG
  too
  ... the filter shorthands for example work in HTML in Chrome
  but not in SVG

  ed: that's right

  Tav: so that should be low hanging fruit to pick up

  shane: that might be low hanging fruit, but there has to be
  demand
  ... if you want to think like an implementor, they're going to
  be looking at what the general webdev public demands
  ... if there's no demand from authors then it won't be
  prioritised

  Tav: it's a chicken and egg problem
  ... what I'm going to do, is I'll start enabling some things in
  Inkscape output

  nikos: we could start tracking what features are actually
  implemented
  ... so we can get a handle on what is starting to be
  implemented

  Rossen: also, as an implementor, I want something that is
  stable
  ... if it's not stable I'm not going to look atit
  ... when I talk to my management, they don't want to know about
  SVG until there's something which you can print and you don't
  have reprint many times
  ... it's the door-opener
  ... I have spoken to some other implementations that have large
  adoption, and they have similar feedback

  shepazu: so you're saying stabilise, then we'll pay attention

  Rossen: yes, that's what I've been saying for 15 months

  shepazu: because SVG is a large spec, is stabilising chapters a
  reasonable thing? or it has to be the whole thing?

  Rossen: can we break these chapters into their own modules and
  say this thing is CR?

  AmeliaBR: at this point that would slow things down

  Rossen: it seems like the spec is going in the right direction
  though
  ... here's a simple kind of conversation that will happen in a
  company like ours
  ... you look at the history you see a spec that has been in
  development for the last 12 years, in order to have faith in
  this work you need to see the rubber stamp
  ... as an implementor I want to go and do that work, but can't,
  because I'm resource bound
  ... when someone looks at a spec that has been going on for
  that long, how do they know it's not going to keep going for
  another 13 years?
  ... that the message this WG must be able to send, to say it's
  done
  ... to say it's stable and ready for implementation
  ... it's just this really long timeline that is holding us back
  ... we did the same thing with CSS, at least in IE
  ... until 2.1 was stable there wasn't a good reason to go and
  implement it

  alex: from Chrome's PoV, my experience in SVG and standards I
  agree with Rossen
  ... with the 1.2T timeframe, JSR226, there are other standards
  bodies that want a stable spec before looking at it
  ... from Chrome's impl PoV it's irrelevant, but from a
  standards PoV yes

  birtles: I think what I'd be interested in is if SVG 2 feels
  like a lot, if there were some sort of subsets of low hanging
  fruit or things other implementors agreed or community votes,
  smaller packages of work available, that might be an easier
  sell

  Rossen: but this is what CR is for

  birtles: not talking about the process
  ... we hate html5tests, it just counts the number of APIs you
  implement, but if you have things like that it's a package of
  work to say it's a goal to get this to pass
  ... saying the goal is "SVG 2" is a big sell

  alex: I think the point of W3C process, CR is the thing to get
  things out the door

  birtles: nothing to do with standardisation, I'm saying if
  someone else as an independent effort to say we think these 3
  features are the most important ones out of SVG 2, we're going
  to make up a matrix...

  Rossen: sure, but at this point how do you know these will be
  the same features by the time the spec is in CR?
  ... there's a Rec process for a reason
  ... so going out there and saying that you know these features
  are going to be the way they are...
  ... there is a formalised standardisation process which serves
  at least one thing that's good, which is "this is a stable
  spec"

  birtles: I'm just saying, as an implementor something that
  would be helpful is, after CR, to narrow the scope of what we
  do first

  Rossen: prioritisation?

  birtles: yes
  ... trying to say "lets do all of SVG 2" is an overwhelmingly
  big task
  ... if someone wants to prioitise and agree on how to
  prioritise that's an easier sell

  Rossen: then you get into 80/20 problem

  <Zakim> AmeliaBR, you wanted to recast discussion: which parts
  of the spec are stable enough to start building tests?

  AmeliaBR: these all sound like good points, and I think Rossen
  has clearly argued that it's no use asking for impls until we
  get the rubber stamp
  ... but for our own purposes, we can still start breaking
  things down into individual components as Brian was saying,
  certain things are going to be different priority for users
  ... and the other thing is testing
  ... even if some of us are still rewriting the Text chapter, if
  another chapter is stable and people have time to write tests
  they can move ahead with that
  ... and so that from that perspective it's still useful to have
  a matrix of our own to keep track of which new features have
  been introduced and we're confident it's not going to change

  nikos: the other topic is marking features at risk for CR
  ... i don't really know the process for that sort of thing

  alex: I think you just get implementor feedback about what
  things are likely to be implemented

  shepazu: we mark features at risk if we feel they're not going
  to be implemented
  ... with the new process, going back to CR which used to be
  more painful, is streamlined
  ... so Process2015 streamlines with how you iterate on a spec
  ... It hink we should be resonbile without we try to portray
  issues
  ... it's not as useful to identify these at risk features
  before CR now with the new process

  BogdanBrinza: I might repeat Rossen's view in a pragmatic way
  ... there have been features implemented in other browsers,
  Inkscape; we'll gladly implement things we feel we need to
  implement
  ... features that are being used out there
  ... support in other browsers is great, and it shows the
  pipeline
  ... we're #3 or #4 browser now, so we're under no pressure to
  implement
  ... we will show our interest and implement things we have to

  nikos: at the April editor's meeting we can enumerate all the
  SVG 2 feature, as a basis for tracking implementation, what
  needs tests, and as a communication tool with implementors
  ... for now let's just get the text in coords/text chapters
  finished

SVGZoomEvent

  <nikos> [34]https://github.com/w3c/svgwg/issues/21

    [34] https://github.com/w3c/svgwg/issues/21

  nikos: the question was raised by chromium folks, about whether
  SVGZoomEvent is needed
  ... whether anyone uses it
  ... it wasn't clear to them from reading the spec how it should
  work
  ... when currentScale changes the event should be fired, I
  think
  ... there was some history with Opera Presto which had a
  control to scale SVG content within the page

  ed: apparently SVGZoomEvent doesn't work in Chrome
  ... so I think they're looking to see whether they can drop it
  ... not sure if people are trying to dependent on this

  BogdanBrinza: are there use counters?

  nikos: no mention of them

  <paradisaeidae> Please don't drop SVGZoomEvent

  AmeliaBR: I suspect it's very poorly used just because there no
  active implementations right now have user controlled pan and
  zoom options
  ... so I'm not sure whether anybody fires this event for pinch
  zoom etc.
  ... so it's certainly an edge case

  <paradisaeidae> Use counters are not
  potentialUseContersWhenUseIsUnderstoodCounters

  Rossen: was the zoom event raised on user zoom or pinch zoom?

  AmeliaBR: SVG used to have zoomAndPan, which users coul use to
  zoom in/out

  <paradisaeidae> This is an area I did not have time to put to
  the panel last night.

  AmeliaBR: and then authors could listen to this event to
  respond to these zooms

  Rossen: you say there's interactivity where the user is
  interacting with SVG content, based on which other SVG
  content...

  AmeliaBR: the idea was the browser would show zoom UI
  ... but nobody does that
  ... (since Opera Presto was dropped)

  Rossen: today we're hiding the interaction between pinch
  zooming and viewport more and more

  <paradisaeidae> SVGZoomEvent can signal the level of detail to
  be rendered.

  Rossen: so that you can implement efficient zooming in the GPU

  shepazu: there's a difference between optical zoom and
  functional zoom. we're not talking about making the thing
  bigger, talking about drilling down into more details

  Rossen: these things work well today in response to touch
  events, etc.
  ... zooming is a user instantiated action which is controlled
  on the app layer most of the time
  ... in that case, you know how your application should behave
  ... there's no reason to have another event to say the user did
  a pinch gesture
  ... this is your app, you know what that gesture means
  ... without needing another event which means your zooming
  ... what Amelia said makes sense, if the browser was allowing
  zoom in a script-undetectable way, then it makes sense

  <paradisaeidae> is pinch the only way zooming can be signalled?

  shepazu: there's any number of ways users can initiate these
  things
  ... however they did it, it's like an INDIE UI thing
  ... letting the page know that the user zoomed, the page reacts

  Rossen: if this is the case, why doesn't HTML have the same
  thing?

  <stakagi>
  [35]https://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Investiga
  tion_of_APIs_for_Level_of_detail#Events_for_start.2C_end_and_du
  ring_transition_of_zooming_and_panning.

    [35] https://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Investigation_of_APIs_for_Level_of_detail#Events_for_start.2C_end_and_during_transition_of_zooming_and_panning.

  shepazu: the kinds of apps you build with HTML are different

  Rossen: we have a semantic zoom to say you can double tap to
  different menus, categories, different levels of HTML layers
  ... nothing to do with CSS
  ... so I'm questioning the need for the necessity for this
  event

  alex: should put a use counter on it

  <stakagi> Regardless of SVG, the event about zoom on web
  browsers is made confused.

  nikos: according to the bug it's not implemented but it can be
  feature detected

  AmeliaBR: it was implemented in the Adobe viewer which had
  those controls
  ... I would argue against what some of what Rossen said, I'd
  love to see a semantic zoom event
  ... the user did an input which normally means zoom on their
  system, but I don't see the use of having an SVG specific event

  BogdanBrinza: looking at Chromium source it's declared but not
  used

  nikos: sounds like there might be good use cases for this but
  it's not specced properly

  AmeliaBR: we could for wording tie it into the znp control
  wording

  nikos: sounds like this could be removed and looked at in a
  wholistic way later on

  shepazu: just noting that INDIE UI hasn't been updated in a
  year or so, they seem to have something called zoomrequest but
  dropped in interest of spec speed

  RESOLUTION: Remove SVGZoomEvent from SVG 2.

  <nikos> scribenick: nikos

Exclusion shapes for text

  Tav: The spec right now uses shape-outside
  ... It doesn't really match the CSS concept of shape-outside
  ... which is to specify a region that an object is shrunk by

  Rossen: Here's a scenario: you have a text element. The number
  one thing you want to do is say wrap this text inside a shape
  (e.g. circle)
  ... and here are two or three other shapes, that if they
  intercept with the shape inside, they subtract geometry from
  the shape
  ... a nice term for describing this might be shape-subtract, or
  shape-exclude
  ... shape-subtract further changes the shape specified fro
  shape-inside if there's an intersection

  <ed> BogdanBrinza, heycam: do you both agree with
  [36]https://svgwg.org/svg2-draft/interact.html#issue6
  suggestion not to list events from DOM Events / HTML?

    [36] https://svgwg.org/svg2-draft/interact.html#issue6

  Rossen: shape-outside was confusing and the wrong thing to use
  because of it's ability to change the geometry of the shape
  that is used for the exclusion (as opposed to the shape that is
  rendered)
  ... we can use shape-outside in SVG 2 in the future but we have
  to use it for the exact same purpose as in CSS, and that's not
  the case with the current description of shape-outside

  RESOLUTION: Rename shape-outside to shape-subtract to reflect
  that the way it is specified is different than shape-outside in
  CSS.

Summary of Action Items

[NEW] ACTION: BogdanBrinza to do thorough check on focus and tabIndex in HTML and circle back with ARIA group on the results [recorded in http://www.w3.org/2016/02/04-svg-irc]


  [NEW] ACTION: stakagi to add non-normative authoring guidance
  about content precision to conform.html [recorded in
  [37]http://www.w3.org/2016/02/05-svg-minutes.html#action01]

    [37] http://www.w3.org/2016/02/05-svg-minutes.html#action01

Summary of Resolutions

   1. [38]Animations do not run in resource documents.
   2. [39]Keep the modes, define them in terms of policies,
      basically as a table mapping modes to specific policies.
   3. [40]Spec editors will meet in April adjacent to Libre
      Graphics, no meeting in May, organising SVG meeting July or
      so later.
   4. [41]Remove SVGZoomEvent from SVG 2.
   5. [42]Rename shape-outside to shape-subtract to reflect that
      the way it is specified is different than shape-outside in
      CSS.

  [End of minutes]