- From: Cyril Concolato <cyril.concolato@telecom-paristech.fr>
- Date: Fri, 25 May 2012 11:22:22 +0200
- To: public-svg-wg@w3.org
- Message-ID: <4FBF4F4E.40707@telecom-paristech.fr>
Hi all, Belated regrets for yesterday but I'm changing ISP at the moment and I realized yesterday night that I don't have access to the Internet from home. Cyril Le 5/25/2012 1:12 AM, Nikos Andronikos a écrit : > > Minutes from today's SVG WG telcon are at > > http://www.w3.org/2012/05/24-svg-minutes.html > > and below as text. > > [1]W3C > > [1] http://www.w3.org/ > > - DRAFT - > > SVG Working Group Teleconference > > 24 May 2012 > > [2]Agenda > > [2] > http://lists.w3.org/Archives/Public/public-svg-wg/2012AprJun/0053.html > > See also: [3]IRC log > > [3] http://www.w3.org/2012/05/24-svg-irc > > Attendees > > Present > > ed, heycam, +1.415.832.aaaa, +33.9.53.77.aabb, krit, > > +61.2.980.5.aacc, nikos, Doug_Schepers > > Regrets > > Chair > > Cameron > > Scribe > > nikos > > Contents > > * [4]Topics > > 1. [5]Test the web forward event > > 2. [6]SVG 2 update > > 3. [7]Referencing properties from other specs in SVG 2 > > 4. [8]Removal of the Media Type Registration chapter from > > SVG 2 > > 5. [9]Do we still like solidColor? > > 6. [10]Naming things going forward (camel case still in > > favour?) > > 7. [11]Dropping contentStyleType and contentScriptType > > * [12]Summary of Action Items > > __________________________________________________________ > > <trackbot> Date: 24 May 2012 > > <heycam> ScribeNick: nikos > > Test the web forward event > > <krit> [13]http://testthewebforward.org/ > > [13] http://testthewebforward.org/ > > CM: Are any SVG group members attending? > > DS: I'll be there > > <heycam> Doug and Dirk will both be there > > CM: focus is on testing, it'd be good to have test repository > > and framework up and running by there > > Tav: frame work is up but repostory isn't there yet > > ... other way around > > krit: which account do you use to commit? > > <heycam> [14]http://www.w3.org/Graphics/SVG/WG/wiki/Svgwg.org > > [14] http://www.w3.org/Graphics/SVG/WG/wiki/Svgwg.org > > CM: svgwg.org account > > ... need to send ssh public key to jwatt or myself to get > > access > > krit: I'm talking about repository for test suite, not spec > > CM: they're on the same machine > > <ed> hg clone ssh://svgwg@svgwg.org/hg/svg2-tests > > CM: might be possible to set it up so that you use different > > accounts > > krit: can we avoid sending public key for tests? > > ... want to make it accessible > > CM: you mean to people outside the wg? > > krit: yes > > ... we should ask css group and others to commit tests > > CM: so anyone from the public could get an account and commit? > > would there be restrictions? > > Tav: it would be like css where you can commit to your own > > area, needs approval to move > > CM: is that done with hooks? > > ... or is it convention? > > krit: no folder besides the approved folder is restricted > > Tav: don't forget we're using the 2 step system, so it's more > > complicated > > CM: in the CSS group do you commit directly to the w2c > > mercurial? > > krit: yes > > Tav: we should re-discuss our test format > > ... we have a format we came up with, new tests should follow > > that format > > krit: can't we just do it like the css wg? > > Tav: how is that? > > <krit> csswg.org > > krit: they have a good wiki > > <krit> [15]http://wiki.csswg.org/test > > [15] http://wiki.csswg.org/test > > krit: in general, I think it would be great if we keep it as > > similar as possible > > Tav: that's the plan > > CM: I think we're half way there, repository is in the right > > structure > > Tav: template is worked out > > krit: only problem is to connect and commit > > CM: I'll look into it > > ... looking a the contribute page, when you had it set up so > > you could commit, what authentication did yo use? > > krit: sign up for wiki, then send email to Peter Lins, > > CM: during this event, is the intention for people to get > > accounts and commit to the repository? > > krit: yes > > <scribe> ACTION: Cameron to look into getting repository > > working for test the web forward [recorded in > > [16]http://www.w3.org/2012/05/24-svg-minutes.html#action01] > > <trackbot> Created ACTION-3295 - Look into getting repository > > working for test the web forward [on Cameron McCormack - due > > 2012-05-31]. > > CM: is it 3 weeks away? > > krit: 15-16 June > > SVG 2 update > > CM: what's the latest work that's been done? > > ... reminder that the plan is to publish FPWD in July, 2 months > > away > > ... I've been working on the painting chapter > > ... I see Erik has added buffered rendering > > 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? > > 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 > > ... 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 > > ... I think we wouldn't lose too much automation if we included > > IDL in the pre elements > > ... manually > > ... in terms of other changes, I've been bringing property > > layouts in line with the css specs > > <heycam> > > [17]https://svgwg.org/svg2-draft/painting.html#StrokeShape > > [17] https://svgwg.org/svg2-draft/painting.html#StrokeShape > > CM: it's a bit more algorithmic than usual, is that good or > > should we rewrite it a different way? > > krit: the images are done with svg yeh? > > CM: yes > > ... I did it with a dash array > > ... I mentioned on the mailing list, it's probably safe to use > > 1.1 features, but not filters or animations > > krit: I'm fine with that > > CM: what I might do is add links to the png renderings of the > > svg > > nikos: we need a script where you can point to an svg and get a > > png > > CM: use common sense and avoid things that we know aren't well > > supported > > krit: can we convert dash array to a path? > > Tav: inkscape can do that > > krit: it would be a good idea for dash array so that it renders > > the same everywhere > > CM: I've been using the coloured backgrounds when I've been > > reworking sections from the 1.1 text > > ... When it's good, I change it to yellow which means its ready > > for SVG WG to review > > krit: It gets turned to white after review? > > CM: when we publish, the group as a whole will sign off on the > > yellow and turn them to white > > ... It will be good if people look through at the yellow > > sections to get an idea whats in there > > ... 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 > > krit: I want to make sure equations have metadata > > CM: I'm a bit concerned about the accessibility, the usual > > method with maths is to use 'mathplayer' which is ie only > > ... it would be good to know if there's a better solution > > krit: in general we don't care how it gets displayed, as long > > as it can, in theory, be transformed > > CM: I've used a hidden pre element with the content > > <heycam> > > [18]https://svgwg.org/svg2-draft/painting.html#ColorInterpolati > > onProperty > > [18] > https://svgwg.org/svg2-draft/painting.html#ColorInterpolationProperty > > CM: copy and paste the formula and you'll see the hidden markup > > ... I'm using an aria element > > ... I could have a hidden button that turns off the mathjax > > rendering > > krit: be careful with hidden elements, they're not read or > > displayed > > CM: with the annoations we're adding, should we remove them > > once we add the feature? > > Tav: they have some historic value > > ... the idea is when they're published they're hidden > > ... 10 years from now someone might want to know why it was > > done that way > > Referencing properties from other specs in SVG 2 > > CM: might not be much to talk about here > > ... in my email > > [19]http://www.w3.org/mid/4FB5A353.3050802@mcc.id.au > > [19] http://www.w3.org/mid/4FB5A353.3050802@mcc.id.au > > CM: in svg 1.1 there's a bunch of css properties that hav ebeen > > redefined > > ... we should reference existing definitions > > ... remove the tables and reference the css spec > > <heycam> > > [20]https://svgwg.org/svg2-draft/painting.html#VisibilityContro > > l > > [20] https://svgwg.org/svg2-draft/painting.html#VisibilityControl > > CM: I've preserved most of the text, but reworded a little > > 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 > > CM: I'm not sure about the property links in the text, should > > it go to css? > > nikos: no, should link to same document > > Tav: I agree > > CM: similarly for properties we've moved from svg to specs we > > depend on > > ... 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 > > ... one of the changes with 2nd edition 1.1 is for every > > element that's styleable is to allow all presentation > > attributes > > ... I think a hook in the main spec that other svg specs can > > link to would be good > > <krit> > > [21]http://dev.w3.org/csswg/css3-transforms/#svg-transform > > [21] http://dev.w3.org/csswg/css3-transforms/#svg-transform > > krit: See sentence 'This specification will also introduce the > > new present...' > > CM: the last sentence about parsing, I think the svg spec will > > need a couple of definitions like that > > ... other specs will need to specify if they allow extended > > syntax > > <heycam> krit: css3-syntax spec will define syntax for > > presentation attributes > > krit: CSS 3 syntax spec will define syntax for presentation > > attributes > > shepazu: I've been asked to present on SVG at Test the web > > forward. Anyone interested in helping me? > > Tav: I can > > krit: I can do that > > ... I can talk about committing, we can share the presentation > > if you'd like > > ... however you want to organise it > > shepazu: We are looking at an API for querying test results > > krit: That's what shepherd is for > > 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 > > Removal of the Media Type Registration chapter from SVG 2 > > CM: I thought that because we have the media type registered > > now that we don't need the chapter > > ... I asked Chris > > ... He thinks we don't > > ... unless there are objections, I'll remove it > > ... it existed in the spec so the registry could point to > > something > > ... the media type won't mean anything difference between SVG 1 > > and SVG 2. not neccessary to resubmit > > shepazu: 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? > > ... A non XML SVG might be someone using SVG in HTML where they > > aren't quoting attributes, the HTML parser doesn't care. > > ... anything to do with HTML parsing can't be called XML > > CM: I think there was interest in using an error correcting > > parser for XML > > ... maybe a community group started up > > <heycam> [22]http://lists.w3.org/Archives/Public/public-xml-er/ > > [22] http://lists.w3.org/Archives/Public/public-xml-er/ > > CM: not much activity since February > > Do we still like solidColor? > > CM: solidColour is something we've resolved to have in SVG 2 > > but I don't like it > > ... one of the reasons is that it's not that hard to have the > > same effect with the current elements > > krit: even with changed behaviour? > > tav: how would you do it in another way? > > CM: until CSS variables are available use a single stop > > gradient > > ... slightly ugly but you don't have to put all the gradient > > attributes there > > Tav: It would be so much simpler to have solid color > > ... suppose you have a drawing with the same colour but in 16 > > different places, it would be problematic > > krit: you have a prsentation attribute and change it in one > > place > > 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 > > ... I'm thinking from an authoring point of view > > ... If there's interest in keeping it I won't block it > > ... 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 > > ... whether we keep camel case > > ... for each camel case name we introduce, we need to update > > the implementations > > Naming things going forward (camel case still in favour?) > > [No strong opinions given on solidColour] > > 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. > > ... if we introduce new attributes with camel case, the > > implementations need updating > > krit: I think that's fixed in DOM 4 > > ... don't have to think about it from a spec point of view > > CM: don't think so. if it's not registered it will become all > > lower case, and the DOM is case sensitive > > ... is it actually a problem to update the parser when adding > > the implementation for the new attribute? > > Tav: camel case is painful. I wonder if adding lower case > > versions of the attributes that have camel case would be the > > way forward? > > krit: what if you want one that's all uppercase? > > shepazu: you wouldn't want to > > ... in HTML it doesn't matter > > ... for XML parsing, case does matter > > ... for HTML, it's case sensitive, but when it's parsed it's > > all lower case, so the DOM is all lowercase. > > ... if we made all lower case versions of the tokens, HTML, SVG > > and XML could be valid > > ... 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 > > CM: in HTML parsing, if you put lower case and it becomes mixed > > case in the DOM, it's confusing > > shepazu: I've seen lots of problems with viewBox > > ... I don't think Chris would like this > > ... but if others think there's merit we should consider it > > CM: At the moment, what do we do with new things? Keep the > > existing scheme until we make a decision? > > ... I'm drawn to consistency > > shepazu: with what? HTML or SVG? > > CM: It's not just what people know, but what the other things > > in the same SVG fragment look like\ > > Tav: I agree > > CM: it's the same sort of issue with CSS property values > > ... they use dash separated names if anything > > shepazu: I think we should be consistent with HTML rather than > > CSS > > CM: you could introduce a dashed version of camel case > > properties > > <shepazu> sI think we should be consistent with HTML and CSS > > rather than SVG 1.1/I think we should be consistent with HTML > > and CSS rather than SVG 1.1/ > > shepazu: I used to think that consistency with SVG was more > > important, but now I find some of our conventions get in the > > way > > CM: If we convert everything to the one true convention, then > > at that point we can decide how to name new things > > ... I don't want to be in the situation where we have a mix > > ... not something we need to decide now, but we should consider > > it in future > > ... the near future > > Dropping contentStyleType and contentScriptType > > CM: In SVG 1, these attributes are designed to specify the > > language used in the style and event attributes > > ... SVG 1 spec says they're deprecated, should we remove them? > > shepazu: I think we can remove them > > ED: I agree > > shepazu: I think any solution (if necessary) will be mutual > > between SVG and HTML > > CM: These started as HTTP headers, then became attributes in > > HTML > > ... they don't exist in HTML 5 > > ... I understand the point that normally they're not used but > > because they are for extensibility they might be used privately > > ... Private use doesn't need something in the spec > > shepazu: I've used them > > ... you could do something weird with script that you can't do > > with regular javascript > > CM: Anybody against removing them? > > Resolution: Remove contentStyleType and contentScriptType > > <heycam> ACTION: cameron to investigate having a hidden button > > to turn mathjax rendering off [recorded in > > [23]http://www.w3.org/2012/05/24-svg-minutes.html#action02] > > <trackbot> Created ACTION-3296 - Investigate having a hidden > > button to turn mathjax rendering off [on Cameron McCormack - > > due 2012-05-31]. > > Summary of Action Items > > [NEW] ACTION: cameron to investigate having a hidden button to > > turn mathjax rendering off [recorded in > > [24]http://www.w3.org/2012/05/24-svg-minutes.html#action02] > > [NEW] ACTION: Cameron to look into getting repository working > > for test the web forward [recorded in > > [25]http://www.w3.org/2012/05/24-svg-minutes.html#action01] > > [End of minutes] > > __________________________________________________________ > > Minutes formatted by David Booth's [26]scribe.perl version > > 1.136 ( [27]CVS log) > > $Date: 2012/05/24 23:05:51 $ > > __________________________________________________________ > > [26] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm > > [27] http://dev.w3.org/cvsweb/2002/scribe/ > > Scribe.perl diagnostic output > > [Delete this section before finalizing the minutes.] > > This is scribe.perl Revision: 1.136 of Date: 2011/05/12 12:01:43 > > Check for newer version at > > [28]http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ > > [28] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ > > Guessing input format: RRSAgent_Text_Format (score 1.00) > > Succeeded: s/uuse/use/ > > Succeeded: s/Tav/shepazu/ > > Succeeded: s/event/even/ > > Succeeded: s/shepazu/tav/ > > Succeeded: s/colour/color/ > > Succeeded: s/chaneg/change/ > > Succeeded: s/Tav/shepazu/ > > Succeeded: s/Tav/shepazu/ > > Succeeded: 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/ > > Succeeded: s/the solution/any solution (if necessary)/ > > Found ScribeNick: nikos > > Inferring Scribes: nikos > > Default Present: ed, heycam, +1.415.832.aaaa, +33.9.53.77.aabb, krit, + > > 61.2.980.5.aacc, nikos, Doug_Schepers > > Present: ed heycam +1.415.832.aaaa +33.9.53.77.aabb krit +61.2.980.5.aa > > cc nikos Doug_Schepers > > Agenda: > > [29]http://lists.w3.org/Archives/Public/public-svg-wg/2012AprJun/0053.h > > tml > > Found Date: 24 May 2012 > > Guessing minutes URL: > > [30]http://www.w3.org/2012/05/24-svg-minutes.html > > People with action items: cameron > > [29] > http://lists.w3.org/Archives/Public/public-svg-wg/2012AprJun/0053.html > > [30] http://www.w3.org/2012/05/24-svg-minutes.html > > End of [31]scribe.perl diagnostic output] > > [31] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm > > The information contained in this email message and any attachments > may be confidential and may also be the subject to legal professional > privilege. If you are not the intended recipient, any use, > interference with, disclosure or copying of this material is > unauthorised and prohibited. If you have received this email in error, > please immediately advise the sender by return email and delete the > information from your system.
Received on Friday, 25 May 2012 09:23:10 UTC