minutes, Linköping 2015 SVG F2F Day 1



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

                               - DRAFT -

                    SVG Working Group Teleconference

09 Jun 2015


      [2] https://www.w3.org/Graphics/SVG/WG/wiki/F2F/Linkoping_2015/Agenda_proposals

   See also: [3]IRC log

      [3] http://www.w3.org/2015/06/09-svg-irc


          Cameron, Erik, Rossen, Bogdan, Tav, Takagi, Nikos,




     * [4]Topics
         1. [5]Resolving on getting SVG 2 to CR
     * [6]Summary of Action Items

   <trackbot> Date: 09 June 2015

   <ed> Meeting: Linköping F2F day 1

   <scribe> Scribe: Cameron

   <scribe> ScribeNick: heycam

Resolving on getting SVG 2 to CR

   BogdanBrinza_: last time we agreed that we want to take this to
   a stable spec, resolve the issues as fast as possible
   ... we've made great progress on the issues
   ... what I think we lost along the way is an understanding of
   where we are right now
   ... are we close to this?
   ... what are the steps we need to get to CR?
   ... one of the things that might be useful in getting us there,
   is to ask chapter owners to present the current state of the
   ... we have done a lot of changes, but more are expected
   ... we should figure out what's remaining for every chapter
   ... if any chapters are ready we could sign off on them now
   ... let's look at each chapter
   ... chapter 1, cyril, no issues; we can move forward
   ... chapter 2, rendering model


      [7] http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Chapter_Assessment

   nikos: as far as issues go, there's nothing else that needs
   resolving on
   ... it's just a case of making the changes that need to be done

   BogdanBrinza_: how long do you expect those changes to be made?

   nikos: I think Cameron was going to something about the
   overflow property

   BogdanBrinza_: so nothing blocking?

   nikos: no
   ... I think the most useful thing would be to get some feedback
   on the changes

   BogdanBrinza_: maybe do that after this?
   ... next one is types is Cameron

   heycam: Issue 20, SVGViewSpec definitions, I made some progress
   ... have it on the agenda for discussion
   ... Issue 13, getCTM, is awaiting Dirk's ACTION-3724
   ... Issue 15 is waiting for use counter results, I think Erik
   was going to measure that

   <ed> status of getTransformToElement -

      [8] https://www.chromestatus.com/metrics/feature/timeline/popularity/692

   ed: this probably hasn't hit stable yet

   BogdanBrinza_: I think that's similar to most non-mainstream
   ... i.e. extremelty low usage

   ed: we were measuring this to see if we can avoid defining how
   getTransformToElement works between separate SVG fragments
   ... this is in stable already actually
   ... so the numbers should be good

   BogdanBrinza_: we don't get different usage between intranet
   and public internet for web features, generally
   ... I wouldn't expect this to be different

   RESOLUTION: Drop getTransformToElement

   <scribe> ACTION: Cameron to remove getTransformToElement
   [recorded in

   <trackbot> Created ACTION-3793 - Remove gettransformtoelement
   [on Cameron McCormack - due 2015-06-16].

   heycam: I haven't looked into the getCTM issue

   ed: it's related to other issues with adding transform to <svg>

   <krit> To getScreenCTM: The intention was to get all transforms
   to the device coord space

   <krit> Not sure if we want to do that. Should be clarified in
   the spec

   <krit> (Especially for inline SVG)

   heycam: I am a bit worried about lots of features in the spec
   being underspecified
   ... and we'll only really work out the gaps once we start
   building up the test suite
   ... not sure whether people want to try to get everything
   nailed down exactly before CR
   ... or to do that after CR while we work on testing
   ... apart from that this chapter is close to being done
   ... I added one new issues too, but we can discuss that later

   BogdanBrinza_: next one, Document Structure, Erik

   ed: I have quite a few issues in progress
   ... most of them have actions assigned
   ... so it's just a matter of getting to do them
   ... some of the issues that are open are not on me, and some of
   them are on things that should move to other chapters
   ... or are general, for the entire spec
   ... I think there's not a whole lot to be done
   ... the most complicated one is the <use> element, and all the
   definitions around them
   ... it's kind of loose at the moment
   ... it depends how we want to specify that, and how much we
   want to refer to Web Components
   ... and Shadow DOM

   <krit> What about playbackorder on SVG element?

   ed: external <use> is probably the most difficult one to nail

   <krit> It does have an issue but do we still want that with

   ed: I think one way to solve that would be to not require
   external <use> in this spec, but to lay down some requirements
   for it
   ... as an optional feature
   ... some implementations support external use, some don't
   ... should we require it?
   ... that's not listed among the issues here, but just something
   I know is the case
   ... I know people want to use external <use>
   ... for icon resources, etc.

   heycam: what is the difficulty? just SVG Integration kind of

   ed: for example if you have @media rules, what's the viewport
   of the resource document?
   ... the <use> element may not define the viewport
   ... whether that should be the same as the using document's
   viewport or not
   ... for Blink, there's no frame for the external resources, and
   that causes issues for CSS cascading
   ... it's kind of why it doesn't work properly with external
   <use> all the time
   ... it would be somewhat complicated to rewrite to use a frame
   there, though not impossible
   ... it's what we used to do in Presto

   BogdanBrinza_: do you have security concerns?

   ed: for sure, which we haven't thought much about

   BogdanBrinza_: a perfect user tracker?

   ed: that's why I suggested having crossorigin attribute on
   ... which is now in the spec
   ... I have a prototype implementation for Blink
   ... that could use some more review/feedback
   ... so <use> is the biggest slowdown factor in this chapter
   ... the rest of the issues are mostly editorial or simple to do
   ... the accessibility ones, I haven't looked at them yet
   ... hopefully Rich is on top of those

   Rossen: it's a bit of a catch-22; it's one of those applicable
   features that I can see people requesting a bit
   ... at the same time, it's going to be the one that'll slow us
   down the most
   ... working out security, perf, ...
   ... the underlying implementation complexity is quite high for
   ... my suggestion would be, if we can, to peel it off from this
   chapter altogether
   ... and then work on it on its own
   ... as much as we can
   ... I'm leaning toward your first suggestion, have something
   basic specified here

   ed: I think the text at the moment is more or less the same as
   SVG 1.1
   ... we can have this as an optional feature that have certain
   requirements -- such as scripting disabled

   Rossen: how would you test it then

   krit: don't need to test it if it's optional

   Rossen: this is a really sought after and requested feature
   ... it's going to require a lot of work speccing and
   ... in that respect, it deserves its own place

   krit: I think more work to specify than implement

   Rossen: I wouldn't go that far
   ... but anyway, it would be easier if we peel it off in its own
   module, and work on it there
   ... we're not going to slow down anything by doing this
   ... we might give room for people to work on external resources
   an easier way to make progress, without having to be bogged
   down with the SVG 2 spec
   ... and then we can spend the time iterating on that module
   ... I agree with Cam, specifying it half way is as good as not
   specifying at all

   krit: if you make it an optional feature, say that we work on a
   spec later on, but implementations have to think about certain
   issues --- we know already what the big problems will be
   ... otoh SVG 1.1 supported it

   ed: it's there but it's not well defined
   ... so it's not really something you can count on
   ... there are lots of things that are undefined in SVG 1.1

   heycam: I don't mind having a note in there to say it's planned
   for a module

   Rossen: I would say that it should be read that we do indeed
   care about this feature
   ... to the extent that we're dedicating a module to it, where
   it can be worked on in a focussed way
   ... having a module like this is going to loop in a whole bunch
   of other depenencies

   krit: I'm fine with adding a note, rather than it being

   ed: me too

   heycam: so we should create a new module and point to it from
   the SVG 2 spec?

   Rossen: yes
   ... we don't need the document to be there now, we can see the
   feedback in response to this change
   ... what Dirk says makes sense; let's see when someone has the
   time to work on it
   ... until then, SVG 2 will be fine on its own, and will have
   the note mentioning the future work

   heycam: so will this be disallowed or undefined?

   krit: undefined

   Rossen: I'm ok with that
   ... if someone has an implementation, I don't want them to
   remove it

   heycam: what does that mean for the crossorigin attribute that
   got added?

   ed: I think that would get moved to the new module
   ... attribute doesn't make sense without external references
   ... I would remove that as part of undefining it

   heycam: makes me feel we should have the module so we have
   somewhere to move it

   RESOLUTION: SVG 2 will leave external <use> as undefined and
   mention in a note that we plan to work on defining it in a
   future/separate spec

   <scribe> ACTION: Erik to make external <use> be explicitly
   undefined and remove crossorigin attribute [recorded in

   <trackbot> Created ACTION-3794 - Make external <use> be
   explicitly undefined and remove crossorigin attribute [on Erik
   Dahlström - due 2015-06-16].

   Bogdan: there is one issue for discussion, about requiring CSS?

   heycam: we've already decided that, to require style sheet

   ed: I'll just drop the "if you support style sheets" wording

   <ed> next up: styling chapter

   <ed> heycam: chapter not close to being done

   heycam: some of the issues for discussion I have on the agenda
   ... the only one I haven't made progress on is the UA style
   ... issue 18
   ... most of the open issues are editorial/rewrites
   ... I will overhaul the chapter

   Rossen: an issue that come up at CSS is filtering propagation
   of property inheritance
   ... let's say you have inline SVG, would a color property
   inherit in?
   ... what about for inline SVG with a forignObject in it?
   ... so there was a discussion about "filtering" property values
   ... the CSS WG said that SVG has to deal with this, and define
   the boundaries and what propagates or not
   ... my take is that we should make a stronger statement, and
   have it handled in HTML, in general, if we want to have any
   kind of value propagation filtering or not
   ... and SVG would be one of the elements as part of that

   [some discussion of examples]

   Rossen: just want to bring that up from CSS WG
   ... let's discuss the issue later

   <ed> [11]http://en.wikipedia.org/wiki/Fika_%28culture%29

     [11] http://en.wikipedia.org/wiki/Fika_%28culture%29

   -- break --

   Bogdan: Geometry chapter
   ... I think we did decide what to do with issue 1, which is
   what to do with text x/y properties
   ... Dirk will remember for sure, but I think it was #2

   Rossen: and we have a resolution on this already?

   heycam: I believe so

   Bogdan: next chapter, Coordinates
   ... most of the issues listed there are actionable
   ... two things need discussion with the WG
   ... whether we should drop "defer", I have an action to create
   a test acse

   <nikos_> [12]http://www.w3.org/2015/02/12-svg-minutes.html

     [12] http://www.w3.org/2015/02/12-svg-minutes.html

   Bogdan: when we discussed it, we had trouble coming up with
   useful examples of it


     [13] http://www.w3.org/2015/03/19-svg-minutes.html

   BogdanBrinza: is it a compelling enough use case to keep this?
   ... the meeting notes lead me to believe it is not
   ... we were going to send a mail to the list asking if anyone
   has use cases for defer
   ... next issue is issue #20, needs talking with dirk; let's
   wait until he's here

   Tav: issue 17 in coords.html is on me
   ... to define objectBoundingBox for mesh gradients
   ... when it's not being used as a paint server, what does
   objectBoundingBox mean?
   ... this is for x/y attributes
   ... but for the mesh path syntax, that's always in user units

   heycam: objectBoundingBox isn't that useful if the path syntax
   can't be interpreted as objectBoundingBox values

   nikos_: one the primary use cases for mesh gradients is to make
   scalable complex fill textures
   ... so being able to scale it is essential for that, to fit
   within the object being filled

   Rossen: can you give a simple example?

   nikos_: suppose you are making an icon, and the icon can be
   various sizes
   ... the icon is a car. for different parts of the car, you
   define mesh gradient, but you want to be able to size that
   automatically to the size of the icon

   BogdanBrinza: how can you transform the coordinates of a mesh?

   Tav: you can put a gradientTransform="" on it

   ed: patterns are an example of a paint server with
   ... and it's just a scaling factor
   ... if you want to set up a coordinate space for the segments
   of the mesh, you could use that

   Tav: still has to be mapped into the bounding box, though

   ed: it's the same for patterns

   nikos_: if you have a game, and tiles in the game, a grass
   texture defined with a mesh gradient, and you want to fill
   different shapes with that...

   Tav: I think the most useful thing is for the mesh to follow
   the object around


     [14] https://svgwg.org/svg2-draft/pservers.html#PatternElementPatternUnitsAttribute

   heycam: you can just use a transform="" on the shape for that

   Bogdan: why would you want the mesh not to follow the object?

   [discussion of paint server vs using mesh gradients themselves
   for rendering]

   Rossen: when used as a paint server, you would expect to be
   able to map the gradient to the bounding box I think

   Tav: OK, I will make path segments be interpreted as 0..1
   bounding box values when objectBoundingBox is used

   Rossen: what is better for mesh toolability?

   Tav: don't think it makes much difference

   Rossen: when the mesh is declared on its own, you still want to
   provide some editing experience for this

   Tav: it'd be the same
   ... you wouldn't put in a defs, though
   ... right now in Inkscape it only works as a paint server
   ... you can draw a mesh
   ... but you can also start with a shape that you'll fill, and
   it can provide a mesh that fits the shape nicely
   ... e.g. a conic shaped gradient for filling a circle

   <scribe> ACTION: Tav to make objectBoundingBox on meshes cause
   the path syntax to be interpreted as 0..1 bounding box values
   [recorded in

   <trackbot> Created ACTION-3795 - Make objectboundingbox on
   meshes cause the path syntax to be interpreted as 0..1 bounding
   box values [on Tavmjong Bah - due 2015-06-16].

   BogdanBrinza: next chapter, Paths
   ... most of the open issues are Catmull-Rom, which are already
   being moved out

   Rossen: I think we discussed all of these

   ed: issue 12, the SVGPathSeg one, the minutes link talks about
   dropping the path seg interfaces


     [16] https://www.chromestatus.com/metrics/feature/timeline/popularity/568


     [17] http://www.w3.org/2015/02/11-svg-minutes.html#item10

   ed: in the spec I dropped two of the synchronized lists --
   normalized path seg lists, as they weren't implemented
   ... the rest of them, they are used, but it's not very high

   <Rossen> [18]https://svgwg.org/svg2-draft/paths.html#issue12

     [18] https://svgwg.org/svg2-draft/paths.html#issue12

   ed: if we're adding new path segment types, we need to resolve
   on this
   ... I'd like to see a better path api, and I did suggest one of
   those to www-svg
   ... I don't think we resolved on anything there
   ... but a more lightweight interface


     [19] https://lists.w3.org/Archives/Public/www-svg/2015Feb/0026.html

   ed: definitely some resistance to just dropping it


     [20] https://lists.w3.org/Archives/Public/www-svg/2015Feb/0036.html

   nikos: a lot of people in the thread weren't aware of the
   feature but said they would've used it if they did know

   ed: in that mail I suggested a new simpler interface
   ... I don't want two APIs

   Rossen: if we have a chance to kill it, now is the time

   ed: this API could exist in parallel to the existing one
   ... so if an implementation wants to keep the old way for a
   time, it doesn't clash

   BogdanBrinza: why would you want to keep the old one?

   ed: compat reasons?

   BogdanBrinza: there's no evidence that is a problem
   ... even people interested in the topic have used these APIs

   heycam: I agree with one commenter that we don't want to make
   people parse d attributes
   ... we could add a new API like this in the separate Paths

   ed: so how about we drop the path apis from SVG 2, add this new
   proposal to the Paths module

   Rossen: sounds good to me

   <scribe> ACTION: Erik to remove the SVG path list interfaces,
   and move the new proposed API to the Path module [recorded in

   <trackbot> Created ACTION-3796 - Remove the svg path list
   interfaces, and move the new proposed api to the path module
   [on Erik Dahlström - due 2015-06-16].

   BogdanBrinza: next chapter, Basic Shapes, Rossen

   Rossen: it's basically done

   BogdanBrinza: next chapter, Text, on Tav

   Tav: this chapter needs some work
   ... it's mostly straightforward, I'll sit down with Cameron for
   a few hours

   Rossen: so there are 8 issues marked as needing discussion
   ... is that the current state?

   Tav: we've discussed some of these already
   ... for baseline-shift, Inkscape uses this for super/subscript
   ... for issue 34 not sure what that's about

   heycam: I think it's describing how to apply x/y after CSS text
   layout, which is essential to have described in here

   <Rossen> [22]https://svgwg.org/svg2-draft/text.html#issue38

     [22] https://svgwg.org/svg2-draft/text.html#issue38

   heycam: for issue 36, text-overflow:clip, I don't think we need
   to discuss it in the spec really
   ... but I want to review the chaper first

   Tav: issue 40 is about exposing the entire text when
   text-overflow applies

   Rossen: we've discussed things like ellipses etc. in CSS --
   implied text -- in the ideal case, the ellipses would be a
   pseudo element you can style/address
   ... hover, interact, etc.
   ... so if this is the path forward, then my assumption is that
   all of the presentation level will be handled by CSS
   ... so then there'd be nothing to do here in SVG
   ... also, I would hate to be in a state where CSS would go
   defining something different, and then SVG has yet something
   ... so in the short term, one way to specify this would be to
   say that on hover, a tooltip will be used for displaying the
   text that is the additional text
   ... again, we have to be careful because tooltips have limits

   heycam: I'm reluctant to say SVG should have tooltips here, if
   not in HTML text-overflow:ellipsis

   Rossen: this is a general thing that would apply to HTML as
   well, and I don't think this has come up in HTML/CSS contexts
   so far

   nikos: I think text-overflow is for a visually pleasant
   rendering in constrained space
   ... but I'm not sure if an automatic display of overflow text
   is going to be useful. it's going to be very case-by-case
   whether it's useful to show it in a particular way.

   Rossen: you can have :hover rule to change it to

   Tav: and if you want to hover just over the ellipsis?

   Rossen: that's why the CSS WG wants to make the ellipsis into a
   ... but for overflow:clip, you don't have the same solution,
   there's no pseudo element there
   ... in the HTML case, when you have text which is overflowing
   based on layout, and clipped based on layout, then changing
   from clip to non-clip is tricky
   ... you're not working with one element, but different text
   ranges, and they're dynamically changing
   ... but if you want to create this visual effect of showing the
   text on hover, and then hiding it again, you can do that by
   setting the containg element, a div in HTML, do div:hover {
   overflow: visible; }
   ... we can bring back an issue to the CSS WG, but with the
   existing properties, what is it that you cannot do on :hover,
   so that you need a new mechanism?

   [Rossen draws on board]

   Rossen: so I think we can drop the issue

   -- lunch --

   Bogdan: next chapter is Embedded Content, Bogdan

   krit: first let's talk about one more issue in Geometry
   ... the <number> shouldn't be in the property definitions for
   x, y, etc.

   heycam: I added that, but you're right it shouldn't be there

   <scribe> ACTION: Dirk to remove <number> from geometry
   properties [recorded in

   <trackbot> Created ACTION-3797 - Remove <number> from geometry
   properties [on Dirk Schulze - due 2015-06-16].

   krit: I think the Coordinates chapter is very confused about
   canvas, viewport, etc.
   ... rewriting the whole chapter would be ideal, but would be a
   lot of work
   ... I'll look into it
   ... there are some parts that can be removed, e.g. how CTM
   works, since it's in the Transforms spec
   ... if there are deficiencies in the Transforms spec, then we
   should fix it there, and reference it
   ... embedded content then

   heycam: last time we discussed this we decided to allow HTML
   namespaced elements in the SVG document
   ... and avoid duplicating the elements in SVG

   krit: I think there's a problem, a request for users to support
   this, but not much implementation appetite

   Rossen: why can't these people just use foreignObject?
   ... I'm expecting foreignObject support to pick up speed
   ... my point is that it's a well defined way to go between
   boundaries of HTML and SVG
   ... why should we make exceptions for some elements to get
   around this?

   BogdanBrinza: looking at foreignObject use counters on blink
   it's picking up in usage

   Rossen: the only thing you get is not needing to write

   <stakagi> I would like to use embedded content's
   documentElement etc.

   heycam: you do have to set the positioning of the child of the

   stakagi, that should still be possible, with
   <foreignObject><iframe> -- you can get contentDocument of the
   iframe object

   stakagi, I don't think we are talking about <foreignObject
   xlink:href>, which is a separate issue


   <fs> [24]https://html.spec.whatwg.org/#parsing-main-inforeign -
   "A start tag whose tag name is one of: ..."

     [24] https://html.spec.whatwg.org/#parsing-main-inforeign

   heycam: I'd like to look up our previous discussions before

   Rossen: next chapter, Painting, Cameron

   heycam: all issues have been discussed, editing work isn't a
   ... so shouldn't take long to complete


     [25] http://www.w3.org/TR/css4-images/#the-image-rendering


     [26] https://svgwg.org/specs/color/

   <ed> [27]https://svgwg.org/svg2-draft/painting.html#issue25

     [27] https://svgwg.org/svg2-draft/painting.html#issue25

   <ed> -- fika break --

   Rossen: next, Paint Servers chapter, Tav

   Tav: chapter is mostly ok
   ... I'll need help for issues 9, 10, 11
   ... from Cameron

   Rossen: next, Interactivity, Erik

   ed: I did investigate issue 5 a bit
   ... this was regarding some formal definition of "document
   ... couldn't find anything in cssom-view or DOM saying what it
   actually means
   ... some spec should define it, but it's not really on our side
   to define
   ... we already had this wording since SVG 1.1
   ... leaving it as it is isn't a change
   ... I agree it's something that should be defined

   heycam: so this is just for when windows get resized

   ed: yes

   krit: it's not clear if it should fire before, during or after
   the resize

   ed: resize is defined in the DOM spec as well
   ... so it's essentially just listing it here

   krit: can we just reference the whole thing from the DOM spec?

   ed: we could
   ... still have to define that it works in SMIL event listeners
   and the onfoo attributes

   krit: a lot of these things don't seem SVG specific
   ... can we just reference DOM and that's it?

   ed: one of the changes I made to the chapter is to drop the SVG
   prefix from the event names
   ... that's a change from SVG 1.1

   krit: which events have special SVG behaviour?

   ed: load, at least

   krit: I think we should just list the differences from DOM
   ... have a note that it's different from SVG 1.1
   ... I would just reference the DOM spec and say that events
   specified by the DOM spec apply to SVG elements (and word it so
   that it works for future DOM versions)


     [28] http://www.w3.org/TR/DOM-Level-2-Events/events.html

   ed: my expectation is that a UA that supports some event in
   HTML, that it would work in SVG too

   <stakagi> >The resize event occurs when a document view is

   ed: another case here where we dropped DOMActivate
   ... that's another difference from SVG 1.1
   ... so let's remove the things and reference DOM for those
   events that we can

   Rossen: for issue 4,


     [29] https://svgwg.org/svg2-draft/interact.html#issue4

   Rossen: you needed to discuss this with Rich?

   ed: haven't had time to do that
   ... some of these terms like "being rendered" need to be
   defined for SVG elements anyway
   ... but it's unclear where it should go

   heycam: these algorithms like "focusing steps", can't we just
   reference HTML?

   ed: I think they were in HTML 5.1, not HTML 5, and we couldn't
   reference 5.1 at the point these were added

   krit: 5.1 has a draft now though


     [30] http://www.w3.org/html/wg/drafts/html/master/editing.html#processing-model-6

   <ed> [31]https://www.w3.org/Graphics/SVG/WG/track/actions/3775

     [31] https://www.w3.org/Graphics/SVG/WG/track/actions/3775

   Rossen: how ready is this chapter?

   ed: the focus events and cleaning up support of listed events
   is probably the main changes since 1.1
   ... and I think that's what we want to do
   ... so 4, on a 1-5 scale (5 being ready to ship)
   ... next, Linking, Bogdan

   BogdanBrinza: I've moved three issues to Actionable
   ... two more need discussion
   ... I think it'd make the other changes before that
   ... these are issue 8 and 9-13


     [32] https://svgwg.org/svg2-draft/linking.html#issue9

   krit: the list of allowable URL references for various elements
   and properties
   ... in section 15.1.4, it includes filter, feImage
   ... should these be removed, since they're in the Filters spec

   heycam: I think these restrictions should all be in the
   separate sections that define the properties/elements

   ed: agreed


     [33] https://svgwg.org/svg2-draft/linking.html#SVGFragmentIdentifiers

   [discussion about what #xywh means for SVG image references]

   krit: one issue is what #xywh means when referencing an image
   with percentage width/height

   BogdanBrinza: let's say that it applies to the resolved image

   heycam: and add an example. hopefully that's enough.

   BogdanBrinza: next, Scripting, Bogdan
   ... only two issues in the chapter

   ed: these are kind of related to the Interactivity chapter
   ... I'm not sure we need to be super specific about these here
   ... I haven't spent any time editing this, but they're tied to
   the changes we make in the Interactivity chapter, for what
   attribute names are used for events etc.
   ... I'm not sure we need to duplicate the same information here
   ... we could remove "graphical event attributes" since they're
   allowed on all SVG elements now

   BogdanBrinza: is there anything specific to SVG here?

   ed: don't think so, apart from defining or restricting the set
   of events or attributes we have
   ... it shouldn't be any hard editing or issues to solve, just


     [34] https://svgwg.org/svg2-draft/script.html#EventHandling

   krit: the Event Handling and Event Attributes sections look
   like they reference each other
   ... I think Event Attributes needs to be removed and the other
   section cleaned up

   RRSAgent: pointer?

   ed: I think some of the terms here are in definitions.xml, a
   category for event attributes

   RRSAgent: pointer?

   ed: I think some of the terms here are in definitions.xml, a
   category for event attributes

   RRSAgent: pointer?

   ed: I think we should rewrite or remove most of what's here
   ... don't need to list each attribute just to say it's not
   ... we might need to discern between document event attributes
   and global event attributes

   Bogdan: so can we remove the whole section about events?

   heycam: yes, though someone should carefully check that it's
   all duplicating information in Interactivity

   BogdanBrinza: what about merging script into the interactivity

   ed: yes that should be ok

   BogdanBrinza: Animation chapter

   Rossen: should be no issues to deal with for SVG 2

   krit: I'm wondering what to do with animVal

   heycam: do we define how they work if you do support SMIL and
   how they work if you don't?

   krit: now might be the time to just make animVal an alias of


     [35] https://www.chromestatus.com/metrics/feature/timeline/popularity/567

   ed: that's measuring creation of anything that's related to the
   SVG 1 DOM

   krit: so this might be counting modernizr's feature detection?

   ed: no I think that just creates an element to test, so it
   wouldn't get counted here

   Rossen: next, Extensibility
   ... I gave this a 4
   ... we already have a WG resolution and action on me to merge
   it with embedded content chapter
   ... then the issues should move to the SVG DOM appendix
   ... so it's straightforward editorial work

   heycam: let's go through the appendices

   BogdanBrinza: SVG DOM, Bogdan
   ... the one that needs discussion is really editorial

   Rossen: I am certain these are all dicsussed

   ed: the only thing is from SMIL changes and if we make any DOM
   changes, this chapter will need to change
   ... I'm thinking of liveness

   Rossen: Feature Strings appendix

   heycam: what do we want to do; we were going to post proposals
   to the list and come back to discuss it, but nobody did that

   Rossen: in SVG 2 we always return true in hasFeature
   ... we could remove the feature strings, or we could say
   nothing, knowing that they all evaluate to true anyway
   ... and given that authors cannot rely on them

   Tavmjong: but lang switching will stay

   heycam: I would be happy for them to disappear

   Bogdan: this will reflect the world's state anyway

   heycam: so drop that plus requiredFeatures="" attribute

   RESOLUTION: We will remove the Feature Strings appendix and the
   requiredFeatures="" attribute.

   <scribe> ACTION: Cameron to remove feature strings [recorded in

   <trackbot> Created ACTION-3798 - Remove feature strings [on
   Cameron McCormack - due 2015-06-16].

Summary of Action Items

   [NEW] ACTION: Cameron to remove feature strings [recorded in
   [NEW] ACTION: Cameron to remove getTransformToElement [recorded
   in [38]http://www.w3.org/2015/06/09-svg-minutes.html#action01]
   [NEW] ACTION: Dirk to remove <number> from geometry properties
   [recorded in
   [NEW] ACTION: Erik to make external <use> be explicitly
   undefined and remove crossorigin attribute [recorded in
   [NEW] ACTION: Erik to remove the SVG path list interfaces, and
   move the new proposed API to the Path module [recorded in
   [NEW] ACTION: Tav to make objectBoundingBox on meshes cause the
   path syntax to be interpreted as 0..1 bounding box values
   [recorded in

   [End of minutes]

Cameron McCormack ≝ http://mcc.id.au/

Received on Tuesday, 9 June 2015 16:07:11 UTC