07:25:53 RRSAgent has joined #svg 07:25:53 logging to http://www.w3.org/2008/08/22-svg-irc 07:25:55 RRSAgent, make logs public 07:25:55 Zakim has joined #svg 07:25:57 Zakim, this will be GA_SVGWG 07:25:57 I do not see a conference matching that name scheduled within the next hour, trackbot 07:25:58 Meeting: SVG Working Group Teleconference 07:25:58 Date: 22 August 2008 07:26:05 Zakim, remind me in 8 hours that i shouldn't work too hard 07:26:05 ok, heycam 07:26:19 Meeting: SVG Nuremberg F2F Day 2 07:26:28 Present: Doug, Cameron, Anthony, Erik 07:31:01 ISSUE-2032? 07:31:01 ISSUE-2032 -- SVGT 1.2; 16.2.6 Paced animation and complex types -- RAISED 07:31:01 http://www.w3.org/Graphics/SVG/WG/track/issues/2032 07:31:02 scribenick: shepazu 07:31:43 Topic: ISSUE-2032 (Paced animation and complex types) 07:32:13 anthony has joined #svg 07:32:28 ED: let's look at the issues one by one 07:32:48 ED: "unnecessary assertion" 07:34:16 CM: seems a little nitpicky 07:34:32 ED: yes, not immediately neccessary to change 07:35:38 ED: let's move all the points we don't change now to Core for later... this is stuff we need to address at some point 07:35:48 ED: "Inconsistencies" 07:38:02 http://schepers.cc/w3c/svg/animationDiff/ani-changes.html 07:38:19 ED: is this still the same in the current draft? it seems it is 07:40:34 CM: he has changed it to disallow paced animation of path, data, or list values 07:40:51 ED: at least scalars or vectors or a mixture 07:41:12 DS: must this be addressed now? 07:41:27 ED: it's quite a big change 07:41:40 DS: we're probably going to revamp animation a bit later anyway 07:42:03 CM: I agree that the definitions are a bit arbitrary... what does 1.1 say 07:43:19 ED: it's not in 1.1 07:43:45 CM: so, he's hoping to get it right the first time, since this was added for clarification 07:43:55 ... but it's already implemented as specced 07:44:38 DS: could we change in in the next version without breaking compatibility? 07:44:46 ED: not sure 07:45:35 DS: we should have discussed this a long time ago 07:49:50 ED: it is a little inconsistent, but it's good to have it defined 07:51:58 CM: the spec has the easiest definition that makes a small amount of sense, and I don't think there's much to be gained by removing it at this point 07:55:44 "Wrong notation of value type" 07:56:01 ED: I think he's correct with this, and we could make this change easily 07:56:23 CM: I could fix this up 07:57:13 Resolution: we will make sure all the value types to have to the the type definitions, and will fix the formatting of the data 07:57:47 Action: heycam to fix the notation of value types for paced animation 07:57:47 Created ACTION-2149 - Fix the notation of value types for paced animation [on Cameron McCormack - due 2008-08-29]. 07:58:40 ED: "Obscure definition" 07:59:01 CM: he's right about this one too 07:59:51 ED: all of the control points --all of the values of the path syntax-- should be used 08:00:17 CM: bit weird... what about flags for arcs 08:00:32 ED: Tiny doesn't have arcs 08:02:10 ED: so, what should we replace point with? 08:05:01 CM: we need to treat coordinate values as pairs, not as individual values... the formula only includes control points, I think 08:05:28 .... wait, it looks like we already made a change 08:05:52 AG: I think Andreas made that change 08:07:56 http://dev.w3.org/cvsweb/SVG/profiles/1.2T/master/animate.html.diff?r1=1.84&r2=1.85&f=h 08:08:00 http://www.w3.org/Graphics/SVG/Group/track/actions/1337 08:09:17 http://lists.w3.org/Archives/Public/www-svg/2006Jun/0089.html 08:10:12 ED: "Obviously absurd formula" 08:17:24 "Trying to add an angle to a length is similar as to add one second to one kg minced meat" 08:17:33 (awesome line) 08:18:30 CM: I'd be happy to change that to only look at the angle and not at the origin of the rotation 08:19:32 ED: what if you have 2 rotate transforms that have different center of rotation, and you want to do paced? 08:25:22 CM: if we disregard the centerpoint, and make the distance based only on the difference of angle.... 08:26:07 ... if you have animation where the centerpoints are different, but the angles are the same, then that segment of the animation will take 0s 08:26:42 ... and translation should be applied separately 08:28:58 so remove "sqrt((v_a1 [0] - v_b1 [0])^2 + (v_a1 [1] - v_b1 [1])^2))) / 2" from the rotate 08:29:32 Resolution: stop adding seconds to minced meat 08:29:34 Action: heycam to stop adding seconds to minced meat 08:29:34 Created ACTION-2150 - Stop adding seconds to minced meat [on Cameron McCormack - due 2008-08-29]. 08:31:09 Chair: "Surprising formula for transform scale" 08:36:24 ED: the rationale for the formula is not explained, so the context is missing for people trying to use it 08:36:42 ... on the other hand, that is something we could add later 08:36:55 CM: unless we discover it makes no sense :) 08:40:48 CM: looking at Batik... I just add the difference between the 2 dimensions, which is less sensible 08:41:15 CM: Euclidian does make some sense 08:45:24 Resolution: we will use Euclidian distance formulae for type scale 08:45:53 Action: heycam to change paced animation of scale to use Euclidian distance formulae 08:45:54 Created ACTION-2151 - Change paced animation of scale to use Euclidian distance formulae [on Cameron McCormack - due 2008-08-29]. 08:46:31 Chair: "Interpretation of some given formulas missing" 08:46:41 ED: let's defer this until later 08:47:17 Chaiir: ED 08:47:22 Chair: ED 08:47:52 ED: "The section is incomplete" 08:49:32 ED: list of coordinates is the same as list of length 08:49:34 ... list of number should also be the same 08:50:04 ED: coodinate+ might be different 08:54:34 CM: "coordinate+" should be "list of coordinate", and "number+" should be "list of number" 09:00:21 DS: I'm a little concerned about changing this 09:01:20 ... coordinate+ is a special case of the list, with at least one value 09:02:59 Resolution: we will change "coordinate+" to "list of coordinate", and "number+" to "list of number" for consistency, and constrain them in the element definition to have at least one value 09:03:20 Action: heycam to change "coordinate+" to "list of coordinate", and "number+" to "list of number" for consistency 09:03:21 Created ACTION-2152 - Change \"coordinate+\" to \"list of coordinate\", and \"number+\" to \"list of number\" for consistency [on Cameron McCormack - due 2008-08-29]. 09:04:49 Resolution: we will add change "list of coordinate" and "list of number" to the paced animation table, with the same distance formula as "list of length" 09:05:09 s/add change/add/ 09:06:21 Action: heycam to add "list of coordinate" and "list of number" to the paced animation table, with the same distance formula as "list of length" 09:06:21 Created ACTION-2153 - Add \"list of coordinate\" and \"list of number\" to the paced animation table, with the same distance formula as \"list of length\" [on Cameron McCormack - due 2008-08-29]. 09:10:43 Action: fattony to split unresolved points of ISSUE-268 / ISSUE-2032 into individual issues for Core 09:10:43 Created ACTION-2154 - Split unresolved points of ISSUE-268 / ISSUE-2032 into individual issues for Core [on Anthony Grasso - due 2008-08-29]. 09:12:54 trackbot, close ACTION-2152 09:12:54 ACTION-2152 Change "coordinate+" to "list of coordinate", and "number+" to "list of number" for consistency closed 09:46:00 ed has joined #svg 09:47:19 scribe: Erik 09:47:26 scribeNick: ed 09:47:33 Topic: DOM 3 Events 09:48:07 DS: D3E is not going to be a REC in december 09:48:41 ...don't want to rush the D3E spec out 09:50:02 ...we're going to have to remove the svgt12 dependency somehow 09:50:12 ...most of the things we need are in dom 2 events 09:50:25 ...we could change most of the references 09:51:29 ...for those places where we depend on D3E we can put the additions in the uDOM or as an appendix 09:51:39 ...probably better as an appendix 09:52:07 CM: what parts of D3E do we depend on? 09:52:13 ...namespaced events? 09:52:28 ED: no, svgt12 events are in no namespace 09:52:40 DS: it's mostly the keyboard stuff 09:53:06 ...and that is implemented in SVG UA:s is from the D3E snapshot from a couple of years ago 09:53:22 ...there's talk about changing D3E 09:53:55 ...for the purpose of svgt12 it's probably better if we use that snapshot 09:54:46 DS: there are three different ways to identify a key 09:55:14 ...the named key (unicode name), the unicode value (the codepoint), and the actual character itself (for keys that have characters) 09:55:45 ...the control key is an example that has to be a named key because there's no unicode value for it 09:56:30 CM: as long as these new things are added to this old keyidentifier and the model doesn't change much, then I think putting in what was in d3e into tiny12 is a workable solution 09:57:11 DS: is the capital 'Q' returned for the 'q' key 09:57:19 ...and what is the value of the key 09:58:02 ...it's not predictable because of keyboard mapping between modified and unmodified key values 09:58:12 ...we need to figure out how that affects keyidentifier 09:58:28 CM: it is likely to be different from that 2year old draft 09:59:26 DS: there could be an additional attribute on keyevent, keyvalue that is the actual mapped value for that key given its modifier state 10:00:20 CM: good to expose this in this new keyevent 10:00:30 ...the old draft doesn't expose this 10:08:35 DS: I think we're going to have to use the unicode values, and D3E will be more comprehensive 10:09:41 ...the softkeys will be in an appendix but non-normative 10:17:32 RESOLUTION: to add a snapshot of keyidentifiers and KeyboardEvents from D3E to SVGT12 10:17:53 ...and TextInputEvent 10:19:54 CM: there's also CustomEvent, do we care about that? 10:20:01 DS: no 10:20:25 CM: there's nothing using them explicitly in svgt12 10:20:52 ...there's MutationNameEvent 10:21:03 ...not using that either 10:21:07 ...wheelEvent 10:21:18 DS: we have that, but we're aligning 10:22:33 CM: all of the namespace-aware methods addEventListenerNS, removeEventListenerNS . The initEventNS method isn't used in uDOM. 10:23:31 DS: all examples in the svgt12 spec should be corrected to not use namespaced events 10:24:21 ACTION: DS to add the keyboard events from DOM 3 Events to an SVGT12 appendix 10:24:21 Created ACTION-2155 - Add the keyboard events from DOM 3 Events to an SVGT12 appendix [on Doug Schepers - due 2008-08-29]. 10:26:50 CM: there's defaultPrevented in uDOM 10:27:03 ...but stopImmidiatePropagation isn't in uDOM 10:30:05 DS: maybe we can mark defaultPrevented as "at risk" 10:30:55 CM: there are a couple of methods that throw more exceptions than in DOM 2 Events 10:31:45 EventTarget.dispatchEvent() was changed to throw a new exception (DISPATCH_REQUEST_ERR, which is also a new constant on EventException) 10:32:15 ...EventTarget.dispatchEvent isn't in uDOM 10:32:29 ...and we don't have the EventException interface either 10:33:09 ...canDispatch on DocumentEvent (not in uDOM) 10:35:31 ...getModifierState on MouseEvent and KeyboardEvent (not in uDOM explicitly but we're going to add that method explicitly) 10:37:30 ...we're not adding hasFeature 10:38:28 ...focus, blur, dblclick were added to D3E but are not included in SVGT12 10:49:26 ACTION: Cameron to fix transition from DOM 3 Events to DOM 2 Events and uDOM, and to fix testsuite 10:49:26 Created ACTION-2156 - Fix transition from DOM 3 Events to DOM 2 Events and uDOM, and to fix testsuite [on Cameron McCormack - due 2008-08-29]. 10:53:45 trackbot, close ACTION-2154 10:53:45 ACTION-2154 Split unresolved points of ISSUE-268 / ISSUE-2032 into individual issues for Core closed 12:03:06 ed has joined #svg 12:05:04 scribe: erik 12:05:08 scribeNick: ed 12:05:35 Topic: camerons issues 12:05:38 http://www.w3.org/mid/20080808065205.GD4643@arc.mcc.id.au 12:07:05 RESOLUTION: take out from the SVGT12 RNG and the types chapter 12:07:14 RATIONALE: it's not used anywhere 12:07:26 http://www.w3.org/mid/20080809063244.GA22724@arc.mcc.id.au 12:07:57 CM: I noticed that references uses sometimes the latest, sometimes the dated version 12:08:59 DS: we shouldn't use the latest version 12:10:34 http://www.w3.org/mid/20080810103228.GB8910@arc.mcc.id.au 12:10:55 CM: various places that should use 'lacuna value', but i wasn't sure 12:12:08 DS: looks like it should say lacuna value 12:12:24 http://www.w3.org/mid/20080811062030.GG18982@arc.mcc.id.au 12:15:51 CM: regardless of type of element the first element whose conditions evaluate to true will be the chosen one 12:15:55 ...in a switch 12:17:41 ED: so it shouldn't be talking about rendering elements, but processing of elements 12:26:40 ...style changes agreed upon, but it's low priority 12:26:50 http://www.w3.org/mid/20080811065441.GJ18982@arc.mcc.id.au 12:27:53 ED: it seems strange, there could be use-cases for having test-attributes on tbreak 12:29:08 http://www.w3.org/mid/20080811070750.GK18982@arc.mcc.id.au 12:30:17 DS: agree that it shouldn't run or remove itself 12:30:23 http://www.w3.org/mid/20080812123435.GA14080@arc.mcc.id.au 12:32:18 DS: yes, change the should to a must there 12:34:54 http://www.w3.org/mid/20080818004208.GB18063@arc.mcc.id.au 12:37:59 DS: I think CTM shouldn't include user transforms 12:38:12 CM: there should be two terms, screen CTM and CTM 12:39:18 ...I'll write some tests for it and come back with a proposal 12:39:26 http://www.w3.org/mid/20080808063636.GA26296@arc.mcc.id.au 12:40:12 DS: suggest mailing CL about this 12:40:54 http://www.w3.org/mid/48A3AE10.3040407@w3.org 12:43:46 RESOLUTION: we will the ElementTraversal stuff in SVGT12 "at risk" and reference the DOM 3 ElementTraversal spec instead 12:43:59 s/will/will mark/ 12:44:53 ACTION: Cameron to do all of the actions discussed above 12:44:53 Created ACTION-2157 - Do all of the actions discussed above [on Cameron McCormack - due 2008-08-29]. 12:48:24 Topic: Action triage 12:48:30 http://www.w3.org/Graphics/SVG/WG/track/products/2 12:50:01 aemmons has joined #svg 12:52:47 sure 12:58:02 anthony has joined #svg 13:20:17 DS: the last day of the SVG testfest in Ottawa (sept 29-oct 2) will be dedicated to last call comments 13:22:44 scribe: anthony 13:22:52 ScribeNick: anthony 13:24:28 ED: 29 Actions left 13:24:39 Topic: ACTION-2011 13:24:44 ED: Something we could hold off 13:25:07 shepazu has joined #svg 13:25:10 ... I don't expect the JSR group to give a response in the time frame we have 13:25:33 CM: I don't understand what this is about 13:26:28 ED: The JSR Group wrote about taking out get and set attribute in uDOM 13:26:39 ... they are not including in JSR 287 13:26:41 http://lists.w3.org/Archives/Member/w3c-svg-wg/2008AprJun/0055.html 13:26:45 s/in/it/ 13:26:52 CM: Why? 13:26:59 ED: Due to complexities 13:27:47 DS: We should just leave it as is 13:29:12 ... it's really useful for users 13:29:21 ED: I'm tempted to say leave it in 13:29:27 ... is there any reason not to 13:29:33 ... we added because of CDF 13:29:44 ... still makes sens in mixed context 13:30:15 s/sens/sense/ 13:30:35 DS: Users are going to expect them to be there 13:31:02 CM: If you have to support arbitrary attributes on elements you have to store them 13:31:11 ... if you use traits you wouldn't have to store them 13:32:52 DS: Perhaps we should make them a should 13:33:32 CM: Why did CDF add them? 13:33:40 ED: Wanted this to be used in HTML 13:34:40 CM: So for the non prefixed attribute you don't need to store the names 13:34:48 ... because there can only be one spelling for it 13:35:08 ... for prefixed things you need to store the prefix 13:35:38 ED: They are just asking us to consider dropping it 13:36:01 DS: We don't me make it a should? 13:36:06 ED: Then you can't depend on it 13:36:38 DS: If you intend it to work on mobile devices you should use the name space versions 13:37:11 ED: We spoke with CDF to have them in their spec 13:37:54 AG: Why don't we leave it as is, then we don't have anything to do? 13:38:26 DS: Because it's going to be non-conforming and they've given a valid reason 13:39:20 ... when doing it in a mixed content environment you should expect it to be there 13:40:41 CM: From a CDF point of view would that be considered it being taken out 13:40:52 ... it is a bit strange to have should things on an interface 13:43:13 ED: We could get a clarification 13:43:18 ... address it for Core? 13:43:44 ... postpone? 13:45:23 ... I say we close the action 13:46:03 RESOLUTION: We will close ACTION-2011 and we will leave the set and get interface as is 13:46:16 trackbot, close ACTION-2011 13:46:16 ACTION-2011 Write JSR 287 EG and ask for clarification regarding setAttribute/getAttribute use cases closed 13:46:51 http://www.w3.org/Graphics/SVG/WG/track/actions/2014 13:46:51 Topic: ACTION-2014 13:47:14 ED: This is on Chris 13:47:16 http://lists.w3.org/Archives/Public/www-svg/2008Apr/0069.html 13:47:22 http://www.w3.org/2008/05/13-svg-minutes.html#item04 13:47:24 ... is any one comfortable on font family selection rules 13:48:31 ED: Old wording wasn't very good 13:48:39 CM: Interesting the ligature one - D 13:51:51 ... there are two things 13:51:59 ... he wants a better fallback algorithm 13:52:18 ED: He's saying you can get something which the test is not testing 13:53:30 http://dev.w3.org/SVG/profiles/1.2T/test/svg/fonts-glyph-04-t.svg 13:58:13 ED: Is this something we need to change in the spec 13:58:28 ... or is this a test that needs to be changed 13:59:25 DS: I'll email Chris asking about this 13:59:59 Topic: ACTION-2022 14:00:05 http://www.w3.org/Graphics/SVG/WG/track/actions/2022 14:00:22 CM: Sounds similar to what we discussed about yesterday 14:00:28 DS: Different question 14:00:34 ... and should be deferred 14:00:38 ... change it to SVG Core 14:01:14 Topic: ACTION-2023 14:01:21 http://www.w3.org/Graphics/SVG/WG/track/actions/2023 14:02:32 CM: Wait we decided something different yesterday 14:03:08 DS: So what have we decided on? 14:03:10 CM: That it is an error 14:03:54 http://lists.w3.org/Archives/Public/public-svg-wg/2008AprJun/att-0082/20080520-svg-minutes.html#item03 14:04:17 CM: Perhaps the action came out of the same issue we had 14:04:19 ED: Could have 14:04:51 ... was this to allow tests to be written for circular reference? 14:05:29 CM: The spec doesn't say where the unsupported thing happens 14:06:00 DS: We changed it because opacity is difficult to check how many iterations 14:06:11 ... we changed it so it shifts the shape downwards 14:06:24 ... the question is what is the visible sign of an error 14:06:58 ED: Should we revisit the resolution from yesterday? 14:08:13 DS: What is the difference with treating it as an error or an unsupported value? 14:08:31 ... unsupported value it goes back to the Lacuna value 14:09:49 ... there is no Lacuna value for xlink:href 14:09:51 ED: For animation it's the parent element 14:10:00 ... but would result in odd behavior 14:10:27 DS: We talked about this yesterday and we went through a change of reasoning 14:10:31 ... that's sounds 14:10:57 CM: So this action is about changing the spec 14:11:03 ... if we leave it as is 14:11:07 ... what about the test 14:11:15 AG: The test is fine as long as the UA doesn't blow up 14:11:46 CM: Full 1.1 says render up until the broken thing 14:11:52 ... what do you do in this case? 14:12:11 DS: An error is underspecified 14:12:16 ... maybe we should specify it 14:12:24 ... we could say for example 14:12:45 ... in a recursion that the render should stop for that recursion and then render 14:12:53 ... as able 14:13:31 CM: The first one that you come across in rendering tree order 14:13:54 DS: Can be quiet complicated 14:14:17 ... some UAs allow a certain level of circular reference 14:14:34 ... the only problem with circular references is the risk of excessive memory usage 14:14:42 ... that's why we don't want to allow it 14:14:58 ED: So yesterday did we have any action on that? 14:15:01 DS: No 14:15:08 ... but we should say what an error means 14:15:57 CM: [Reads out passing condition of test] 14:16:08 ED: So you'd have one level or recursion 14:16:18 DS: No not necessarily 14:16:40 CM: So you don't even rely on one cycle 14:19:20 DS: [Tests different implementations] 14:20:24 DS: In my point with regards to error handling, in the case of recursion the 14:20:28 ... change should be broken 14:20:34 ... but we don't say where 14:20:57 ... perhaps at a UA specific time of detection of the loop 14:21:14 CM: For the test case say that circles will appear, duplicates will not 14:21:46 DS: We should further say that, UAs must continue to render the document as they are able 14:24:05 ... comes down to a highly perceivable error 14:25:11 CM: At the moment it doesn't say what to do about the rendering of the document when there is an error 14:25:19 ... we could say use a Lacuna value if there is one 14:25:31 ... and not render it if there is none 14:25:40 ED: The Lacuna value may not make sense 14:25:56 DS: Hang on, what causes errors? 14:28:59 ED: In Animation chapter 14:29:02 ... for the begin attribute 14:29:06 ... there is some wording 14:29:12 ... saying that if the Begin attribute is in error 14:29:22 ... it's equivalent to blah 14:29:30 ... should say SMIL error 14:29:44 see http://www.w3.org/TR/2005/REC-SMIL2-20051213/smil-timing.html#Timing-ErrorHandlingSemantics 14:32:47 RESOLUTION: Circular dependencies are an Error. Error handling needs to be better defined 14:34:35 syntactically invalid 14:36:58 AG: What about application/java-archive 14:37:01 ... in scripting 14:37:18 ... if the EventListenerInitializer2 is not implemented, it is an error 14:37:25 ... should this be a Java error? 14:50:02 http://www.explain.com.au/oss/libxml2xslt.html 14:51:01 CM: Does it need to an error? 14:51:29 s/to an/to be an/ 14:51:57 ... it doesn't seem to be like a particularly bad thing that needs to be an error 14:52:04 ... I think just say that nothing is run 14:52:12 ED: Would be nice to show a message about it 14:52:28 DS: Unsupported will also put something in the console 14:53:56 CM: If it's not in error where else will we hook in? 14:54:07 ... we could say that the element is unsupported 14:54:24 ... if it doesn't pull in script 14:54:40 ... so the equivalent Java script is it tries to evaluate it 14:54:50 ... and through an unsupported type error 14:54:57 s/error/exception/ 15:14:53 http://dev.w3.org/SVG/profiles/1.2T/master/script.html 15:15:12 ED: Ok to leave it I guess 15:16:41 Topic: ACTION-2024 15:16:48 http://www.w3.org/Graphics/SVG/WG/track/actions/2024 15:19:11 DS: Ok 15:19:15 ... this is an easy on 15:19:19 s/on/one/ 15:20:05 http://lists.w3.org/Archives/Public/public-svg-wg/2008AprJun/att-0082/20080520-svg-minutes.html#item03 15:20:27 Topic: ACTION-2027 15:20:34 http://www.w3.org/Graphics/SVG/WG/track/actions/2027 15:22:07 ED: I guess it is possible to calculate some kind of range 15:22:41 CM: What does it mean... is the current range wrong? 15:22:58 ... the current restrictions are make it easy for users typing content 15:23:09 ... the range is such that it's suitable for 16 point 16 numbers 15:23:18 ... not sure what it'd be changed to in this action 15:26:04 ... chapter is types 15:26:06 heycam, you asked to be reminded at this time that i shouldn't work too hard 15:26:38 Zakim, remind me in 2 hours that I'm awesome 15:26:38 ok, anthony 15:27:58 CM: Have we used more than 4 decimal places in tests? 15:28:42 ED: Don't think it's such a big thing 15:29:23 ... haven't had anyone complain about the epsilon that we are using 15:29:40 CM: Dr Olaf's test have some to 8 decimal places 15:36:58 ED: From what I remember it was about calculating the epsilon for the test 15:37:41 CM: There are 27 tests have a dot followed by 5 digits 15:37:53 AG: 5 or more 15:37:55 CM: Yes 15:38:35 ED: What about scientific notation 15:38:51 ... I think we should continue? 15:40:52 DS: We should change the tests at a later point 15:42:05 CM: So move the action to the test suite 15:43:16 Topic: ACTION-2048 15:43:24 http://www.w3.org/Graphics/SVG/WG/track/actions/2048 15:44:11 CM: Change it for text content element and not block elements 15:44:18 ED: I guess I can do that tomorrow 15:44:36 AG: We could split it 15:44:45 ... so that you only do the Tiny 1.2 bit 15:44:57 Topic: ACTION-2063 15:45:22 CM: Got a reply about it 15:45:29 ... I'll be doing it 15:45:44 Topic: ACTION-2072 15:45:54 ED: Already done the issue 15:46:01 ... action can be closed 15:46:16 Topic: ACTION-2075 15:46:21 http://www.w3.org/Graphics/SVG/WG/track/actions/2075 15:47:19 DS: Problem is a duplicate id 15:48:37