See also: IRC log
<trackbot> Date: 23 June 2011
<scribe> ScribeNick: vhardy
CM: First topic, joint meeting with CSS
VH: We can host the SVG meeting
... We have problems finding a room for the joint meeting.
... we can host the SVG WG meeting.
CL: there has been two offers to host the CSS WG, but none has been confirmed.
CM: My guess is that it should not be a problem to find a big enough room at Microsoft.
CL: I sent a message asking to meet tuesday to Friday, and Tuesday would be the overlap day.
CM: that is fine.
RESOLUTION: The SVG WG will meet Tuesday to Friday. Tuesday will be the joint meeting.
VH: Adobe can host Wednesday/Thursday/Friday.
<konaya> Oh, a bot
VH: we are looking into hosting the FX meeting and the CSS WG meeting but we have issues finding the right-size room.
RC: There are Microsoft and Google buildings in the same neighborhood.
<scribe> ACTION: ITEM to CL to talk to Microsoft to see if they can host the joint FX meeting. [recorded in http://www.w3.org/2011/06/23-svg-minutes.html#action01]
<trackbot> Sorry, couldn't find user - ITEM
<scribe> ACTION: CL to talk to Microsoft to see if they can host the joint FX meeting. [recorded in http://www.w3.org/2011/06/23-svg-minutes.html#action02]
<trackbot> Created ACTION-3054 - Talk to Microsoft to see if they can host the joint FX meeting. [on Chris Lilley - due 2011-06-30].
CM: Anything else we need to
discuss on the F2F?
... The end of the month is coming, remember to enter Action Item requests.
s/Action Items/Agenda Items
CM: Next topic is test
... CSS 2.1 test suite conversion
CM: Tav mailed in that he is
converting CSS 2.1 tests to SVG.
... I wanted to use that as a starting point to discuss plans for the test suite and using the same test framework as the CSS working group.
Tav: How does that differ from what we do now.
CL: The test suite does a lot
about agregating test results automatically on the back-end. It
is worthwhile for someone in the public to run some of the
tests. You can get test confirmation by having several people
running the same tests.
... there was also a plain text format to submit test results.
CM: Do they have both automated and manual tests?
CL: It is automated in the sense
there is a button, but the user needs to press the button.
There were some automated tests support, so it should be
possible to integrate them.
... This is being moved to W3C, and it is work in progress. You need to track and follow to see how it is going.
Tav: Does it require us to change our test?
CL: No, but it would require us to do a ref test for all tests, a simplified version of how it is supposed to look.
ED: Yes, that is correct. We already do that for some tests, we would have to do it for all tests.
CL: it may not be possible for all these CSS tests, e.g., tests on filters.
CM: In that case, use a PNG.
CL: the advantage of using a ref file instead of a PNG, is that it takes out the issues with sub-pixel and font variations.
Tav: what you mean by a ref test is an SVG capture of what the expected result should be.
CL: for example, if you tested
the alignment thing, you could have a ref test that positioned
... we have tests where the expected result is shapes filled in green, and that is simple to produce in a reference SVG image.
CM: Is it worth looking at what they have right now?
CL: I suggest sending an email to ask where they are, what we should do to adopt the harness.
... Peter Linss is the right contact?
CL: Yes, I believe so.
<ChrisL> Peter Linss <firstname.lastname@example.org>
CM: the other thing that was discussed was having a joint telcon about this.
CL: I talked to Philippe about it, but it was not ready at that time. May be we should have the meeting now.
CM: there is no harm in asking
... I'd like to have a plan now for a way to add test to the repository.
ED: I think it is useful to add SVG reference tests anyway, even if we figure out how to put them in the harness later.
<scribe> ACTION: CM to email Peter Linss to coordinate on using the test harness in the SVG WG. [recorded in http://www.w3.org/2011/06/23-svg-minutes.html#action03]
<trackbot> Sorry, amibiguous username (more than one match) - CM
<trackbot> Try using a different identifier, such as family name or username (eg. charles, cmccorma)
<scribe> ACTION: Cameron to email Peter Linss to coordinate on using the test harness in the SVG WG. [recorded in http://www.w3.org/2011/06/23-svg-minutes.html#action04]
<trackbot> Created ACTION-3055 - Email Peter Linss to coordinate on using the test harness in the SVG WG. [on Cameron McCormack - due 2011-06-30].
CM: Tav, when you looked at the test suite, there are a bunch of tests that do not apply, right?
Tav/CL: yes, e.g., Box model tests.
CL: Some of the tests tend to be very atomic, instead of grouping things together.
DS: atomic tests can be good, but each test has a cost when you run nightly.
CL: yes, it can take up to 5 days to run the CSS test suite manually.
CM: even the size of the SVG WG
test suite is a bit much.
... I am glad to be moving towards an automated solution.
DS: what do implementors think between the trade-off between more atomic tests and fewer tests.
CM: I agree there are advantages in having more atomic tests in some cases, but there is overhead.
DS: part of me also wonders if we
should think about automatically creating tests. Are there
things, like APIs, that we could automate?
... that could save work.
CM: for tests that could let you test things automatically, I would tend to do that in the test itself, with script.
VH: in my experience, we tried to break down tests into small atomic pieces grouped into a single test case to avoid having more test files.
DS: may be we can try to keep some atomicity in the tests and combine the ones that are related.
CM: I think there are advantages in grouping, especially if they are the same form.
CL: Yes, and if you have used a particular technique, they you can share code and it is easier to maintain.
CM: Another point people may
consider is the absolute number of tests.
... Yes, this can be a double edge sword.
... we could identify, in the test meta-data, how many subtests there are. So we could talk about the number of tests and test files. So we could say the total number of tests.
... that may not always be easy to separate out.
... for scripted tests, we have a number of assertions, so you can say, after running the test, how many assertions you had.
DS: that is what I was talking about: how many assertions where tested?
CM: this is possible for scripted
... for my own SVG tests, I have tended to make it match a particular rectangle on the rendering.
... you can visually see how many subtests are there.
VH: Should we add meta-data as DS suggested?
CM: I don't want to add more
meta-data if we can avoid it. They can become out of
... my feeling is that in some cases, the number of subtests might be easy, and hard in some other cases. Looking at the number of test files is an easier metric.
... I am not sure if I am decided.
VH: The CSS harness has a way to reference back the SVG spec.
CL: yes, that is right, and so does the SVG harness.
DS: We should do that.
CL: yes, we just have to decide
and make the pointers to the spec. consistent.
... rather to linking to the section, tests should link to the specific testable assertion. The link actually provides a way to highlight the specific assertion.
DS: I am trying to do that with
DOM Level 3 events.
... I have tried to break things down into testable assertions, which is not easy.
CL: My feeling, is that if you do
it like this, then it is easier to implement.
... We were very careful with testable assertions in WOFF.
... it worked out well, it was a good plan.
DS: I would like to follow
something similar in the SVG WG.
... there are benefits to having discipline there.
CM: we should start organizing a space in the repository for tests so that we can start shuffle things there.
ED: Don't we already have a repository set up for SVG 2.0 tests?
CM: I do not remember if there is anything for the test suite.
CM: We have that directory already.
CL: apparently, one advantage of using this repository is that you can deploy versions of the test suite fairly easily.
ED: It would be good if we started to review tests if they are put in the repository.
CM: We should start putting tests in the repository. It is currently empty.
VH: Should we have a requirements document for SVG 2.0 to capture the type of agreements we just had.
CL: a requirement document can be written before or after.
DS: you need to have some requirements before.
<ChrisL> um. thats not really my point
CM: Either way, we need to have something written up about what our goals are.
<ChrisL> there are two ways to develop. on e is a reqts doc in advance and then build that
<ChrisL> the second is to spec stuff and see what gets agreement and implementor traction. then you effectively write a summary at the end which is the requirements
<scribe> ACTION: Vincent to put together a wiki page to capture requirements for the SVG 2.0 test suite. [recorded in http://www.w3.org/2011/06/23-svg-minutes.html#action05]
<trackbot> Created ACTION-3056 - Put together a wiki page to capture requirements for the SVG 2.0 test suite. [on Vincent Hardy - due 2011-06-30].
<ChrisL> there are advantages and disadvantages to oboth approaches
Tav: CL, did you start looking at the test cases you have put together?
CL: yes, I did. They look good so far.
DS: Tav, thanks a lot for doing that work.
... next topic: Continue discussion on joint FX specs.
... I continued the thread after the CSS WG had their meeting this week. Looking at the minutes, I see the CSS WG did not discuss it this week and also got a charter extension.
CL: Yes, that is right and VH could not make it to the meeting this week.
CM: I sent my thoughts on the
items VH listed. It would be good if we could have agreement on
what our collective opinion is.
... I am not sure if the email list discussion will get us to resolution.
CL: Yes, we need resolution to make sure we have a common agreement between the groups.
CM: Let's go over my email.
CM: Filter effects.
CL: Yes, this seems pretty
... There may have been confusion where some people thought there would only be canned tests. This seems to have been cleared.
ED: I would prefer a single spec.
RC: Me too.
VH: Is that still undecided?
RC: no, that has been agreed upon. There was confusion, but that is clear now.
DS: Is that clear for everybody now?
VH: It seems that the group's position is that there should be a single spec. applying to CSS and SVG which will include predefined filters and extensible filters.
CL: I'll bring that to the CSS WG meeting next week.
RESOLUTION: The SVG WG agrees we should have a single filter spec. applying to CSS and SVG which will include predefined filters and extensible filters.
CM: next is compositing. I think it is similar to filters so it should be a common spec.
CL: I agree, but I do not see many people in the CSS WG excited about this.
DS: may be it is because they have a lot of other things to think about.
CL: there was some interest in the Porter-Duff compositing rules.
... some other people were not interested or questioned the usefulness.
CM: for compositing, since it is reasonably simple, and it is straightforward how it applies to CSS, it is easy to get it in a form that can be reviewed and adopted later on.
DS: yes, we could also make it so that it could be immediately useful to CSS, like pointer-events.
RC: yes, and things like enable background are also part of filter effects.
RESOLUTION: The SVG WG think it would be preferable to work jointly on the compositing spec. but would carry it forward if the CSS WG is not interested.
ED: Yes, the spec. is already in last call, so we could work on the next version as a joint effort.
CM: next is gradients.
... I am not exactly clear on this one. Tab is working on the CSS Image Values spec.
DS: I would like to work on this together to make sure that there is coordination and interoperability.
CM: Yes, I agree.
DS: syntax is on thing, but we should try to have a common model.
RC: I have raised that on the mailing list before. This was rejected at the time, but I think people are coming back to it now.
RESOLUTION: The SVG WG thinks the gradient effort should be coordinated to ensure an interoperable model with SVG gradients even if there are syntactic variations. There should be a way to reference SVG paint servers. Two separate coordinated specifications seem ok.
CM: next is parameters.
... this is interested because it started of as something specific and it can be generalized. This would determine if it should be SVG only or not. DS: what do you think?
DS: I am torn. I want the functionality for SVG. I hear people wanting it for CSS, but I am not sure how to do it in CSS. I have gone through different revisions. I'd be very happy if something like this, even in a different form, were to happen in CSS. I am not sure what it would be though. Trying to get the perfect thing may end up being like RCC/sXBL/XBL and not see implementation / traction. It is very, very useful for SVG. There are a few things
I would change based on feedback I got.
DS: I am happy to work on it with the CSS WG if there is interest.
CM: Do you know how it might relate to CSS variables.
DS: they could be combined I
think. It depends on what you mean by CSS variables.
... DG's CSS variables allow you to have CSS variables that are then used throughout the file.
CL: Yes, it is like macros.
... some people wanted predefined constants.
... some people wanted actual variables with values actually computed and modified in scripts.
DS: the primary use case I have
is the ability to reuse the same SVG content by passing in data
per-instantiation of the image.
... CSS variables do not do that, they do something different.
... but that is not incompatible.
Tav: Example of param is a button with different text.
DS: yes, or an icon with
... or a t-shir with different colors.
CM: I think you are right that
the differences are significant.
... there is also the CSS mixin proposal.
VH: I think that is different than parametrized SVG.
DS: I have talked to authoring
tool vendors who have actually implemented this because they
saw the value.
... Yes, it could be generalized, but may be we should start in the SVG WG.
CM: We could always keep in mind that it could be generalized later.
DS: why don't we just say that this an SVG-only effort at this point.
CM: Tab is the one who wants to push forward the CSS variables?
CL: Yes, but Daniel Glazman is as well, and he is writing an authoring tool.
CM: is it worth contacting Tab whether CSS variables are moving forward and evaluate how that relates to parameters?
DS: I am open to other people's suggestion.
VH: CSS variable's initial values could be made the value of parameter, but apart from that, they are different things.
CM: this is the type of things that we should discuss with Tab and others.
DS: whatever we do, we should
discuss with the CSS WG to make sure it works.
... I'd like to see how this will work with calc()
RESOLUTION: The SVG WG wants to work on parametrized SVG content and we would like to coordinate with the CSS WG on syntax and possible relation to CSS proposed features such as variables and calc().
CM: next is content layout.
... my feeling is that there are parts of the spec. that are directly usable and some that are not. I do not think there is a particular need to specify this in a separate spec.
DS: does that also bear on your constraints efforts?
CM: I am not sure.
RESOLUTION: The SVG WG proposes that any spec. that specifies how any CSS layout spec. applies to SVG content would be done in an SVG WG specification, coordinated with the CSS WG.
CM: Next, shared properties (like
... I do not think the coordination overhead is worth it.
ED: that is fine.
RESOLUTION: SVG WG thinks that how random shared properties apply to SVG can be defined in the SVG specification.
CM: advanced text layout.
VH: I would like to see convergence on how single text line composition is done.
CM: I think that is
... what about flowing text.
VH: This depends on how most implementations will be: if they are both HTML and SVG.
CM: Yes, it has an influence on
how important to have advanced text features in SVG.
... For stand-alone SVG implementations, it is important to have more functionality than a single line of text.
... were people keen on enhancing the flow-text features in SVG?
CL: It is a commonly requested feature and a commonly opposed feature.
Tav: Inkscape has an implementation.
CL: Batik as well.
VH: I wonder if we should enhance the SVG features or enhance the integration of CSS text feature?
Tav: From our perspective, we should enhance the SVG text features.
DS: these are not contradictory, more CSS text features would enhance the SVG features.
VH: we should strive to have a single model, and may be allow different syntax for SVG for the stand alone case.
CM: it does not sound like that we need a joint specification.
DS: yes, that is right.
... this is saying we draw from CSS where we can.
... Except that we are asking the CSS WG to take SVG into account as well as HTML.
RESOLUTION: The SVG WG does not the need to have a joint effort on text layout other than regular coordination.
tracbot end telecon
<shepazu> trackbot, end telcon
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) FAILED: s/Action Items/Agenda Items/ Succeeded: s/Tab/Tav/ Succeeded: s/for all tests/for all these CSS tests/ Succeeded: s/spec.s/specs./ FAILED: s/Inkscape/Inkscape/ Succeeded: s/Inkspace/Inkscape/ Found ScribeNick: vhardy Inferring Scribes: vhardy Default Present: Doug_Schepers, ed, tbah, Rick, heycam, Oliver_Goldman, ChrisL Present: Doug_Schepers ed tbah Rick heycam Oliver_Goldman ChrisL Agenda: http://lists.w3.org/Archives/Public/public-svg-wg/2011AprJun/0162.html Found Date: 23 Jun 2011 Guessing minutes URL: http://www.w3.org/2011/06/23-svg-minutes.html People with action items: cameron cl cm item vincent WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]