See also: IRC log
<trackbot> Date: 24 May 2012
<heycam> ScribeNick: nikos
<krit> 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> 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> 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 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
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> 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> 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
CM: might not be much to talk
about here
... in my email
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> 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> 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
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> http://lists.w3.org/Archives/Public/public-xml-er/
CM: not much activity since February
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
[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
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 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].
This is scribe.perl Revision: 1.136 of Date: 2011/05/12 12:01:43 Check for newer version at 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.aacc nikos Doug_Schepers Agenda: http://lists.w3.org/Archives/Public/public-svg-wg/2012AprJun/0053.html Found Date: 24 May 2012 Guessing minutes URL: http://www.w3.org/2012/05/24-svg-minutes.html People with action items: cameron[End of scribe.perl diagnostic output]