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

<BogdanBrinza_> 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 on
... 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 - 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 features
... 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 http://www.w3.org/2015/06/09-svg-minutes.html#action01]

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

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

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

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 <use>
... 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 this
... 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 implementation
... 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 optional

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 http://www.w3.org/2015/06/09-svg-minutes.html#action02]

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

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

<BogdanBrinza> 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 x/y/width/height
... 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

<ed> 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 http://www.w3.org/2015/06/09-svg-minutes.html#action03]

<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

<ed> https://www.chromestatus.com/metrics/feature/timeline/popularity/568

<Rossen> 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 everywhere
... the rest of them, they are used, but it's not very high

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

<nikos> https://lists.w3.org/Archives/Public/www-svg/2015Feb/0026.html

ed: definitely some resistance to just dropping it

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

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 http://www.w3.org/2015/06/09-svg-minutes.html#action04]

<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> 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 different
... 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 overflow:visible

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 pseudo
... 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 http://www.w3.org/2015/06/09-svg-minutes.html#action05]

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

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

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

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

data: text/html,<svg><video><script>alert(document.querySelector("video").namespaceURI)</script>
... text/html,<svg><p><script>alert(document.querySelector("p").namespaceURI)</script>

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

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

Rossen: next chapter, Painting, Cameron

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

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

https://svgwg.org/specs/color/

<ed> 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 view"
... 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 events
... 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)

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

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,

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

<krit> http://www.w3.org/html/wg/drafts/html/master/editing.html#processing-model-6

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

<BogdanBrinza> 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 now?

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

ed: agreed

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

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

<krit> 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 animatable
... 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 chapter?

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 baseVal

<ed> 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 http://www.w3.org/2015/06/09-svg-minutes.html#action06]

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

This is scribe.perl Revision: 1.140  of Date: 2014-11-06 18:16:30  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/doesn't/does/
Succeeded: s/kidn/kind/
Succeeded: s/modules/module/
Succeeded: s/Rossen/Bogdan/
Succeeded: s/removed/remove/
Succeeded: s/rather than having document event attributes and global event attributes?/we might need to discern between document event attributes and global event attributes/
Succeeded: s/Cameron/Bogdan/
Found Scribe: Cameron
Found ScribeNick: heycam

WARNING: Replacing list of attendees.
Old list: [IPcaller] svgwg +1.415.832.aaaa
New list: [IPcaller] svgwg

Default Present: [IPcaller], svgwg
Present: Cameron Erik Rossen Bogdan Tav Takagi Nikos Fredrik_Söderquist
Agenda: https://www.w3.org/Graphics/SVG/WG/wiki/F2F/Linkoping_2015/Agenda_proposals
Found Date: 09 Jun 2015
Guessing minutes URL: http://www.w3.org/2015/06/09-svg-minutes.html
People with action items: cameron dirk erik tav