- From: Cameron McCormack <cam@mcc.id.au>
- Date: Wed, 10 Jun 2015 02:06:41 +1000
- To: www-svg@w3.org
http://www.w3.org/2015/06/09-svg-minutes.html
[1]W3C
[1] http://www.w3.org/
- DRAFT -
SVG Working Group Teleconference
09 Jun 2015
[2]Agenda
[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
Attendees
Present
Cameron, Erik, Rossen, Bogdan, Tav, Takagi, Nikos,
Fredrik_Söderquist
Regrets
Chair
Erik
Scribe
Cameron
Contents
* [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
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_>
[7]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Chapter_Assessme
nt
[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
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 -
[8]https://www.chromestatus.com/metrics/feature/timeline/popula
rity/692
[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
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
[9]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
[10]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> [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
<BogdanBrinza>
[13]http://www.w3.org/2015/03/19-svg-minutes.html
[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
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>
[14]https://svgwg.org/svg2-draft/pservers.html#PatternElementPa
tternUnitsAttribute
[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
[15]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>
[16]https://www.chromestatus.com/metrics/feature/timeline/popul
arity/568
[16] https://www.chromestatus.com/metrics/feature/timeline/popularity/568
<Rossen>
[17]http://www.w3.org/2015/02/11-svg-minutes.html#item10
[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
everywhere
... 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
<nikos>
[19]https://lists.w3.org/Archives/Public/www-svg/2015Feb/0026.h
tml
[19] https://lists.w3.org/Archives/Public/www-svg/2015Feb/0026.html
ed: definitely some resistance to just dropping it
<ed>
[20]https://lists.w3.org/Archives/Public/www-svg/2015Feb/0036.h
tml
[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
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
[21]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> [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
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
[23]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("vid
eo").namespaceURI)</script>
...
text/html,<svg><p><script>alert(document.querySelector("p").nam
espaceURI)</script>
<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
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
[25]http://www.w3.org/TR/css4-images/#the-image-rendering
[25] http://www.w3.org/TR/css4-images/#the-image-rendering
[26]https://svgwg.org/specs/color/
[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
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>
[28]http://www.w3.org/TR/DOM-Level-2-Events/events.html
[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
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,
[29]https://svgwg.org/svg2-draft/interact.html#issue4
[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
<krit>
[30]http://www.w3.org/html/wg/drafts/html/master/editing.html#p
rocessing-model-6
[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
<BogdanBrinza>
[32]https://svgwg.org/svg2-draft/linking.html#issue9
[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
now?
heycam: I think these restrictions should all be in the
separate sections that define the properties/elements
ed: agreed
<krit>
[33]https://svgwg.org/svg2-draft/linking.html#SVGFragmentIdenti
fiers
[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
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>
[34]https://svgwg.org/svg2-draft/script.html#EventHandling
[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
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>
[35]https://www.chromestatus.com/metrics/feature/timeline/popul
arity/567
[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
[36]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].
Summary of Action Items
[NEW] ACTION: Cameron to remove feature strings [recorded in
[37]http://www.w3.org/2015/06/09-svg-minutes.html#action06]
[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
[39]http://www.w3.org/2015/06/09-svg-minutes.html#action05]
[NEW] ACTION: Erik to make external <use> be explicitly
undefined and remove crossorigin attribute [recorded in
[40]http://www.w3.org/2015/06/09-svg-minutes.html#action02]
[NEW] ACTION: Erik to remove the SVG path list interfaces, and
move the new proposed API to the Path module [recorded in
[41]http://www.w3.org/2015/06/09-svg-minutes.html#action04]
[NEW] ACTION: Tav to make objectBoundingBox on meshes cause the
path syntax to be interpreted as 0..1 bounding box values
[recorded in
[42]http://www.w3.org/2015/06/09-svg-minutes.html#action03]
[End of minutes]
__________________________________________________________
--
Cameron McCormack ≝ http://mcc.id.au/
Received on Tuesday, 9 June 2015 16:07:11 UTC