Re: minutes, 24 May 2012 SVG WG telcon

From: Cyril Concolato <cyril.concolato@telecom-paristech.fr>
Date: Fri, 25 May 2012 11:22:22 +0200
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
>
>
>       [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
>
>
>    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
>
>
>    ... 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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:20:14 UTC