05:44:45 <RRSAgent> RRSAgent has joined #svg
05:44:45 <RRSAgent> logging to http://www.w3.org/2013/02/06-svg-irc
05:44:53 <nikos> RRSAgent make minutes
05:45:28 <heycam> RRSAgent, make minutes
05:45:28 <RRSAgent> I have made the request to generate http://www.w3.org/2013/02/06-svg-minutes.html heycam
05:45:45 <nikos> yeh =)
05:45:52 <heycam> RRSAgent, make minutes public
05:45:52 <RRSAgent> I'm logging. I don't understand 'make minutes public', heycam.  Try /msg RRSAgent help
05:46:50 <heycam> RRSAgent, make logs public
05:48:27 <heycam> nikos, do you have local IRC logs?
05:48:55 <nikos> I'll check.
05:51:36 <nikos> I do. What would you like me to do with them?
05:56:27 <heycam> do you want to just mail them as is as the minutes for the day? too much trouble to get them processed as HTML minutes, I think.
05:57:56 <nikos> Ok, will do
06:01:37 <konno> konno has joined #svg
06:02:00 <heycam> thanks
06:15:25 <nikos> heycam, they should be bcc'd to public-svg right?
06:15:49 <nikos> I was messing around with scribe.perl seeing if I could generate something nice out of them but will have to give up for now
06:15:51 <heycam> yep
06:15:55 <heycam> ok, no problem
06:16:47 <heycam> trackbot, close ACTION-3417
06:16:47 <trackbot> Closed ACTION-3417 Relax referencing requirements (issue-2295).
06:25:03 <heycam> Cyril, when you get a chance could you add IDL for the SVGDiscardElement interface to struct.html? the build scripts give me a warning each time I touch that chapter.
06:32:53 <heycam> trackbot, close ACTION-3130
06:32:53 <trackbot> Closed ACTION-3130 Edit the spec. for http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Resolutions#Remove_the_restriction_of_tref_pointing_to_only_an_SVG_document_fragment..
07:05:46 <birtles> birtles has joined #svg
07:09:27 <birtles_> birtles_ has joined #svg
07:21:29 <birtles_> birtles_ has joined #svg
07:27:08 <birtles> birtles has joined #svg
07:31:48 <birtles_> birtles_ has joined #svg
07:39:25 <birtles_> birtles_ has joined #svg
07:47:08 <birtles> birtles has joined #svg
07:51:27 <birtles_> birtles_ has joined #svg
11:22:53 <cabanier> cabanier has joined #svg
11:47:16 <silvia> silvia has joined #svg
22:30:42 <RRSAgent> RRSAgent has joined #svg
22:30:42 <RRSAgent> logging to http://www.w3.org/2013/02/06-svg-irc
22:30:44 <trackbot> RRSAgent, make logs public
22:30:45 <Zakim> Zakim has joined #svg
22:30:46 <trackbot> Zakim, this will be GA_SVGWG
22:30:46 <Zakim> I do not see a conference matching that name scheduled within the next hour, trackbot
22:30:47 <trackbot> Meeting: SVG Working Group Teleconference
22:30:47 <trackbot> Date: 06 February 2013
22:30:51 <heycam> RRSAgent, this meeting spans midnight
22:31:04 <heycam> Meeting: SVG WG F2F Sydney 2013 Day 4
22:31:07 <heycam> Chair: Erik
22:34:14 <AlexD> AlexD has joined #svg
22:37:52 <heycam> Zakim, remind me in 8 hours about something
22:37:52 <Zakim> ok, heycam
22:37:53 <birtles> scribenick: birtles
22:37:59 <birtles> topic: border brushes
22:38:00 <dino> dino has joined #svg
22:38:07 <birtles> cabanier: in CSS you have the border-image property
22:38:13 <birtles> ... where you can slice up an image
22:38:16 <birtles> ... and tile the sides
22:38:28 <birtles> ... you can stretch them and after a point they start duplicating themselves
22:38:39 <cabanier> link: http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Sydney_2013/Agenda/border_brushes
22:39:04 <birtles> ... we have the same features in Illustrator
22:39:15 <birtles> ... and you can define a side and a corner and it does the stacking for you
22:39:23 <birtles> ... instead of just a png
22:39:32 <birtles> ... if you do a google search you can see many places where people use this
22:39:38 <birtles> ... on the wiki there are several examples
22:39:42 <dmitry> dmitry has joined #svg
22:40:18 <birtles> krit: you could use svg
22:40:33 <birtles> cabanier: but that's kind of hard because you have to define where the border is
22:41:11 <birtles> dino: do the two images orient along the edge
22:41:13 <birtles> cabanier: yes
22:41:24 <birtles> ... when there's a curve the artwork needs to bend along the curve
22:41:31 <birtles> ... so you might need to add some limitations
22:41:58 <birtles> ... e.g. if there was a gradient then you'd need to morph the gradient
22:42:18 <birtles> birtles: so is this for just SVG
22:42:30 <birtles> cabanier: this is the SVG counterpart to what's in CSS
22:42:54 <birtles> AlexD: this would have to be an adaptive dashing style thing
22:43:07 <birtles> ... so you have an exact integer number of repeats
22:43:25 <birtles> ... like we talked about for dashing where you try to make the dash array end on exact integers
22:43:33 <birtles> cabanier: you'd use this brush like a stroke
22:43:41 <birtles> ... so it also is effected by the stroke-width
22:43:47 <birtles> ... e.g. a stroke width of 2 would make it scale by two
22:43:52 <birtles> ... there's an e.g. with dashes
22:43:57 <birtles> ... so each dash would be one of the images
22:44:15 <birtles> heycam: so, theses dashes here, some of them are squashed when they're small
22:44:27 <birtles> ... but in the non-dashing examples they maintain their aspect ratio
22:44:54 <birtles> cabanier: I think in dashing examples they either squash or duplicate
22:45:07 <birtles> ... when you apply the corners...
22:45:13 <birtles> ... I think for now we only want this on polygons
22:45:19 <birtles> ... because how do you work out the corner of a path?
22:45:30 <birtles> ... even for rects you know where the corners are
22:45:38 <birtles> heycam: but you have examples of using this on a path
22:45:47 <birtles> cabanier: yes, I just drew these in Illustrator
22:46:00 <birtles> ... in the star it uses the corner on the outside but not in the inside
22:46:08 <birtles> ... I think it is a special case for stars
22:46:12 <shepazu> (this corners question applies to the "rounded corners" proposal from Rigi-Kaltbad, too)
22:46:16 <birtles> dino: are you sure?
22:46:27 <birtles> cabanier: oh, I think you're right
22:46:44 <birtles> krit: it looks like the engine looks for the smallest angle
22:46:49 <birtles> ... and orients to that angle
22:46:59 <birtles> cabanier: I think the syntax for this would be fairly easy
22:47:47 <birtles> ... for rounded corners it doesn't use the corner piece
22:48:00 <birtles> ... that's just how Illustrator implemented it
22:48:19 <birtles> heycam: is it warping the corner pieces?
22:48:21 <birtles> cabanier: yes
22:48:52 <birtles> ed: so if you had a sharp corner in the last example with the squiggly line
22:48:57 <birtles> ... would it get the corner piece?
22:49:02 <birtles> cabanier: no
22:49:12 <birtles> dino: so you'd only use it for basic shapes?
22:49:17 <birtles> cabanier: right
22:49:33 <birtles> dino: even if you drew the star as a path you wouldn't get the corner piece?
22:49:35 <birtles> cabanier: yes
22:49:40 <birtles> ... otherwise you have to define what is a corner
22:50:13 <birtles> dino: seems like there would be a lot of work in describing how you walk a rectangular object...
22:50:26 <birtles> cabanier: it would be a lot of implementation work but not so much spec work
22:50:38 <birtles> ... I don't think the warping would be defined in the spec
22:50:54 <birtles> dino: I think how the control points are warped should be defined in the spec
22:50:59 <birtles> ... if you want it to be interoperable
22:51:17 <birtles> heycam: I think you could have a high-level description regarding how points along the bezier are mapped
22:51:35 <birtles> cabanier: I'm not saying we don't have to do it.. but do we do that elsewhere in the spec?
22:51:46 <birtles> ed: yes, we do
22:52:11 <ed> http://www.w3.org/TR/SVG11/text.html#TextPathElement
22:52:20 <birtles> ... the method attribute
22:52:25 <birtles> ... when you set that to stretch
22:52:41 <birtles> ... it says something about how its done but it's not very precise
22:53:11 <birtles> dmitry: I checked and Illustrator does apply the corner pieces to custom paths
22:53:18 <birtles> cabanier: so it does, you're right
22:53:32 <birtles> s/custom paths/custom paths with sharp corners/
22:53:57 <birtles> ed: if you make a star with a path you probably want it
22:54:23 <birtles> krit: there's more calculation to determine if the corner between two curves is a sharp corner or not
22:54:44 <birtles> ed: where is the cut-off point
22:54:52 <birtles> krit: maybe it does it on all sharp corners?
22:55:11 <birtles> krit: these are fairly detailed discussions...
22:55:37 <heycam> https://svgwg.org/svg2-draft/painting.html#TermLineJoinShape
22:56:05 <birtles> heycam: the new wording about computing the shape of a stroke has the kinds of descriptions you would want for the warping here
22:56:19 <birtles> ... it's a high-level description of taking points on a path and turning them into shapes or different points
22:56:25 <dmitry> Screenshot of the corner processing in Illustrator: http://cl.ly/image/0h3l0u0D3r1B
22:56:32 <birtles> cabanier: so this would effect getStrokeBBox too right?
22:57:20 <birtles> heycam: if some of the tiling pattern didn't fill out the whole tiling space or overflow it, would that effect the stroke bbox?
22:57:42 <birtles> cabanier: there was some discussion of this in the mailing list
22:57:59 <birtles> ... at least it's easier than other brushes like the bristle brush
22:58:41 <birtles> ... I think this is pretty easy and would be nice to have in CSS too
22:58:49 <birtles> ... in CSS you would just use it like border-image
22:59:07 <birtles> ... and if you applied it to a CSS box you wouldn't have the deformed beziers
22:59:34 <birtles> ... do you think this is useful?
22:59:52 <birtles> krit: I think this should not go into SVG2
22:59:55 <birtles> birtles: I agree
23:00:08 <birtles> krit: so should we continue at all, and if so how should we continue?
23:00:37 <birtles> dmitry: Illustrator lets you define two different corner pieces (inside and outside corner)
23:01:10 <birtles> heycam and cabanier: agree it should not be in SVG2
23:01:17 <dmitry> Screenshot of two types of corners: http://cl.ly/image/1S3B3i1l0E0e
23:01:20 <birtles> krit: so do we want the feature?
23:01:25 <birtles> heycam: I think we want the feature
23:01:50 <birtles> krit: do we want to have a module for this or in SVG.next?
23:01:58 <birtles> heycam: I think it could be a separate spec
23:02:00 <birtles> ed: sure
23:02:12 <heycam> dino, http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Commitments
23:03:50 <birtles> RESOLUTION: We will continue developing border brushes in a separate specification
23:05:29 <birtles> ACTION: Rik to create a module to define SVG border brushes
23:05:29 <trackbot> Created ACTION-3440 - Create a module to define SVG border brushes [on Rik Cabanier - due 2013-02-13].
23:05:45 <birtles> topic: variable width stroke
23:06:40 <birtles> http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Sydney_2013/Agenda/discuss_vw_stroke
23:06:59 <birtles> cabanier: so this is not going to be for SVG2
23:07:13 <birtles> heycam: but we had the requirement to represent InkML traces in SVG
23:07:25 <birtles> ... we said we'd enable InkML to be rendered
23:07:35 <birtles> ... so we *could* consider it for SVG2
23:07:48 <birtles> cabanier: defining it is pretty easy
23:07:57 <birtles> ... not sure how hard it is to do in the graphic libraries
23:08:07 <birtles> heycam: can't be harder than these border brushes
23:08:26 <birtles> cabanier: at any rate, defining it should be very easy
23:08:48 <birtles> ... you just say that along these paths we have these points and at each point you say, e.g. the stroke should be 200%
23:09:18 <birtles> ... and then you draw a catmull-rom curve along the points
23:09:27 <birtles> AlexD: why would you do that, when it involves tension
23:09:37 <birtles> heycam: I'm thinking we could just extend stroke-width itself
23:10:27 <birtles> ... e.g. stroke-width="10px 15px"
23:10:33 <birtles> cabanier: I think you want to use percentages
23:10:42 <birtles> ... e.g. to represent pressure on the pen
23:10:55 <birtles> ... or if you pick up a bigger pen you want to just say 200%
23:11:06 <birtles> heycam: (e.g. on the board)
23:11:33 <birtles> ... stroke-width="10px" stroke-width-variation="0px 100%, 100px 100%, 150px 50%"
23:12:29 <birtles> birtles: (use case from previous discussion) I want this feature to be able to do finger-drawing on a tablet where the stroke width varies with touch pressure
23:13:01 <birtles> cabanier: I think I prefer stroke-width-varation="0% 100%, 66% 100%, 10% 50%"
23:13:50 <birtles> krit: do you want to be able to specify different widths for each side (left/right)
23:14:06 <birtles> cabanier: I think that might get complicated because it might not always be obvious which side is which
23:14:10 <birtles> heycam: I think it is ok
23:14:44 <birtles> dmitry: I think if you really want that you can just change the path
23:15:24 <birtles> heycam: if the widths could be a repeating pattern you could do spaghetti lines
23:16:08 <birtles> ... I don't think it's much more work
23:16:16 <birtles> cabanier: yes, I agree
23:16:58 <birtles> heycam: I think you could automatically tile it, especially if your offsets are absolute lengths
23:17:52 <birtles> ... I would actually be ok with different left-right sides
23:18:03 <birtles> ... since I think the implementation difficulty would be the same
23:18:17 <birtles> ... but what if the two intersected?
23:18:25 <birtles> cabanier: they can't since the percentage is always positive
23:19:04 <birtles> birtles: is it worth adding the features in stages?
23:19:20 <birtles> ... I think the primary use cases would be data from tablets and calligraphy
23:19:59 <birtles> ... where you probably don't need repeating patterns or asymmetric variations
23:20:14 <birtles> ed: I think it would be nice to have a spread-method like approach
23:20:17 <birtles> ... where it just repeats
23:20:37 <Cyril> Cyril has joined #svg
23:22:10 <birtles> ... I think you might want to use variable-stroke width for custom line cap
23:22:13 <birtles> ... where the end tapers off
23:22:20 <birtles> dmitry: you could use markers for that
23:22:45 <birtles> ... but it doesn't always work
23:22:59 <birtles> cabanier: like if you have a gradient on the stroke
23:23:21 <birtles> ... the marker would have a separate gradient
23:24:04 <birtles> dino: who do we expect to use this?
23:24:12 <birtles> ... hand authors? tools to export?
23:24:46 <birtles> ... I think this kind of feature is complex to hand author
23:25:30 <birtles> cabanier: I think it's not so hard
23:25:43 <birtles> krit: of course, you can already export this from Illsutrator
23:26:31 <birtles> cabanier: but strokes become a series of paths
23:26:40 <birtles> AlexD: cartographers have been asking for this
23:27:09 <birtles> dmitry: and if the export from Illustrator loses the original path then you can't modify it in script
23:27:34 <birtles> birtles: and I think there are many uses cases where you create/modify paths from script
23:27:58 <birtles> Cyril: does this affect markers
23:28:08 <birtles> heycam: yes
23:28:31 <birtles> ... because markers can be scaled in size depending on the stroke width
23:28:57 <birtles> ... but that's probably what you want
23:29:06 <birtles> ed: I think there are cases where you don't
23:29:15 <birtles> cabanier: I think you want the original stroke-width
23:30:08 <birtles> Cyril: in d3 examples, where you have flows of data
23:30:18 <birtles> ... and you have arrows where you want the arrow to grow or shrink
23:30:36 <birtles> ed: so how should we proceed?
23:31:02 <birtles> heycam: if someone is keen to do the work, someone could specify the minimum set of features
23:31:23 <birtles> ... symmetric stroke width variation with no repeating
23:31:32 <birtles> krit: can stroke-width-variation be a shorthand
23:31:46 <birtles> heycam: not sure about the naming
23:31:50 <birtles> cabanier: it could be
23:31:57 <birtles> Cyril: this would be a presentation attribute?
23:32:02 <birtles> heycam: as I've written it, yes
23:32:12 <birtles> cabanier: can you define a URI somewhere
23:32:20 <birtles> heycam: so you can re-use the definition?
23:32:31 <birtles> ... inheritance works so that might be enough
23:32:41 <birtles> ... at first I'd like to avoid element syntax and just have the property
23:32:55 <birtles> ... if we need a pre-defined thing we can add it later
23:33:29 <birtles> ... it's currently assigned to Doug in the requirements commitments
23:33:48 <birtles> (item 20)
23:33:56 <birtles> cabanier: I can talk to Doug about it
23:34:35 <shepazu> (I'm happy to defer to someone else for this, cabanier)
23:34:46 <birtles> ACTION: Rik to specify variable width stroking in SVG2
23:34:46 <trackbot> Created ACTION-3441 - Specify variable width stroking in SVG2 [on Rik Cabanier - due 2013-02-13].
23:35:02 <shepazu> (also happy to discuss it and give feedback)
23:35:47 <ed> -- 15min break --
23:35:47 <birtles> -- break, 15min --
00:00:42 <shanestephens_> shanestephens_ has joined #svg
00:08:15 <Cyril> Cyril has joined #svg
00:09:10 <heycam> ScribeNick: heycam
00:10:28 <heycam> Topic: Media fragments and SVG stacks
00:11:03 <heycam> krit: I'm not sure on the status of media fragments on the <image> element
00:11:07 <heycam> … especially for xlink:href
00:11:16 <heycam> … I don't think it's specified in SVG
00:11:34 <heycam> … should it be combined together with media fragments? allow #xywh there as well? seems to be useful, but it's not specified currently.
00:11:39 <heycam> … how would that affect our SVG Stacks hack?
00:11:48 <heycam> ed: I don't think it would affect it that much
00:11:54 <heycam> … unless you pick that particular ID
00:12:02 <heycam> krit: there are more fragments that SVG supports that aren't supported in Media Fragments
00:12:06 <heycam> … choosing the viewport e.g.
00:12:19 <heycam> … should we talk to the Media Fragments WG people?
00:12:31 <silvia> http://www.w3.org/TR/media-frags/
00:12:32 <heycam> silvia: what are the other things you're missing?
00:12:49 <silvia> spatial dimensions: http://www.w3.org/TR/media-frags/#naming-space
00:12:52 <heycam> https://svgwg.org/svg2-draft/linking.html#LinksIntoSVG
00:13:11 <heycam> ed: you can pass transforms, a viewBox
00:13:22 <heycam> Cyril: I don't understand how this depends on xlink:href="" spec
00:13:32 <heycam> krit: Media Fragments conflicts with SVG in some cases
00:13:39 <heycam> Cyril: I don't see the problem with XLink href
00:13:46 <heycam> … media fragments are defined by the MIME type
00:13:55 <heycam> … if you use it in xlink:href="" or src="", it shouldn't matter
00:14:19 <heycam> krit: we need to reference Media Fragments
00:14:29 <heycam> ed: I don't think they're in very much conflict with each other
00:14:36 <heycam> … we should reference Media Fragments
00:14:43 <heycam> silvia: are you using Media Fragments with SVG resources yet?
00:14:45 <heycam> ed: no
00:15:02 <heycam> silvia: SVG resources define how their ID fragments get interpreted, if you don't adopted the Media Fragment spec for that resource type then there's no conflict
00:15:11 <heycam> Cyril: but it makes sense to support Media Fragments, xywh, or timing as well
00:15:22 <heycam> silvia: you just need to extend the fragment specification for SVG
00:15:29 <heycam> Cyril: so t and xywh should be reserved?
00:16:10 <heycam> heycam: just reserve "t=" and "xywh="
00:16:20 <heycam> Cyril: in Media Fragments you have four dimensions. how does ID work?
00:16:24 <heycam> silvia: nobody has implemented that
00:16:46 <heycam> … the way we envision it is that some containers define names for sections, it's like imagine having a WebVTT chapter file in a webm file, and you have names for sections of the video file
00:16:56 <heycam> … and you can use the chapter name to address the chapter
00:17:00 <heycam> Cyril: what's the syntax?
00:17:01 <konno> konno has joined #svg
00:17:03 <heycam> silvia: id=string
00:17:20 <heycam> Cyril: so it's not "#<string>" it's "#id=<string>"
00:17:21 <heycam> silvia: yes
00:18:07 <heycam> krit: for SVG would it be a difference to support #<element> compared to #id=<element>?
00:18:09 <heycam> Cyril: the question is how to combine them
00:18:22 <heycam> … once you start using a freeform name, you can't use an "&" and follow it with another dimension
00:18:41 <heycam> silvia: we wanted to be able to support multiple dimensions; choose this one video segment (temporal), and then choose a spatial area
00:18:52 <heycam> … that's why we defined the parsing for these media fragments
00:18:58 <heycam> … if you don't do that from the start it's difficult to post-fit it
00:19:13 <heycam> … your selectors are functions?
00:19:26 <heycam> … you could do something like "#mediafrag(xywh=…)" to be compatible
00:19:44 <heycam> Cyril: you'd have to treat SVG differently then
00:19:51 <heycam> … sometimes you don't know what the type of the resource is
00:19:58 <heycam> krit: do all media fragments require an equals sign?
00:19:59 <heycam> silvia: yes
00:20:02 <heycam> krit: then it's probably fine
00:20:05 <heycam> … we shouldn't need to have #mediafrag
00:20:44 <heycam> Cyril: we could disallow ampersand in SVG IDs, then it combines well here
00:21:11 <heycam> krit: media fragments in HTML, if you have <img src="blah#xywh=…"> you would have the same problem yes?
00:21:28 <heycam> silvia: on HTML pages it's difficult, since HTML has specified the way a fragment is interpreted
00:21:49 <heycam> … often you have a custom web site, e.g. in YouTube you can have similar time offsets with fragments
00:21:59 <heycam> … but that's not what we've standardised for
00:22:03 <heycam> … we've done this only for media files
00:22:07 <heycam> … HTML is a different media type
00:22:16 <heycam> krit: depends on the MIME type of the document you reference?
00:22:17 <heycam> silvia: yes
00:22:22 <heycam> … that's how the URL specification has defined fragments to work
00:22:42 <heycam> krit: so we need to specify how SVG's fragments are interprted
00:22:47 <heycam> s/interprted/interpreted/
00:23:18 <heycam> krit: the timing fragments are useful in SVG too yes/
00:23:22 <heycam> ed: we should define how that works
00:23:31 <heycam> birtles: we've said for Web Animations we want this to work
00:23:41 <heycam> … would be good if this worked for HTML containing documents with animations as well as SVG
00:23:53 <heycam> Cyril, http://www.w3.org/TR/2006/REC-xml-20060816/#NT-Name
00:24:35 <heycam> dino: Cyril is asking how you distinguish #t=… from normal ID references in HTML
00:25:04 <heycam> Cyril: if HTML doesn't use the same solution as us, disallowing "&" and "=", it wouldn't be good
00:25:26 <heycam> krit: same problem with SVG in HTML, the MIME type is text/html, and the fragments would work differently
00:25:37 <heycam> silvia: the HTML MIME type does not support media fragments
00:25:39 <heycam> Cyril: yet?
00:25:43 <heycam> silvia: I think it's unlikely
00:25:51 <heycam> ed: but if we have Web Animations it might be useful
00:26:09 <heycam> silvia: we discussed xywh for HTML, it might be an interesting feature, but the HTML WG should discuss that
00:26:24 <heycam> Cyril: so should we aim for alignining with other media-like resources, or what HTML supports?
00:26:33 <heycam> silvia: I'd go with both strategies
00:27:05 <heycam> … I would want to be as much compatible with that spec as possible, and when SVG goes forward have its MIME type define how media fragments work, it's a bigger argument for HTML to support it
00:27:15 <heycam> … I don't think this will break SVG documents, but with HTML it could well break pages
00:27:30 <heycam> … people might have used #t= to mean something different on HTML pages
00:27:40 <heycam> … I would orient myself towards that problem, but rather being compatible with other media files
00:27:51 <heycam> krit: so Media Fragments defines how xywh are parsed, why do we need to define that in SVG?
00:28:00 <heycam> Cyril: we just need to say image/svg+xml follows media fragments
00:28:00 <heycam> silvia: right
00:28:11 <heycam> … the Media Fragments working group was bound by the URL specification
00:28:21 <heycam> … fragments are defined interpreted based on the mime type
00:28:29 <heycam> … we didn't want to have to deal with all of the mime types around, just video
00:28:45 <heycam> krit: SVG is still based on IRI, which should allow more characters
00:28:54 <heycam> silvia: it's not a problem; we wrote the spec to be based on UTF-8
00:29:01 <heycam> … the only place where it really mattered was the chapter names, named references
00:29:27 <heycam> heycam: I think the URL Standard is meant to supersede IRIs
00:30:59 <heycam> Cyril: I think I'm fine with the group saying we adopt media fragments, and we restrict our IDs not to include xywh=, ampersands, etc.
00:31:13 <heycam> … and then later can coordinate with HTML WG to see if it's possible for them to support this too
00:32:09 <heycam> silvia: one part of the Media Fragments spec has been included in HTML; it defines how time offsets in videos are interpreted
00:32:30 <heycam> Cyril: if you put t=15 does the document timeline start at 0?
00:32:33 <heycam> birtles: it does a seek
00:32:37 <heycam> … then we need to add automatic pausing
00:32:57 <heycam> RESOLUTION: SVG 2 will use Media Fragments.
00:33:52 <heycam> ACTION: Cyril to add Media Fragments support to SVG 2.
00:33:52 <trackbot> Created ACTION-3442 - Add Media Fragments support to SVG 2. [on Cyril Concolato - due 2013-02-14].
00:34:38 <heycam> Cyril: is #svgView(viewBox()) the same thing as #xywh?
00:34:40 <heycam> ed: not quite
00:35:35 <heycam> ACTION: Brian to define how #t= is interpeted in Web Animations.
00:35:35 <trackbot> Created ACTION-3443 - Define how #t= is interpeted in Web Animations. [on Brian Birtles - due 2013-02-14].
00:36:25 <heycam> … percentages will be different
00:36:45 <heycam> krit: for #xywh these reference the original viewport
00:37:49 <heycam> Topic: SVG/CSS Matrix harmonisation
00:38:08 <heycam> krit: we have a new function that gets the transform between two elements
00:38:12 <heycam> … I think this will be harder with CSS transforms
00:38:16 <heycam> … since they have 3d transforms
00:38:26 <heycam> … and it's not really possible to get a transformation matrix over this flattening
00:38:33 <heycam> … the question is how do we want to solve this
00:38:39 <heycam> … and second, it returns an SVGMatrix which is 2D
00:38:42 <heycam> … it's not applicable for this
00:38:49 <heycam> … it should return something that can represent 3D matrices
00:38:53 <heycam> … I spoke with Dean about flattening
00:39:01 <heycam> … we think that it should either give you an exception, a null matrix back...
00:39:10 <heycam> … somethign that indicates it's not possible to get the transformation
00:39:15 <heycam> … something to be resolved is the return type
00:39:25 <heycam> … we would need to specify a new matrix
00:39:28 <heycam> … CSS Transforms had a spec for it
00:39:40 <heycam> … which needed to be removed, since uses CSS OM
00:39:44 <shanestephens_> shanestephens_ has joined #svg
00:39:45 <heycam> s/since/since it/
00:39:49 <heycam> … Dean proposed Matrix4x4
00:39:58 <heycam> … we didn't know at this time where it should live -- maybe in ECMAScript?
00:40:00 <heycam> … on the window object
00:40:03 <heycam> … what does it look like?
00:41:19 <krit> http://lists.w3.org/Archives/Public/public-fx/2012JanMar/0007.html
00:41:49 <heycam> krit: there were some discusisons about whether it should work with Euler coordinates
00:42:05 <heycam> dino: there was some discussion that day in the SVG meeting about this
00:42:08 <heycam> … which I never followed up on
00:42:23 <heycam> … I think it was about whether to use radians or degrees
00:43:08 <heycam> … we have methods on here for both modifying the matrix and returning a new one
00:43:17 <heycam> … the other big discussion was someone suggested it should really be an ECMAScript type
00:43:35 <heycam> … someone else discussing whether it shouldn't have all those exposed as attributes, it should be a typed array with a wrapper of some sort
00:43:41 <heycam> krit: they wanted to use it with WebGL as well
00:43:44 <heycam> … which needs to be fast
00:43:55 <heycam> dino: that's why I have copyIntoFloat32Array
00:44:14 <heycam> … but you might not want to call this function each time
00:44:27 <heycam> heycam: I don't think there's a concept of live typed arrays is there?
00:44:44 <heycam> dino: I think the suggestion was to have the typed array backing the matri
00:44:46 <heycam> s/matri/matrix/
00:44:56 <heycam> … there would be an attribute to access that matrix backing data directly
00:45:12 <heycam> … in WebGL it would just be a matter of getting that out, instead of constantly creating new typed arrays
00:45:27 <heycam> … we didn't really have strong drive to get this happening quickly
00:45:33 <heycam> … but I think we do now, now that the spec is closer to completion
00:46:00 <heycam> heycam: makes you think well then why not about Points, etc.
00:46:11 <heycam> dino: I think that's why it wouldn't make sense to send it to ECMA
00:46:17 <heycam> … if we just have Matrix
00:46:32 <heycam> dino: there is still more work to do with improving SVG DOM interfaces
00:46:45 <heycam> … should we add something now to expose 4x4 matrices
00:46:52 <heycam> … or have conversion functions separate from the SVG DOM
00:47:13 <heycam> heycam: could we not replace SVGMatrix with Matrix4x4?
00:47:14 <heycam> dino:  that was the idea
00:47:40 <heycam> krit: we got everything from SVGMatrix on Matrix4x4, then we make SVGMatrix inherit from this one
00:48:02 <heycam> … there are some things that need to be in SVGMatrix
00:48:21 <heycam> http://www.w3.org/TR/SVG/coords.html#InterfaceSVGMatrix
00:49:31 <heycam> krit: there are SVGExceptions being thrown
00:49:35 <heycam> heycam: that's gone in SVG2
00:49:43 <heycam> dmitry: nobody uses skews
00:49:54 <heycam> cabanier: why does this issue keep coming up then?
00:50:00 <heycam> krit: Mozilla found some pages that did use skew
00:50:08 <heycam> dino: people use it for horrible fake 3d, isometric
00:50:24 <heycam> dmitry: we should encourage them to not do this by not having it in the specification
00:50:40 <heycam> cabanier: I know people use skew a lot in animations for fake 3d
00:50:47 <heycam> krit: we could strongly ask people not to use it...
00:51:20 <heycam> dmitry: it should be easier to make beautiful things, not just easier to make ugly things too
00:51:44 <heycam> krit: we could have them be deprecated but browsers still implement it
00:53:14 <heycam> dino: I don't think we can remove skews from transform syntax any more
00:53:19 <heycam> … do we need to expose them in this interface?
00:53:21 <heycam> krit: yes
00:53:28 <heycam> dino: sounds like we do if we want to replace SVGMatrix with Matrix4x4
00:54:17 <heycam> ed: so do we need to fix this in SVG2?
00:54:24 <heycam> krit: do we want to go with this new interface? I think yes
00:54:36 <heycam> … if it should live in ECMA we can worry about that later
00:54:56 <heycam> … whether it should go on window I asked the CSS group for approval
00:55:33 <heycam> heycam: I think just leave it not [NoInterfaceObject]
00:55:43 <heycam> krit: which spec should it live in? a new one?
00:55:53 <heycam> cabanier: Canvas references SVGMatrix, would be nice to reference this intead
00:55:56 <heycam> s/intead/instead/
00:56:59 <heycam> krit: what happens if you have a 3D transform on canvas?
00:57:46 <heycam> heycam: who should write this Matrix4x4 spec?
00:57:51 <heycam> krit: have to ask first, but I will probably do it
00:58:52 <heycam> dino: what about the name Matrix4x4?
00:58:54 <heycam> heycam: eh...
00:59:04 <heycam> dino: GL calls them matrix4, vec3, etc.
01:01:40 <heycam> krit: i prefer Matrix to Matrix4x4
01:01:50 <heycam> heycam: should Matrix replace SVGMatrix, or SVGMatrix inherit?
01:02:13 <heycam> ed: I don't think it's common for people to rely on "[object SVGMatrix]" being the actual object type
01:02:21 <heycam> krit: ok, just replace SVGMatrix with the new Matrix then
01:02:30 <heycam> ed: as long as we have the same method names I think it should be fine
01:02:44 <heycam> RESOLUTION: SVG 2 will reference the new Matrix specification and replace SVGMatrix with Matrix, once that spec is ready.
01:03:01 <heycam> ACTION: krit to write up a spec for Matrix
01:03:01 <trackbot> Error finding 'krit'. You can review and register nicknames at <http://www.w3.org/Graphics/SVG/WG/track/users>.
01:03:05 <heycam> ACTION: dirk to write up a spec for Matrix
01:03:06 <trackbot> Created ACTION-3444 - Write up a spec for Matrix [on Dirk Schulze - due 2013-02-14].
01:03:50 <heycam> ACTION-3444: Also update SVG 2 to reference the spec when it's ready.
01:03:51 <trackbot> Notes added to ACTION-3444 Write up a spec for Matrix.
01:04:51 <heycam> Topic: Changes to Filter Effects and Custom Filters
01:05:03 <krit> https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/index.html#custom-filter
01:06:40 <heycam> krit: custom filters are used with CSS shaders
01:06:54 <heycam> … so that you can apply some distortion/modification to the graphics
01:09:44 <heycam> … in the old specification, the syntax was "custom(url('vertexshader') mix(url('fragmentshader') multiply src-over), 4 4 attached, param1 value1, param2 value2)"
01:10:00 <heycam> … it's very long, hard to read, and only supports GLSL
01:10:08 <heycam> … MS asked us to make it more generic to support other shader languages
01:10:42 <heycam> … one idea is "custom()" references an at-rule
01:10:59 <heycam> … @filter f1 { … }
01:11:15 <heycam> … but this does not support animations
01:11:53 <heycam> dino: you could have @filter f2 {  … } and animate between f1 and f2
01:12:05 <heycam> krit: we wanted to try to keep it simple
01:12:13 <heycam> … the @filter rule tries to emulate @font-face
01:12:33 <heycam> … so it has a 'src' attribute, and you can provide a type
01:14:05 <heycam> … src: url(…) format("x-shader/x-vertex")
01:14:47 <heycam> heycam: these are just hints not to download, like @font-face?
01:14:53 <heycam> krit: no it's different from font-face
01:14:57 <heycam> … you need all of these resources
01:15:19 <heycam> … there's also "geometry: grid(4,4);"
01:15:55 <heycam> … and "margin: …;" like a filter primitive margin
01:16:04 <heycam> … and "parameters: …;" for the parameters to the shader programs
01:16:15 <heycam> … so what happens with different shader formats.
01:16:28 <heycam> … the @filter defines a generic primitive, so this is not limited to CSS Shaders
01:17:04 <heycam> … if you don't support GLSL, we'd suggest a new media query
01:17:13 <heycam> … @media (filter: glsl) { … }
01:17:37 <heycam> … so other browser could define new properties on the at rule
01:17:44 <heycam> ed: what is the point of the format() yet?
01:18:11 <heycam> krit: in case there is a new shader type under GLSL
01:18:42 <heycam> dino: WebGL defines a restricted version of GLSL
01:18:46 <heycam> … it's not strictly GLSL
01:18:52 <heycam> krit: maybe this keyword could be "WebGL" then
01:18:55 <heycam> … we can think about that later
01:19:13 <heycam> ed: so you have src with format()s in case you support more shader types later?
01:19:25 <heycam> krit: also you could reference an SVG filter here
01:20:45 <heycam> <filter id="f2">
01:20:55 <heycam>   <feOffset dx="var(x1)" dy="var(x2)"/>
01:20:57 <heycam> </filter>
01:21:07 <heycam> … something like SVG Parameters or CSS Variables
01:21:14 <heycam> … the custom() function would then reference f2
01:22:01 <heycam> s/f2/a filter at-rule that references the SVG filter/
01:22:43 <heycam> @filter g2 { src: url(#f2) format('svg'); parameters: x1 30, x2 30; }
01:23:06 <heycam> filter: custom(g2, x1 20, x2 20);
01:23:36 <heycam> ed: what is the var() syntax there? is that defined somewhere?
01:23:46 <heycam> krit: we're not going to put that in the first version of the spec
01:23:54 <heycam> … since it's not clear how Parameters / CSS Variables is working in SVG yet
01:24:06 <heycam> … but this is how custom SVG filters can be animated in the future
01:24:31 <heycam> ed: it might be useful to be able to pass in the document time into the filter
01:25:59 <heycam> krit: we can think about that for v2
01:26:56 <heycam> heycam: I find it a bit strange that format() in src works differently from in @font-face
01:30:33 <heycam> krit: what if we rename "src" to "filter-src"?
01:30:46 <heycam> heycam: maybe… it might be the combination of "src" and "format()" that looks to me like formats are hints to avoid downloading
01:31:02 <heycam> … why require format() at all given you can look at the actual served Content-Type?
01:31:12 <heycam> krit: servers might not set that correctly
01:31:20 <heycam> dino: there's not even a standardised extension for these files
01:31:27 <heycam> … what if you reference from the local file system
01:32:47 <heycam> heycam: what is the advantage of 'src' having the same format across different shading language @filter rules?
01:33:24 <heycam> dino: the source language format is the thing most likely to change
01:33:40 <heycam> … geometric, margin, parameters make sense with other shader languages too
01:33:58 <heycam> krit: so are people happy with @filter rule?
01:34:21 <heycam> heycam: I like it more than stuffing everything in to the property
01:35:08 <heycam> … what about the src descriptor, people want a different name?
01:35:24 <heycam> Cyril: you plan to have different mime types for vertex vs fragment shaders?
01:35:27 <heycam> krit: it's the case already
01:35:32 <heycam> … that's defined by WebGL
01:36:38 <heycam> Cyril: is the mime type registered?
01:36:51 <heycam> dino: x-shader/* is not registered, but someone would have written something down somewhere
01:38:19 <heycam> heycam: for me, you don't need to rename src for now…
01:38:59 <heycam> RESOLUTION: Filter Effects changes to use @filter.
01:39:47 <heycam> -- lunch break one hour --
02:39:20 <krit> krit has joined #svg
02:42:28 <silvia> silvia has joined #svg
02:43:33 <stakagi> stakagi has joined #svg
02:44:12 <shanestephens_> shanestephens_ has joined #svg
02:44:38 <cabanier> scribenick: cabanier
02:45:22 <cabanier> heycam: filter media query feels different from other media queries
02:45:34 <cabanier> …since those are properties of the device
02:45:46 <cabanier> ed: maybe @supports?
02:46:14 <cabanier> heycam: so you could write '@support filter(glsl)'
02:46:28 <cabanier> … the syntax is extended but not implement
02:46:41 <cabanier> krit: yes, that seems better
02:46:52 <cabanier> .. I'm OK with that
02:46:59 <cabanier> s/../...
02:47:19 <cabanier> heycam: at some point there will be @supports for @-rules
02:47:35 <cabanier> krit: inside the rule?
02:47:51 <cabanier> heycam: you could then have:
02:48:21 <cabanier> … atrule(filter, src:… format('x-shader')
02:48:38 <cabanier> … the normal properties just check if they parse correctly
02:48:55 <cabanier> … so maybe it's not quite right, but I'd be happy
02:49:16 <cabanier> … Maybe email www-style
02:49:53 <cabanier> action: Dirk to email www-style about at-supports filter function
02:49:53 <trackbot> Created ACTION-3445 - Email www-style about at-supports filter function [on Dirk Schulze - due 2013-02-14].
02:50:21 <cabanier> krit: is @filter-rule fine?
02:50:40 <cabanier> ed: are there other possibilities
02:50:54 <cabanier> … is everything of the previous syntax possible
02:50:59 <cabanier> krit: yes
02:51:32 <cabanier> cabanier: even animations:
02:51:50 <cabanier> heycam: that's for the @media part no the rule
02:51:57 <cabanier> s/no/not
02:52:54 <cabanier> krit: do we need a new resolution?
02:53:03 <cabanier> heycam: can you do the same as before?
02:53:07 <cabanier> krit: yes
02:53:50 <cabanier> resolution: accept proposed descriptors for at-filter rule
02:54:07 <krit> s/resolution/RESOLUTION/
02:54:18 <cabanier> topic: CSS OM and SVG DOM improvements; exposing calc values
02:54:50 <cabanier> heycam: the question is if we support css lenght and how we reflect that in svg
02:54:59 <cabanier> … Dirk, did you add it already?
02:55:27 <cabanier> krit: yes. as unknown because we don't want to expose the CSS OM
02:55:56 <krit> s/expose the CSS OM/extend SVG DOM at this time/
02:56:02 <cabanier> heycam: so, there are a few new unit types such as rem, vw, vh, ch, etc
02:56:21 <cabanier> ….rem is default font size
02:56:38 <cabanier> shanestephens_:  it's to do layout based on the font
02:56:53 <cabanier> heycam: for instance to do margins
02:57:03 <cabanier> shanestephens_: MDN has a good description
02:57:11 <cabanier> heycam: we want to support all of those
02:57:35 <cabanier> … my question was that we want to add accessors for all of those
02:57:55 <cabanier> krit: should make it so that it becomes more extensible
02:58:03 <cabanier> heycam: you could use named properties
02:58:20 <cabanier> … that makes it open ended. But you'd have to update the spec
02:58:32 <cabanier> ed: that makes it more clear that the spec is going to be extended
02:58:55 <cabanier> … having a group of names makes that more clear
02:59:36 <cabanier> … the spec refer to the group of supported unit types in CSS
03:00:04 <cabanier> heycam: named properties would require slightly different implementation
03:00:15 <cabanier> … but I like them to be visible in IDL
03:00:31 <cabanier> ed: as long as the spec is clear that they can be updated, it's fine by me
03:00:51 <cabanier> heycam: I think we want an accessor so you can set it by string
03:01:14 <cabanier> … .x.? to get the string value
03:01:53 <cabanier> … to write or read the string
03:02:31 <cabanier> … .value ?
03:02:36 <cabanier> shanestephens_: I like that
03:02:45 <cabanier> … value would be a strange name for a unit
03:03:46 <cabanier> resolution: add a 'value' attribute to read or write the CSS serialization of a unit lenght
03:04:06 <cabanier> s/resolution/RESOLUTION
03:04:19 <Cyril> RRSAgent, draft minutes
03:04:19 <RRSAgent> I have made the request to generate http://www.w3.org/2013/02/06-svg-minutes.html Cyril
03:04:24 <cabanier> s/lenght/length
03:04:27 <krit> s/resolution/RESOLUTION/
03:04:59 <cabanier> heycam: there are values like 'calc' and 'attr'
03:06:03 <cabanier> krit: x = attr('x')
03:06:20 <cabanier> heycam: that would work
03:06:40 <cabanier> krit: that depends on the css syntax so it would not fail parsing
03:07:07 <cabanier> heycam: no. that would not be a problem.
03:07:28 <cabanier> … you can have a property to looks at attr(style) and that would fail to parse
03:07:48 <cabanier> … do we want calc and attr and var to work in SVG?
03:07:51 <cabanier> krit: yes
03:08:11 <cabanier> heycam: and have them work on x and y to work on CSS
03:08:28 <cabanier> shanestephens_: if something is a calc?
03:08:39 <thorton> thorton has joined #svg
03:08:45 <cabanier> heycam: you can still look at 'px'
03:09:04 <cabanier> … should there be an accessor to get the calc value?
03:09:39 <cabanier> shanestephens_: we have a lot of experience with polyfill and we spend a lot of javascript mimicing value parsing
03:09:51 <cabanier> … web animations has a calc in javascript parser
03:10:29 <cabanier> heycam: the other half is how this is reflect in SVG length
03:10:46 <cabanier> … and follow Dirk's example to reflect them as unknown values
03:11:22 <cabanier> ed: yes, that is the only reasonable value
03:12:25 <cabanier> action: heycam add a string accessor on SVG animated length and to make 'calc', 'attr' and 'var' work
03:12:25 <trackbot> Created ACTION-3446 - Add a string accessor on SVG animated length and to make 'calc', 'attr' and 'var' work [on Cameron McCormack - due 2013-02-14].
03:13:30 <cabanier> heycam: I changed the spec that if there is a list, you just set the first value
03:13:37 <cabanier> … if there is no value, we add one
03:13:50 <cabanier> ed: sounds reasonable
03:14:07 <cabanier> heycam: I didn't add anything to SVGAnimatedAngle
03:14:25 <cabanier> … since noone is really using that one
03:14:36 <cabanier> … everyone uses the length one
03:14:47 <cabanier> cabanier: maybe better to be consistent
03:14:52 <cabanier> heycam: OK
03:15:55 <cabanier> action: heycam to update SVGAnimatedAngle as well
03:15:55 <trackbot> Created ACTION-3447 - Update SVGAnimatedAngle as well [on Cameron McCormack - due 2013-02-14].
03:21:00 <cabanier> topic: Web Animations
03:21:24 <birtles> https://dvcs.w3.org/hg/FXTF/raw-file/default/web-anim/index.html
03:21:53 <cabanier> birtles: there a 3 documents
03:22:00 <cabanier> s/a/are/
03:22:25 <cabanier> … the link is the core spec and the intent is to have 2 more document to map SVG and CSS features
03:22:41 <cabanier> … Is Tab's work available yet?
03:22:58 <cabanier> shanestephens_:  it's not quite ready, but I'll provide a link
03:24:43 <shanestephens_> This is a copy of the CSS integration document, but it does rely on features that are not yet firmed up in the core specification: https://docs.google.com/document/d/1CrfospthGnMg3tXmYYnZmRDE8Re-uL4mGkuSB0VPcTA/edit
03:25:01 <cabanier> birtles: we have f2f next week
03:25:11 <cabanier> shanestephens_: there's a few reasons that the spec is so big
03:25:30 <cabanier> … we need to provide IDLs and Brian added a lot of diagrams
03:25:39 <cabanier> … and complete descriptions of processes
03:26:13 <cabanier> … Also we have a fairly complete polyfill that is ony using 1700 lines of code
03:26:18 <cabanier> s/ony/only/
03:26:31 <cabanier> krit:  does the polyfill do synchronisation?
03:26:44 <cabanier> shanestephens_: yes, but it doesn't integrate with CSS and SVG
03:26:55 <cabanier> … but it works with other libraries
03:27:06 <shanestephens_> here is the polyfill: https://github.com/web-animations/web-animations-js
03:27:41 <cabanier> birtles: there's a skeleton for the SVG integration
03:27:49 <cabanier> … but don't even look at that
03:28:03 <cabanier> … I want to talk about scheduling
03:28:15 <shanestephens_> (actually it's now about 2200 lines)
03:28:21 <cabanier> … next week we have a f2f to fix remaining issues
03:29:21 <cabanier> … and then request FPWD
03:29:34 <cabanier> … there are 3 contentious features
03:29:58 <cabanier> shanestephens_: except for video, the main thrust of the doc is correct
03:30:35 <cabanier> birtles: the FX taskforce will be asked to review so we can publish it
03:30:48 <cabanier> … and we hope to do that at the end of next week
03:32:18 <cabanier> shanestephens_: the review will be 2 ways. People will either like it or there will be a lot of contentious issues
03:32:35 <cabanier> cabanier: probably have to ask each group for resolution
03:32:44 <cabanier> birtles: yes
03:33:06 <cabanier> dino: It would like to know what changed since I provided feedback
03:33:22 <cabanier> … a declarative form is more important and it's not in the document
03:33:42 <cabanier> … I notice that the template is taken so that's good
03:34:08 <cabanier> shanestephens_: for declarative, we would like to CSS animation, transition and SVG all work the same under the hood
03:34:11 <cabanier> dino:  yes
03:34:28 <cabanier> shanestephens_: so that in future version we can push more declarative markup in the spec
03:35:06 <cabanier> dino: OK. Then I have no problem with the model and it does a good job of describing what an animation engine does in a browser
03:35:22 <cabanier> … my concern is with the really big javascript API
03:35:54 <cabanier> … CSS transitions became popular because they're powerful without being complex
03:36:12 <cabanier> … people are hesitant for massive APIs
03:36:23 <cabanier> Cyril: authoring tools like it
03:36:34 <cabanier> shanestephens_: it's a lot smaller than SMIL
03:36:48 <cabanier> … the shim that we built is really quite small
03:36:59 <Cyril> s/authoring tools like it/authoring tools are missing/
03:37:18 <cabanier> … another things is that it provides a declarative view
03:37:42 <cabanier> … It's really very similar to CSS
03:37:58 <cabanier> … I understand that that doesn't address your concerns
03:38:08 <cabanier> … the polyfill is mostly for testing
03:38:22 <cabanier> s/poylfill/API/
03:38:40 <cabanier> krit: in theory SVG and CSS animations should have the same model under the hood
03:39:41 <cabanier> … the most important part is that this provides an animation model that is currently lacking in CSS
03:40:12 <cabanier> birtles: there's an appendix https://dvcs.w3.org/hg/FXTF/raw-file/default/web-anim/index.html#webidl-ref
03:40:23 <cabanier> dino: that's still really big
03:40:39 <cabanier> birtles: we can talk about things that shouldn't be exposed
03:40:59 <cabanier> dino: A lot of this stuff is needed
03:41:24 <cabanier> … an author wants to provide timing to a document
03:41:45 <cabanier> … he wants things to happen at certain times
03:42:08 <cabanier> … for example, read long books
03:42:21 <cabanier> … where we want something to happen at a certain time
03:42:53 <cabanier> … just that alone, is requested a lot more than low level access to an animation
03:43:07 <cabanier> … scrubbing animation, querying animations, etc
03:43:24 <cabanier> … but we get almost no request for something like this
03:43:50 <cabanier> shanestephens_: In Google we could use this a lot
03:44:07 <cabanier> dino: but most people want simple features
03:44:17 <cabanier> shanestephens_: chaining animations is low level?
03:44:32 <cabanier> dino: it would be great to have that.
03:45:02 <cabanier> … We're on the fence about that one
03:45:15 <cabanier> … I'm not saying not to provide this
03:45:31 <cabanier> … having such a massive API as step 1 seems too much
03:45:57 <cabanier> shanestephens_: Are you suggesting not to provide a JS API?
03:46:16 <cabanier> dino: no, put more emphasis on the integration specs
03:46:44 <cabanier> … step 1, describe the timing mode and the next step is to provide the integration spec
03:47:30 <cabanier> shanestephens_: we think that the most important thing is CSS and SVG animations use the same model
03:47:36 <cabanier> … so we agree with you
03:48:03 <cabanier> dino: I would like to solve of an author that want to make an animated page
03:48:19 <cabanier> … and this API is not a solution for that
03:48:29 <cabanier> birtles: yes, this is not for authors
03:48:45 <cabanier> dino: that is why I want those specs at the same time
03:49:07 <cabanier> shanestephens_: should we have the spec ready at FPWD time?
03:50:01 <cabanier> dino: yes, but not have such an extensive API
03:50:18 <cabanier> krit:  CSS animations and transitions need a model now
03:50:39 <cabanier> AlexD: maybe we need to split the APIs into a separate document
03:51:16 <cabanier> dino: ???
03:51:54 <cabanier> birtles: there is a way to split things up in 2 parts
03:52:47 <cabanier> dino: yes, the timing object would allow you to write your animations
03:52:54 <Cyril> q+
03:52:57 <cabanier> birtles: that concept is already there
03:53:06 <cabanier> shanestephens_: that sounds exciting
03:53:23 <cabanier> … do you think the CSS WG would go for that
03:53:51 <cabanier> dino: if you have a class '::timeactive'
03:54:11 <cabanier> … and have a CSS animation in there
03:54:18 <cabanier> … that would be very powerful
03:54:30 <cabanier> birtles: we can do a timesheet
03:54:37 <cabanier> … and I would love to do that
03:54:53 <cabanier> shanestephens_: so we should split the IDL off and into 2 pieces
03:55:45 <cabanier> Cyril: yes, the size is an issue
03:56:11 <cabanier> … maybe splitting the spec in separate documents
03:56:19 <cabanier> birtles: I don't know how that would help
03:56:40 <cabanier> Cyril: setting time in a document is useful by itself with no animations
03:56:58 <cabanier> … media elements could be hooked to that
03:57:06 <cabanier> birtles: those use cases are already met
03:57:13 <cabanier> … you can have a media element
03:57:28 <cabanier> Cyril:  you can't have frame accuracy today
03:57:43 <cabanier> … so maybe one step is solve this problem
03:57:58 <cabanier> birtles: it's hard to prioritize
03:58:07 <cabanier> … I'm happy to split the API up
03:58:09 <silvia> q+
03:58:21 <cabanier> … with regards to the size, we can work on that
03:58:37 <konno_> konno_ has joined #svg
03:58:46 <cabanier> … but our problem is that we want to harmonize CSS and SVG
03:59:01 <cabanier> … and we're cutting out a bunch from SMIL already
03:59:10 <cabanier> … so, it will always be big
03:59:34 <cabanier> Cyril: how can you integrate inconsistent models?
03:59:59 <cabanier> … if you map the models, will it break anything?
04:00:05 <konno__> konno__ has joined #svg
04:00:05 <cabanier> birtles: no
04:00:17 <cabanier> shanestephens_: CSS is underspecified
04:00:28 <cabanier> birtles: and inconsistently implemented
04:00:47 <birtles> (that is, some details of SVG are inconsistently implemented)
04:00:54 <cabanier> shanestephens_: would it be OK to delay ::timeactive?
04:01:00 <cabanier> … or can we do that later
04:01:14 <cabanier> dino: I would like to have that now and can write something up
04:01:26 <shanestephens_> s/can we do that later/should we do that now/
04:01:31 <cabanier> … it would be very useful to a lot of people without exposing a large API
04:01:49 <birtles> Zakim, who is on the queue?
04:01:49 <Zakim> I see Cyril, silvia on the speaker queue
04:02:03 <cabanier> … I would like to reimplement CSS animations in WebKit with your spec
04:02:27 <cabanier> … take canvas for instance that took 8 years and only 2 classes
04:02:30 <Cyril> ack
04:03:05 <cabanier> silvia: introducing a big new feature using CSS, SVG and even HTML, how much overlap is there with HTML?
04:03:38 <cabanier> … also when you're introducing this big thing, it's not enough and too much. Since people come with their own angles
04:04:07 <cabanier> … for an HTML person it's not enough but the spec is too big
04:04:20 <cabanier> … splitting it into more document will help
04:04:46 <cabanier> … also providing examples and summaries is very helpful since it's too hard to digest
04:05:01 <cabanier> birtles: there are no changes to HTML
04:05:21 <cabanier> … just additions to document and element interfaces
04:06:25 <cabanier> silvia: how about animateColor. That is in the spec
04:06:32 <cabanier> birtles: that's surprising
04:07:11 <stakagi> stakagi has joined #svg
04:07:23 <cabanier> shanestephens_: it's tricky
04:07:32 <cabanier> … people say it's too much but want more features
04:07:58 <krit1> krit1 has joined #svg
04:08:12 <cabanier> … we should stick to the brief that we want to unify CSS and SVG animation model
04:08:40 <cabanier> silvia: the minute you introduce the API you can animate an HMTL page
04:09:37 <cabanier> Cyril: I want to make sure that we can integrate with media elements
04:09:56 <cabanier> silvia: you can touch the HTML spec if it's needed
04:10:11 <cabanier> … there's an interface that will be needed
04:10:32 <cabanier> dino: <par> and <seq> would be nice to have in the document
04:10:50 <cabanier> … and it's simpler than javascript
04:11:04 <cabanier> … I would like to style animation
04:11:19 <cabanier> shanestephens_: what is the next step?
04:11:26 <cabanier> … we're working on this full time
04:11:39 <cabanier> … and a lot of engineering time to make this happen
04:12:04 <cabanier> dino: where do we want to be in order to make a first draft
04:12:57 <cabanier> … I think the integration document is the most useful
04:13:09 <cabanier> birtles: how can you have that without a model?
04:13:26 <cabanier> ed: yes, I would like the integration specs first
04:13:52 <cabanier> silvia: I would like to see the markup to see what you're trying to do
04:13:59 <cabanier> shanestephens_: this doesn't really apply here
04:14:43 <cabanier> … providing examples in markup will not do
04:15:07 <cabanier> krit1: it seems like we're going in circles
04:15:25 <cabanier> Cyril: everyone agrees that there should be a unified model
04:16:13 <cabanier> … at a minimum we should have the model and integration with CSS
04:16:35 <cabanier> krit1: are timesheets important?
04:16:45 <cabanier> dino: I would like to
04:16:58 <cabanier> … I think those are more important
04:17:08 <cabanier> birtles: I think we can already do that
04:18:06 <nikos1> nikos1 has joined #svg
04:18:59 <cabanier> Cyril: I would like to integrate with media elements
04:20:13 <ed> -- 15min break --
04:45:04 <glenn> glenn has joined #svg
04:47:09 <glenn_> glenn_ has joined #svg
04:47:57 <glenn> glenn has joined #svg
04:49:11 <glenn_> glenn_ has joined #svg
04:53:16 <shanestephens_> shanestephens_ has joined #svg
04:54:29 <stakagi> stakagi has joined #svg
04:55:33 <heycam> ScribeNick: heycam
04:56:27 <heycam> Topic: Web Animations continued
04:57:24 <glenn> glenn has joined #svg
04:57:25 <heycam> shanestephens_: I had a suggestion that we could keep the parts of the IDL that expose the behaviour of animations generated by CSS and SVG, and remove parts of the IDL that let you create content through js
04:57:29 <heycam> … so we can test the CSS and SVG are in the same model and are the same thing
04:57:39 <heycam> … and then cyril can go forward with animations in HTML
04:57:45 <heycam> … and dean can go forward with timesheets
04:58:02 <heycam> … and we can look at completing the js api
04:58:08 <heycam> … I think Brian is interested in adding functionality to SVG
04:58:12 <heycam> birtles: I'll work on SVG integration
04:58:29 <heycam> shanestephens_: v1 of the document can be the model, CSS integration, SVG integration, and just enough IDL to confirm that all of the timing parameters of the model are working correctly
04:58:39 <heycam> Cyril: a browser will be compliant to the standard if it exposes the right objects with the right values at the right time
04:59:06 <heycam> shanestephens_: that's pretty much all we care about. functionally that the two specs are aligned.
04:59:18 <heycam> birtles: I don't really like exposing a read only model like that. I think we should split the API into a separate spec.
04:59:33 <heycam> shanestephens_: it wouldn't have to be read only, but you'd need to leave out things like play()
05:00:00 <heycam> shanestephens_: the only problem I have with splitting out the API is that it leaves nothing testable
05:00:05 <heycam> … and if it's not testable, it can't be a spec
05:00:39 <heycam> birtles: maybe that's OK
05:00:45 <heycam> … and we publish the API later and test that
05:01:29 <heycam> dino: the model could go onto the REC track
05:01:52 <heycam> s/the model could/a NOTE can/
05:02:06 <heycam> birtles: I think we can still work on the API spec, it's not sidelined
05:02:13 <heycam> … I think we're going to implement it anyway, just pref it off
05:02:34 <heycam> … just having a read only API doesn't meet those use cases
05:02:41 <heycam> shanestephens_: why do we want to get it to FPWD?
05:02:50 <heycam> birtles: I think we want to get rid of the animations stuff from SVG and point to this thing
05:02:57 <heycam> … that's where this whole discussion is going in terms of FPWD
05:03:00 <heycam> … is this going to be a problem for SVG?
05:03:05 <heycam> … SVG is moving along, and this one is slowing down
05:03:11 <heycam> … we've got to work out how to solve that
05:03:16 <heycam> shanestephens_: if we make it a NOTE would that work?
05:03:31 <heycam> birtles: we still have the SVG integration document and that will be referenced by SVG 2
05:04:12 <heycam> shanestephens_: the CSS integration document will only allow you to test that CSS transitions
05:04:23 <heycam> birtles: what's the whole point of having a unified model, to think out loud?
05:04:30 <heycam> silvia: from what I'm hearing, you can't have a unified model without the JS API?
05:04:36 <heycam> shanestephens_: you can't test that it exists without a handle on it
05:04:47 <heycam> … another way forward would be as part of the spec, specify some interoperability primitives between SVG and CSS
05:05:01 <heycam> … so have some SVG animations using CSS key frames for example, and vv
05:05:07 <heycam> … but that's getting in to new features
05:05:45 <heycam> heycam: you could test how CSS and SVG animations interact
05:06:05 <heycam> shanestephens_: so a model document that says how CSS and SVG animations exist in the model and how they interact
05:06:09 <heycam> … then you can test the results of that
05:06:58 <heycam> birtles: this is not testing much of the animation model
05:07:06 <heycam> shanestephens_: can we just expose TimedItem?
05:07:16 <heycam> birtles: it's almost more meaningful to allow CSS animations to have an absolute start time
05:07:19 <heycam> … in terms of unifying the two
05:07:26 <heycam> … then at least you know they're working off the same clock
05:07:31 <heycam> shanestephens_: that doesn't make them interoperable at all though
05:07:43 <heycam> shanestephens_: exposing TimedItem as a r/w object...
05:07:47 <heycam> birtles: we could think about that next week
05:07:54 <heycam> … if you do that I think you might draw in the rest pretty quickly
05:10:38 <heycam> Cyril: you might want to see if people agree with the model by implementing something
05:12:25 <heycam> heycam: I think it would be fine to go along the REC track, perhaps with conformance classes on other specifications using the model spec
05:12:29 <heycam> … you don't need a test suite to pass CR
05:13:02 <heycam> … though you could just wait until you have feedback from implementors that they are happy with re-jigging their animation implementations in terms of the model
05:13:32 <heycam> shanestephens_: you could point to the API spec and suggest that as a way for them to test it internally
05:13:49 <heycam> silvia: people won't be excited about a model spec
05:14:00 <heycam> shanestephens_: I think we're pushing the model faster so that it can be normatively referenced
05:14:06 <heycam> … the API can still stay as an ED next to it and publicise it
05:14:22 <heycam> … brian, dean and I are the people likely to implement in 3/5 browsers, so it's not like the people who need to see this aren't seeing it
05:14:48 <heycam> Cyril: will MS start implementing this now that there's a unified model?
05:15:43 <heycam> dino: wonder if a polyfill running in IE is enough to count as an implementation
05:18:16 <heycam> Topic: Requirements reevaluation continued
05:18:18 <heycam>  [65] Have unknown elements treated as <g> for the purpose of rendering
05:18:34 <heycam> AlexD: useful for globalCoordinateSystem
05:19:10 <heycam> heycam: I've never been entirely comfortable with changing the behaviour here
05:19:13 <heycam> ed: I don't like it at all
05:19:23 <heycam> shanestephens_: Web Components is like a subset of unknown elements
05:19:28 <heycam> … is that going to end up in SVG as well?
05:19:47 <heycam> heycam: they rely on unknown elements being rendered?
05:19:52 <heycam> shanestephens_: we'd need to look at exactly what they rely on
05:19:57 <heycam> … it's only a subset of unknown elements <x-blah>
05:20:38 <krit> krit has joined #svg
05:21:05 <dmitry> *http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Commitments*
05:21:49 <heycam> heycam: it would be nice to have explicit wording about exactly what is required of unknown elements
05:22:07 <heycam> ed: I don't know if it makes sense to separate elements found outside of <text> from text content elements
05:22:12 <heycam> … that's what you typically get from unknown/fallback
05:22:25 <heycam> Cyril: in previous minutes we said it could be a fallback for connectors
05:22:41 <heycam> … a new implementation will implement connectors, and a previous one would ignore it
05:23:06 <heycam> krit: do we have something in mind that we want to add new graphical elements in the future?
05:23:38 <heycam> … if we wanted introduce a <brush> element as a new resource, this wouldn't work as expected
05:23:50 <heycam> … for browsers who implement this unknown element, they would render the <brush> contents
05:23:57 <heycam> … but those who do implement it would not render it
05:24:07 <heycam> ed: I think it makes more sense to ignore / not draw unknown content
05:24:13 <heycam> krit: I think it will harm more than solve problems
05:26:24 <heycam> RESOLUTION: We will drop the unknown-elements-are-rendered requirement from SVG 2.
05:26:36 <heycam> ACTION: Cameron to clarify the behaviour of unknown elements in SVG 2.
05:26:36 <trackbot> Created ACTION-3448 - Clarify the behaviour of unknown elements in SVG 2. [on Cameron McCormack - due 2013-02-14].
05:26:46 <heycam>  [66] Remove the requirement to have @width and @height on foreignObject
05:29:57 <shepazu> (I think this was a mischaracterization of the "unknown elements" proposal)
05:31:36 <heycam> heycam: this was to make foreignObject sized by shrink wrapping based on its contents
05:34:34 <heycam> dino: the width will be based on the viewport in HTML
05:34:50 <heycam> … doesn't make sense for it to be wider than that
05:35:02 <heycam> krit: once width and height are properties, we have the auto value
05:35:15 <heycam> … but we should keep the 0 width/height defaults
05:35:32 <heycam> heycam: it's not something I feel strongly about
05:35:46 <heycam> ed: I'm fine with not doing anything for this one
05:36:11 <heycam> RESOLUTION: We will drop the "foreignObject can be automatically sized" requirement for SVG 2.
05:36:24 <heycam>  [67] Improve the fallback mechanism using switch
05:36:45 <heycam> Cyril: is this similar to allowReorder?
05:36:56 <heycam> ed: this is how you treat unknown elements
05:37:13 <heycam> … if you want to switch on something that is a new element, then you won't check the conditional processing attributes
05:37:16 <heycam> … that's the issue
05:37:54 <heycam> … let's say we introduce a new <foo> element in SVG, in old user agents you'd still like to see if the new feature string is there, and do something special
05:38:01 <heycam> … <foo requiredFeatures="blah">
05:38:11 <heycam> heycam: you could just wrap it in a <g>
05:38:18 <heycam> ed: that's the workaround
05:38:24 <heycam> … maybe in some cases you don't want to have some wrapper element
05:38:39 <heycam> krit: if unknown elements are ignored, then you cannot reference it
05:38:42 <heycam> ed: render it
05:39:33 <heycam> heycam: I say just look at those conditional processing attributes if the element is in the SVG namespace
05:40:03 <heycam> ed: currently a <switch> would always pick an unknown element, since it is considered not to have any conditional processing attributes, and therefore passes the tests
05:40:52 <heycam> Cyril: you should never pick the element you don't know, what's the sense in that?
05:41:02 <heycam> ed: either you check the attributes you already know on SVG elements, or you just ignore them
05:41:08 <heycam> Cyril: so just remove it for the purpose of switch processing
05:41:53 <heycam> ed: the only way you can get what you want is to wrap it in a known SVG element
05:44:12 <heycam> ACTION: Erik to do the "Improve the fallback mechanism using switch" requirement.
05:44:12 <trackbot> Created ACTION-3449 - Do the "Improve the fallback mechanism using switch" requirement. [on Erik Dahlström - due 2013-02-14].
05:44:32 <heycam> RESOLUTION: Keep the "Improve the fallback mechanism using switch" requirement in SVG 2.
05:44:40 <heycam>  [68] Provide a way to control audio level and playback
05:45:02 <heycam> heycam: sounds like we should get this behaviour from the HTMLAudioElement interface
05:45:08 <heycam> … so I don't think SVG needs anything specific
05:45:34 <heycam> ed: the previous discussions didn't include <audio>, but I think they should be
05:47:31 <heycam> ACTION-3432: Should also add <audio>.
05:47:31 <trackbot> Notes added to ACTION-3432 Edit SVG 2 to add the iframe, canvas, video elements.
05:48:08 <heycam> RESOLUTION: The "Provide a way to control audio level and playback" SVG 2 requirement does not need any action, as we will get this functionality from HTMLAudioElement.
05:48:14 <heycam>  [69] Provide positioning information in MouseEvents
05:48:43 <heycam> AlexD: returning a user space position
05:49:32 <heycam> heycam: I thought I had a proposal on SVGPoint to get the UIEvent's position in a given element's coordinate space
05:49:46 <heycam> krit: I'd like to not encourage SVGPoint but rather a more general Point that's being discussed in CSS
05:50:34 <heycam> heycam: the problem is UIEvent is not really defined by use
05:50:36 <heycam> s/use/us/
05:51:21 <heycam> heycam: I'll take the requirement
05:51:40 <heycam> RESOLUTION: We will keep the "Provide positioning information in MouseEvents" requirement in SVG 2.
05:51:48 <heycam> ACTION: Cameron to do the "Provide positioning information in MouseEvents" SVG 2 requirement.
05:51:49 <trackbot> Created ACTION-3450 - Do the "Provide positioning information in MouseEvents" SVG 2 requirement. [on Cameron McCormack - due 2013-02-14].
05:51:55 <heycam>  [70] Support CSS3 Color syntax
05:52:05 <heycam> ed: this one already done
05:52:08 <heycam>  [71] Support CSS3 image-fit
05:52:17 <heycam> ed: got renamed to object-fit
05:52:36 <heycam> ed: I'll keep that, if I have the time to do it
05:53:05 <heycam> ACTION: Erik to do the "Support CSS3 image-fit" SVG 2 requirement.
05:53:05 <trackbot> Created ACTION-3451 - Do the "Support CSS3 image-fit" SVG 2 requirement. [on Erik Dahlström - due 2013-02-14].
05:53:12 <heycam> RESOLUTION: We will keep the "Support CSS3 image-fit" SVG 2 requirement.
05:53:15 <heycam>  [72] Make it easier to write a zoom/pan widget, possibly by adding convenience method to get scale/transfer
05:54:09 <heycam> heycam: so we discussed in zurich possibly extending CSS overflow and tying zoom/pan to that
05:54:12 <heycam> … Tab was interested in this
05:54:20 <heycam> … but it does not exist as a proposal yet
05:54:24 <heycam> … and needs more thought
05:54:38 <heycam> … I say defer unless there is a concrete proposal
05:54:41 <heycam> ed: yep
05:55:04 <heycam> RESOLUTION: We will defer the "Make it easier to write a zoom/pan widget" SVG 2 requirement unless a concrete proposal is forthcoming.
05:55:13 <heycam>  [73] Align with CSS Value and Units
05:55:23 <heycam> heycam: I'd like to take that one
05:55:32 <heycam> ACTION: Cameron to align SVG 2 with css3-values.
05:55:32 <trackbot> Created ACTION-3452 - Align SVG 2 with css3-values. [on Cameron McCormack - due 2013-02-14].
05:55:42 <heycam> RESOLUTION: We will keep the "Align with CSS Value and Units" SVG 2 requirement.
05:55:56 <heycam>  [74] Deprecate baseline-shift and use vertical-align
05:56:03 <heycam> heycam: contingent on me rewriting the whole Text chapter
05:56:08 <heycam> … I will keep it
05:56:19 <heycam> RESOLUTION: We will keep the "Deprecate baseline-shift and use vertical-align" SVG 2 requirement.
05:56:24 <heycam>  [75] Allow video elements to have captions, tracks, etc
05:56:27 <heycam> krit: I don't know why I put my name there
05:56:57 <heycam> heycam: should be part of Takagi-san's action, given he is adding <video>
05:57:12 <heycam> krit: so <track> and <source> would both be SVG elements as well
05:57:52 <heycam> ACTION-3432: Should also add <track> and <source>.
05:57:52 <trackbot> Notes added to ACTION-3432 Edit SVG 2 to add the iframe, canvas, video elements.
05:58:07 <heycam> RESOLUTION: We will keep the "Allow video elements to have captions, tracks, etc" SVG 2 requirement.
05:58:10 <heycam>  [76] Allow clip to reference any element
05:58:25 <heycam> heycam: Chris' name is on that currently
05:59:03 <heycam> krit: the problem is you have a <g> with a <rect>, why should that not clip while a plain <rect> would clip?
05:59:10 <heycam> … I don't think this would be a huge problem for anyone to implement
06:00:09 <heycam> heycam: if you have an existing shape, you don't want to duplicate it to put it in a <clipPath>
06:00:23 <heycam> krit: I'm not against it but I am not interesting in doing the spec work
06:00:27 <heycam> s/interesting/interested/
06:01:12 <heycam> cabanier: I will take it
06:01:31 <heycam> birtles: we already have a resolution to allow a <g> in a <clipPath>
06:02:16 <heycam> ACTION: Rik to allow the clip-path property to reference non-<clipPath> elements in SVG 2, and to allow <g> in a <clipPath>.
06:02:16 <trackbot> Created ACTION-3453 - Allow the clip-path property to reference non-<clipPath> elements in SVG 2, and to allow <g> in a <clipPath>. [on Rik Cabanier - due 2013-02-14].
06:02:28 <birtles> http://www.w3.org/2012/01/13-svg-irc#T03-58-11
06:02:28 <heycam> RESOLUTION: We will keep the "Allow clip to reference any element" SVG 2 requirement.
06:02:44 <heycam>  [77] Promote some attributes to properties
06:03:23 <heycam> krit: so this is just allowing auto for lengths etc.?
06:03:28 <heycam> heycam: this is the whole property promotion change
06:04:02 <heycam> … unless somebody puts their hand up, defer
06:04:18 <heycam> krit: leave it in the list and see if we have time for it later
06:04:56 <heycam> krit: I just know I won't have the time in the next few months to look at this, maybe after it
06:05:29 <heycam> heycam: how about I put your name next to it
06:05:30 <heycam> krit: ok
06:05:54 <heycam> ACTION: Dirk to do the "Promote some attributes to properties" SVG 2 requirement.
06:05:54 <trackbot> Created ACTION-3454 - Do the "Promote some attributes to properties" SVG 2 requirement. [on Dirk Schulze - due 2013-02-14].
06:06:05 <heycam> RESOLUTION: We will keep the "Promote some attributes to properties" SVG 2 requirement for now, and hope Dirk gets time to do it.
06:06:14 <heycam>  [78] Have an advance font metrics interface
06:06:28 <heycam> heycam: seems deferable to me
06:06:36 <heycam> dino: what does this mean? isn't there a measureText API in canvas?
06:06:40 <heycam> ed: that's usable for SVG as well
06:06:45 <heycam> ed: if we don't have to do anything that's good too
06:06:50 <heycam> cabanier: I'm not sure if people are happy with that API
06:06:59 <heycam> dino: if you can defer something to another group, and they're actually going to do it...
06:07:07 <heycam> ed: what kind of things does it give you?
06:07:19 <heycam> dino: the descender lengths, ...
06:07:24 <heycam> cabanier: font bounding boxes, widths
06:12:17 <heycam> RESOLUTION: We will defer the "Have an advance font metrics interface" to the canvas spec.
06:12:32 <Cyril> Cyril has joined #svg
06:12:37 <heycam> ACTION: Rik to investgate making the canvas font metrics interface without needing a <canvas> element.
06:12:37 <trackbot> Created ACTION-3455 - Investgate making the canvas font metrics interface without needing a <canvas> element. [on Rik Cabanier - due 2013-02-14].
06:13:08 <heycam> ACTION-3455: Maybe by making TextMetrics take a constructor with a text string, element context for style.
06:13:08 <trackbot> Notes added to ACTION-3455 Investgate making the canvas font metrics interface without needing a <canvas> element..
06:13:52 <heycam> -- finish --
06:14:02 <heycam> RRSAgent, make minutes
06:14:02 <RRSAgent> I have made the request to generate http://www.w3.org/2013/02/06-svg-minutes.html heycam
06:22:20 <shanestephens_> shanestephens_ has joined #svg
06:37:52 <Zakim> heycam, you asked to be reminded at this time about something
07:08:09 <silvia> silvia has joined #svg
07:45:20 <dmitry> dmitry has joined #svg
10:35:17 <Zakim> Zakim has left #svg
12:59:07 <cabanier> cabanier has joined #svg