See also: IRC log
<trackbot> Date: 09 June 2015
<ed> Meeting: Linköping F2F day 1
<scribe> Scribe: Cameron
<scribe> ScribeNick: heycam
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[End of scribe.perl diagnostic output]