20:58:58 RRSAgent has joined #svg 20:58:58 logging to http://www.w3.org/2012/05/24-svg-irc 20:59:00 RRSAgent, make logs public 20:59:00 Zakim has joined #svg 20:59:02 Zakim, this will be GA_SVGWG 20:59:02 ok, trackbot; I see GA_SVGWG(SVG1)5:00PM scheduled to start in 1 minute 20:59:03 Meeting: SVG Working Group Teleconference 20:59:03 Date: 24 May 2012 20:59:50 agenda+ svg test overview 21:00:35 GA_SVGWG(SVG1)5:00PM has now started 21:00:41 +??P3 21:00:48 Zakim, ??P3 is me 21:00:48 +ed; got it 21:01:48 +??P11 21:01:51 Zakim, ??P11 is me 21:01:51 +heycam; got it 21:03:41 + +1.415.832.aaaa 21:04:03 + +33.9.53.77.aabb 21:04:08 Zakim, aabb is me 21:04:08 +krit; got it 21:04:12 + +61.2.980.5.aacc 21:04:16 zakim, +33 is me 21:04:16 sorry, Tav, I do not recognize a party named '+33' 21:04:22 zakim, aaaa is me 21:04:22 +krit; got it 21:04:43 Zakim, +61.2 is me 21:04:43 +nikos; got it 21:04:55 Zakim, +33 is Tav 21:04:55 sorry, heycam, I do not recognize a party named '+33' 21:05:00 zakim, +33.9 is me 21:05:00 sorry, Tav, I do not recognize a party named '+33.9' 21:05:34 Zakim, +33 is no longer krit 21:05:34 I don't understand '+33 is no longer krit', heycam 21:06:00 Chair: Cameron 21:06:04 Agenda: http://lists.w3.org/Archives/Public/public-svg-wg/2012AprJun/0053.html 21:06:12 Zakim, pick a scribe? 21:06:12 I don't understand your question, heycam. 21:06:14 Zakim, pick a scribe 21:06:14 Not knowing who is chairing or who scribed recently, I propose heycam 21:06:18 Zakim, pick a scribe 21:06:18 Not knowing who is chairing or who scribed recently, I propose nikos 21:07:04 ScribeNick: nikos 21:07:20 Topic: Test the web forward event 21:07:27 http://testthewebforward.org/ 21:07:43 CM: Are any SVG group members attending? 21:07:56 DS: I'll be there 21:08:13 Doug and Dirk will both be there 21:08:51 CM: focus is on testing, it'd be good to have test repository and framework up and running by there 21:09:10 Tav: frame work is up but repostory isn't there yet 21:09:39 Tav: other way around 21:09:54 krit: which account do you use to commit? 21:10:21 http://www.w3.org/Graphics/SVG/WG/wiki/Svgwg.org 21:10:32 CM: svgwg.org account 21:10:52 CM: need to send ssh public key to jwatt or myself to get access 21:11:09 krit: I'm talking about repository for test suite, not spec 21:11:15 CM: they're on the same machine 21:11:21 hg clone ssh://svgwg@svgwg.org/hg/svg2-tests 21:11:38 CM: might be possible to set it up so that you use different accounts 21:12:02 krit: can we avoid sending public key for tests? 21:12:14 krit: want to make it accessible 21:12:28 CM: you mean to people outside the wg? 21:12:30 krit: yes 21:12:40 ... we should ask css group and others to commit tests 21:12:55 CM: so anyone from the public could get an account and commit? would there be restrictions? 21:13:15 Tav: it would be like css where you can commit to your own area, needs approval to move 21:13:20 CM: is that done with hooks? 21:13:24 ... or is it convention? 21:13:59 krit: no folder besides the approved folder is restricted 21:14:13 Tav: don't forget we're using the 2 step system, so it's more complicated 21:14:33 CM: in the CSS group do you commit directly to the w2c mercurial? 21:14:35 krit: yes 21:14:55 Tav: we should re-discuss our test format 21:15:13 ... we have a format we came up with, new tests should follow that format 21:15:34 krit: can't we just do it like the css wg? 21:15:37 Tav: how is that? 21:15:39 csswg.org 21:15:43 krit: they have a good wiki 21:15:58 http://wiki.csswg.org/test 21:16:46 krit: in general, I think it would be great if we keep it as similar as possible 21:16:49 Tav: that's the plan 21:17:19 CM: I think we're half way there, repository is in the right structure 21:17:28 Tav: template is worked out 21:17:47 krit: only problem is to connect and commit 21:18:10 CM: I'll look into it 21:18:49 CM: looking a the contribute page, when you had it set up so you could commit, what authentication did yo uuse? 21:18:53 s/uuse/use 21:19:15 krit: sign up for wiki, then send email to Peter Lins, 21:19:47 CM: during this event, is the intention for people to get accounts and commit to the repository? 21:19:55 krit: yes 21:20:33 Action: Cameron to look into getting repository working for test the web forward 21:20:33 Created ACTION-3295 - Look into getting repository working for test the web forward [on Cameron McCormack - due 2012-05-31]. 21:20:49 CM: is it 3 weeks away? 21:21:03 krit: 15-16 June 21:21:34 Topic: SVG 2 update 21:21:57 CM: what's the latest work that's been done? 21:22:07 ... reminder that the plan is to publish FPWD in July, 2 months away 21:22:15 ... I've been working on the painting chapter 21:22:39 ... I see Erik has added buffered rendering 21:23:10 ED: I was wondering, a couple that I've signed up for require changes to the IDL, do we have something that parses web IDL or do we need to tweak the script? 21:24:09 CM: The problem is the IDL parser we're using is old. I'll have to update the parser or we'll lose some automation and have to write the IDL directly in the chapters 21:25:16 CM: at the moment, we get a lot of formatting done by the scripts. I'm not a fan of the formatting, I'd like to change it and bring the element definitions up in the chapter, rather than at the end 21:25:29 ... I think we wouldn't lose too much automation if we included IDL in the pre elements 21:25:33 ... manually 21:26:38 CM: in terms of other changes, I've been bringing property layouts in line with the css specs 21:26:46 https://svgwg.org/svg2-draft/painting.html#StrokeShape 21:27:32 CM: it's a bit more algorithmic than usual, is that good or should we rewrite it a different way? 21:27:54 krit: the images are done with svg yeh? 21:27:57 CM: yes 21:28:06 ... I did it with a dash array 21:28:19 ... I mentioned on the mailing list, it's probably safe to use 1.1 features, but not filters or animations 21:28:25 krit: I'm fine with that 21:28:48 CM: what I might do is add links to the png renderings of the svg 21:29:27 nikos: we need a script where you can point to an svg and get a png 21:29:54 CM: use common sense and avoid things that we know aren't well supported 21:30:00 krit: can we convert dash array to a path? 21:30:11 Tav: inkscape can do that 21:30:56 krit: it would be a good idea for dash array so that it renders the same everywhere 21:31:25 CM: I've been using the coloured backgrounds when I've been reworking sections from the 1.1 text 21:31:46 ... When it's good, I change it to yellow which means its ready for SVG WG to review 21:31:54 krit: It gets turned to white after review? 21:32:13 CM: when we publish, the group as a whole will sign off on the yellow and turn them to white 21:32:34 ... It will be good if people look through at the yellow sections to get an idea whats in there 21:33:07 ... most of the existing diagrams from the 1.1 spec have a thin blue border, I've been removing that and putting in the css instead 21:33:43 krit: I want to make sure equations have metadata 21:34:16 CM: I'm a bit concerned about the accessibility, the usual method with maths is to use 'mathplayer' which is ie only 21:34:38 ... it would be good to know if there's a better solution 21:34:51 krit: in general we don't care how it gets displayed, as long as it can, in theory, be transformed 21:35:22 CM: I've used a hidden pre element with the content 21:35:26 https://svgwg.org/svg2-draft/painting.html#ColorInterpolationProperty 21:36:11 CM: copy and paste the formula and you'll see the hidden markup 21:37:00 CM: I'm using an aria element 21:38:11 CM: I could have a hidden button that turns off the mathjax rendering 21:38:29 krit: be careful with hidden elements, they're not read or displayed 21:39:16 CM: with the annoations we're adding, should we remove them once we add the feature? 21:39:21 Tav: they have some historic value 21:39:46 Tav: the idea is when they're published they're hidden 21:39:59 ... 10 years from now someone might want to know why it was done that way 21:40:46 Topic: Referencing properties from other specs in SVG 2 21:40:56 CM: might not be much to talk about here 21:41:04 ... in my email 21:41:05 http://www.w3.org/mid/4FB5A353.3050802@mcc.id.au 21:41:28 CM: in svg 1.1 there's a bunch of css properties that hav ebeen redefined 21:41:39 ... we should reference existing definitions 21:41:58 ... remove the tables and reference the css spec 21:42:23 https://svgwg.org/svg2-draft/painting.html#VisibilityControl 21:42:31 CM: I've preserved most of the text, but reworded a little 21:42:55 Tav: that's good, you've got a short summary of what they do. If people want to know the nitty gritty they go to the other spec 21:43:29 CM: I'm not sure about the property links in the text, should it go to css? 21:43:36 nikos: no, should link to same document 21:43:38 Tav: I agree 21:43:56 +Doug_Schepers 21:44:20 CM: similarly for properties we've moved from svg to specs we depend on 21:44:46 ... one issue with having properties moved out of svg spec is that we need to make sure the presentation attributes are allowed on all the elements 21:45:57 ... one of the changes with 2nd edition 1.1 is for every element that's styleable is to allow all presentation attributes 21:46:19 ... I think a hook in the main spec that other svg specs can link to would be good 21:46:24 http://dev.w3.org/csswg/css3-transforms/#svg-transform 21:46:45 krit: See sentence 'This specification will also introduce the new present...' 21:47:03 CM: the last sentence about parsing, I think the svg spec will need a couple of definitions like that 21:47:37 ... other specs will need to specify if they allow extended syntax 21:49:35 krit: css3-syntax spec will define syntax for presentation attributes 21:49:35 krit: CSS 3 syntax spec will define syntax for presentation attributes 21:51:48 shepazu: I've been asked to present on SVG at Test the web forward. Anyone interested in helping me? 21:51:58 Tav: I can 21:52:16 krit: I can do that 21:52:44 krit: I can talk about committing, we can share the presentation if you'd like 21:53:09 ... however you want to organise it 21:53:42 shepazu: We are looking at an API for querying test results 21:53:43 -krit 21:53:59 krit: That's what shepherd is for 21:54:26 +krit.aa 21:54:34 shepazu: the other thing I want to mention is, the event is useful because it's an examination of the idea of the community helping with tests. I'd like to crowdsource tests in the future 21:55:18 Topic: Removal of the Media Type Registration chapter from SVG 2 21:55:40 CM: I thought that because we have the media type registered now that we don't need the chapter 21:55:43 ... I asked Chris 21:55:48 ... He thinks we don't 21:55:55 ... unless there are objections, I'll remove it 21:56:06 ... it existed in the spec so the registry could point to something 21:56:26 ... the media type won't mean anything difference between SVG 1 and SVG 2. not neccessary to resubmit 21:57:16 Tav: It occurred to me that if we're aligning more closely with HTML, would it be useful to have another mime type for non XML SVG? 21:57:29 s/Tav/shepazu/ 21:58:25 shepazu: A non XML SVG might be someone using SVG in HTML where they aren't quoting attributes, the HTML parser doesn't care. 21:58:33 ... anything to do with HTML parsing can't be called XML 21:59:28 CM: I think there was interest in using an error correcting parser for XML 21:59:36 ... maybe a community group started up 22:00:15 http://lists.w3.org/Archives/Public/public-xml-er/ 22:00:29 CM: not much activity since February 22:02:49 Topic: Do we still like solidColor? 22:03:13 CM: solidColour is something we've resolved to have in SVG 2 but I don't like it 22:03:35 ... one of the reasons is that it's not that hard to have the same effect with the current elements 22:03:48 krit: event with changed behaviour? 22:04:00 s/event/even/ 22:04:29 shepazu: how would you do it in another way? 22:04:39 CM: until CSS variables are available use a single stop gradient 22:04:53 ... slightly ugly but you don't have to put all the gradient attributes there 22:05:09 s/shepazu/tav/ 22:05:13 Tav: It would be so much simpler to have solid colour 22:05:24 s/colour/color/ 22:06:21 Tav: suppose you have a drawing with the same colour but in 16 different places, it would be problematic 22:06:35 krit: you have a prsentation attribute and chaneg it in one place 22:06:41 s/chaneg/change 22:07:19 CM: my concern is that once variables is implemented everywhere people would prefer to use it over solidColor and then we'd have multiple ways of doing it, which I'd like to avoid 22:07:43 CM: I'm thinking from an authoring point of view 22:08:11 CM: If there's interest in keeping it I won't block it 22:08:35 ... The reason I started thinking about it is because I was wondering what our plan in general is in regard to naming of attributes and elements 22:08:39 ... whether we keep camel case 22:09:20 ... for each camel case name we introduce, we need to update the implementations 22:09:43 Topic: Naming things going forward (camel case still in favour?) 22:10:16 [No strong opinions given on solidColour] 22:10:53 CM: Because of how the HTML parser works, elements and attributes are either lower case or case insensitive. There's a fix to transform to camel case for SVG. 22:11:10 q+ 22:11:18 ... if we introduce new attributes with camel case, the implementations need updating 22:11:26 krit: I think that's fixed in DOM 4 22:11:36 ... don't have to think about it from a spec point of view 22:11:57 CM: don't think so. if it's not registered it will become all lower case, and the DOM is case sensitive 22:12:33 ... is it actually a problem to update the parser when adding the implementation for the new attribute? 22:13:04 Tav: camel case is painful. I wonder if adding lower case versions of the attributes that have camel case would be the way forward? 22:13:18 krit: what if you want one that's all uppercase? 22:13:23 Tav: you wouldn't want to 22:13:32 ... in HTML it doesn't matter 22:13:42 ... for XML parsing, case does matter 22:13:52 s/Tav/shepazu/ 22:14:28 Tav: for HTML, it's case sensitive, but when it's parsed it's all lower case, so the DOM is all lowercase. 22:14:46 ... if we made all lower case versions of the tokens, HTML, SVG and XML could be valid 22:15:11 s/Tav/shepazu 22:17:39 shepazu: I know it's doubling the number of elements in the namespace, but the benefit would be an SVG that you could use case insensitively or lower case and it's all consistent 22:18:06 CM: in HTML parsing, if you put lower case and it becomes mixed case in the DOM, it's confusing 22:18:28 shepazu: I've seen lots of problems with viewBox 22:18:39 ... I don't think Chris would like this 22:18:52 ... but if others think there's merit we should consider it 22:19:37 CM: At the moment, what do we do with new things? Keep the existing scheme until we make a decision? 22:19:47 ... I'm drawn to consistency 22:19:53 shepazu: with what? HTML or SVG? 22:20:11 CM: It's not just what people know, but what the other things in the same SVG fragment look like\ 22:20:27 Tav: I agree 22:20:49 CM: it's the same sort of issue with CSS property values 22:21:09 ... they use dash separated names if anything 22:21:20 shepazu: I think we should be consistent with HTML rather than CSS 22:21:32 CM: you could introduce a dashed version of camel case properties 22:21:48 sI think we should be consistent with HTML rather than CSS/I think we should be consistent with HTML and CSS rather than SVG 1.1/ 22:22:11 s/I think we should be consistent with HTML rather than CSS/I think we should be consistent with HTML and CSS rather than SVG 1.1/ 22:23:15 shepazu: I used to think that consistency with SVG was more important, but now I find some of our conventions get in the way 22:23:39 CM: If we convert everything to the one true convention, then at that point we can decide how to name new things 22:23:53 ... I don't want to be in the situation where we have a mix 22:24:20 ... not something we need to decide now, but we should consider it in future 22:24:24 ... the near future 22:24:47 Topic: Dropping contentStyleType and contentScriptType 22:25:29 CM: In SVG 1, these attributes are designed to specify the language used in the style and event attributes 22:25:43 ... SVG 1 spec says they're deprecated, should we remove them? 22:26:02 shepazu: I think we can remove them 22:26:15 ED: I agree 22:26:36 shepazu: I think the solution will be mutual between SVG and HTML 22:26:49 CM: These started as HTTP headers, then became attributes in HTML 22:26:55 ... they don't exist in HTML 5 22:27:35 ... I understand the point that normally they're not used but because they are for extensibility they might be used privately 22:27:36 s/the solution/any solution (if necessary)/ 22:28:00 CM: Private use doesn't need something in the spec 22:28:04 shepazu: I've used them 22:28:41 ... you could do something weird with script that you can't do with regular javascript 22:28:56 CM: Anybody against removing them? 22:29:17 Resolution: Remove contentStyleType and contentScriptType 22:30:34 -Doug_Schepers 22:30:39 -krit.aa 22:30:43 -ed 22:30:47 RRSAgent, make minutes 22:30:47 I have made the request to generate http://www.w3.org/2012/05/24-svg-minutes.html heycam 22:31:33 -heycam 22:33:16 -krit.a 22:33:17 -nikos 22:33:19 GA_SVGWG(SVG1)5:00PM has ended 22:33:19 Attendees were ed, heycam, +1.415.832.aaaa, +33.9.53.77.aabb, krit, +61.2.980.5.aacc, nikos, Doug_Schepers 22:42:39 action: cameron to investigate having a hidden button to turn mathjax rendering off 22:42:39 Created ACTION-3296 - Investigate having a hidden button to turn mathjax rendering off [on Cameron McCormack - due 2012-05-31]. 22:53:55 birtles has joined #svg 23:05:46 RRSAgent, make minutes 23:05:46 I have made the request to generate http://www.w3.org/2012/05/24-svg-minutes.html heycam 23:44:56 action: cameron to look into Web IDL parsing for build scripts 23:44:56 Created ACTION-3297 - Look into Web IDL parsing for build scripts [on Cameron McCormack - due 2012-05-31].