15:50:31 RRSAgent has joined #svg 15:50:31 logging to http://www.w3.org/2009/06/09-svg-irc 15:50:33 Sorry, heycam, I don't understand 'trackbot, hello'. Please refer to http://www.w3.org/2005/06/tracker/irc for help 15:50:36 See http://www.w3.org/2005/06/tracker/irc for help 15:50:42 RRSAgent, make logs public 15:50:44 Zakim has joined #svg 15:50:46 Zakim, this will be GA_SVGWG 15:50:46 I do not see a conference matching that name scheduled within the next hour, trackbot 15:50:48 Meeting: SVG Working Group Teleconference 15:50:50 Date: 09 June 2009 15:52:21 ScribeNick: ChrisL 15:52:33 Topic: SVG2 15:53:10 CL: we have a bunch of open issues on svg2 now, things to discuss that wewre deferred 15:53:19 ED: Start from a spec 15:53:40 CM: Start from scratch, no grandfathering. More concise 15:54:02 ... examples are fine, but crisper conformance statements 15:54:44 JW: should not need the examples to understand the rest 15:54:56 CM: Not as pseudocodey as HTML5 15:55:18 ED: Goal is to pick parts from tiny 1.2 and full 1.1, merged into one spec 15:55:35 CM: Also some things that are not the right thing that we could change 15:56:56 CL: Is it possible to conform to both svg2 and svg 1.1/1.2T? Need to decide on expectetions for older user agents etc 15:57:36 CM: Once svg2 is in the repo it will lead away from fixing up 1.1 15:58:03 ED: merging does not exclude mobile, this is a spec for desktop and mobile. new iphone supports acid 3 as an example 15:58:17 ... opera 9.7 on windows mobile also passes 15:58:57 CM: Forwards/back compat like Tiny, not a complete break 15:59:08 CL: So not a new mime type for example 15:59:29 CM: Userr base is more adapatble 16:00:14 s/also passes/gets a 100/100 score/ 16:01:07 rrsagent, make minutes 16:01:07 I have made the request to generate http://www.w3.org/2009/06/09-svg-minutes.html ChrisL 16:01:43 cl: we bneed to not piss off existing adopters like inkscape, kde, xslfo+svg users 16:02:21 Chair: Erik 16:02:24 s/also passes/gets a 100\/100 score/ 16:02:37 Present: Cameron, Erik, Doug, Jonathan, Chris 16:02:44 rrsagent, make minutes 16:02:44 I have made the request to generate http://www.w3.org/2009/06/09-svg-minutes.html ChrisL 16:03:23 s/also passes/scored 100 out of 100/ 16:04:37 CL: perhaps we could list our hated or unuseful features 16:04:55 JW: eRR needs better defined 16:05:07 ED: vertical text needs better defined 16:05:23 JW: Lets have a wiki page for this 16:05:52 CL: two secions, one hitlist for dropping and one underdocumented list 16:13:11 rrsagent, make minutes 16:13:11 I have made the request to generate http://www.w3.org/2009/06/09-svg-minutes.html ChrisL 16:24:27 http://dev.w3.org/SVG/modules/color/master/color-syntax.txt 16:29:26 ACTION-2550: http://dev.w3.org/SVG/modules/color/master/color-syntax.txt 16:30:29 Sorry... adding notes to ACTION-2550 failed, please let sysreq know about it 16:33:41 http://a.deveria.com/caniuse/#agents=All&eras=All&cats=SVG,Summary&alts=j&statuses=rec,cr,wd,ietf 16:41:37 CL: so i think that gradients which link to other gradients has turned out to be a misfeature 16:47:02 CL: Markers are an issue, in a new language i would not have markers, instead i would have a separate polymarker element 16:49:10 CL: painted bounding box 16:49:21 JW: getting pbb is very expensive 16:49:42 ed: yes, it can be. requires off screen painting in many cases 16:50:14 (some yes it is, no it isn't ratholing) 16:50:25 my it seems to be almost lunchtime 16:56:19 http://www.selenic.com/mercurial/wiki/CvsConcepts 17:05:22 break for lunch 17:11:58 eseidel has joined #svg 17:54:56 karl has joined #svg 17:58:35 eseidel_ has joined #svg 18:02:46 Zakim has left #svg 18:22:38 ed has joined #svg 18:45:00 back from lunch 18:49:04 DS: Like to lookat the polar element, and nurbs 18:50:00 http://en.wikipedia.org/wiki/Nurbs 18:53:24 Topic: making things properties 18:54:04 ED: CSS wg seemed to think some of our attrs were suitable as properties, not all of them 18:54:56 CL: So you want to make all attrs properties, doug? 18:55:03 DS: Yes prtetty much 18:55:10 CL, JW: Why? 18:55:19 ACTION-2569? 18:55:19 ACTION-2569 -- Erik Dahlström to draft a proposal to have width and height properties -- due 2009-05-27 -- OPEN 18:55:19 http://www.w3.org/Graphics/SVG/WG/track/actions/2569 18:55:37 DS: Want to use classes to affect other things than style. d== no, href, id, no.... 18:55:46 JW: Prefer to add on a case by case basis 18:55:49 ED: yes 18:56:19 DS: More a thought exercise 18:56:35 CM: Could use stuff from css3 values and units, so calc() 18:57:13 CL: Would rather have a calculation facility that would work on attrs and properties 18:57:35 CM: My thinking was that if its easy to turn attr to prop to get that functionality then do that 18:57:51 ... if we can ger a syntax that works on non-property attrs that is good 18:58:17 ED: So see which of ourt attrs have an existing css property, width and height obvious ones 18:58:24 CM; If they have the same meaning 18:58:32 http://dev.w3.org/SVG/profiles/1.1F2/publish/attindex.html 18:58:34 s/outs/our/ 18:59:18 ED: Is there a global list of all css properties from all css3 drafts? 18:59:24 CL: Not as far as I know 18:59:51 document.properties.iterate() 19:02:15 (discussion on the difficulty of aggregating specs from multiple WGs) 19:02:35 ED: transform is going into css, so there is anothetr one. need to define for 2dtx 19:03:07 CM: Likely that animatable attes should be properties (as a first cut) 19:03:54 ... transform, width, height 19:04:14 ED: x1 y1 cs cy etc do not have a direct mapping, but could be more useful 19:04:36 s/cs/cx/ 19:04:51 DS: rx ry has applicability, rounded corners 19:05:12 CL: thats border-radius 19:05:52 JW: Properties that inherit into stuff need to have consistent meanings from html and css. not so critical for non-inherited properties 19:06:54 JW: Concerned over making everything a property 19:07:08 CL (amusing tale of xml:id becoming inherited in C12n) 19:07:34 ED: Could get benefts by yusing transform together with width and height 19:07:42 CM: Not with rounded corners 19:08:05 ... rx has different meaning on rect and ellipse 19:09:32 DS: Not terribly different 19:10:22 DS: Yesterday I mentioned wanting rx, ry and stroke on image, as a poor mans clippath 19:12:01 DS: Is there an optimisation hit for that ... not sure its worth it. But typically can see the thing you are clipping 19:12:16 CM: Can use 'use' in clippath 19:12:32 ... pointing to a graphical shape 19:18:18 (brief discussion about ITU liaison as we remember they meet soon) 19:18:45 ED: Some things that udom is good for and full dome does not cover, like pulling out a path from a glyph element 19:18:54 ... missing from 1.1, should be added 19:19:09 ... typed access is better for presentation properties, better than dom2 style 19:20:54 CM: onclick, not a property 19:26:00 (digression on JSRs) 19:26:20 CM: things that have lengths 19:26:31 DS: Things that don't have complex types 19:26:47 cm: polyline - list of numbers, nt lengths 19:27:00 ds: often wanted a percentage on a path. 19:27:06 CM: Or H 2em 19:29:36 rrsagent, make minutes 19:29:36 I have made the request to generate http://www.w3.org/2009/06/09-svg-minutes.html ChrisL 19:30:36 ED: How does css transform integrate into svg, and what about gradient transform? 19:30:59 ... why is it even called gradient-transform and not just transform 19:31:31 ... and pattern-trandform 19:31:41 CL: and svg:transform 19:32:31 CM: Points is ok as a property value, but not things more complex than lists of simple types 19:35:48 (digression on consistent list syntax in SVG2) 19:37:14 ED: Mozilla has transforms in css. does it aply to svg, currently 19:37:22 JW: No it does not, yet 19:38:29 ... need to say the property is mapped , or that it takes precedence 19:38:46 ... practicval difference if its made to inherit 19:38:54 ED: Not difficult to make it inherit 19:39:10 JW: what if therre is an animateTransform 19:39:23 ED: Works on the eventual transform, after cascading 19:44:04 CL: (explains CSS and XML animation) 19:44:37 CL: doing animates the property, it's not possible to animate the presentation attribute separately 19:45:51 ed: JW could you look into how svg transforms and css transforms interact on svg content? 19:45:55 JW: sure 19:46:11 action: jwatt to look into how svg transforms and css transforms interact on svg content? 19:46:11 Created ACTION-2603 - Look into how svg transforms and css transforms interact on svg content? [on Jonathan Watt - due 2009-06-16]. 19:48:56 http://dev.w3.org/csswg/css3-values/ 19:54:59 http://dev.w3.org/csswg/css3-values/#the-calc-function 19:57:55 so calc only does constant expressions on lengths 19:58:22 which must have a unit 19:58:32

20:00:02 Issue: At a later date new operators such as min/max, conditionals, new constants, division by length units etc. may be added. 20:00:02 Created ISSUE-2278 - At a later date new operators such as min/max, conditionals, new constants, division by length units etc. may be added. ; please complete additional details at http://www.w3.org/Graphics/SVG/WG/track/issues/2278/edit . 20:01:53 CM: it'd be a bit annoying to have to say instead of 20:02:16 CM: oh no, it's the scientific notation that is restricted 20:02:42 CM: so you couldn't say 20:03:05 CM: and scientific notation is primarily useful for geometric attributes like width="" on 20:11:18 http://dev.w3.org/SVG/profiles/1.1F2/ua-tests/presentationattr-scientificnotation.svg 20:13:22 Opera, Firefox and Safari all behave slightly different on that testcase 20:17:10 (we agree to try again to get sci.not accepted in css) 20:20:39 CM: units optional in presentation attrs, but required in stylesheets 20:21:21 action: jwatt rock the roc re sci.not 20:21:21 Created ACTION-2604 - Rock the roc re sci.not [on Jonathan Watt - due 2009-06-16]. 20:30:57 Topic: Fonts 20:31:22 scribeNick: ed 20:31:51 CL: we have a fonts module, but it's not checked in 20:32:02 ...john daggett has done some of the work 20:32:12 ...subsetting to the parts that are implemented 20:32:26 ...extended fontmatching stuff dropped 20:32:51 ...things that are missing: standalone spec for svgfonts with different conformance levels, for xsl 20:33:00 ...though they might also want opentype fonts 20:33:24 ...extensions of fonts, vertical text 20:33:33 ...other things missing: xml syntax 20:35:42 CL: svgs xml syntax, other spec could cameleon it into another spec 20:35:56 ...commenting on css3 fonts 20:36:07 ...jdaggett is writing tests 20:36:14 ...I'm converting them to svg syntax 20:36:25 ...want to put them into the svg testsuite 20:36:51 ...he's only testing HTML implementation 20:37:19 CM: saw the mail you sent out about existing implementatioins 20:37:28 ...among which are several svg impls 20:37:59 CL: i feel we need more font tests 20:39:06 ...good to see opera shipping with support for svgfonts and truetype fonts 20:39:34 CM: what about hte module? 20:39:50 CL: if it's useful to make a module then I can do the work 20:39:59 CM: useful if we need to define something for xsl 20:40:38 ...wopuld the module have @font-face equivalent, would it require svgfonts? 20:40:52 CL: don't think so, they're more interested in opentype fonts 20:40:55 ...downloadable fonts 20:41:04 DS: they're doing print stuff right 20:41:11 ...why wouldn't they want svgfonts? 20:41:30 ...having a supplementatry spec to svgtiny12 would be good for JIS 20:41:38 ...for vertical text 20:41:48 CM/CL: good point 20:42:47 CM: just wondering if it was worth having a module 20:42:53 DS: for vertical text yes 20:42:59 ...but does it belong in a font module? 20:43:10 CL: font support for vertical text belongs in a font module 20:43:49 (discussion of vertical text missing in tiny12) 20:44:42 CL: easy to make fonts standalone with added support for vertical 20:45:03 ...difficult if it ties into the rest of svg, gradients etc 20:45:23 DS: (draws on whiteboard) 20:47:34 ...want to annotate text 20:47:40 ...and selectable 20:48:02 CL: you could do one glyph with complex subshapes 20:48:29 ...inkscape added some functionality for drawing svgfonts 20:48:56 ...do you want an ALT tag? 20:49:15 DS: just some way of saying something is text, and this is what it represents 20:49:24 ...title with a role=text? 20:50:33 ...talked to designers, making svg posters made more difficult because of lacking support 20:50:49 CL: who in moz is working on that btw? 20:50:59 JW: jdaggett I think 20:51:59 CL: happy to help if it's needed 20:52:33 JW: he started asking about svgfonts 20:55:14 (discussion about blocked bugs) 20:57:54 eseidel has joined #svg 20:59:07 CL: making a module that does tiny fonts + vertical font 20:59:36 ...we're not sure about the xml serialization of @font-face (for possible reuse by xsl) 21:00:32 CM: if JIS is interested question is, what use is it without support for vertical text? 21:01:02 CL: yeah, it's more useful when combined 21:06:31 ACTION: CL to commit the SVG Fonts module, removing the parts already covered by CSS3 Fonts 21:06:31 Created ACTION-2605 - Commit the SVG Fonts module, removing the parts already covered by CSS3 Fonts [on Chris Lilley - due 2009-06-16]. 21:13:54 break for a moment, waiting for anthony to join for discussion on print/transform/color/compositing modules 21:22:47 eseidel_ has joined #svg 21:52:36 Topic: Print / Color 21:53:03 AG: CL you split out color right? 21:53:20 CL: yes 21:53:25 Scribe: Cameron 21:53:29 ScribeNick: heycam 21:53:38 CL: i was at csswg last week and they want to add cmyk support 21:53:50 ... i objected on the grounds that they weren't clear on whether they wanted icc cmyk or device color 21:53:57 ... implementors are demanding it 21:54:07 ... hakon doesn't really understand the different 21:54:16 ... response he got back from implementors is that they want both 21:54:18 s/different/difference/ 21:54:28 ... so if you look at the current spec it still has the old stuff about device color 21:54:36 ... it says device color is a name followed by a list of numbers 21:54:47 ... and the name takes you to a device-color element, which olds an href that points out to who knows what 21:55:05 ... and the example uses a numberOfComponents attribute that's not used anywhere, and extension namespaces 21:55:11 ... the info about what the colours actually are are in a comment block 21:55:24 ... for the common case where you want to say this is device cmyk, how do you do that? 21:55:37 ... what uri should i use/mint to represent device cmyk? there isn't an easy way to do that. 21:55:48 ... so i started changing the device-color element to make that work 21:56:00 ... but the css folks just want a simple property value for that, not indirecting through an xml block 21:56:07 http://dev.w3.org/SVG/modules/color/DoC/Tiny12DoC.html 21:56:13 ... looking at this DoC, all the comments on print 21:56:22 ... so you can take a copy of this to make the DoC for the Page module, changing some bits 21:56:43 ... there's a lot of green there, except for one purple item "we need to change this" 21:56:51 ... i've got proposed text in there to accede to the commentor 21:57:05 ... "device color would be better using pseudo profiles ...", and i said we disagree 21:57:30 ... but i propose we change that to green/agree, since at the end of the day what you want is device cmyk (very important), device rgb perhaps, device grey, and device multi channel which is just as vague as the current spec 21:57:39 ... hexachrome, you could probably do that with an icc profile 21:57:58 ... and photo rgb printers like the epsons: cyan, light cyan, magenta light magenta.... 7 colour printers 21:58:03 ... but that's no big deal they take sRGB input 21:58:20 ... so i've change the device-color token to be one of device-grey, device-cmyk, ... 21:58:26 ... device-grey takes one colour 21:58:32 ... device-rgb takes three colours 21:58:38 ... device-cmyk takes four colours 21:58:49 ... unlike the current spec, it tells you what those colour parameters mean 21:59:05 ... device-multichannel thing takes how many every colours it takes, and you don't know what they mean 21:59:05 ... but that's by far the least useful case anyway 21:59:16 AG: would you have a list of numbers that you don't know the length of? 21:59:17 CL: yes 21:59:24 ... that's the weak part of the proposal 21:59:31 ... jeremias from fop wanted these 21:59:42 ... so we're giving them exactly that 22:00:02 ... csswg wanted something quite similar to this 22:00:13 ... so the vendors who want this functionality get both of the things what they want 22:00:22 ... and we keep inkscape/scribus happy, who also wanted device cmyk 22:01:31 ... so i propose that we adopt this, then i add it, which is easy 22:01:36 ... and i'll also add the syntax appendix part 22:01:54 http://dev.w3.org/SVG/modules/color/master/SVGColor.html 22:02:30 AG: did we want to lift any content from my 2007 paper? 22:02:34 CL: yes but that would mostly go in the primer 22:02:49 ... another thing i've done is i've changed all the defs of the rendering intents 22:02:51 ... so it uses HP's wording 22:02:55 ... (from the DoC) 22:03:25 ... at LGM they were happy about splitting the spec apart 22:03:35 DS: people still do want a pagination model, though 22:03:43 CL: they may have misunderstood split to mean throw out 22:03:44 DS: right 22:04:39 DS: is canon still interested in pagination? 22:04:41 AG: not at the moment 22:05:05 ... they're more focussed on the UI stuff at the moment still 22:05:41 AG: can i get this master version of the spec reviewed by my guys yet? 22:05:48 CL: i'd like to publish this, i need to do some responses to the commentors 22:05:55 ... so 2 weeks response time for that 22:06:01 ... it's public anyway, so you can point them to dev.w3.org 22:06:09 AG: many more changes in the next 2 weeks? 22:06:13 CL: not apart from folding in that syntax change 22:06:20 ... i'm likely to beef up the primer 22:06:25 ... add the stuff from your paper 22:06:43 AG: we might take the language spec and review it then 22:06:46 CL: sure 22:07:43 ... i don't think is just ready for another LC yet 22:07:48 ... but fairly shortly after this it should 22:07:56 ... i do want to move it forward to CR, since there are implementors waiting for it 22:09:36 ... one of the other things i've put in is a clear conformance requirement that UAs colour match embedded images 22:09:42 ... firstly, the old spec assumed that but didn't mention it really 22:09:51 ... it only told you how to override the colour profile with a different one, which is of less interest 22:10:12 ... the reason that's important is that firefox and safari both do colour management of images now 22:10:27 ... so they would conform to that part, and we can raise bugs if they colour manage images in html and not in svg, and they can reuse code and just hook it up 22:11:09 AG: can we still add bits and pieces to the language spec? 22:11:15 CL: yes, i'm not asking for a second LC yet, but it's getting close 22:11:21 ... so i'll bring that to a telcon, but in a couple of weeks 22:11:37 AG: i think it would be good to have something like "preserve black" in there, for text 22:11:52 ... so if you have text that's black, and set a preserve black on it, so that it uses the black ink at the cmyk end 22:12:10 CL: if you look at the rendering intents, i've change the language. one of the changes is that primarily you should be using relative-colorimetric 22:12:26 ... and using that with black point compensation, so if the target device black is not 0, but some measured value of black, you'll map your blacks to that 22:12:53 AG: yes but if you wanted to use a different rendering intent, or the one on the profile isn't there since not all profiles support it, then you might run in to problems 22:13:05 ... i would like to see preserve black in there 22:13:05 ... it's also useful for images 22:13:16 CL: so that'd be a second attribute on the element? 22:13:30 AG: yeah probably 22:13:39 ... although i'll check with the guys here 22:13:51 CL: i can add it in to the spec so it sounds reasonable 22:13:55 AG: should i propose some wording? 22:13:58 CL: yes please 22:14:12 ACTION: anthony to propose wording for "preserve black" attribute for color profiles 22:14:12 Created ACTION-2606 - Propose wording for "preserve black" attribute for color profiles [on Anthony Grasso - due 2009-06-16]. 22:15:53 CL: i'm going to start on test cases, tho it's a bit difficult without an implementation 22:15:58 AG: does opera support colour management? 22:16:00 ED: no 22:16:06 CL: firefox 3.5 does, 3.1 did not 22:16:10 ... unless you switched on specific prefs 22:16:18 ... only on embedded images 22:17:05 AG: we'll have to think up of some crafty colour values for the tests 22:17:22 CL: for input i found documentation for the macbeth colour checker with measured colour values 22:19:14 ... got those values converted to cielab 22:19:24 ... from that i can produce srgb values etc., so i've done that here 22:20:16 AG: are we going to allow... i know we have solid colour, viewport fill... what other things use colour? feFlood? 22:20:21 CL: yes 22:20:30 ... flood-color 22:20:46 ... it's missing viewport-fill though 22:21:27 ... there is an outstanding issue that many profiles don't have all four rendering intents specified, so what do you do if you ask for a rendering intent that's not supplied? 22:21:33 AG: i think this was mentioned in the first round of comments from guys here 22:21:43 ... they said something on the lines of using fallback, or ignoring it 22:21:56 CL: if you allow it to use any rendering intent, you need it to definitely work if it has those rendering intents 22:22:08 ... if it only has a single rendering intent, then allow it to use that 22:22:53 AG: be good to say in the spec if the rendering intent is not in the profile, then just do colour conversion as normal 22:23:47 ... there are also some minor editorial notes that unintentionally limit things, i'll send those in in the next week or so 22:24:02 ... the sentence that begins "if icc based named colours are provided" 22:24:13 ... in "icc named colour", in the first red box 22:24:20 CL: it says it must use it in preference to the fallback 22:24:41 AG: we should remove the "use profile connections other than ciexyz or ..." 22:24:42 CL: why? 22:24:49 ... are there profiles that use other connection spaces? 22:25:05 AG: those are two common ones that i know of, don't know, but they could 22:25:05 ... it's just limiting 22:25:14 CL: i wanted to say that if you get a profile connection space that you don't know about, then you don't use it 22:25:19 ... so you use fallback 22:25:37 AG: ok i like your wording better 22:25:46 or uses an unsupported profile connection space 22:27:05 ACTION: Chris to follow up to all commentors on the colour module that haven't been responded to 22:27:06 Created ACTION-2607 - Follow up to all commentors on the colour module that haven't been responded to [on Chris Lilley - due 2009-06-16]. 22:27:19 ACTION: Chris to fold in the edits to the colour module that were discussed at this meeting 22:27:19 Created ACTION-2608 - Fold in the edits to the colour module that were discussed at this meeting [on Chris Lilley - due 2009-06-16]. 22:27:48 Topic: Compositing 22:27:52 AG: haven't done much on that, just letting it sit 22:28:01 ... still have to fold in cameron's and erik's comments in 22:28:15 ... we haven't worked out any common wording for enable-background 22:28:38 ED: we did publish a first draft of compositing right? 22:28:40 AG: yes 22:34:11 DS: there are a few things that would be good to get done by svg open, that you are working on 22:34:19 ... compositing e.g., what needs to be done for that? 22:34:26 AG: just folding in erik's and cameron's comments 22:35:41 Topic: Transforms 22:36:07 DS: did you respond back to dino about the openvg stuff? 22:36:13 AG: openvg is a bit higher level than opengl 22:36:17 ... haven't responded back to him about that 22:36:39 ... i did ping him and ask him if we can sit down and work out some common ground for the specs, but he seems to be a bit busy at the moment 22:36:45 ... he'll get in touch with me some time soon 22:37:26 ... i did some reading up on perspective transformations in 3d and looked a number of different ways of doing it 22:37:31 ... from what i can tell, and other guys here tell, the way that canon's proposed matches what's currently known and done out there 22:37:43 ... we don't understand the use case & reqs that css have 22:37:55 ... e.g. for stringing along multiple perspective transformations in the one transform property 22:38:11 ... so that's the first thing i need to talk to dino about 22:38:12 ... i've played around with webkit for a bit, since they implement the transform stuff 22:38:23 ... the results it produces when you apply a perspective transform seem a bit odd 22:38:32 ... it's as if it doesn't implement it at all 22:38:32 ... so not sure what's going on there 22:38:48 CM: it might just be the iphone build of safari 22:39:22 AG: i did some testing between the css proposal and ours 22:39:29 ... with both you can get the same effects 22:39:40 ... but i would like to understand why they want the chainable perspective transformations 22:39:51 ... a lot of the other things are similar, and we could use the same syntax/spec for 22:40:46 DS: might be useful to still write up why the matrices are the way they are, and the openvg reasons 22:41:22 AG: using openvg, you need to render all your graphics to a buffer, flatten it, then apply a 3x3 perspective transform 22:41:37 ... the maths is in the spec 22:41:42 ... what sort of write up are you looking for? 22:41:55 DS: a rationale about why it doesn't hinder the spec to do it this way 22:42:16 AG: compared to what css proposes, it doesn't really change anything 22:42:22 DS: but we need to justify it 22:42:53 AG: another thing we'll need in the transforms spec is, and i'd like the group's opinion on, is an xml syntax for transforms, like we've discussed with paths 22:43:55