22:09:28 <RRSAgent> RRSAgent has joined #svg
22:09:28 <RRSAgent> logging to http://www.w3.org/2012/01/10-svg-irc
22:09:37 <Zakim> Zakim has joined #svg
22:15:35 <heycam> RRSAgent, this meeting spans minute
22:15:35 <RRSAgent> I'm logging. I don't understand 'this meeting spans minute', heycam.  Try /msg RRSAgent help
22:15:39 <heycam> RRSAgent, this meeting spans midnight
22:15:59 <heycam> Meeting: SVG WG Sydney 2012 F2F day 1
22:16:02 <heycam> Chair: Cameron
22:18:42 <cyril> cyril has joined #svg
22:25:01 <heycam> Agenda: http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Sydney_2012/Agenda
22:27:02 <cabanier> cabanier has joined #svg
22:27:08 <birtles> birtles has joined #svg
22:28:59 <vhardy> vhardy has joined #svg
22:29:19 <dino> dino has joined #svg
22:33:23 <dino> agenda link?
22:34:05 <cabanier> http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Sydney_2012/Agenda
22:36:07 <vhardy> ScribeNick: vhardy
22:39:55 <cyril> cyril has joined #svg
22:40:29 <vhardy> http://www.speedtest.net/result/1699186634.png
22:41:57 <cabanier> cyril is having some issues with his computer
22:47:21 <ChrisL> ChrisL has joined #svg
22:51:40 <birtles> birtles has joined #svg
22:52:33 <vhardy> heycam: let's start with the first topic
22:52:46 <vhardy> Topic: https://www.w3.org/Bugs/Public/show_bug.cgi?id=12558
22:52:54 <vhardy> Topic: support HTML's entities in SVG.
22:53:05 <ChrisL> https://www.w3.org/Bugs/Public/show_bug.cgi?id=12558
23:02:58 <birtles> birtles has joined #svg
23:04:27 <TabAtkins> TabAtkins has joined #svg
23:05:24 <vhardy> heycam: the request is that HTML entities be available in SVG content.
23:05:37 <vhardy> ... I think this is not possible with just messing with XML.
23:05:48 <vhardy> chris: I would not like a special version of XML that is SVG specific :-)
23:05:57 <shepazu> q+
23:06:12 <vhardy> ... people should just use Unicode and get used to it.
23:06:45 <TabAtkins> Presumably SVG-in-HTML has access to all of HTML's entities, right?
23:06:47 <vhardy> .... the HTML entities do not cover very much (greek, symbols, latin-1...). For most characters, people will have to use entities or type it in.
23:07:29 <vhardy> ... we could say that if you use HTML serialization, you can use them, if you use XML serialization, you have to include them in the DTD (internal DTD subset). 
23:07:33 <shans> shans has joined #svg
23:08:01 <heycam> TabAtkins, yes, that will work
23:08:10 <vhardy> heycam: doug, do you have comments?
23:08:11 <heycam> ack
23:08:24 <vhardy> doug: people will want to use the same entities.
23:09:34 <dino_> dino_ has joined #svg
23:09:48 <TabAtkins> ChrisL, I don't know what "magical" is in this context.  I'm not sure whether the XML serialization of HTML allows the full set of HTML entities, or just the XML entities.
23:10:09 <vhardy> ... chris argument to use Unicode is good. There are people who are going to be surprised that some things work in SVG in HTML but not in stand-alone SVG. I think the strongest argument is that people will want to use SVG in HTML and get things working the same way in stand-alone.
23:10:35 <shepazu> http://www.w3.org/TR/html5/named-character-references.html
23:10:38 <ChrisL> tab,the entities inHTMLare declared in the external DTD subset, which browsers don't fetch nor do most XMLtools like XSLT etc
23:10:51 <vhardy> heycam: yes, but we have to live with these differences, because there are differences before the differnet serializations anyway. entities is just another thing you can do with XML that is not available in HTML serialization.
23:10:57 <ChrisL> so in general you will get an 'undeclared entity' well formedness error
23:11:12 <TabAtkins> ChrisL: Okay, then we should be fine following the same thing here.
23:11:24 <vhardy> doug: there are certain ones that people will expect, like soft hyphens. Things that they can think of the HTML entity name.
23:11:26 <TabAtkins> Modulo the fact that standalone SVG is forced to use the XML serialization.
23:11:28 <TabAtkins> We can fix that.
23:11:36 <vhardy> .. and they do not know the unicode. 
23:11:54 <vhardy> heycam: non-breaking space is one that is very common for me.
23:11:58 <TabAtkins> <!doctype html><svg>...</svg> can qualify as an html-serialized standalone svg, or something like that.
23:12:12 <vhardy> chris: nbsp, joiners are needed.
23:12:47 <vhardy> chris: if you want those, you can put them in the internal DTD subset.
23:13:33 <vhardy> heycam: if these entities are useful, they should be supported at the XML level rather than SVG. Relying on the DTD is not a great way because some processors do not use it. The solution should not be at the SVG level.
23:13:50 <stakagi> stakagi has joined #svg
23:13:50 <vhardy> chris: we do not want to break things like XSLT that use SVG as input or output.
23:14:05 <TabAtkins> I agree with heycam
23:14:26 <TabAtkins> Fix XML as necessary, and fix SVG outside of XML as well.
23:15:00 <vhardy> chris: Ane has been talking about his XML5 effort. There was an idea to use an HTML5 parsing algorithm for general markup languages. There may be some renewed interest to change XML.
23:15:03 <ChrisL> http://annevankesteren.nl/2007/10/xml5
23:15:33 <TabAtkins> cyril: Not skype, but I can use anything else.
23:15:50 <ChrisL> to quote anne "Entities are in fact a fricking nightmare"
23:15:55 <vhardy> doug: defining an SVG parsing algorithm that is stricter than HTML5 but looser than XML would be good.
23:16:20 <vhardy> heycam: so solving is as part of another initiative that would also solve it for SVG.
23:16:43 <TabAtkins> Yes, a parsing algorithm that has the looseness of HTML (but not the random quirks like assumed elements and auto-closing) would be great.
23:16:49 <vhardy> ... I think  people like the XML5 idea.
23:17:06 <vhardy> chris: for the moment, we are not going to define a new parsing solution for SVG.
23:17:27 <vhardy> doug: why not? Some people in our community are interested, like Tab and Ane. I do not think we should take it off the table.
23:17:42 <shepazu> s/Ane/Anne/g
23:17:53 <vhardy> heycam: I meant that we as the SVG WG will not work on it because it is a broader issue than SVG and the SVG WG is not the right place for that work.
23:18:14 <vhardy> chris: this may seem simple, but it could be a huge time sink and a very large number of interested parties.
23:18:27 <vhardy> doug: this is why I am not proposing to do it in SVG2 but in parallel.
23:18:31 <vhardy> heycam: in the group?
23:19:06 <vhardy> doug: no, but the XML community is not doing this work and has not prioritized this even though it has been brought up in the past 5 years. I do not think we should solve that for SVG 2.
23:19:55 <vhardy> heycam: interested people in the groupd could work on that, but it is probably outside of the charter of the SVG WG. I'd be happy for the problem to be solved.
23:20:00 <TabAtkins> We have a de-facto second parsing solution for SVG already.  SVG-in-HTML allows unquoted attributes, frex.
23:20:14 <vhardy> doug: I do not think that SVG parsing is outside the scope of our group.
23:20:32 <vhardy> heycam: I think we should use the new parsing solution in XML or other markup parsing solutions.
23:20:37 <vhardy> doug: ok.
23:20:47 <TabAtkins> Whether we subset this behavior to get a clean description of a "looser" SVG parsing, or we use something like XML5 with similar effects, it's a useful thing to pursue.
23:21:40 <vhardy> heycam: I think we should respond and close the bug to say that if we want to solve this problem, it should be at the XML level and may be some SVG WG people could work on that but it would not be done as part of an SVG WG deliverables.
23:21:46 <vhardy> chris: so resolve and wont-fix?
23:21:49 <vhardy> heycam: yes.
23:22:01 <vhardy> ed: should we request that change to be made in the XML wg?
23:22:33 <vhardy> heycam: this is a problem that has been known about for a long time and has not been solved. Not sure a message will help more.
23:22:44 <TabAtkins> The problem with making it a general XML problem is that it'll invoke a lot more people trying to improve things.  That's great, but it's not what we need.
23:23:09 <TabAtkins> The short-term problem is SVG-in-HTML allowing things that standalone SVG doesn't.  This can be fixed much more easily by a simplified HTML-like parsing solution triggered by some switch.
23:24:52 <heycam> TabAtkins, well you can just serve it as text/html -- are you instead proposing to come up with a new text/svg or something?
23:25:33 <heycam> TabAtkins, I think it would be harder to get buyin for a new parsing mode for SVG content than for markup languages in general (despite the fact that solving that might involve more people)
23:25:51 <TabAtkins> heycam: SVG-as-text/html is as bad an idea as XML-as-text/html.  ^_^
23:26:18 <vhardy> RESOLUTION: The SVG WG thinks this well know limitation on XML entities is a wider problem than just SVG and should be addressed by working groups addressing markup parsing (e.g., XML WG). When that issue is addressed, the problem will be solved for SVG and other markups facing that issue (e.g., XSLFO).
23:26:31 <jun> jun has joined #svg
23:26:38 <ChrisL> rrsagent, here
23:26:38 <RRSAgent> See http://www.w3.org/2012/01/10-svg-irc#T23-26-38
23:30:20 <heycam> [15 minute break]
23:59:18 <dino> ScribeNick: dino
23:59:20 <dino> Topic: Mapping
00:00:29 <dino> +doug
00:00:40 <dino> +dirk
00:00:52 <ChrisL> Present+ doug,dirk
00:01:02 <ChrisL> zakim,git it a rest :)
00:01:02 <Zakim> I'm glad that smiley is there, ChrisL
00:01:13 <dino> present+ doug, dirk
00:02:16 <stakagi> First, I would like you to discuss about the need for SVGTL. 
00:02:44 <jun> http://www.w3.org/Graphics/SVG/WG/wiki/Requirements_for_Mapping
00:02:54 <jun> http://www.w3.org/Submission/2011/SUBM-SVGTL-20110607/
00:03:21 <dino> Jun: Links above for mapping requirements and tiling.
00:05:10 <stakagi> http://www.w3.org/Graphics/SVG/WG/wiki/Requirements_for_Mapping#Tiling_and_Layering
00:05:57 <stakagi> Dirk-san's comment http://lists.w3.org/Archives/Public/public-svg-wg/2011OctDec/0117.html
00:06:40 <dino> CM: Dirk, can you summarise your comments on mapping?
00:07:01 <cabanier> cabanier has joined #svg
00:07:18 <dino> DS: I think GML is good enough - we need a transformation btw GML and SVG. That's all. I'm not sure what else we need.
00:07:40 <dino> CL: I believe that is what we're proposing. A way to map the coord system in SVG.
00:07:55 <heycam> (this DS is Dirk rather than Doug)
00:08:03 <shepazu> s/DS:/Dirk:/
00:08:17 <stakagi> Dirk-san's comment http://lists.w3.org/Archives/Public/public-svg-wg/2011OctDec/0117.html
00:08:18 <stakagi> Enabling usage of huge graphics by a hyperlink means SVGTL. 
00:09:26 <dino> Chris: we can't always use the server to do the mapping, since the data might come from various sources.
00:09:59 <stakagi> http://www.w3.org/2011/web-apps-ws/papers/KDDI.html
00:10:16 <dino> Dirk: it's not client side vs server side, it's more about that it shouldn't be integrated into SVG.
00:11:11 <dino> Chris: the proposal is to provide enough information such that the client can combine and render data from various sources. It is not an attempt to build a GIS system in SVG.
00:11:43 <shepazu> q+
00:12:22 <dino> Dirk: my concern why we would add special logic for maps - but not other techs like math, etc.
00:13:03 <dino> Chris: understood - the idea is to provide just enough information to overlay map data
00:13:30 <dino> ChrisL: It does not provide any reprojection (other that linear transforms)
00:13:59 <TabAtkins> I believe the underlying primitive - being able to link to lots of files and give their bounds, so the UA can decide which ones to load based on the viewport position/size, is good.
00:14:06 <TabAtkins> It sounds useful for lots of things more than maps.
00:14:07 <dino> Doug: also, tiling and layering is useful beyond mapping. 
00:14:16 <TabAtkins> But I'm uncomfortable with any direct tie-in to mapping data.
00:14:19 <TabAtkins> Or coords.
00:14:56 <dino> Dirk: I would prefer the new tag/attribute names to be not-specific to mapping. I'd rather more generic names.
00:15:00 <TabAtkins> Another example of a use-case is video games using SVG-based graphics.
00:15:20 <dino> Dean notes Tab's comments out loud for the room.
00:15:23 <TabAtkins> (Though that may require control over how aggressive the UA should be in downloading.)
00:15:39 <stakagi> And I think that it is the important characteristic of WWW to use a hyperlink. 
00:15:47 <shepazu> q+
00:16:04 <dino> Cameron: (generally agrees with generic approach)
00:16:33 <dino> FJ: This is exactly why we call it tiling and layering - we're not trying to be specific to maps.
00:16:35 <TabAtkins> Also: allowing multiple layers of tiling sounds good.
00:16:54 <dino> FJ: other things can be developed separately
00:17:06 <dino> s/FJ/JunF/g
00:17:35 <dino> Doug: Although, I think mapping is important, so I'm ok with some features being added to help that use case
00:17:40 <ChrisL> q+
00:17:45 <shepazu> q-
00:18:06 <dino> Cameron: I don't want to preclude mapping applications.
00:18:19 <dino> Cameron: people already write mapping applications
00:18:28 <stakagi> And, implementation of SVGTL is not so large.
00:18:48 <dino> Chris: Although it would be better if we didn't need JS for such applications - prefer declarative.
00:19:20 <thorton_> thorton_ has joined #svg
00:19:25 <TabAtkins> I wouldn't mind optional declarative abilities to pan across a large image.
00:19:46 <TabAtkins> Doing panning/dragging in JS is simple, but painful.
00:20:18 <dino> Cameron: i wonder if there is some intermediate ground where we give instructions on how to declare the geographic location, but not necessarily require a new implementation (ie. script required to process it).
00:20:41 <cyril> q+
00:21:34 <dino> JunF: I asked Takagi-san if he is happy to use script to match mapping data from various sources. He replied that he'd prefer hyperlinks.
00:21:42 <ChrisL> I wanted to point to some earlier work on multi-resolution images (SVG 1.2 full) http://www.w3.org/TR/2004/WD-SVG12-20041027/media.html#multires
00:21:53 <dino> Takagi: - re-usability
00:22:04 <krit> krit has joined #svg
00:23:12 <dino> Takagi: I've been working with various developers of mapping systems in Japan. They conveyed that it is difficult to use the data if it is tightly integrated with script.
00:24:06 <dino> Cameron: I am wondering if we can come up with some extended format for *describing* the mapping regions, but still require script to do the stitching together of data.
00:25:56 <ChrisL> LinkedOpen Data
00:26:09 <dino> Takagi: tends to agree with Cameron's comment. He has been working with various government agencies and would prefer a clear-open solution. It is easier to share data than a script interface.
00:26:25 <dino> ChrisL: (points to the multi-res image proposal above)
00:27:39 <dino> ChrisL: allows you to pull higher resolution data, etc. Similar to Microsoft's PhotoSynth. You can certainly do this with script, but it is more simple if it is declarative. Other use cases like medical imaging, high-resolution photographs, etc
00:27:50 <ChrisL> There are a lot of use cases for multiresolution imaging, both raster and vector
00:27:59 <dino> Cameron: I'm not against a completely declarative solution.
00:28:59 <dino> Dean: does a declarative solution require some kind of UI or API in order to control the layering?
00:29:17 <dino> Cameron: That's part of the document.
00:31:57 <dino> Dean: (supports the general idea of being able to define a coordinate system mapping btw documents - wonders how or who controls the fetching and display of data)
00:32:00 <ChrisL> q?
00:32:05 <ChrisL> ack ChrisL
00:33:13 <dino> Cyril: If you have a use case such as a map with two levels of quality and multiple tiles. There are different strategies (go deep to get high-res data first, or go wide to get a broader low-res map)
00:33:51 <dino> Cyril: The behaviour there is significantly different - who is defining what the application should do?
00:34:04 <dino> Cameron: In this case it would be the developer/author.
00:34:18 <dino> Brian: Are we talking about a core SVG feature, or a module?
00:34:47 <dino> Chris: I think it was supposed to be a module, but there are parts that should be core (e.g. multiresolution imagery)
00:35:10 <dino> Cameron: we have already agreed that some parts are core SVG. For example, path sharing.
00:35:31 <dino> Cameron: my fear is that we go ahead with this and then not enough people implement or use it
00:36:25 <dino> Brian: question is how critical this is to the progress of SVG2?
00:36:58 <dino> Chris: I'm aware of two implementations of this already (yet no implementations of some other SVG2 features)
00:37:10 <cyril> ack cyril
00:38:52 <dino> Vincent: Looking at the proposal, I understand the linear transformation, but I do not understand how you would use this in practice. 
00:39:56 <dino> cameron shows example
00:40:48 <TabAtkins> Any way to get the example into irc?
00:41:00 <dino> Vincent: I propose collecting use cases
00:41:14 <jun> <?xml version="1.0" encoding="UTF-8"?>
00:41:15 <jun>   <svg xmlns="http://www.w3.org/2000/svg">
00:41:15 <jun>   <globalCoordinateSystem
00:41:15 <jun>     srsName="http://purl.org/crs/84"
00:41:15 <jun>     transform="matrix(15.3631,0.0,0.0,-18.6994,-1889.2916,849.9202)"/>
00:41:15 <jun>     <circle cx="258.1401" cy="185.1558" r="10.0" stroke="none" fill="green"/>
00:41:17 <jun>   </svg>
00:41:41 <TabAtkins> I don't really understand this example.  It gets up a coord system, yes.  So does viewBox.  What's the benefit?
00:41:47 <TabAtkins> s/gets/sets/
00:42:07 <dino> Cyril: The point is that it exists in the file
00:42:46 <dino> Chris: and it defines where you start
00:42:50 <TabAtkins> (Also, the use of a matrix() transformation there is very difficult to understand.  I assume it's actually a scale and transform?)
00:43:10 <ChrisL> ChrisL has joined #svg
00:43:47 <TabAtkins> Oh, <gCS> tells you what coords *this file* covers, relative to the coord system of the including document?
00:44:22 <dino> (sorry, some unminuted discussion where Dean is educated on the proposal)
00:45:04 <TabAtkins> If my understanding is correct, I'd *much much much* prefer something that explicitly declared the bounds.  Like a viewBox that used units from the including file.
00:45:21 <TabAtkins> The use of a scale/transform to indicate this is weird.
00:45:57 <dino> Cyril: This is not giving any bound information
00:46:13 <dino> Vincent: and it is a standalone element in the file - the <circle> is not a child.
00:47:15 <heycam> TabAtkins, yes I think we should declare the extent explicitly
00:47:23 <TabAtkins> What's an example of the master file that uses the subfile illustrated here?
00:48:00 <heycam> TabAtkins, I *think* in that document right at the end of section 3
00:48:15 <heycam> TabAtkins, (but I am still confused by it)
00:48:16 <ed> <svg xmlns="http://www.w3.org/2000/svg" viewBox="20 110 120 85">
00:48:16 <ed>     <globalCoordinateSystem
00:48:16 <ed>       srsName="http://purl.org/crs/84"
00:48:16 <ed>       transform="matrix(15.3631,0.0,0.0,-18.6994,-1889.2916,849.9202)"/>
00:48:17 <ed>     <animation   x="0"   y="0" width="100" height="70" xlink:href="0_0.svg"/>
00:48:17 <dino> Chris: It seems we are missing the information which describes how to actually merge these two files
00:48:19 <ed>     <animation x="100"   y="0" width="100" height="70" xlink:href="1_0.svg"/>
00:48:21 <ed>     <animation x="200"   y="0" width="100" height="70" xlink:href="2_0.svg"/> ... </svg>
00:48:35 <ed> what I pasted is an example of the master file
00:48:43 <TabAtkins> (Section 3 of which document?  I'm looking at a blog post that has that example, but in section 4.3.)
00:49:02 <cyril> http://www.w3.org/Submission/2011/SUBM-SVGTL-20110607/
00:49:03 <TabAtkins> Yeah, that's still not a usage, I don't think.
00:49:20 <TabAtkins> Ah, I was getting a 502 last time I tried to access that file.
00:50:07 <stakagi> 4.1 Rendering of import SVG data with geographic coordinate system
00:50:22 <stakagi> pluase see
00:50:56 <TabAtkins> The use of <animation> confuses me.
00:51:25 <heycam> TabAtkins, think of <animation> as <use>
00:51:46 <TabAtkins> Also: if <gCS> is used in the child files to declare their bounds, that means we have to download *all* of the child images to tell where they go.
00:51:49 <ed> TabAtkins: it's like <html:iframe> or a dynamic form of <svg:image>
00:51:49 <TabAtkins> That's... less than optimal.
00:52:00 <TabAtkins> Ugh, that's a bad bad name.
00:52:06 <dino> Dean: It seems that this is saying you should ignore x,y,width and height on any element that references data with the globalCoordinateSystem element
00:52:26 <TabAtkins> By "less than optimal" I really mean "completely unusable for real-world mapping applications".
00:52:59 <TabAtkins> Or, hm.
00:53:15 <TabAtkins> Are the x/y/width/height on <animation> used to declare the bounds, or the <gCS> in the child files?
00:53:26 <TabAtkins> I guess I'm still confused about what <gCS> is supposed to accomplish. :/
00:53:31 <dino> MASS CONFUSION EVERYWHERE
00:53:45 <cyril> cyril: Tab the name comes from a smil element: <audio>, <video>, <animation>
00:54:17 <TabAtkins> cyril: The name is bad regardless of its provenance. ^_^
00:54:31 <TabAtkins> Particularly since <animations> doesn't scream "map tile" to me.
00:54:49 <TabAtkins> It instead sounds like "I misspelled <animate>".
00:55:13 <cyril> cyril: animation points to an animated vector graphics resource
00:55:20 <dino> Chris explains image referencing in SVG on a whiteboard (which is going to be hard to scribe)
00:55:36 <cyril> it's specified in SVG 1.2 Tiny
00:56:17 <dino> Chris: the <gCS> element should always use WGS84
00:56:26 <dino> Cameron: why not always be <g>?
00:57:05 <dino> Vincent: this isn't a transform on the children. It's a description of how the data was transformed.
00:58:10 <ed> s/always use WGS84/always use WGS84 and you shouldn't have to specify it using that special srsName=<url> syntax, it should just say in the spec that it's always WGS84/
00:59:30 <TabAtkins> I don't understand the use of a transform in the first place.  Either the subfiles should use local coords and make the transforming automatic based on the containing file's declared bounds, or the local coords should *be* global coords and just trivially work.
01:01:04 <TabAtkins> (For the automatic case, something simple like mapping the subfile's viewBox into the containing file's declared x/y/width/height for the tile would work I think.)
01:01:06 <dino> TabAtkins, I believe the desire is that the subimage might (for some reason) have a different viewport than the coordinate system definied
01:01:21 <dino> (I might not be conveying that correctly - I'm very confused)
01:01:29 <TabAtkins> Me too. ;_;
01:01:45 <stakagi> http://sourceforge.net/projects/wwwmap/
01:02:00 <stakagi> LGPL implementation 
01:04:02 <dino> Takagi: this is a chrome extension that provides tiling in SVG images
01:05:44 <birtles> looking at the source of http://svg.mbsrv.net/extmaps/BingMapAu/ContainerBing.svg if you want to view the source
01:06:25 <TabAtkins> I don't think I can sanely evaluate this at this point.  The example are extremely confusing and the explanations are incomplete.
01:08:31 <dino> Shane: the x,y,width,height of the referencing element (eg <animate>) is telling the UA when to fetch the sub-resource
01:08:48 <dino> Shane: the important point is section 4.2 of the proposal
01:09:35 <TabAtkins> That part makes sense, and sounds like an interesting and probably useful primitive.
01:10:45 <dino> Dean: I think this should be a new element. Otherwise it is significantly changing existing behaviour.
01:11:41 <TabAtkins> If I'm understanding Shane's back-channel explanation, then I still don't understand the point of <gCS>. :/
01:13:31 <dino> TabAtkins, gCS defines each resource's transformation from some universal coordinate system (WGS84 for example) 
01:13:40 <TabAtkins> Yeah, just got that in the backchannel.
01:14:05 <TabAtkins> I understand the mechanics of <gCS> now, but not the purpose.
01:14:47 <TabAtkins> Why do we need this coord indirection?  Why not just specify the images in the global coords to start with?
01:14:56 <TabAtkins> ed, agreed.
01:15:18 <ed> <tile> might be a better name than <animation> for this
01:16:46 <cyril> Tab: because you don't control the way the SVG is generated in every server
01:17:05 <birtles> ChrisL also brought up the issue of precision
01:17:06 <cyril> but you can still mash them up if all of them provide gCS data
01:17:11 <dino> Cameron: I think Vincent's suggest of enumerating use cases is a good one. We'll see how the proposal covers the uses. 
01:17:30 <TabAtkins> cyril, are you saying that we're worried about map data using effectively random coords?
01:17:33 <krit> krit has joined #svg
01:17:37 <dino> Vincent: And I think a new element is worth investigation.
01:17:41 <TabAtkins> If it does, then how can we depend on it using <gCS> to map its coords?
01:17:51 <TabAtkins> And if it *can* use <gCS>, why can't it just change its coords directly?
01:18:06 <cyril> I don't understand the questions.
01:18:28 <TabAtkins> I don't understand the premises. ;_;
01:18:34 <TabAtkins> Let me try again.
01:19:16 <TabAtkins> So, <gCS> lets the child files map their local coordinates into a global coord system.  <gCS> also allows the containing file to do the same thing.  After applying them both, you have a way of connecting together two different kinds of local coords.
01:19:22 <TabAtkins> But why is this necessary?
01:19:52 <TabAtkins> The child files can just work in global coords.  We're talking *map data* - there are reasonably common ways of doing this.
01:20:01 <dino> Cameron: someone needs to distill this proposal into a clear example.
01:20:09 <TabAtkins> If a child *can* change itself to include a <gCS>, it can also change itself to use global coords directly.
01:20:26 <TabAtkins> If it can't change itself to use global coords, then it probably can't change to include <gCS> either.
01:20:42 <TabAtkins> So I don't see the use of <gCS>.
01:22:18 <dino> ChrisL: the reason we need localized coordinate systems is for accuracy. If you're drawing a map of your house, you don't want to use WGS84
01:23:01 <TabAtkins> Okay, that makes sense.
01:23:16 <dino> Dean: for example, floor plan of a building
01:23:25 <dino> Vincent: or components in machinery
01:23:34 <TabAtkins> In that case, a clearer method of indicating the transform, like a from="x y w h" to="x y w h" would be nice.
01:23:50 <shans> and we can't just use a <g> because that actually does the conversion, and you can't then view the file independently of the mapping context
01:24:09 <TabAtkins> The fact that the examples use matrix() did no favors for understanding this concept.
01:24:39 <dino> I believe shane just documented Brian's question and the answer
01:24:40 <TabAtkins> Or maybe something on <svg> that maps the viewBox into a gcs.
01:25:45 <TabAtkins> I'm just angling for a human-writable version of the feature here.  There are a few annoying features in legacy SVG that were clearly designed without thinking of humans.  ^_^
01:26:11 <dino> Cyril: I understand why we need gCS in the children, I'm not so sure why we need the gCS in the container
01:26:29 <TabAtkins> Yes, that's my second concern now.
01:26:45 <dino> Shane: In order to use this proposal in a non-mapping situation, then is it enough to leave out the mention of WGS84?
01:28:58 <stakagi> property name 'srsName' may not be cobinient. 'glovalCoordnateSystemURI'
01:30:36 <TabAtkins> No need for a URI at all.  If we *need* to declare what the gcs is, use a keyword.  But if we can avoid it, do so.
01:31:28 <dino> TabAtkins, I suggested (not minuted) we use something like "this-is-a-map"
01:31:43 <dino> and every other use case is a free for all
01:31:44 <TabAtkins> Naming issues aside, yes, something like that.
01:31:55 <dino> if you want to combine a medical image with a map, good luck.
01:32:05 <ChrisL> tab, the srsnameis inherited from the rdf-mess in svg 1.1 which was a more longwinded way to saythe samething
01:32:18 <TabAtkins> ChrisL: Okay, but that doesn't mean that *we* need to inherit it.
01:32:23 <TabAtkins> We can do things correctly.  ^_^
01:33:05 <dino> Chris: some of these names are a simplification of SVG 1.1. we can change them if needed, but not spend too much time on it
01:34:04 <dino> Vincent: would it me sufficient to update the existing metadata that exists? The other part of the solution is whether or not we need a new element to reference such data
01:34:19 <cyril> s/it me/it be/
01:34:36 <TabAtkins> I'll be gone in a few minutes for at least 2 hours.
01:34:56 <dino> Cameron: I'm not sure we should hide the active processing. 
01:36:34 <dino> Cameron: we'll break for lunch now, and come up with resolutions afterwards.
01:36:45 <dino> ---- LUNCH ----
01:36:55 <heycam> [for one hour]
01:56:26 <thorton> thorton has joined #svg
01:57:17 <stearns> stearns has joined #svg
01:57:22 <krit> krit has joined #svg
01:57:45 <birtles> birtles has joined #svg
01:59:01 <heycam> heycam has joined #svg
02:03:51 <stakagi> stakagi has joined #svg
02:03:56 <cyril> cyril has joined #svg
02:19:37 <stakagi> stakagi has joined #svg
02:29:57 <stakagi> stakagi has joined #svg
02:46:41 <shans> shans has joined #svg
02:47:29 <cabanier> cabanier has joined #svg
02:49:04 <birtles_> birtles_ has joined #svg
02:50:54 <jun> jun has joined #svg
02:51:36 <cabanier> cabanier has joined #svg
02:52:42 <dino> dino has joined #svg
02:53:00 <stakagi> stakagi has joined #svg
02:53:49 <cyril> cyril has joined #svg
02:57:14 <shans> shans has joined #svg
02:58:40 <cabanier> cabanier has joined #svg
03:01:06 <ed> scribeNick: ed
03:01:20 <heycam> RRSAgent, make minutes public
03:01:20 <RRSAgent> I'm logging. I don't understand 'make minutes public', heycam.  Try /msg RRSAgent help
03:01:34 <heycam> RRSAgent, set public
03:01:34 <RRSAgent> I'm logging. I don't understand 'set public', heycam.  Try /msg RRSAgent help
03:01:47 <heycam> RRSAgent, help
03:02:09 <ed> topic: mapping requirements (continued from last slot)
03:02:36 <cabanier> cabanier has joined #svg
03:03:00 <ed> CM: as vincent said, we need short examples and use-cases, to be able to grasp the proposal better
03:03:15 <ed> ... not sure who would be best to work on those
03:03:28 <ed> CL: i can help, but I need someone else to work on it too
03:03:55 <cabanier> cabanier has joined #svg
03:04:09 <stakagi> stakagi has joined #svg
03:05:13 <ed> ACTION: CL to write up a short description of Tiling and layering and use-cases for it
03:05:14 <trackbot> Created ACTION-3197 - Write up a short description of Tiling and layering and use-cases for it [on Chris Lilley - due 2012-01-18].
03:05:37 <ed> CM: is it worth discussing if it should be a module or built into svg2?
03:05:49 <ed> CL: too early, we need to see how general it will be first
03:06:07 <shans> shans has joined #svg
03:06:08 <ed> CM: that was the first requirement from the wikipage takagi-san made
03:06:20 <ed> ... next one, non-scaling-stroke vector effect
03:06:35 <ed> ... we have already resolved to include the functionality of non-scaling-stroke in SVG2
03:06:50 <ed> ... next is shared path segments
03:07:02 <ed> CL: I think we decided to move that to vector-effects
03:07:30 <heycam> http://www.w3.org/Graphics/SVG/WG/wiki/Requirements_for_Mapping#Vector_effect -- non-scaling stroke
03:07:47 <heycam> http://www.w3.org/Graphics/SVG/WG/wiki/Requirements_for_Mapping#Shared_paths
03:07:48 <heycam> http://www.w3.org/Graphics/SVG/WG/wiki/Requirements_for_Mapping#Fixed-size_object -- transform ref
03:08:01 <vhardy> vhardy has joined #svg
03:08:17 <ed> CM: ST can you explain what you meant with misunderstanding of how transform-ref worked? 
03:08:56 <ChrisL> rrsagent, make logs public
03:09:34 <birtles> birtles has joined #svg
03:11:49 <stakagi> stakagi has joined #svg
03:11:53 <ed> ST: the implementation of this fixed-size is different from the spec wrt the viewbox behaviour
03:12:11 <ed> CM: what particular functionality is desired here?
03:12:28 <ed> ... so that it stays the same size regardless of scale?
03:12:30 <ed> CL: right
03:13:01 <ed> CM: it's limited to referring to the outermost svg in tiny 1.2
03:13:20 <ed> CL: yes, that's a limitation in tiny, could reference to any sub-svg really
03:13:37 <stakagi> Mr. Alex understands the complete information of these functionality. 
03:13:49 <ed> CM: it's one of those features where it's useful if the zoom-and-pan is done using built-in functionality, not with script
03:14:33 <ed> CM: does opera implement transform-ref?
03:14:42 <ed> ED: yes
03:15:05 <ed> CM: is there content taht uses it?
03:15:22 <ed> CL: since alex implemented this too, there is probably content that uses it
03:15:38 <ed> ... it's generally useful
03:15:50 <ed> CM: shouldn't be too hard to implement
03:16:04 <ed> ... you have to track changes to coordinate space
03:16:32 <ed> BB: the use-case is for markers on a map?
03:16:49 <ed> CL: map symbols that don't get bigger when you zoom
03:17:09 <ChrisL> s/alex/alex and kddi/
03:17:16 <ed> CM: we haven't decided on this one for SVG2, can we do that now?
03:17:39 <ed> CL: non-scaling-stroke and this funcationality sort of goes together 
03:17:42 <cabanier> cabanier has joined #svg
03:18:01 <ed> CM: anyone object to having transform-ref in svg2
03:18:44 <ed> ED: it does mean we introduce something more that CSS transforms need to deal with
03:18:59 <ChrisL> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input
03:19:39 <ed> ... so we'd need to address this issue in the FXTF transform spec
03:21:08 <stakagi> stakagi has joined #svg
03:21:13 <ed> CM: not sure i like the name 'ref', not really descriptive
03:21:29 <ed> CL: it points to which coordinate system it uses
03:22:18 <ed> (explains the tranform-ref functionality)
03:22:23 <shans> shans has joined #svg
03:23:13 <ed> CM: i'd like to see some example documents using this to see its usefulness
03:23:34 <ed> ... what if you wanted rotation but not scale, does it cover that?
03:23:42 <ed> ... or the other way around
03:24:06 <ed> ... we had another discussion about wanting text to not rotate
03:24:32 <ed> CL: pinned video in svg tiny 1.2 is similar
03:25:30 <ed> CC: that's 'transformBehaviour' and it is useful, could be used for other things than video
03:25:49 <ed> ... changes the way the transform applies to the object
03:26:18 <cabanier> cabanier has joined #svg
03:26:19 <ed> ... so in one case: only affect the centerpoint
03:26:45 <ed> RC: transform-origin in css is similar too
03:28:12 <ed> CM: don't want to resolve right now on transform=ref right now, want to see more examples first
03:28:22 <ed> ... some form of transform-cancelling behaviour
03:29:00 <stakagi> stakagi has joined #svg
03:29:02 <ChrisL> 3.4.1 Constrained Transformations
03:29:17 <ChrisL> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Constrained_Transformations
03:29:44 <cabanier> cabanier has joined #svg
03:29:52 <ed> CM: are people happy requireing that, or do we need more writeup?
03:30:05 <ed> ... want to make sure it's a useful enough feature
03:30:18 <ed> BB: in mapping sure, but outside of that not so sure
03:31:03 <ed> ... UI-components was one use-case mentioned, but you could affect this script anyway
03:31:06 <Zakim> Zakim has left #svg
03:31:24 <Zakim> Zakim has joined #svg
03:32:03 <ed> CL: you could say the same about (missed, something CSS?)
03:32:13 <heycam> about position:fixed
03:32:38 <ed> BB: just wondering about use-cases outside of mapping
03:33:05 <cabanier> cabanier has joined #svg
03:33:06 <ed> s/(missed, something CSS?)/position:fixed/
03:33:26 <ed> CC: trying to remember the use-cases
03:33:54 <ed> CM: why would the UI be part of the content, and not in a separate group?
03:34:13 <ed> CL: callouts, on objects that have text
03:34:27 <stakagi> stakagi has joined #svg
03:34:36 <ed> VH: you want things to follow along, but nonscaled
03:35:19 <ed> BB: yeah that's a better usecase
03:35:34 <ed> ...might be useful for a diagramming application, but do we need to support it in svg itself?
03:35:55 <ed> VH: well, we could just adopt transform-ref since it's specced and implemented
03:36:11 <ed> CM: not sure it addresses everything we discussed here
03:36:24 <ed> ... such as rotation without scaling
03:36:46 <ed> ... but maybe i don't understand transform-ref fully
03:37:05 <ed> ... anyway, regardless of the solution, are the use-cases sufficient for us?
03:38:56 <cabanier> cabanier has joined #svg
03:40:53 <ed> CM: whatever in SVG1.2 Full isn't going to help us decide here
03:41:23 <ed> ... if some ppl need more convincing, we need some more examples demonstrating the functionality
03:41:48 <vhardy> vhardy has joined #svg
03:42:36 <ed> ACTION: CL to write up general use-cases (mapping and other) for constrained transformations, aka transform=ref(...)
03:42:37 <trackbot> Created ACTION-3198 - Write up general use-cases (mapping and other) for constrained transformations, aka transform=ref(...) [on Chris Lilley - due 2012-01-18].
03:43:45 <heycam> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Alternative_transforms
03:43:54 <ed> CL: it's been considered before
03:43:59 <heycam> (http://www.w3.org/Graphics/SVG/WG/wiki/Requirements_for_Mapping#Non-linear_transformation)
03:44:09 <ed> ... this is different from 3d transformations
03:44:34 <ChrisL> ChrisL has joined #svg
03:44:34 <shans> shans has joined #svg
03:44:40 <ed> ... DOH was asking for polar coordinate system, and Dailey was asking for kalleidoscopic projections
03:45:09 <ed> ... next, on UI
03:45:10 <heycam> http://www.w3.org/Graphics/SVG/WG/wiki/Requirements_for_Mapping#Built-in_User_Interface
03:45:25 <ed> CM: for UI controls
03:46:40 <ed> ... built-in, native UI, not sure about that
03:46:57 <ed> CL: making it easier to construct UIs would be better I think
03:47:10 <ed> VH: for video many people want to make their own ui
03:47:14 <stakagi> stakagi has joined #svg
03:47:34 <ed> ... but you can also specify 'controls' (html5)
03:47:56 <ed> CL: it's useful for vector graphics to have zoom-and-pan controls
03:48:56 <ed> BB: in mapping scenarios you generally want to construct your own ui
03:49:25 <ed> CL: but for some applications, such as a floorplan of a house you might not want to go through all that trouble
03:49:55 <cyril_> cyril_ has joined #svg
03:50:23 <ed> CM: i'm not that against having controls
03:50:32 <ed> ... video will be probably more common
03:50:42 <ed> ... compared to vector content
03:51:15 <ed> ... it's not a difficult thing to implement, and you do want different ui depending on device, and the implemetation might be in a better position to make a better ui
03:51:33 <ed> ... can listen for touch events for pinch-zoom e.g
03:52:54 <ed> CM: back to the non-linear transforms
03:53:11 <ed> ... we've already resolved to have support for differnet projections
03:53:34 <ed> ... the mapping requirements page doesn't have this as a hard requirement, so no need to reopen taht requirement
03:53:48 <ed> ... back to controls again
03:54:07 <ed> ... this is similar to zoomAndPan
03:54:14 <ed> ... but with a different name
03:54:29 <ed> BB: you can pinch-zoom without any ui on the screen
03:54:51 <ed> CM: that automatic zooming and being able to scroll the css box, and not being able to do that on the content inside
03:55:05 <ed> ... not sure what should happen if you have mixed svg and html content
03:55:51 <stakagi> stakagi has joined #svg
03:55:58 <ed> ... would anything we do different here change browsers about how they interpret zoom-and-pan
03:56:23 <shans> shans has joined #svg
03:56:42 <ed> VH: if it's something we can do and it's not too difficult it should be higher on the priority list
03:56:50 <cyril> s/we've already resolved to have support for differnet projections/we've already resolved not to have support for different projections/
03:57:39 <ed> CM: it's not too difficult to do, so we don't save that much work if you were to do it yourself in script
03:58:08 <ed> VH: sure, you can change the currentScale/currentTranslate or modify viewbox
03:58:16 <ed> CM: propose that we don't include UI controls
04:00:40 <stearns_> stearns_ has joined #svg
04:00:55 <ed> ED: do we have other requests for this in SVG2?
04:00:56 <ed> CM: yes, dailey
04:00:59 <ed> RESOLUTION: we won't require support for built in zooming and panning UI in SVG2
04:01:05 <ed> CM: next, programmingless geolocation
04:01:06 <ed> ... scroll to center of mapview automatically
04:01:08 <ed> CL: geolocation is an api
04:01:16 <ed> CC: but this is a declarative way
04:01:18 <birtles_> birtles_ has joined #svg
04:01:19 <ed> CM: not sure it's that useful
04:01:27 <ed> ... to avoid the two lines of script to set the location
04:01:29 <heycam> http://www.w3.org/Graphics/SVG/WG/wiki/Requirements_for_Mapping#Programming-less_geolocation
04:01:33 <ed> CC: does feature phones have javascript engines?
04:01:34 <stakagi> Since this spec is what specialized in the map, according to the till now context, it may be difficult for it to put in. 
04:01:35 <ed> CL: yes
04:01:46 <ed> BB: if you use this in an <image> you might want it declarative, because script is disabled
04:02:05 <ChrisL> ChrisL has joined #svg
04:02:16 <ed> CM: but you could use an #svgView(...) on the <image> to set the view
04:02:24 <ed> ... doesn't seem that useful
04:03:06 <ed> ... for a map you'd want to use scripting anyway
04:03:33 <ed> RESOLUTION: we won't require automatic geolocation centering of maps or content
04:03:41 <shans> shans has joined #svg
04:03:53 <heycam> http://www.w3.org/Graphics/SVG/WG/wiki/Requirements_for_Mapping#Setting_SVG_views_by_IRI_fragments_using_geographic.28global.29_coordinates
04:04:02 <ed> CM: next, setting svg views with url syntax and in the global coordinate system
04:04:10 <ed> ... slightly more useful to me
04:04:30 <vhardy> vhardy has joined #svg
04:04:40 <ed> ... for static maps, e.g a restaurant location, and you want to use a country map with your data
04:04:55 <ed> ... we already have #svgView
04:05:29 <ed> CL: seems straightforward, except you need to say if you link to a point outside of a map, or if it's not a map
04:05:40 <ed> ... also needs the geographic location thing
04:06:09 <ed> VH: so you map that point to the center of the viewport
04:06:22 <ed> CM: oh, thought it was an area?
04:06:28 <ed> CL: yes it's an area
04:06:39 <ed> ... but if we make the widht and height optional
04:06:47 <ed> VH: how do you get the transform?
04:06:54 <ed> ... would need the global transform
04:07:12 <ed> CL: if you link to something that's not a map, then we need to say what happens
04:07:30 <ed> ... or if you link to a map of sydney and it's a map of melbourne
04:07:54 <ed> ... maybe go to the edge of the map, or whatever
04:08:34 <ed> CM: we should have optional width and height for the svgView thing, so that it centers that point
04:09:03 <ed> ... if we have the global coordinates from tiling and layering then we should have this
04:09:08 <stakagi> stakagi has joined #svg
04:09:08 <ed> ... would go naturally with that
04:09:38 <ed> RESOLUTION: if we have the tiling and layering module then we'll have a way of making svgView transformations work in global coordinate space
04:10:07 <ed> CC: so we couldn't have a keyword svgView(my-location)?
04:11:44 <ed> ED: there are cases where this doesn't map to anything (if disabled, or not available), anyway, as said before that needs to be specified
04:12:11 <ed> CM: the kind of maps where you want to center, you're going to want interactivity anyway
04:12:22 <ed> ... why do we need a programmingless way of doing it?
04:12:38 <ed> ... that was the reasoning from before
04:12:55 <ed> ... move on, last on the page
04:12:55 <heycam> http://www.w3.org/Graphics/SVG/WG/wiki/Requirements_for_Mapping#API_for_smooth_transition_action_of_zooming.2Cpannning.2Crotating
04:13:18 <ed> CL: don't understand it, is it transitions?
04:13:57 <ed> ... why does it talk about suspendRedraw?
04:15:03 <ed> BB: one possibility is to stop it from updating while you do your animation
04:15:31 <ed> ... and then you'd unsuspend when you're done zooming
04:16:00 <ed> CL: if you're really zoomed in and you don't want to trigger fetching resources while you pan a lot
04:16:09 <ed> BB: difficult to spec I think
04:16:35 <ed> CL: if we had the automatic fetching of tiles, but if we don't have it...
04:17:48 <ed> CM: if we could disable the automatic tile fetching so that you could turn off fine detail while scrolling 
04:19:42 <ed> ... being able to turn off tile fetching would be fine
04:19:52 <ed> BB: you may need events for this
04:20:13 <ed> CM: so to fade between different detail?
04:20:17 <ed> BB: yes, maybe
04:20:20 <cyril_> cyril_ has joined #svg
04:20:43 <ed> CL: yes, ahving progress events for this would be useful
04:21:22 <ed> RESOLUTION: we will have a way to control the automatic tile fetching in the tiling and layering spec
04:21:35 <heycam> http://www.w3.org/Graphics/SVG/WG/wiki/Requirements_for_Mapping#Transformation_functions_between_global_.28geospatial.29_coordinate_systems_and_user.2Fviewport_coordinate_systems
04:21:48 <ed> CM: seems like a nobrainer
04:22:20 <ed> ... we're already going to have better interfaces for mouse events and coordinate systems, so we should have this
04:23:19 <cyril> http://soln-sr3450.movielink.net.au/common_ip_cgi/prepaid_access.cgi?MAC_ADDRESS=00:24:d7:85:22:80&ASSIGNED_IP=10.71.15.82&ROOM_NO=WAP-316&FLAGS=3&PORT_ID=243&STATUS=8&VLAN_ID=66&UID=28656
04:25:51 <ChrisL> ChrisL has joined #svg
04:27:22 <ed> RESOLUTION: we will expose the global coordinate system in the SVG DOM somehow
04:27:51 <heycam> http://www.w3.org/Graphics/SVG/WG/wiki/Requirements_for_Mapping#DOM_access_API_for_cascading_SVG_Documents
04:28:36 <ed> CM: this is asking for the contentDocument on the referencing element (tiles, here it is the image and svgtiny12 animation element)
04:29:41 <ed> ED: don't think we want to allow this for <image>
04:30:01 <ed> CM: right, this is similar to <html:img>
04:30:07 <dino> dino has joined #svg
04:30:32 <ed> RESOLUTION: we will have contentDocument and contentWindow on svg elements that reference whole documents except for <image>
04:31:09 <ed> JF: wondering what we should do with the mapping TF
04:32:24 <dino> dino has joined #svg
04:33:26 <shepazu> shepazu has joined #svg
04:34:08 <ed> JF: ST talked about creating a community group in japan
04:34:26 <ed> ... but isn't sure if we could run a group in europe
04:34:36 <ed> CM: is this for tiling and layering?
04:34:56 <ed> CL: no, it's for general mapping things, tiling and layering should be done in svgwg
04:35:20 <stakagi> potentially Open Street Map and Open Layers
04:35:58 <stakagi> communities are candidate
04:36:12 <ed> DS: the SVG IG has not been very active
04:36:26 <ed> ... should we shut it down?
04:36:54 <ed> ... and make a community group for all of the svg community groups around the world
04:37:18 <ed> CM: is it the barrier of joining the group? or is it more of a don't-have-time thing?
04:38:11 <ed> DS: just want to make it easy for people to join the community group
04:38:30 <ed> ... still requires real experts to drive things forward
04:38:51 <ed> ... but we could reach a broader audience with a community group
04:39:01 <ChrisL> web mapping community group
04:39:06 <ed> ... we could have a dedicated mapping com group
04:39:20 <stakagi> http://www.openstreetmap.org/  http://openlayers.org/
04:40:28 <ed> DS: i contacted the openstreetmap folks
04:40:57 <ed> ... would be good to have an OSM person on the SVGWG
04:41:32 <ed> --- 15min BREAK ---
05:08:33 <birtles> Topic: SVG2 Requirements
05:08:39 <birtles> ScribeNick: birtles
05:09:32 <cyril> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#to-animateTransform_definition
05:10:21 <birtles> 2.14.4
05:11:04 <birtles> CM: so it's about how to get smooth animations for to-animation with animateTransform
05:11:42 <birtles> http://brian.sol1.net/svg/animatetransform-issues/to-animation-and-animatetransform/
05:12:27 <birtles> to-animation needs a base value but that's not always possible to get
05:12:53 <birtles> CM: because of how animateTransform only allows to provide a single transform even though it targets a transform list
05:13:23 <heycam> To animations provide specific functionality to get a smooth change from the underlying value to the ‘to’ attribute value, which conflicts mathematically with the requirement for additive transform animations to be post-multiplied. As a consequence, in SVG 1.1 the behavior of to animations for ‘animateTransform’ is undefined.
05:14:27 <heycam> ScribeNick: heycam
05:14:47 <heycam> BB: the bigger issue is that animateTransform deals with a single transform, but targets a transform list
05:14:51 <heycam> … that's where the problem comes up
05:15:07 <heycam> … how are you supposed to animate lists when the list lengths differ
05:15:12 <heycam> VH: they all stack up
05:15:18 <heycam> BB: but it's a special case, no other type of animation does that
05:16:09 <heycam> CM: <text x=""> for example doesn't have this implicit additive animation behaviour
05:16:18 <heycam> CC: so olaf wants us to revisit this restriction?
05:16:20 <heycam> … is he proposing something?
05:17:01 <heycam> VH: this is more of a bug in the spec, having this undefined
05:17:11 <heycam> CC: even if it doesn't make sense?
05:17:21 <heycam> VH: the spec should say something
05:17:37 <heycam> VH: we should define it, as being an error or as doing something
05:18:00 <heycam> CM: I'm assuming there are two different behaviours implementations take here?
05:18:16 <heycam> BB: Opera and Batik, if it can match up the transform types, it does a smooth interpolation
05:18:25 <heycam> … if it can't, then Opera will take 0 as the base value
05:18:48 <heycam> … and I think that's what we end up doing in Gecko, it tries to match it up
05:19:49 <heycam> ED: should we make this requirement more generic?
05:19:53 <heycam> VH: define all undefined things in the spec?
05:19:56 <heycam> ED: yes
05:20:18 <heycam> RESOLUTION: We will attempt to define all explicitly undefined parts of the SVG spec.
05:20:38 <heycam> CM: next, allow animateTransform type="matrix"
05:20:45 <heycam> VH: shouldn't this be allowed in the Transforms spec?
05:20:56 <heycam> DJ: yes, but Olaf doesn't like it
05:21:02 <cyril> RRSAgent, pointer
05:21:02 <RRSAgent> See http://www.w3.org/2012/01/10-svg-irc#T05-21-02
05:21:07 <heycam> ED: he wants the individual items in the matrix just interpolate
05:21:29 <heycam> VH: I remember we went over this years ago
05:21:46 <heycam> … if you do simple interpolation between matrix components, it has weird and unuseful visual results
05:21:53 <heycam> … as soon as you have a skew or rotation
05:21:58 <heycam> DJ: the SVG spec doesn't say how to get from matrix A to matrix B
05:22:44 <heycam> CL: we talked about doing piecewise interpolations
05:22:57 <heycam> CC: in d3.js it does each component
05:23:00 <heycam> DJ: it's not what we want though
05:23:12 <heycam> … I think SVG/SMIL animations should follow the same model that the combined Transforms spec says
05:23:21 <heycam> … which is decompose the matrix and use quaternions
05:23:32 <heycam> VH: or we have a switch, that's the default behaviour
05:24:03 <heycam> DJ: my answer to Olaf was, if there's someone who wants to do that they can decompose the matrix manually
05:24:35 <heycam> CC: you could have different type="" attribute values, type="matrix" and type="matrix-decomposed"
05:24:35 <dino> (which unfortunately doesn't always work)
05:25:50 <heycam> DJ: I think his point was that he might have composed a matrix in a different form from what the unmatrix algorithm does
05:26:40 <heycam> … I think it's OK to put forward the proposal right now to do matrix decomposition as specified
05:26:59 <heycam> … that's what 99% of people will want
05:28:55 <heycam> RESOLUTION: We will allow <animateTransform type="matrix"> in SVG2
05:29:09 <heycam> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Declarative_animation_value_conservation.2Fuse
05:29:47 <heycam> ED: maybe it is asking for reversing animations?
05:29:56 <heycam> … some way of getting the "from" or "to" value from what it is at the moment
05:31:26 <heycam> BB: the duration is a problem with animation reversing
05:31:50 <heycam> VH: if you do a to-animation, you have the hover effect from 0 to 100 then 100 to 0, if halfway you start the second one, it'll have a dampening effect
05:31:54 <heycam> … the first one is still trying to get to 100
05:32:04 <heycam> … but it's inconsistent with CSS animations
05:34:22 <heycam> CM: what did we already decide for animation reversing in SVG?
05:35:55 <birtles> time manipulations: http://www.w3.org/TR/SMIL/smil-timemanip.html
05:36:16 <birtles> http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Auckland_2011/Animation_improvements#Wanted_feature:_reversing_animations
05:36:22 <heycam> BB: last year I proposed reversing behaviour
05:36:50 <shepazu> +! to reversing
05:36:51 <heycam> … I think it's fair to split that into a separate requirement
05:37:09 <shepazu> s/+!/+1/
05:38:20 <heycam> VH: I think Olaf is asking for something like fill="freeze" but to change the actual value
05:38:20 <heycam> CC: what's the use for that? so the next to-animation would start from there?
05:38:21 <heycam> CL: yes
05:38:24 <heycam> VH: but we're just guessing
05:38:34 <Zakim> Zakim has left #svg
05:38:41 <birtles> http://lists.w3.org/Archives/Public/www-svg/2010Nov/0015.html
05:38:55 <heycam> ACTION: Cameron to mail Olaf to clarify http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Declarative_animation_value_conservation.2Fuse
05:38:56 <trackbot> Created ACTION-3199 - Mail Olaf to clarify http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Declarative_animation_value_conservation.2Fuse [on Cameron McCormack - due 2012-01-18].
05:40:05 <heycam> CM: seems to be asking for a way to declaratively (on click e.g.) get the current animated value and stick that in a variable
05:40:14 <heycam> … and then use that variable as a value in another animation
05:40:34 <heycam> … I don't know what this buys us
05:40:41 <heycam> ED: I wouldn't mind seeing use cases for that
05:44:07 <heycam> CC: you have the first animation on an element
05:44:09 <heycam> … it produces a value
05:44:12 <shepazu> (I think that it would be better to have some sort of animation state machine to drive interactions like that)
05:44:21 <heycam> … that value you want to keep it for each time you click on an element
05:44:40 <heycam> … once you've run the first to-animation, the second time you run it it won't animate, because the underlying value is the end value of the to-animation, it's not the end value of the animation before that
05:45:55 <shepazu> yes, SCXML could do that
05:46:15 <shepazu> (as done by BitFlash)
05:47:23 <heycam> RESOLUTION: We will not add getValue/setValue for animation value conservation and reuse without convincing use cases
05:47:59 <heycam> because this can be done easily with script
05:49:00 <heycam> next, animation reversing
05:49:11 <heycam> BB: maybe speed is useful too (from time manipulation module) but let's consider them separately
05:51:22 <heycam> CC: I will split the existing requirement request for time containers and time manipulation module
05:53:17 <heycam> CM: how does it work in Transitions and Animations?
05:53:31 <heycam> DJ: there's a difference between reversing the animation
05:53:35 <heycam> … it's just playing it backwards actually
05:53:54 <heycam> … auto reverse of a transition we also reverse the easing
05:53:54 <heycam> … like playing backwards
05:54:05 <heycam> … I think dbaron implemented that in Firefox
05:54:11 <heycam> … I'm still not completely convinced it's what you want 
05:54:25 <heycam> … auto reversing of transitions, that is
05:54:36 <heycam> … if during a transition you set the target value to whereever it was you were coming from, in that case you reverse
05:54:49 <heycam> … if you went from opacity 1 to 0, halway through you went to 0.999, you wouldn't get the same as going back to 1
05:55:21 <heycam> SS: I think it depends strongly on what the designer wants
05:55:37 <heycam> … we have a proposal in the CSS WG to control this, specify a range of different reversing behaviours
05:55:45 <heycam> CL: sounds better than magically relying on a particular value to trigger that behaviour
05:55:55 <heycam> DJ: the magic isn't so magic because normally you want auto reversing on hover transitions e.g.
05:56:05 <heycam> … going back to the same state, it's always the same value
05:56:13 <stakagi> stakagi has joined #svg
05:56:14 <heycam> CL: I agree it's useful, just quibbling with the way it's specified
05:56:17 <heycam> DJ: a good example is a bounce
05:56:26 <cyril> I've split the proposed requirement on time manipulation and time container into 2 req
05:56:33 <heycam> … you don't want that to just play in reverse
05:56:44 <cyril> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#SMIL_time_manipulation_module
05:56:46 <cyril> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#SMIL_time_containers
05:57:01 <heycam> BB: you could just make another animation if you want different reversing behaviour
05:57:05 <heycam> … in SVG you can't do reversing with the current features
05:57:08 <heycam> … we need something that can do that
05:57:25 <heycam> … if we have the timing features you could write it either way
05:57:32 <birtles> http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Auckland_2011/Animation_improvements#Wanted_feature:_reversing_animations
05:57:45 <cyril> http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Auckland_2011/Animation_improvements#Wanted_feature:_reversing_animations
05:57:46 <ed> http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Auckland_2011/Animation_improvements#Wanted_feature:_reversing_animations
05:58:12 <heycam> BB: I don't think I like any of the options I proposed
05:58:27 <heycam> … regarding the timing function, we should follow CSS Animations and not Transitions
05:58:35 <heycam> … where ease-in becomes ease-out if you reverse
05:58:37 <heycam> DJ: it's not just that
05:58:49 <heycam> … it's also as if it's an ease-out that started 0.7seconds into the animation
05:58:52 <heycam> BB: yes, you're right
05:59:36 <heycam> … as far as syntax I don't have a specific proposal
05:59:52 <heycam> … aligning with CSS Animations is important
06:00:37 <heycam> CM: let's discuss the other aspects of time manipulation module
06:00:38 <heycam> … for this requirement
06:00:58 <heycam> … let's start with acceleration/deceleration
06:01:06 <heycam> BB: I think that is keySplines on time containers
06:01:15 <heycam> … is that a useful feature? I think if we do time containers it probably is
06:01:38 <cabanier> cabanier has joined #svg
06:01:50 <heycam> … it's less powerful than keySplines
06:02:29 <heycam> VH: but not useful on individual animations?
06:04:10 <heycam> ACTION: Cyril to ask Jack Jansen the difference between accelerate/decelerate and keySplines
06:04:11 <trackbot> Created ACTION-3200 - Ask Jack Jansen the difference between accelerate/decelerate and keySplines [on Cyril Concolato - due 2012-01-18].
06:05:29 <heycam> http://www.w3.org/TR/SMIL/smil-timemanip.html#TimeManip-autoReverseSyntax
06:07:24 <cyril> http://www.w3.org/TR/SMIL/smil-timemanip.html#TimeManip-accelerateSyntax
06:08:41 <heycam> DJ: it's just a way to avoid writing keySplines, it's a nicer syntax for doing keySplines
06:08:50 <heycam> … I thought it was a multiplier but it's not
06:09:02 <heycam> … it's saying how fast it should be doing the "ease-in" part of the curve
06:09:32 <heycam> RESOLUTION: We will solve animation reversing in SVG2
06:11:48 <heycam> CM: then speed attribute
06:11:53 <heycam> BB: negative values will make it tricky
06:12:12 <heycam> … you have accumulated state as the animations progress
06:12:25 <heycam> … negative speed would take that into account
06:13:09 <heycam> VH: if speed is on a time container, it's like seeking back all the time
06:13:16 <heycam> s/speed/negative speed/
06:13:24 <heycam> … on an animation element it's not as much of a problem
06:15:58 <heycam> CC: we could disallow negative speed values
06:19:42 <heycam> CL: for accessibility reasons some people would want to play animations slower than usual
06:24:04 <heycam> RESOLUTION: We will have support for non-negative speed="" on time containers (if we decide to include time containers) in SVG2
06:26:16 <heycam> RRSAgent, make minutes
06:26:16 <RRSAgent> I have made the request to generate http://www.w3.org/2012/01/10-svg-minutes.html heycam
06:28:53 <heycam> Present: Doug_phone, Dirk_phone, Vincent, Cameron, Erik, Dean, Takagi-san, Dean, Jun, Cyril, Brian, Chris, Rik
06:29:01 <heycam> RRSAgent, make minutes
06:29:01 <RRSAgent> I have made the request to generate http://www.w3.org/2012/01/10-svg-minutes.html heycam
06:40:39 <jun> jun has joined #svg
10:01:12 <cyril> cyril has joined #svg
10:37:01 <cyril> cyril has joined #svg
10:45:50 <dino> dino has joined #svg
10:46:14 <dino_> dino_ has joined #svg