IRC log of svg on 2015-06-09

Timestamps are in UTC.

07:01:46 [RRSAgent]
RRSAgent has joined #svg
07:01:46 [RRSAgent]
logging to
07:01:48 [trackbot]
RRSAgent, make logs public
07:01:48 [Zakim]
Zakim has joined #svg
07:01:50 [trackbot]
Zakim, this will be GA_SVGWG
07:01:50 [Zakim]
I do not see a conference matching that name scheduled within the next hour, trackbot
07:01:51 [trackbot]
Meeting: SVG Working Group Teleconference
07:01:51 [trackbot]
Date: 09 June 2015
07:04:13 [ed]
Meeting: Linköping F2F day 1
07:06:36 [slightlyoff]
slightlyoff has joined #svg
07:06:44 [ed]
RRSAgent, remind me in 8 hours about something
07:06:44 [RRSAgent]
I'm logging. I don't understand 'remind me in 8 hours about something', ed. Try /msg RRSAgent help
07:06:54 [ed]
Zakim, remind me in 8 hours about something
07:06:54 [Zakim]
ok, ed
07:08:14 [ed]
07:10:59 [pdr]
pdr has joined #svg
07:16:58 [stakagi]
stakagi has joined #svg
07:19:12 [krit]
krit has joined #svg
07:23:12 [cabanier]
cabanier has joined #svg
07:27:35 [BogdanBrinza]
BogdanBrinza has joined #svg
07:30:18 [BogdanBrinza_]
BogdanBrinza_ has joined #svg
07:31:20 [ed]
Zakim, room for 5
07:31:20 [Zakim]
I don't understand 'room for 5', ed
07:31:24 [ed]
Zakim, room for 5?
07:31:25 [Zakim]
ok, ed; conference Team_(svg)07:31Z scheduled with code 26632 (CONF2) for 60 minutes until 0831Z
07:32:22 [Zakim]
Team_(svg)07:31Z has now started
07:32:29 [Zakim]
07:32:41 [ed]
Zakim, [IP is svgwg
07:32:41 [Zakim]
+svgwg; got it
07:34:39 [heycam]
Scribe: Cameron
07:34:41 [heycam]
ScribeNick: heycam
07:34:48 [ed]
Present: Cameron, Erik, Rossen, Bogdan, Tav, Takagi, Nikos, Fredrik Söderquist
07:35:50 [heycam]
Topic: Resolving on getting SVG 2 to CR
07:36:03 [Zakim]
+ +1.415.832.aaaa
07:36:05 [heycam]
BogdanBrinza_: last time we agreed that we want to take this to a stable spec, resolve the issues as fast as possible
07:36:09 [heycam]
... we've made great progress on the issues
07:36:19 [heycam]
... what I think we lost along the way is an understanding of where we are right now
07:36:27 [heycam]
... are we close to this?
07:36:44 [heycam]
... what are the steps we need to get to CR?
07:37:28 [heycam]
BogdanBrinza_: 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
07:37:37 [stakagi_]
stakagi_ has joined #svg
07:37:37 [heycam]
... we have done a lot of changes, but more are expected
07:37:44 [heycam]
... we should figure out what's remaining for every chapter
07:37:50 [heycam]
... if any chapters are ready we could sign off on them now
07:38:45 [heycam]
... let's look at each chapter
07:38:51 [heycam]
... chapter 1, cyril, no issues; we can move forward
07:38:55 [heycam]
... chapter 2, rendering model
07:39:03 [BogdanBrinza_]
07:39:44 [heycam]
nikos: as far as issues go, there's nothing else that needs resolving on
07:39:49 [heycam]
... it's just a case of making the changes that need to be done
07:40:01 [heycam]
BogdanBrinza_: how long do you expect those changes to be made?
07:40:18 [heycam]
nikos: I think Cameron was going to something about the overflow property
07:40:47 [heycam]
BogdanBrinza_: so nothing blocking?
07:40:49 [heycam]
nikos: no
07:41:16 [Zakim]
07:41:21 [Zakim]
07:41:34 [heycam]
nikos: I think the most useful thing would be to get some feedback on the changes
07:42:14 [heycam]
BogdanBrinza_: maybe do that after this?
07:42:21 [heycam]
BogdanBrinza_: next one is types is Cameron
07:43:54 [heycam]
heycam: Issue 20, SVGViewSpec definitions, I made some progress on
07:44:00 [heycam]
... have it on the agenda for discussion
07:44:12 [heycam]
... Issue 13, getCTM, is awaiting Dirk's ACTION-3724
07:44:25 [heycam]
... Issue 15 is waiting for use counter results, I think Erik was going to measure that
07:44:32 [ed]
status of getTransformToElement -
07:44:46 [heycam]
ed: this probably hasn't hit stable yet
07:44:59 [heycam]
BogdanBrinza_: I think that's similar to most non-mainstream features
07:45:03 [heycam]
... i.e. extremelty low usage
07:46:05 [heycam]
ed: we were measuring this to see if we can avoid defining how getTransformToElement works between separate SVG fragments
07:46:09 [heycam]
ed: this is in stable already actually
07:46:13 [heycam]
... so the numbers should be good
07:46:46 [heycam]
BogdanBrinza_: we don't get different usage between intranet and public internet for web features, generally
07:46:51 [heycam]
... I wouldn't expect this to be different
07:47:16 [heycam]
RESOLUTION: Drop getTransformToElement
07:47:22 [heycam]
ACTION: Cameron to remove getTransformToElement
07:47:22 [trackbot]
Created ACTION-3793 - Remove gettransformtoelement [on Cameron McCormack - due 2015-06-16].
07:48:17 [Tav]
Tav has joined #svg
07:48:25 [heycam]
heycam: I haven't looked into the getCTM issue
07:48:33 [heycam]
ed: it's related to other issues with adding transform to <svg>
07:50:01 [krit]
To getScreenCTM: The intention was to get all transforms to the device coord space
07:50:14 [krit]
Not sure if we want to do that. Should be clarified in the spec
07:50:23 [krit]
(Especially for inline SVG)
07:52:47 [heycam]
heycam: I am a bit worried about lots of features in the spec being underspecified
07:52:59 [shane]
shane has joined #svg
07:53:01 [heycam]
... and we'll only really work out the gaps once we start building up the test suite
07:53:13 [heycam]
... not sure whether people want to try to get everything nailed down exactly before CR
07:53:20 [heycam]
... or to do that after CR while we work on testing
07:53:44 [heycam]
... apart from that this chapter is close to being done
07:54:00 [heycam]
... I added one new issues too, but we can discuss that later
07:54:18 [heycam]
BogdanBrinza_: next one, Document Structure, Erik
07:54:26 [heycam]
ed: I have quite a few issues in progress
07:54:31 [heycam]
... most of them have actions assigned
07:54:36 [heycam]
... so it's just a matter of getting to do them
07:54:48 [heycam]
... some of the issues that are open are not on me, and some of them are on things that should move to other chapters
07:54:52 [heycam]
... or are general, for the entire spec
07:54:57 [heycam]
... I think there's not a whole lot to be done
07:55:05 [heycam]
... the most complicated one is the <use> element, and all the definitions around them
07:55:09 [heycam]
... it's kind of loose at the moment
07:55:20 [heycam]
... it depends how we want to specify that, and how much we want to refer to Web Components
07:55:23 [heycam]
... and Shadow DOM
07:55:31 [krit]
What about playbackorder on SVG element?
07:55:35 [heycam]
... external <use> is probably the most difficult one to nail down
07:55:46 [krit]
It doesn't have an issue but do we still want that with WebAnim?
07:55:51 [heycam]
... 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
07:55:54 [heycam]
... as an optional feature
07:56:02 [krit]
07:56:20 [heycam]
... some implementations support external use, some don't
07:56:24 [heycam]
... should we require it?
07:56:32 [heycam]
... that's not listed among the issues here, but just something I know is the case
07:56:43 [heycam]
... I know people want to use external <use>
07:56:47 [heycam]
... for icon resources, etc.
07:57:12 [heycam]
heycam: what is the difficulty? just SVG Integration kind of issues?
07:57:24 [heycam]
ed: for example if you have @media rules, what's the viewport of the resource document?
07:57:29 [heycam]
... the <use> element may not define the viewport
07:57:46 [heycam]
... whether that should be the same as the using document's viewport or not
07:58:09 [heycam]
... for Blink, there's no frame for the external resources, and that causes issues for CSS cascading
07:58:23 [heycam]
... it's kidn of why it doesn't work properly with external <use> all the time
07:58:26 [heycam]
07:58:35 [heycam]
... it would be somewhat complicated to rewrite to use a frame there, though not impossible
07:58:39 [heycam]
... it's what we used to do in Presto
07:59:08 [heycam]
BogdanBrinza_: do you have security concerns?
07:59:13 [heycam]
ed: for sure, which we haven't thought much about
07:59:24 [heycam]
BogdanBrinza_: a perfect user tracker?
07:59:33 [heycam]
ed: that's why I suggested having crossorigin attribute on <use>
07:59:35 [heycam]
... which is now in the spec
07:59:41 [heycam]
... I have a prototype implementation for Blink
07:59:50 [heycam]
... that could use some more review/feedback
08:00:00 [heycam]
... so <use> is the biggest slowdown factor in this chapter
08:00:07 [heycam]
... the rest of the issues are mostly editorial or simple to do
08:00:15 [heycam]
... the accessibility ones, I haven't looked at them yet
08:00:19 [heycam]
... hopefully Rich is on top of those
08:00:59 [heycam]
Rossen: it's a bit of a catch-22; it's one of those applicable features that I can see people requesting a bit
08:01:04 [heycam]
... at the same time, it's going to be the one that'll slow us down the most
08:01:16 [heycam]
... working out security, perf, ...
08:01:38 [heycam]
... the underlying implementation complexity is quite high for this
08:01:47 [heycam]
... my suggestion would be, if we can, to peel it off from this chapter altogether
08:01:51 [heycam]
... and then work on it on its own
08:01:57 [heycam]
... as much as we can
08:02:07 [heycam]
... I'm leaning toward your first suggestion, have something basic specified here
08:02:24 [heycam]
ed: I think the text at the moment is more or less the same as SVG 1.1
08:03:28 [heycam]
... we can have this as an optional feature that have certain requirements -- such as scripting disabled
08:04:40 [heycam]
Rossen: how would you test it then
08:04:45 [heycam]
krit: don't need to test it if it's optional
08:05:21 [heycam]
Rossen: this is a really sought after and requested feature
08:05:26 [heycam]
... it's going to require a lot of work speccing and implementation
08:05:35 [heycam]
... in that respect, it deserves its own place
08:05:40 [heycam]
krit: I think more work to specify than implement
08:05:45 [heycam]
Rossen: I wouldn't go that far
08:05:58 [heycam]
... but anyway, it would be easier if we peel it off in its own module, and work on it there
08:06:05 [heycam]
... we're not going to slow down anything by doing this
08:06:24 [heycam]
... 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
08:06:30 [heycam]
... and then we can spend the time iterating on that modules
08:06:33 [heycam]
08:06:43 [heycam]
Rossen: I agree with Cam, specifying it half way is as good as not specifying at all
08:07:10 [heycam]
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
08:07:31 [heycam]
... otoh SVG 1.1 supported it
08:07:36 [heycam]
ed: it's there but it's not well defined
08:07:40 [heycam]
... so it's not really something you can count on
08:07:47 [heycam]
... there are lots of things that are undefined in SVG 1.1
08:08:33 [heycam]
heycam: I don't mind having a note in there to say it's planned for a module
08:08:44 [heycam]
Rossen: I would say that it should be read that we do indeed care about this feature
08:08:59 [heycam]
... to the extent that we're dedicating a module to it, where it can be worked on in a focussed way
08:09:26 [heycam]
... having a module like this is going to loop in a whole bunch of other depenencies
08:10:40 [heycam]
krit: I'm fine with adding a note, rather than it being optional
08:10:41 [heycam]
ed: me too
08:11:29 [heycam]
heycam: so we should create a new module and point to it from the SVG 2 spec?
08:11:31 [heycam]
Rossen: yes
08:13:23 [heycam]
Rossen: we don't need the document to be there now, we can see the feedback in response to this change
08:13:34 [heycam]
... what Dirk says makes sense; let's see when someone has the time to work on it
08:13:46 [heycam]
... until then, SVG 2 will be fine on its own, and will have the note mentioning the future work
08:14:22 [heycam]
heycam: so will this be disallowed or undefined?
08:14:40 [heycam]
krit: undefined
08:14:43 [heycam]
Rossen: I'm ok with that
08:14:53 [heycam]
... if someone has an implementation, I don't want them to remove it
08:15:28 [heycam]
heycam: what does that mean for the crossorigin attribute that got added?
08:15:35 [heycam]
ed: I think that would get moved to the new module
08:15:46 [heycam]
... attribute doesn't make sense without external references
08:15:51 [heycam]
... I would remove that as part of undefining it
08:16:47 [heycam]
heycam: makes me feel we should have the module so we have somewhere to move it
08:17:37 [heycam]
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
08:18:01 [heycam]
ACTION: Erik to make external <use> be explicitly undefined and remove crossorigin attribute
08:18:01 [trackbot]
Created ACTION-3794 - Make external <use> be explicitly undefined and remove crossorigin attribute [on Erik Dahlström - due 2015-06-16].
08:19:00 [heycam]
Bogdan: there is one issue for discussion, about requiring CSS?
08:19:10 [heycam]
heycam: we've already decided that, to require style sheet support
08:19:19 [heycam]
ed: I'll just drop the "if you support style sheets" wording
08:19:39 [BogdanBrinza]
BogdanBrinza has joined #svg
08:21:11 [ed]
next up: styling chapter
08:21:26 [ed]
heycam: chapter not close to being done
08:21:52 [heycam]
heycam: some of the issues for discussion I have on the agenda
08:22:15 [heycam]
... the only one I haven't made progress on is the UA style sheet
08:22:21 [heycam]
... issue 18
08:22:34 [heycam]
... most of the open issues are editorial/rewrites
08:22:37 [heycam]
... I will overhaul the chapter
08:23:12 [heycam]
Rossen: an issue that come up at CSS is filtering propagation of property inheritance
08:23:28 [heycam]
... let's say you have inline SVG, would a color property inherit in?
08:23:34 [heycam]
... what about for inline SVG with a forignObject in it?
08:23:45 [heycam]
... so there was a discussion about "filtering" property values
08:24:00 [heycam]
... the CSS WG said that SVG has to deal with this, and define the boundaries and what propagates or not
08:24:21 [heycam]
... 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
08:24:41 [heycam]
... and SVG would be one of the elements as part of that
08:27:00 [heycam]
[some discussion of examples]
08:27:34 [heycam]
Rossen: just want to bring that up from CSS WG
08:27:41 [heycam]
Rossen: let's discuss the issue later
08:29:33 [ed]
08:30:00 [heycam]
-- break --
08:30:18 [Zakim]
08:36:01 [Zakim]
disconnecting the lone participant, +1.415.832.aaaa, in Team_(svg)07:31Z
08:36:03 [Zakim]
Team_(svg)07:31Z has ended
08:36:03 [Zakim]
Attendees were [IPcaller], svgwg, +1.415.832.aaaa
09:00:05 [ed]
Zakim, room for 5?
09:00:06 [Zakim]
ok, ed; conference Team_(svg)09:00Z scheduled with code 26632 (CONF2) for 60 minutes until 1000Z
09:00:26 [Zakim]
Team_(svg)09:00Z has now started
09:00:33 [Zakim]
09:01:20 [ed]
Zakim, [IP is svgwg
09:01:20 [Zakim]
+svgwg; got it
09:02:05 [heycam]
Bogdan: Geometry chapter
09:02:39 [heycam]
... I think we did decide what to do with issue 1, which is what to do with text x/y properties
09:03:21 [heycam]
... Dirk will remember for sure, but I think it was #2
09:05:13 [heycam]
Rossen: and we have a resolution on this already?
09:05:15 [heycam]
heycam: I believe so
09:05:36 [heycam]
Bogdan: next chapter, Coordinates
09:05:44 [heycam]
... most of the issues listed there are actionable
09:05:50 [heycam]
... two things need discussion with the WG
09:06:05 [heycam]
... whether we should drop "defer", I have an action to create a test acse
09:06:33 [nikos_]
09:06:36 [heycam]
... when we discussed it, we had trouble coming up with useful examples of it
09:06:49 [BogdanBrinza]
BogdanBrinza has joined #svg
09:08:12 [BogdanBrinza]
09:09:39 [heycam]
BogdanBrinza: is it a compelling enough use case to keep this?
09:09:51 [heycam]
... the meeting notes lead me to believe it is not
09:11:30 [heycam]
... we were going to send a mail to the list asking if anyone has use cases for defer
09:12:44 [heycam]
... next issue is issue #20, needs talking with dirk; let's wait until he's here
09:15:17 [heycam]
Tav: issue 17 in coords.html is on me
09:15:26 [heycam]
... to define objectBoundingBox for mesh gradients
09:15:39 [heycam]
... when it's not being used as a paint server, what does objectBoundingBox mean?
09:15:45 [heycam]
... this is for x/y attributes
09:16:24 [heycam]
... but for the mesh path syntax, that's always in user units
09:17:24 [heycam]
heycam: objectBoundingBox isn't that useful if the path syntax can't be interpreted as objectBoundingBox values
09:17:58 [heycam]
nikos_: one the primary use cases for mesh gradients is to make scalable complex fill textures
09:18:17 [heycam]
... so being able to scale it is essential for that, to fit within the object being filled
09:18:39 [heycam]
Rossen: can you give a simple example?
09:18:46 [heycam]
nikos_: suppose you are making an icon, and the icon can be various sizes
09:19:19 [heycam]
... 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
09:22:54 [heycam]
BogdanBrinza: how can you transform the coordinates of a mesh?
09:23:00 [heycam]
Tav: you can put a gradientTransform="" on it
09:23:58 [heycam]
ed: patterns are an example of a paint server with x/y/width/height
09:24:02 [heycam]
... and it's just a scaling factor
09:24:17 [heycam]
... if you want to set up a coordinate space for the segments of the mesh, you could use that
09:24:26 [heycam]
Tav: still has to be mapped into the bounding box, though
09:24:34 [heycam]
ed: it's the same for patterns
09:25:30 [heycam]
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...
09:25:47 [heycam]
Tav: I think the most useful thing is for the mesh to follow the object around
09:26:42 [ed]
09:26:55 [heycam]
heycam: you can just use a transform="" on the shape for that
09:27:42 [heycam]
Rossen: why would you want the mesh not to follow the object?
09:29:35 [heycam]
09:30:12 [heycam]
[discussion of paint server vs using mesh gradients themselves for rendering]
09:31:01 [heycam]
Rossen: when used as a paint server, you would expect to be able to map the gradient to the bounding box I think
09:31:33 [heycam]
Tav: OK, I will make path segments be interpreted as 0..1 bounding box values when objectBoundingBox is used
09:32:02 [heycam]
Rossen: what is better for mesh toolability?
09:32:07 [heycam]
Tav: don't think it makes much difference
09:32:40 [heycam]
Rossen: when the mesh is declared on its own, you still want to provide some editing experience for this
09:32:45 [heycam]
Tav: it'd be the same
09:32:56 [heycam]
... you wouldn't put in a defs, though
09:33:03 [heycam]
... right now in Inkscape it only works as a paint server
09:33:50 [heycam]
... you can draw a mesh
09:34:07 [heycam]
... but you can also start with a shape that you'll fill, and it can provide a mesh that fits the shape nicely
09:34:15 [heycam]
... e.g. a conic shaped gradient for filling a circle
09:35:34 [heycam]
ACTION: Tav to make objectBoundingBox on meshes cause the path syntax to be interpreted as 0..1 bounding box values
09:35:34 [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].
09:35:58 [heycam]
BogdanBrinza: next chapter, Paths
09:36:13 [heycam]
... most of the open issues are Catmull-Rom, which are already being moved out
09:36:23 [heycam]
Rossen: I think we discussed all of these
09:38:16 [heycam]
ed: issue 12, the SVGPathSeg one, the minutes link talks about dropping the path seg interfaces
09:38:18 [ed]
09:38:18 [Rossen]
09:38:45 [heycam]
ed: in the spec I dropped two of the synchronized lists -- normalized path seg lists, as they weren't implemented everywhere
09:39:04 [heycam]
... the rest of them, they are used, but it's not very high
09:40:19 [Rossen]
09:40:22 [heycam]
... if we're adding new path segment types, we need to resolve on this
09:40:43 [heycam]
ed: I'd like to see a better path api, and I did suggest one of those to www-svg
09:40:49 [heycam]
... I don't think we resolved on anything there
09:41:01 [heycam]
... but a more lightweight interface
09:41:32 [nikos]
09:42:39 [heycam]
ed: definitely some resistance to just dropping it
09:42:44 [ed]
09:43:06 [heycam]
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
09:43:14 [heycam]
ed: in that mail I suggested a new simpler interface
09:43:41 [heycam]
... I don't want two APIs
09:43:49 [heycam]
Rossen: if we have a chance to kill it, now is the time
09:44:16 [heycam]
ed: this API could exist in parallel to the existing one
09:44:24 [heycam]
... so if an implementation wants to keep the old way for a time, it doesn't clash
09:44:38 [heycam]
BogdanBrinza: why would you want to keep the old one?
09:44:40 [heycam]
ed: compat reasons?
09:44:45 [heycam]
BogdanBrinza: there's no evidence that is a problem
09:45:01 [heycam]
... even people interested in the topic have used these APIs
09:46:25 [heycam]
heycam: I agree with one commenter that we don't want to make people parse d attributes
09:46:58 [heycam]
... we could add a new API like this in the separate Paths module
09:48:35 [heycam]
ed: so how about we drop the path apis from SVG 2, add this new proposal to the Paths module
09:48:40 [heycam]
Rossen: sounds good to me
09:50:49 [heycam]
ACTION: Erik to remove the SVG path list interfaces, and move the new proposed API to the Path module
09:50:50 [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].
09:51:14 [heycam]
BogdanBrinza: next chapter, Basic Shapes, Rossen
09:51:18 [heycam]
Rossen: it's basically done
09:54:20 [heycam]
BogdanBrinza: next chapter, Text, on Tav
09:54:24 [heycam]
Tav: this chapter needs some work
09:54:40 [heycam]
... it's mostly straightforward, I'll sit down with Cameron for a few hours
09:55:15 [heycam]
Rossen: so there are 8 issues marked as needing discussion
09:55:18 [heycam]
... is that the current state?
09:55:22 [heycam]
Tav: we've discussed some of these already
09:57:34 [heycam]
... for baseline-shift, Inkscape uses this for super/subscript
10:01:49 [heycam]
Tav: for issue 34 not sure what that's about
10:02:03 [heycam]
heycam: I think it's describing how to apply x/y after CSS text layout, which is essential to have described in here
10:02:32 [Zakim]
10:02:33 [Zakim]
Team_(svg)09:00Z has ended
10:02:33 [Zakim]
Attendees were [IPcaller], svgwg
10:04:12 [Rossen]
10:06:19 [Tavmjong]
Tavmjong has joined #svg
10:10:39 [heycam]
heycam: for issue 36, text-overflow:clip, I don't think we need to discuss it in the spec really
10:10:43 [heycam]
... but I want to review the chaper first
10:11:11 [heycam]
Tav: issue 40 is about exposing the entire text when text-overflow applies
10:11:25 [BogdanBrinza]
BogdanBrinza has joined #svg
10:11:39 [heycam]
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
10:11:46 [heycam]
... hover, interact, etc.
10:12:02 [heycam]
... so if this is the path forward, then my assumption is that all of the presentation level will be handled by CSS
10:12:08 [heycam]
... so then there'd be nothing to do here in SVG
10:12:24 [heycam]
... also, I would hate to be in a state where CSS would go defining something different, and then SVG has yet something different
10:12:59 [heycam]
... 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
10:13:08 [heycam]
... again, we have to be careful because tooltips have limits
10:14:26 [heycam]
heycam: I'm reluctant to say SVG should have tooltips here, if not in HTML text-overflow:ellipsis
10:17:04 [heycam]
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
10:20:35 [heycam]
nikos: I think text-overflow is for a visually pleasant rendering in constrained space
10:21:19 [heycam]
... 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.
10:27:32 [heycam]
Rossen: you can have :hover rule to change it to overflow:visible
10:27:51 [heycam]
Tav: and if you want to hover just over the ellipsis?
10:28:01 [heycam]
Rossen: that's why the CSS WG wants to make the ellipsis into a pseudo
10:28:13 [heycam]
... but for overflow:clip, you don't have the same solution, there's no pseudo element there
10:28:35 [heycam]
... 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
10:28:48 [heycam]
... you're not working with one element, but different text ranges, and they're dynamically changing
10:29:21 [heycam]
... 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; }
10:31:34 [heycam]
Rossen: 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?
10:31:44 [heycam]
[Rossen draws on board]
10:34:08 [heycam]
Rossen: so I think we can drop the issue
10:39:08 [heycam]
-- lunch --
12:23:31 [heycam]
Bogdan: next chapter is Embedded Content, Bogdan
12:25:18 [heycam]
krit: first let's talk about one more issue in Geometry
12:25:30 [heycam]
... the <number> shouldn't be in the property definitions for x, y, etc.
12:25:37 [heycam]
heycam: I added that, but you're right it shouldn't be there
12:25:49 [heycam]
ACTION: Dirk to remove <number> from geometry properties
12:25:50 [trackbot]
Created ACTION-3797 - Remove <number> from geometry properties [on Dirk Schulze - due 2015-06-16].
12:26:15 [BogdanBrinza]
BogdanBrinza has joined #svg
12:26:49 [heycam]
krit: I think the Coordinates chapter is very confused about canvas, viewport, etc.
12:26:59 [heycam]
... rewriting the whole chapter would be ideal, but would be a lot of work
12:27:39 [heycam]
... I'll look into it
12:28:02 [heycam]
... there are some parts that can be removed, e.g. how CTM works, since it's in the Transforms spec
12:28:31 [heycam]
... if there are deficiencies in the Transforms spec, then we should fix it there, and reference it
12:28:33 [stakagi]
stakagi has joined #svg
12:29:00 [heycam]
krit: embedded content then
12:32:16 [heycam]
heycam: last time we discussed this we decided to allow HTML namespaced elements in the SVG document
12:32:23 [heycam]
... and avoid duplicating the elements in SVG
12:33:54 [heycam]
krit: I think there's a problem, a request for users to support this, but not much implementation appetite
12:34:39 [heycam]
Rossen: why can't these people just use foreignObject?
12:34:52 [heycam]
... I'm expecting foreignObject support to pick up speed
12:35:08 [heycam]
... my point is that it's a well defined way to go between boundaries of HTML and SVG
12:35:19 [heycam]
... why should we make exceptions for some elements to get around this?
12:35:47 [heycam]
BogdanBrinza: looking at foreignObject use counters on blink it's picking up in usage
12:36:51 [heycam]
Rossen: the only thing you get is not needing to write foreignObject
12:37:54 [stakagi]
I would like to use embedded content's documentElement etc.
12:38:29 [heycam]
heycam: you do have to set the positioning of the child of the foreignObject
12:39:01 [heycam]
stakagi, that should still be possible, with <foreignObject><iframe> -- you can get contentDocument of the iframe object
12:39:23 [heycam]
stakagi, I don't think we are talking about <foreignObject xlink:href>, which is a separate issue
12:43:04 [heycam]
12:44:50 [heycam]
12:49:11 [fs] - "A start tag whose tag name is one of: ..."
12:51:21 [jdaggett]
jdaggett has joined #svg
12:51:21 [BogdanBrinza_]
BogdanBrinza_ has joined #svg
12:51:35 [heycam]
heycam: I'd like to look up our previous discussions before deciding
12:55:40 [heycam]
Rossen: next chapter, Painting, Cameron
12:56:57 [heycam]
heycam: all issues have been discussed, editing work isn't a lot
12:57:01 [heycam]
... so shouldn't take long to complete
13:02:13 [heycam]
13:06:57 [heycam]
13:09:25 [ed]
13:20:18 [ed]
-- fika break --
13:50:15 [heycam]
Rossen: next, Paint Servers chapter, Tav
13:50:19 [heycam]
Tav: chapter is mostly ok
13:50:25 [heycam]
... I'll need help for issues 9, 10, 11
13:50:35 [heycam]
... from Cameron
13:50:56 [heycam]
Rossen: next, Interactivity, Erik
13:51:01 [heycam]
ed: I did investigate issue 5 a bit
13:51:15 [heycam]
... this was regarding some formal definition of "document view"
13:51:31 [heycam]
... couldn't find anything in cssom-view or DOM saying what it actually means
13:51:39 [heycam]
... some spec should define it, but it's not really on our side to define
13:51:47 [heycam]
... we already had this wording since SVG 1.1
13:51:51 [heycam]
... leaving it as it is isn't a change
13:51:57 [heycam]
... I agree it's something that should be defined
13:53:23 [heycam]
heycam: so this is just for when windows get resized
13:53:24 [heycam]
ed: yes
13:53:49 [heycam]
krit: it's not clear if it should fire before, during or after the resize
13:53:54 [heycam]
ed: resize is defined in the DOM spec as well
13:53:58 [heycam]
... so it's essentially just listing it here
13:54:05 [heycam]
krit: can we just reference the whole thing from the DOM spec?
13:54:08 [heycam]
ed: we could
13:54:24 [heycam]
... still have to define that it works in SMIL event listeners and the onfoo attributes
13:55:08 [heycam]
krit: a lot of these things don't seem SVG specific
13:55:13 [heycam]
... can we just reference DOM and that's it?
13:55:35 [heycam]
ed: one of the changes I made to the chapter is to drop the SVG prefix from the event names
13:55:45 [heycam]
... that's a change from SVG 1.1
13:57:05 [heycam]
krit: which events have special SVG behaviour?
13:57:17 [heycam]
ed: load, at least
13:57:23 [heycam]
krit: I think we should just list the differences from DOM events
13:57:30 [heycam]
... have a note that it's different from SVG 1.1
13:58:19 [heycam]
krit: 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)
13:59:04 [stakagi]
13:59:24 [heycam]
ed: my expectation is that a UA that supports some event in HTML, that it would work in SVG too
13:59:29 [stakagi]
>The resize event occurs when a document view is resized.
14:01:56 [heycam]
ed: another case here where we dropped DOMActivate
14:02:02 [heycam]
... that's another difference from SVG 1.1
14:02:37 [heycam]
... so let's removed the things and reference DOM for those events that we can
14:02:41 [heycam]
14:03:11 [heycam]
Rossen: for issue 4,
14:03:13 [heycam]
14:03:24 [heycam]
Rossen: you needed to discuss this with Rich?
14:03:27 [heycam]
ed: haven't had time to do that
14:03:55 [heycam]
ed: some of these terms like "being rendered" need to be defined for SVG elements anyway
14:04:00 [heycam]
... but it's unclear where it should go
14:04:13 [BogdanBrinza]
BogdanBrinza has joined #svg
14:06:08 [heycam]
heycam: these algorithms like "focusing steps", can't we just reference HTML?
14:06:22 [heycam]
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
14:06:27 [heycam]
krit: 5.1 has a draft now though
14:07:37 [krit]
14:07:44 [ed]
14:08:39 [heycam]
Rossen: how ready is this chapter?
14:09:23 [heycam]
ed: the focus events and cleaning up support of listed events is probably the main changes since 1.1
14:09:44 [heycam]
... and I think that's what we want to do
14:09:53 [heycam]
... so 4, on a 1-5 scale (5 being ready to ship)
14:12:01 [ed]
RRSAgent, pointer?
14:12:01 [RRSAgent]
14:12:54 [heycam]
ed: next, Linking, Bogdan
14:13:01 [heycam]
BogdanBrinza: I've moved three issues to Actionable
14:13:07 [heycam]
... two more need discussion
14:13:17 [heycam]
... I think it'd make the other changes before that
14:13:29 [heycam]
... these are issue 8 and 9-13
14:13:46 [BogdanBrinza]
14:15:55 [heycam]
krit: the list of allowable URL references for various elements and properties
14:16:04 [heycam]
... in section 15.1.4, it includes filter, feImage
14:16:11 [heycam]
... should these be removed, since they're in the Filters spec now?
14:17:19 [heycam]
heycam: I think these restrictions should all be in the separate sections that define the properties/elements
14:17:21 [heycam]
ed: agreed
14:24:17 [krit]
14:32:33 [heycam]
[discussion about what #xywh means for SVG image references]
14:33:16 [heycam]
krit: one issue is what #xywh means when referencing an image with percentage width/height
14:35:11 [heycam]
BogdanBrinza: let's say that it applies to the resolved image size
14:35:49 [heycam]
heycam: and add an example. hopefully that's enough.
14:41:43 [heycam]
BogdanBrinza: next, Scripting, Bogdan
14:42:03 [heycam]
BogdanBrinza: only two issues in the chapter
14:42:46 [heycam]
ed: these are kind of related to the Interactivity chapter changes
14:42:52 [heycam]
... I'm not sure we need to be super specific about these here
14:43:14 [heycam]
... 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.
14:43:21 [heycam]
... I'm not sure we need to duplicate the same information here
14:44:00 [heycam]
... we could remove "graphical event attributes" since they're allowed on all SVG elements now
14:44:10 [heycam]
BogdanBrinza: is there anything specific to SVG here?
14:44:21 [heycam]
ed: don't think so, apart from defining or restricting the set of events or attributes we have
14:44:29 [heycam]
ed: it shouldn't be any hard editing or issues to solve, just editing
14:46:03 [krit]
14:46:38 [heycam]
krit: the Event Handling and Event Attributes sections look like they reference each other
14:46:50 [heycam]
... I think Event Attributes needs to be removed and the other section cleaned up
14:48:01 [heycam]
RRSAgent: pointer?
14:48:01 [RRSAgent]
14:48:17 [heycam]
ed: I think some of the terms here are in definitions.xml, a category for event attributes
14:48:56 [heycam]
RRSAgent: pointer?
14:48:56 [RRSAgent]
14:49:16 [heycam]
ed: I think some of the terms here are in definitions.xml, a category for event attributes
14:50:10 [heycam]
RRSAgent: pointer?
14:50:10 [RRSAgent]
14:50:32 [heycam]
ed: I think we should rewrite or remove most of what's here
14:50:39 [heycam]
... don't need to list each attribute just to say it's not animatable
14:51:08 [heycam]
... rather than having document event attributes and global event attributes?
14:52:51 [ed]
s/rather than having document event attributes and global event attributes?/we might need to discern between document event attributes and global event attributes/
14:53:09 [heycam]
Bogdan: so can we remove the whole section about events?
14:54:02 [heycam]
heycam: yes, though someone should carefully check that it's all duplicating information in Interactivity
14:54:27 [BogdanBrinza]
BogdanBrinza has joined #svg
14:56:09 [heycam]
BogdanBrinza: what about merging script into the interactivity chapter?
14:56:13 [heycam]
ed: yes that should be ok
14:57:46 [heycam]
BogdanBrinza: Animation chapter
14:57:56 [heycam]
Rossen: should be no issues to deal with for SVG 2
14:59:29 [heycam]
krit: I'm wondering what to do with animVal
14:59:44 [heycam]
heycam: do we define how they work if you do support SMIL and how they work if you don't?
15:00:00 [heycam]
krit: now might be the time to just make animVal an alias of baseVal
15:00:44 [ed]
15:01:16 [heycam]
ed: that's measuring creation of anything that's related to the SVG 1 DOM
15:01:49 [heycam]
krit: so this might be counting modernizr's feature detection?
15:02:01 [heycam]
ed: no I think that just creates an element to test, so it wouldn't get counted here
15:02:59 [heycam]
Rossen: next, Extensibility
15:03:03 [heycam]
... I gave this a 4
15:03:20 [heycam]
... we already have a WG resolution and action on me to merge it with embedded content chapter
15:03:37 [heycam]
... then the issues should move to the SVG DOM appendix
15:03:47 [heycam]
... so it's straightforward editorial work
15:04:36 [AmeliaBR]
AmeliaBR has joined #svg
15:06:31 [AmeliaBR]
RRSAgent, make minutes
15:06:31 [RRSAgent]
I have made the request to generate AmeliaBR
15:06:55 [Zakim]
ed, you asked to be reminded at this time about something
15:07:17 [AmeliaBR]
RRSAgent, make log public
15:07:23 [AmeliaBR]
RRSAgent, make minutes
15:07:23 [RRSAgent]
I have made the request to generate AmeliaBR
15:15:22 [heycam]
heycam: let's go through the appendices
15:15:42 [heycam]
BogdanBrinza: SVG DOM, Cameron
15:15:46 [heycam]
15:15:54 [heycam]
... the one that needs discussion is really editorial
15:16:03 [heycam]
Rossen: I am certain these are all dicsussed
15:16:29 [heycam]
ed: the only thing is from SMIL changes and if we make any DOM changes, this chapter will need to change
15:16:52 [heycam]
ed: I'm thinking of liveness
15:31:12 [heycam]
Rossen: Feature Strings appendix
15:31:48 [heycam]
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
15:32:49 [heycam]
Rossen: in SVG 2 we always return true in hasFeature
15:32:58 [Zakim]
Zakim has left #svg
15:33:24 [heycam]
... we could remove the feature strings, or we could say nothing, knowing that they all evaluate to true anyway
15:33:32 [heycam]
... and given that authors cannot rely on them
15:33:43 [heycam]
Tavmjong: but lang switching will stay
15:34:09 [heycam]
heycam: I would be happy for them to disappear
15:34:51 [heycam]
Bogdan: this will reflect the world's state anyway
15:35:17 [heycam]
heycam: so drop that plus requiredFeatures="" attribute
15:35:40 [heycam]
RESOLUTION: We will remove the Feature Strings appendix and the requiredFeatures="" attribute.
15:35:48 [heycam]
ACTION: Cameron to remove feature strings
15:35:48 [trackbot]
Created ACTION-3798 - Remove feature strings [on Cameron McCormack - due 2015-06-16].
15:51:39 [heycam]
RRSAgent, make minutes
15:51:39 [RRSAgent]
I have made the request to generate heycam
15:51:55 [heycam]
Chair: Erik
15:51:56 [heycam]
RRSAgent, make minutes
15:51:56 [RRSAgent]
I have made the request to generate heycam
16:20:40 [stakagi]
stakagi has joined #svg
16:21:02 [stakagi]
stakagi has joined #svg