07:57:11 RRSAgent has joined #svg 07:57:11 logging to http://www.w3.org/2010/09/08-svg-irc 07:57:13 RRSAgent, make logs public 07:57:13 Zakim has joined #svg 07:57:15 Zakim, this will be GA_SVGWG 07:57:15 I do not see a conference matching that name scheduled within the next hour, trackbot 07:57:16 Meeting: SVG Working Group Teleconference 07:57:16 Date: 08 September 2010 07:57:22 Chair: Erik 07:57:26 Topic: last call comments on SVG1.1SE 07:57:33 Scribe: Chris 07:57:44 Scribenick: ChrisL 07:57:44 Present: CyrilC, ErikD, AnthonyG, JWatt, ChrisL, DougS 07:58:06 action-2812? 07:58:06 ACTION-2812 -- Erik Dahlström to find the test case, commit it and make some proposed wording -- due 2010-07-13 -- OPEN 07:58:06 http://www.w3.org/Graphics/SVG/WG/track/actions/2812 07:58:22 http://dev.w3.org/SVG/profiles/1.1F2/ua-tests/filter-feconvolvematrix-bias-ISSUE-2812.svg 07:58:22 ED: Found one test and an image 07:59:01 ED: extended the test with colour-interpolation-filters. Seems in inkscape 0.47 that al three are the same 07:59:34 CL: What is the correct result? 07:59:41 ED: That is what Jasper is asking 08:00:02 ISSUE-2335? 08:00:02 ISSUE-2335 -- Last Call Comment: Clarify feConvolveMatrix bias property -- raised 08:00:02 http://www.w3.org/Graphics/SVG/WG/track/issues/2335 08:00:27 ED: What does firefox do with the bias? 08:00:44 ... not much used so cost to change as a result of clarifications is low 08:02:21 (checking inkscape 0.48) 08:02:32 ED: Opera and Firefox same on bias 08:04:03 ED: In batik it drew nothing 08:06:04 cyril has joined #svg 08:07:30 ED: color-interpolation-filters should affect the result, so inkscape 0.48 is wrong 08:08:26 CL: Often filter implementations seem to not get the colour space right for calculations (at least, at first) until they see what a difference it makes 08:09:17 jcdufourd has joined #svg 08:10:56 batik svn says 'rendering document failed' on that test 08:16:02 ED: ASV3 does same as Opera and Firefox 08:23:16 shepazu_ has joined #svg 08:24:17 CL: I extended the test to add an explicit bias="0.0" 08:24:23 ... checking in now 08:26:36 http://dev.w3.org/SVG/profiles/1.1F2/ua-tests/filter-feconvolvematrix-bias-ISSUE-2812.svg 08:30:06 JW: What is the use case here 08:31:45 ED: For example comparing two images by subtraction, bias moves it from being centred on zero (and clipped) to centred on 0.5 08:32:04 DS: Maybe aske DDailey 08:32:16 CC: Ask Vincent Hardy 08:33:34 action: erik to ask Vincent Hardy and David Dailey about bias and ISSUE-2335 08:33:35 Created ACTION-2859 - Ask Vincent Hardy and David Dailey about bias and ISSUE-2335 [on Erik Dahlström - due 2010-09-15]. 08:36:30 DS: Trying test in Safari and Chrome nightlies 08:39:02 Of the implementations that do color-interpolation-filters and do bias, they all get the same result and follow the spec. 08:39:14 s/Of/CL: Of/ 08:43:15 DS: Chrome does not implement color-interpolation-filters but they do implement bias 08:47:38 Topic: SVG 2.0 and audio, video 08:50:42 CL: SVG 1.2T audio and video has good timing, which is an advantage for synchronisation compared to html5 audio and video, but our dom apis suck. A good first step would be the 1.2T markup, with timing and synchronisation, but with the HTML5 apis 08:51:14 ED: What about the src attribute and fallback? 08:51:44 ... fallback formats in 1.2T not as good as the html5 ones, we should adopt them 08:52:01 s/src attribute/soure elements/ 08:52:39 s/soure elements/source elements/ 08:52:43 CC: Microsoft asked me at SVG Open about the differences between html5 and svg video 08:52:55 s/soure/source/ 08:53:23 CC: I had five points of key differece (looks for notes) 08:54:25 CC: separation of document timeline from media timeline 08:54:41 CC: ability to start/stop the media timeline at specific time in the document timeline 08:55:06 CC: ability to start/stop the media timeline at a specific time in the media timeline (SMIL clipBegin/clipEnd) 08:55:32 CC: explicit syncing of media timelines 08:56:40 CL: For example syncing a video stream to an audio stream 08:57:24 CC: ability to receive events from the media (Media Access Events) 08:57:34 DS: Would like to see a more detailed comparison of markup and APIs 08:58:13 CC: People are scared of smil, the timing model is not complex and is already in falsh, mpeg4 etc is is needed functionality 08:58:25 s/falsh/flash/ 08:59:08 DS: Simon Fraser said it was tricky to sync multimedia due to platform concerns. Animation is very different from audio and video sync 08:59:40 CC: yes, timing and animation are quite different. Also audio and video typically handled by a decoder or an external system library 08:59:51 DS: Conzstraints are on the multimedia engine 09:00:28 s/nz/n/ 09:01:35 s/the timing model/the timing model when you restrict it to these 5 points/ 09:01:35 DS: Would prefer to discuss this i the FX task force because Simon is there 09:01:58 s/i /in / 09:02:02 CC: the use of time containers (nested ...) is complex 09:03:14 DS: Not totally convinced SVG should have audio and video 09:03:29 CC: HTML5 has audio, video and track 09:03:41 ... SVG has audio video and animation 09:04:16 CL; Want to see explicit support for subtitling in SVG video so its clear how to add it 09:04:28 s/CL;/CL:/ 09:04:28 s/CL;/CL:§ 09:05:00 DS: Want to see that in the platform 09:05:09 DS: I want to see subtitling on the web platform, but I want it to be the same as is used in HTML 09:06:28 DS; Its important to have audio and video content in SVG but using the HTML5 audio and video its not much of an authoring burden and the api is nice 09:06:44 s/DS;/DS:/ 09:09:14 CC: f the video is only in html, is it flexible enough? Can you make a video paint server for example? 09:09:52 ED:Yes you could, depends on how its implemented, need to wrap in foreign object, better to have a video element as it removes two steps of indirection 09:10:13 s/CC:f the/CC:if the/ 09:10:31 CL: Yes there is no need to invoke an unused box model for a video elemetn (or indeed audio) 09:10:41 DS: Ned to look more at foreignObject 09:10:49 s/Ned/Need/ 09:10:51 s/Ned/Need/ 09:17:24 DS: We need to get more input from the browser implementors on this 09:18:10 ED: Opera experience is that SVGT1.2video is much more efficient than HTML5 video wrapped in foreign object, for svg-with-video 09:18:28 Topic: Markers 09:19:09 I don't want SVG to add video and audio unless it is done in a compatible way to HTML5 (which is what we've been talking about) and unless we have buy-in from all the major browser vendors 09:21:39 s/because Simon is there//because Simon, DSinger, Jack Jansen, and other implementers with specific multimedia expertise are there/ 09:33:46 scribenick: shepazu 09:49:24 ChrisL: [gives background] 09:49:48 ... GKS had the concept of fill, stroke, and marker... 09:50:09 ... it was pivotal in the 1970s in framing the language of 2d graphics 09:50:24 ... when SVG added it, it seemed obvious to talk about it in those terms 09:50:46 ... but if you look at the use of markers, people use markers, or they use paths with fill and stroke... 09:51:27 .... markers are on points of particular interest, rather than on the geometry of the path beziers 09:51:56 ChrisL: so, I feel it was a mistake to add markers in this way... 09:52:11 ... you can have markers on markers, etc. which isn't useful 09:52:39 ... I think it might be a good idea to deprecate markers and add a new, more useful equivalent 09:53:46 ... for example, allowing them to dispatch events rather than just being part of the rendering model 09:53:50 ChrisL: I started to make a proposal for "polymarkers"... 09:54:06 ... which would be like polyline, takes a list of points 09:54:44 ... but that's not good enough, because you can't put events on individual makers 09:55:45 ChrisL: so instead, I think it would be better to have a marker container, where each marker is an element, which can have an id, can be animated and interactive 09:55:56 jwatt: so you couldn't reuse a marker? 09:56:13 ChrisL: you could use a "use"... 09:56:23 ... haven't thought through the exact mechanism 09:56:38 ... could have 'd' attribute, but that's not good enough 09:56:51 ... the other option is having it more like a 09:57:09 ... so you can have multiple colors, and multiple instantiations 09:57:37 ChrisL: if you wanted them to be identical, the container could have the href that points to the marker 09:58:04 jwatt: 2 questions 09:58:25 ... when the path that you're marking.... 09:58:56 ChrisL: no, you're not putting them on a path, they are separate 09:59:28 jwatt: ok, as an author, I may draw a path that I want to have markers in sync 10:00:59 ChrisL: right, but if you want to have straight lines, that's easy... but if have a smooth curve, you always have to sync manually 10:01:27 jwatt: I've been thinking about this, too.... 10:02:23 ... rather than have markers at the vertices between the segments, have a property that says, "every x unit along the path" 10:03:03 ChrisL: or "I want x number of markers evenly placed" 10:03:52 shepazu: or points at a certain length along a path 10:04:53 ChrisL: the disadvantage to that is that it only extends our current model, with lack of addressability 10:05:06 break for lunch 10:16:18 Zakim has left #svg 11:32:57 [back from lunch] 11:35:22 ChrisL has joined #svg 11:35:50 Zakim has joined #svg 11:36:05 action: ChrisL to write up different proposals for markers 11:36:05 Created ACTION-2860 - Write up different proposals for markers [on Chris Lilley - due 2010-09-15]. 11:36:08 zakim, remind me in 5 hours to go home 11:36:08 ok, ChrisL 11:36:26 rrsagent, make logs public 11:38:57 Topic: F2F schedule 11:39:25 ed: we're meeting at TPAC; if you haven't registered, you should do so soon 11:40:24 http://lists.w3.org/Archives/Member/chairs/2010JulSep/0040.html 11:40:37 ed: what about the next F2F? 11:41:17 ... TPAC is in November 11:41:37 anthony: we could do Sydney in February 11:41:56 ed: or New Zealand, where heycam will be 11:45:23 [discussion about NZ] 11:48:24 it would get us folks from Australia, like heycam, Brian Birtles, Alex Danilo... and hopefully ROC could join for a day or 2 11:49:43 ChrisL: where would it be? would mozilla host? 11:50:35 jwatt: there is a small office in Auckland, not big enough to host, but we could talk about getting facilities for a meeting.... I'll have to ask 11:51:41 action: jwatt to investigate Mozilla hosting an SVG WG F2F in Auckland, NZ in February/March 11:51:41 Created ACTION-2861 - Investigate Mozilla hosting an SVG WG F2F in Auckland, NZ in February/March [on Jonathan Watt - due 2010-09-15]. 11:52:52 shepazu: obviously there is also SVG Open and TPAC20111 11:53:46 ... seems like SVG Open may be in Seattle 11:53:48 ed: what about LGM 11:54:10 ChrisL: it's in Montreal 10-13 May 11:54:51 .... AC meeting and possible Interaction Domain meeting 14-17 in Bilbao, Spain 11:57:56 ed: so, if we meet at LGM, it would have to be the first week of May 11:58:11 shepazu: it could just be a short F2F 12:01:24 Topic: telcon times 12:01:50 anthony: I'm happy to do 6am australian time 12:02:38 http://www.w3.org/Graphics/SVG/WG/wiki/Meetings#Times 12:04:11 http://www.timeanddate.com/worldclock/meetingdetails.html?year=2010&month=4&day=15&hour=20&min=0&sec=0&p1=240&p2=195&p3=43&p4=224&iv=1800 12:05:18 http://www.timeanddate.com/worldclock/meetingdetails.html?year=2010&month=9&day=16&hour=20&min=0&sec=0&p1=240&p2=195&p3=43&p4=224 12:07:13 http://www.timeanddate.com/time/dst2010.html 12:09:50 ed: so, we keep the existing times until October 31 12:09:58 ... when DST ends 12:11:19 ed: FXTF meetings will be on Monday 20:00 UTC for 1 hour 12:11:49 action: doug to update FX wiki with telcon times 12:11:49 Created ACTION-2862 - Update FX wiki with telcon times [on Doug Schepers - due 2010-09-15]. 12:19:08 Topic: Non-retain property 12:19:50 ed: this came up at SVG Open 12:20:58 cyril: Andreas Bovens from Opera mentioned the buffered-rendering property, which enables faster rendering after optimization 12:21:41 http://www.w3.org/TR/SVGTiny12/painting.html#BufferedRenderingProperty 12:21:52 ... for a subtree that's not expected to be dynamic 12:22:13 CC: static = "Indicates that the element is not expected to be modified often. " 12:23:46 cyril: I would like to go a step further with a new value that allows you to trash the DOM 12:24:19 anthony: wouldn't that discard the vectors? 12:24:42 cyril: no, you'd keep the internal vector representation, but it would still save memory 12:25:20 anthony: this would be good for the proposed extended path syntax 12:26:03 cyril: we'd have to discuss whether animations or script would still apply 12:27:54 ed: I would like a way to allow a subtree of an SVG that acts as a separate layer, composited on top, which doesn't depend on other parts of the document 12:29:34 shepazu: what about simply allowing SVG in the ? 12:30:04 ed: I don't think that gets us the same thing, because there's no interaction 12:35:06 ... SVGT12 + buffered-rendering might be a way to go though 12:39:37 ACTION: cyril to investigate how the buffered-rendering property can be improved for SVG2 12:39:37 Created ACTION-2863 - Investigate how the buffered-rendering property can be improved for SVG2 [on Cyril Concolato - due 2010-09-15]. 12:45:09 topic: charter 12:45:33 here's a rough list of stuff in the draft (no order, some duplicates): 12:45:35 * Animation and Media 12:45:36 * Color Management 12:45:36 * Compositing 12:45:36 * Connectors 12:45:36 * Filters 12:45:38 * Integration 12:45:38 * Layout Requirements and Use Cases 12:45:40 * Layout 12:45:42 * Masking and Clipping 12:45:44 * Media Access Events 12:45:46 * Pagination 12:45:48 * Paint Servers 12:45:50 * Parameters 12:45:52 * Transformations 12:45:54 * Vector Effects 12:45:57 * SVG 2 12:45:58 * SVG DOM API 12:46:00 * SVG Fonts 12:46:02 * SVG 2 Requirements 12:46:04 * Scalable Vector Graphics (SVG) Tiny 1.2: Requirements; Specification 12:46:06 * SVG 2 Modular Specification 12:46:08 * SVG Print: Requirements; Part 1: Primer; Part 2: Language 12:46:10 * SVG Filters: Requirements; Part 1: Primer; Part 2: Language 12:46:12 * Paint Servers 12:46:14 * SVG Masking and Clipping 12:46:16 * SVG Vector Effects 12:46:18 * SVG Compositing 12:46:20 * SVG Layout: Requirements; Part 1: Primer; Part 2: Language 12:46:22 * SVG WebFonts 12:46:24 * Media Access Events 12:48:54 http://ie.microsoft.com/testdrive/Graphics/49ColorProfiles/ 12:52:22 ChrisL: we're currently on a charter extension 12:55:04 ed: and will we ask for another one until SVG 1.1 SE is done? 13:07:24 [end break] 13:08:42 ed: I want to see a much better treatment of 'foreignObject', with HTML in particular, including requirements, tight wording, and tests for interoperability 13:10:41 ChrisL: it should say that when the CSS box model is used to render the contents of 'foreignObject', the size of the 'foreignObject' element is taken as the size of the outermost containing block, and starts a new CSS canvas 13:12:20 Resolution: we should prioritize defining 'foreignObject' behavior in SVG Integration 13:12:44 action: shepazu to define 'foreignObject' behavior in SVG Integration 13:12:44 Created ACTION-2864 - Define 'foreignObject' behavior in SVG Integration [on Doug Schepers - due 2010-09-15]. 13:13:46 ed: does this handle zooming and transforms? 13:14:03 CL: I don't think zoom is adequately defined.... 13:14:18 ... we once had zoom vs. magnify, but we got rid of that 13:17:03 ed: we should say that if you're an HTML+SVG UA, you must support SVG in the 'foreignObject' element 13:17:18 shepazu: and MathML too 13:17:56 s/support SVG/support HTML and SVG/ 13:18:44 CL: if you support the CSS box model & SVG, then you must support the use of the box model in the SVG 'foreignObject' element 13:35:53 shepazu: I'll add that Transformations may include 2D and 2.5D transforms 13:48:45 Topic: Params 13:49:25 shepazu: need to decide on a better syntax that works for CSS as well 13:50:21 ... and for a URL syntax that doesn't trigger multiple server requests, and isn't cached, like the "?" delimiter does 13:51:03 CL: what about #params(foo=1,bar=red) ? 13:51:09 shepazu: ok 13:56:24 action: shepazu to update Params spec to change URL syntax 13:56:24 Created ACTION-2865 - Update Params spec to change URL syntax [on Doug Schepers - due 2010-09-15]. 13:57:35 shepazu: that syntax should also work for external CSS stylesheet, if CSS decides to add this too 13:58:09 ... I'd like to discuss this with them during the FXTF call 14:00:08 Topic: SVG 2 14:00:15 CL: What are the hot new features for it? 14:00:27 Scribe: anthony 14:00:30 ScribeNick: anthony 14:00:32 DS: Tighter with HTML 5 14:00:51 s/Tigher/Tigher integration/ 14:01:48 Tighter integration with HTML5 and CSS, including using SVG features like filters and gradients with HTML content 14:02:17 ED: Advanced gradients, transforms, filters 14:02:26 ... and compositing 14:02:47 CL: Vector Effects is a fairly visible feature 14:02:52 DS: Params 14:02:56 ED: Params is very useful 14:03:01 ... is the feedback I've been getting 14:03:06 ... makes things reusable 14:03:27 DS: New gradients (mesh, diffusion curves?) 14:03:32 CL: Was asking at a high level 14:03:51 ... looking at blocking out an area as to why you'd use SVG 2 instead of old versions 14:04:05 DS: Component based reuse of SVG is Params 14:04:33 ... possibly connectors? 14:04:42 ED: New CSS properties that might apply to SVG 14:04:51 ... gives better integration with HTML 14:05:31 DS: Maybe the fact that we are cleaning up some of the cruft and making it more consistent 14:05:48 ... and interoperable 14:05:59 ... what about canned effects? 14:06:11 ... author friendly short hands for common effects 14:06:19 CL: Ease of authoring 14:07:10 DS: Richer SVG and CSS animation 14:07:21 ... or maybe cleaner 14:08:56 ED: What features would you be looking for if you were a stand alone UA? 14:08:59 ... the shape path thing 14:09:15 DS: Skeleton paths 14:09:46 CC: Wire frames 14:10:11 CL: Vector Effects can draw like a filter and as a stand alone object 14:10:30 ... and Super path 14:10:45 ... I'd group that with the smooth curves 14:10:51 ED: And the variable stroke width 14:10:59 ... all very useful functionality 14:11:51 CL: I'm after a high level summary 14:11:59 ... with groupings of these features 14:12:04 AG: Should we make something like that? 14:12:06 CL: Yes 14:13:24 ... pulling that stuff together with broad headings would make a nice document 14:14:37 ACTION: Chris to Put together a high level overview stating the most important new features in SVG 2 14:14:37 Created ACTION-2866 - Put together a high level overview stating the most important new features in SVG 2 [on Chris Lilley - due 2010-09-15]. 14:15:03 CL: This is something I'd expect someone to be able to read in a few minutes 14:15:11 ... and have an idea of what we're doing 14:16:43 CL: Are there any big areas of functionality we've been asked for 14:17:03 ... but don't have any work in the area? 14:17:11 DS: Layout and constrains 14:18:41 AG: Have we thought about when we are going to start SVG 2? 14:18:55 DS: I think it is unrealistic for us to simply do it from scratch 14:19:11 ... it is not good for us to simply pull things in 14:19:29 ... we can bring in sections that we need as place holders 14:19:31 ... from 1.1 14:19:39 ... and give them a class that gives them a maturity 14:19:57 ... that maturity would indicate if it's been reviewed 14:20:02 ... there are testable assertions 14:20:11 ... that it is consistent with other parts of the spec 14:20:15 ... and it has test 14:20:38 ... There would be some stylistic thing 14:20:43 ... which denotes it's new 14:21:34 CL: I agree we should pull that text in as a place holder 14:21:54 DS: I think if we go for this more rigorous process of review 14:22:13 f1lt3r has joined #svg 14:22:16 ... we will find inconsistencies that hadn't been found 14:22:27 ... or address things that hadn't been addressed 14:22:41 DS: We talked about having an annotated version of the spec 14:23:05 ... and in that version we could have reasons for certain technical decisions 14:23:12 CL: If you do it the other way around 14:23:28 ... where you author with the annotations 14:23:37 ... and have an XSLT to give you the raw document 14:24:10 DS: My idea was we have a document on the side, in addition to use case and requirements 14:24:35 ... which is like a developers guide 14:24:37 ... and the annotated version of the spec we'd have links into the developers guide 14:24:55 JW: Some sort of design rational doc sounds reasonable to me 14:24:57 ... even for us 14:25:21 DS: Sometimes you're not around CL and it would be good to have that information around 14:25:32 ... for discussions 14:25:51 ... I'm proposing we have a system 14:26:06 JW: Everyone understands how to add stuff 14:26:25 DS: Right, so people can see why we've made the decision 14:26:35 JW: I think it will save us work explaining why we did something 14:26:46 ... rather than trying to recall it 14:27:08 AG: We could link it straight to trackbot 14:27:22 DS: We could put ISSUE numbers in 14:27:35 CL: So when we commit trackbot picks up on it 14:27:44 we could use this: http://www.w3.org/People/Schepers/spec-conventions.html 14:28:15 DS: My proposed stylistic and syntactic convention 14:28:26 ... things would be marked up certain way 14:28:33 ... and it makes it easy to pull out 14:29:23 ED: I liked the thing that Cameron did 14:29:31 ... with the script 14:29:39 ... that would link to definitions 14:29:46 ... and put them in the spec 14:29:48 ... when it was generated 14:30:10 AG: Do we have mark up for assertions? 14:30:17 DS: No, need to add that 14:31:14 ACTION: Doug to Add to the common convention document mark up for testable assertions 14:31:14 Created ACTION-2867 - Add to the common convention document mark up for testable assertions [on Doug Schepers - due 2010-09-15]. 14:31:28 CL: We should have an ID for the assertions 14:31:46 DS: We want to have a link to go to the tests and back 14:32:20 CC: The widget spec being edited while the tests were being edited 14:32:29 ... and so what they did was have a hash 14:32:40 ... that was generated for each test 14:33:00 DS: To a large degree we can solve that by settling on name conventions 14:33:09 ... since we are going to edit the spec by hand 14:33:43 ... we can come up meaningful names 14:34:01 CC: I the test suite at the moment we already have names 14:34:35 CL: Sequential number of sections is a bad idea. But sequential number for tests in a section name is ok 14:35:18 DS: How much of Cameron's build system can be used? 14:35:24 ED: I think it's a good idea to use 14:35:34 ... it's Java based and uses some XSLT 14:35:39 ... and some Perl scripts 14:35:57 CL: If we can modify it to meet our needs 14:36:07 ... then that's better than building something from scratch 14:36:15 ED: Already working well with the modules 14:36:31 DS: We can start with that 14:36:38 ... and the build system can always be changed 14:37:44 Topic: Using href in addition to xlink:href 14:38:45 DS: So the href property would be a getter and setter for the href attribute 14:38:58 CL: And if someone puts in xlink:href what happens? 14:39:17 http://www.w3.org/Graphics/SVG/WG/wiki/Href 14:39:47 DS: [Reads out page] 14:42:11 CC: So I have to remember what the value was? 14:42:17 ... why being so strict? 14:42:22 ED: That's DOM requirement 14:42:26 ... in DOM core 14:42:59 CC: So it's adding a flag probably 14:43:04 DS: That's if only they're using it 14:43:17 CC: maybe that's not an issue because XML events are not being used 14:43:33 ... what about the "ev" prefix? 14:43:43 ED: We just use "event" we don't use the namespace 14:43:49 ... you have to define the prefix 14:44:11 DS: Maybe something we need to think about at some point 14:44:50 ... we are trying to align with HTML here 14:45:12 s/ED: We just use "event" we don't use the namespace/ED: We just use XML events (in SVGT12), and yes you do have to declare the ev prefix to be from XML Events/ 14:48:33 Resolution: We accept the proposal on the wiki and we will add this to the integration specification 14:51:46 ED: I think we should probably put this in SVG 2 14:51:56 ... it doesn't belong in Integration 14:52:14 DS: Need a new resolution then 14:52:33 Resolution: We accept the proposal for href on the wiki and will add this to the SVG 2 specification 14:52:48 ACTION: Doug to Add wiki href proposal to the SVG 2 specification 14:52:48 Created ACTION-2868 - Add wiki href proposal to the SVG 2 specification [on Doug Schepers - due 2010-09-15]. 14:58:12 Topic: Color 14:58:21 CL: There was some good feedback about CieLAB 14:58:33 ... it didn't say what the white point was 14:58:40 ... to make LAB you find out what the white point 14:58:49 ... and you draw a line through the 3D space 14:59:05 ... and that becomes the black white line 14:59:40 ... we need to specify it so we have a default 15:00:04 ... having initially thought that D65 would be the best default 15:00:09 ... because that's what SRG be uses 15:00:24 ... I'm now convinced that D50 is the one to use 15:00:27