- From: Rik Cabanier <cabanier@gmail.com>
- Date: Fri, 6 Dec 2013 15:27:03 -0800
- To: Chris Lilley <chris@w3.org>
- Cc: Cameron McCormack <cam@mcc.id.au>, "www-svg@w3.org" <www-svg@w3.org>
- Message-ID: <CAGN7qDCH1yudXxzWqu_2-KCvf+Ps2aEcz6xWjtid80=ptp9sag@mail.gmail.com>
Thanks for this info Chris! I will go over the history. I think there's only a couple of comments that I need to put in the disposition of comments. On Fri, Dec 6, 2013 at 12:47 PM, Chris Lilley <chris@w3.org> wrote: > Hello Cameron, > > Thursday, December 5, 2013, 10:44:42 PM, you wrote: > > > Minutes from this week's SVG telcon are below. > > > http://www.w3.org/2013/12/05-svg-minutes.html > > > > cabanier: I added isolation to the at-risk list > > > krit: I think that's something we can't do? > > > cabanier: no, that's according to the process > > ... going to CR you list the at risk issues > > > krit: don't you have to do that before LC? > > > cabanier: no it's part of going to CR > > Rik is correct: listing items at-risk is done before entering CR, and > is often done when the LC review period indicates that a particular > feature is poorly understood, non-interoperably implemented by two or > more implementors who don't want to change, has unforseen and poorly > documented interactions with other features, and so on. > > So it is commonly done between exiting LC and entering CR. > > Dirk is correct that a complete and detailed list of changes is > required. Generally, the disposition of comments document will explain > the rationale for the change. > > > heycam: no open issues on the spec? > > > cabanier: all resolved at LC > > ... only reason isolation is on the at risk list, is that we > > have only one implementation so far > > ... but I'm confident we'll have another one by the time we > > exit CR > > As Cameron mentioned after the call, there needs to be a complete > disposition of comments for all comments received since LC was > published (this includes threads that started before LC and are still > being discussed. > > In the case where changes/feature requests were requested but denied > (or moved to a next version) there also needs to be a mail from the > editors asking for confirmation that no change/deferred is okay (and > preferably, confirmation back from the commentor). > > If no change was requested and none made then its enough to just > record the comments and note that no change resulted. > > > heycam: what's the plan for a test suite? > > Tests are not required before entering CR (but are encouraged). Having > an idea of what tests are needed, a test plan etc and a rough estimate > of how long this might take, is information that must be in the > transition request for CR. > > > cabanier: someone from our team is working on a team right now > > ... she has more than 100 tests at the moment > > ... some people at TtwF also wrote some tests > > ... also Blink/Firefox/WebKit implementors writing some tests > > ... we have a test plan > > > Tav: does that include SVG tests? > > > cabanier: yes, as well as HTML tests. > > [11] > > > http://mire.github.io/css-blending-test-plan-proposal/css-blending-test-plan-proposal.html > > > krit: we're creating tests according to that plan > > That sounds good > > > > cabanier: and the Compositing modes are all there already > > ... there are four of them, and by combining them you can do > > src-in, dest-in, etc. > > ... except for 'clear', but you can accomplish that in other > > ways > > Given one of the last call comment from tav, the disposition of > comments could usefully add that information (everything you can do in > SVG1 you can do with this, right?) > If you refer to the old compositing spec, no, we only defined blending. > > nikos: same with Compositing and Blending 2 > > > Tav: what's going to be in there? > > > nikos: Compositing for SVG and HTML > > OK so now I am confused again; the test plan includes tests in SVG and > HTML, but compositing for SVG and HTML is deferred to level 2? > Yes, it is confusing. The only 'compositing' part that the spec currently defines, is for Canvas 2D. Compositing was stripped from the CSS properties because it required major changes in the way browsers draw. It will be back for level 2 and either we will change the model so it can be implemented or we convince the browsers to redo their graphics engines.
Received on Friday, 6 December 2013 23:27:32 UTC