minutes, 24 May 2012 SVG WG telcon

From: Nikos Andronikos <Nikos.Andronikos@cisra.canon.com.au>
Date: Thu, 24 May 2012 23:12:31 +0000
To: "www-svg@w3.org" <www-svg@w3.org>
Message-ID: <D6788E6173C4A64B9B42DE1F2EB94EB9BBE1DC84@exm02-wvp.cisra.canon.com.au>
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?

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

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

<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
... 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
[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 Thursday, 24 May 2012 23:13:11 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:29:50 UTC