with display:none 00:01:07 … so you can stick whatever you want there 00:01:11 … there's no need to put it in the 00:01:32 … the only thing we do have that maybe belongs in the head is the element, though our is structured 00:01:37 … in SVG you can nest elements in 00:01:42 … so it really doesn't belong in either 00:01:58 DS: I do think it's not unreasonable for people to think they should add things to the head 00:02:03 CL: at first sight it's very reasonable 00:02:26 DS: I think our best course of action is not to follow up on hixie's recommendation to define our elements as metadata content 00:02:32 … rather to simply to educate people that you can't do that 00:03:01 … I think it's very unusual that hixie would recommend this course of action 00:03:47 … I will respond to the original commenter 00:04:41 RESOLUTION: SVG will not allow elements to be put in HTML 00:05:33 Topic: shorthand properties as presentation attributes 00:05:45 http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Shorthand_presentation_attribute 00:06:19 ScribeNick: birtles 00:08:22 CL: CM's proposal on the wiki where you put the shorthands before all the properties in doc order satisifies my earlier concerns 00:08:36 CM: proposal is to allow pres attr for properties which are shorthands 00:08:51 ... at the moment you can't write marker="" b/c marker is a shorthand 00:09:03 ... creates confusion for authors 00:09:20 ... don't understand why they need to use marker-start etc. if they're using pres attr 00:09:26 ... with style you can just use "marker" 00:09:46 ... last time this issue came up was in context of when CSS properties get split and orig becomes a shorthand 00:09:53 ... e.g. overflow becoming overflow-x and overflow-y 00:09:59 ... overflow is now a shorthand 00:10:08 CL: likewise whitespace might go that way 00:10:23 CM: we want to allow overflow to continue to be a pres attr 00:10:29 ... even if it becomes a shorthand 00:10:49 ... original reluctance was you have multiple attr targetting the same property 00:11:53 ... and override behaviour was not clear since attr are unordered 00:12:03 ... unlike styles where you have doc order 00:12:20 ... but the proposal addresses that by taking shorthands first 00:12:52 ED: so you if have marker-mid before marker (as attributes) then marker will override marker 00:13:02 ED: so you if have marker-mid before marker (as attributes) then marker will override marker-mid 00:13:43 cabanier_ has joined #svg 00:14:17 CL: it's something we're going to have to address with properties being split up and becoming shorthands 00:16:38 CL: any comments from implementors? 00:16:49 ED: it's probably fine but I need to check the code 00:17:22 ... it would be pretty simple to verify if there were some test cases 00:18:59 CM: I think it should be ok 00:21:28 ... is there a difference between animating the style or the presentation attribute 00:21:45 CL: attributeType is just for disambiguation when the attribute name and property name overlap and are not the same thing 00:21:56 ... not to provide different behaviour 00:25:59 RESOLUTION: We will allow shorthand properties to be used as presentation attributes (ISSUE-2430) according to Cameron's proposal 00:27:06 ACTION: Cameron to describe using shorthand properties as presentation attributes in spec 00:27:06 Created ACTION-3207 - Describe using shorthand properties as presentation attributes in spec [on Cameron McCormack - due 2012-01-20]. 00:27:23 ED: is there an order normally to style 00:27:24 ACTION-3207: http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Shorthand_presentation_attribute 00:27:24 ACTION-3207 Describe using shorthand properties as presentation attributes in spec notes added 00:27:38 CL: yes, if it's in a stylesheet (incl style attr) 00:27:54 ED: if you start modifying the element by script, then the order is not guaranteed 00:28:05 CL: the assertion was attributes are unordered 00:28:19 vhardy has joined #svg 00:28:22 CM: the stylesheet is not exposed to script though right? 00:28:33 ... you can getComputedStyle but there's no order requirement there 00:28:45 ED: if it's just for when it's parsed then it's ok 00:29:12 CM: even if you're modifying the attr then you still need the shorthand first 00:29:37 ... if you're actually creating stylesheets you could create two (one for shorthands) 00:29:42 ... might be simpler than managing the order 00:31:42 ED: what about font? you have to use CSS rules such as requiring units 00:31:46 ... isn't that confusing? 00:31:53 ... for all shorthands you have to use units 00:31:59 ... whereas elsewhere you don't 00:32:08 CL: it's only really for lengths where we have this different 00:32:15 ... where you don't need units in SVG 00:32:20 ... marker etc. are ok 00:32:26 ... it's only really 'font' 00:33:03 ... so it would be a rule that shorthands have to use CSS rules which includes using units (and excluding scientific notation) 00:33:12 CM: what if we came up with our own shorthand 00:33:25 ... that wasn't ambiguous 00:33:31 CL: that would be confusing to use a different notation 00:33:56 ... and might outweigh the benefit of using shorthands 00:34:17 ... because you'd add syntax to disambiguate 00:34:41 CM: so we'll just require CSS parsing for shorthand presentation attributes 00:34:49 ED: I think that would be ok, better than adding quirks 00:35:03 CM: what about new CSS properties? 00:35:18 ... we have font-size in SVG so we can explicitly allow unitless lengths 00:35:46 CM: do we want to revisit scientific notation in SVG 2? 00:35:57 ... because perhaps it's not used? 00:36:24 CM: many scripts default to using exponential notation 00:36:32 s/CM: do we/CL: do we/ 00:36:51 CL: we were originally expecting much more use of the world coord system with very large numbers 00:37:00 ... but in practice you actually run into precision problems 00:37:43 Topic: SVG2 Requirements 00:38:46 ChrisL has joined #svg 00:39:29 Up to: http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Improve_to-animations 00:40:45 we should also deal with http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#SMIL_time_containers 00:41:31 deciding on time containers depends on me finishing action-3202 00:43:56 BB: not sure what this means 00:44:22 CM: I guess it's about addressing differences 00:44:27 BB: what are the differences? 00:44:34 CM: underlying value is fixed, reversing 00:45:05 BB: my guess is reversing? 00:45:14 VH: we should find out what is specificallly required here 00:46:21 ACTION: Cameron to contact Dr. Olaf Hoffmann to ask what is specifically required to make to-animation similar to CSS transitions 00:46:22 Created ACTION-3208 - Contact Dr. Olaf Hoffmann to ask what is specifically required to make to-animation similar to CSS transitions [on Cameron McCormack - due 2012-01-20]. 00:46:45 ACTION-2308: http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Improve_to-animations 00:46:45 ACTION-2308 Draft an email response for the second half of ISSUE-2089 notes added 00:47:09 ACTION-3208: http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Improve_to-animations 00:47:09 ACTION-3208 Contact Dr. Olaf Hoffmann to ask what is specifically required to make to-animation similar to CSS transitions notes added 00:48:54 CL: we are going to have transitions anyway based on Patrick's proposal to allow using SVG's attributes in CSS 00:49:18 RESOLUTION: SVG 2 will allow CSS-transitions-like animations 00:49:32 RRSAgent pointer 00:49:35 RRSAgent, pointer 00:49:35 See http://www.w3.org/2012/01/12-svg-irc#T00-49-35 00:49:47 ACTION-3208: Say to Olaf we have interpreted his request in this way, and we agree, but if he means something else please explain 00:49:47 ACTION-3208 Contact Dr. Olaf Hoffmann to ask what is specifically required to make to-animation similar to CSS transitions notes added 00:50:01 rrsagent, make logs public 00:50:31 next, Transitions for discretely animated properties, text-anchor in particular 00:52:06 commenter wants to smoothly animate from 00:52:08 .................|.................. 00:52:08 SOME_TEXT_1 00:52:08 SOME_OTHER_TEXT_2 00:52:09 to 00:52:19 ................|.................. 00:52:19 SOME_TEXT_1 00:52:19 SOME_OTHER_TEXT_2 00:52:41 ED: even though text-anchor-end animation is discrete it would be possible to provide linear interpolation 00:52:55 CM: it is a bit of a violation of the model and the idea of "discrete" 00:53:18 I think that breaks the modelof animation. at all points in the animation, the value of the animated property has to be one of the actual values 00:53:52 VH: there's a difference between calcMode="discrete" and calcMode="linear" that falls back to discrete 00:54:28 CM: if we wanted it to work for text-anchor we could allow it to take numeric values 00:54:33 we could imaging a mapping with for example-100% as start, 0 as middle,100% as end 00:54:36 ... e.g. -100 to 100 00:55:11 CL: we could spec it fairly easily 00:55:50 ... I think it's ok if we're just talking about calcMode="linear" that falls back 00:55:56 ... as opposed to calcMode="discrete" 00:56:08 CM: but I often rely on that fallback behaviour 00:56:16 ... and don't specify calcMode="discrete" 00:56:42 CL: if we did this change and people are relying on the discrete behaviour they might get a surprise 00:57:23 butthey could fix it by adding calcmode discrete to keep the old behaviour 00:59:12 BB: so you have to modify the definition of those attributes to allow numeric values 01:00:26 CL: the approach is to make attributes that take discrete values to be shorthand for those that take numeric values 01:00:55 CM: in font-weight, some of the keywords are synonyms for numbers 01:01:04 CL: but it's an ordered series 01:01:35 CM: what happens when you getComputedStyle---which do you get? the keyword or the number? 01:02:17 ... likewise what will happen here if we use getComputedStyle on the new text-anchor etc. that takes numeric values 01:02:38 CL: I'm proposing promoting some values so that can take *continuous* values 01:02:47 ... so font-weight would not be an example 01:07:44 RESOLUTION: SVG2 will allow linear interpolation for properties which were previously discrete 01:08:21 ACTION: Chris to write up a proposal for allowing linear interpolation of properties that were previously discrete but could be reasonably interpolated linearly 01:08:22 Created ACTION-3209 - Write up a proposal for allowing linear interpolation of properties that were previously discrete but could be reasonably interpolated linearly [on Chris Lilley - due 2012-01-20]. 01:09:08 ACTION: Brian to look for text in SVG/SMIL that suggests using different calcMode's based on the values used (enum values versus numeric) 01:09:08 Created ACTION-3210 - Look for text in SVG/SMIL that suggests using different calcMode's based on the values used (enum values versus numeric) [on Brian Birtles - due 2012-01-20]. 01:10:37 next, animateTransform with matrix-decomposed like CSS 01:10:46 http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#animateTransform_with_matrix-decomposed_like_CSS 01:11:13 CM: diff between animateTransform and CSS Animations with transform property, is CSS considers the whole transform list, but SVG Animations does one transform at a time and post-multiplies 01:11:29 ... request is to add a new type to animateTransform that matches CSS Animations 01:11:58 ... but we could just to get that behaviour 01:12:26 ... 01:12:29 ... it overrides the whole list 01:13:31 ... need to define how additive works with whole lists of items 01:17:01 VH: so how does animateTransform add to the end of the list? 01:17:11 BB: it differs between browsers 01:17:49 ... if you inspect the animVal in the DOM some browsers will just append a matrix transform, some will try to preseve the animateTransform's type, others just replace the whole list with a matrix 01:19:21 VH: even if we deal with lists we already have a model for adding that to the underlying transform, it doesn't change the model 01:19:37 CC: it doesn't change the post-multiplication 01:20:20 ... it doesn't change the final value 01:20:25 ... but it does change the animVal 01:20:51 VH: but given the way the requirement is worded I think it wouldn't change 01:22:51 VH: we want to allow 01:22:54 CM: I agree 01:23:28 RESOLUTION: We will support animation using a transform-list 01:24:48 http://dev.w3.org/csswg/css3-2d-transforms/#animation 01:27:42 http://brian.sol1.net/svg/animatetransform-issues/accumulation-of-transformations/ 01:29:19 BB: Addition of transforms is a bit unusual (see above link) 01:29:44 ... we can rely on CSS Transform's behviour for interpolation but we need to specify how addition works for transform lists 01:30:24 CM: this difference is specific to animateTransform 01:30:38 ... so if we go to using animate, do we want to just use the default behaviour? 01:31:03 .... which would mean adding the transform components rather than post-multiplication 01:33:43 ACTION: Cyril to investigate different methods for adding transform in animation 01:33:44 Created ACTION-3211 - Investigate different methods for adding transform in animation [on Cyril Concolato - due 2012-01-20]. 01:33:55 ACTION-3211: http://brian.sol1.net/svg/animatetransform-issues/accumulation-of-transformations/ 01:33:56 ACTION-3211 Investigate different methods for adding transform in animation notes added 01:35:16 ---break 1hr for lunch--- 01:35:48 http://dev.w3.org/SVG/profiles/1.2T/test/htmlObjectHarness/animate-elem-81-t.html 01:49:18 Sorry, I didn't catch the end of this discussion, and I hope you had a good lunch :) 01:49:36 When we talk about adding a new element, such as animateTransform, are we consulting with the HTML group as well? 02:31:49 Not animateTransform but any *new* element (sorry) 02:49:50 scribeNick: ChrisL 02:49:58 topic: Milestones and Planning 02:50:58 http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Planning_Page 02:50:59 heycam: need some target dates 02:51:21 vhardy has joined #svg 02:51:33 http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Planning_Page 02:52:23 http://dev.w3.org/SVG/profiles/2.0/reqs/publish/ 02:52:27 heycam: was supposed to add stuff back into the wiki page from the separate document 02:52:55 ChrisL: and people were to add explanation for the accepted items 02:53:20 jun has joined #svg 02:53:37 vhardy: whatabout use cases? 02:53:44 heycam: should be in the wiki page 02:54:08 ... if its useful we can continue working on a /TR requirements doc 02:54:50 ChrisL: want oto avoid work that is of no beefit. wiki page is more easily updated 02:55:09 ed: easier to update wikipage 02:55:20 heycam: easier to read a published doc though 02:55:34 cyril: we have 90 left to do 02:55:46 ... out of 180 at the start 02:55:47 stakagi has joined #svg 02:56:08 ... wereat 40% after tpac 02:56:25 vhardy: think its a big effort to migrate to a new document 02:57:19 ChrisL: people do not read reqts top to tail, they drill down on a particular issue 02:58:20 ... still feasible to do by end of this f2f? 02:59:26 cyril: we have 2/3 by scrollbar 02:59:40 birtles: doc gets longer as we edit 03:00:30 ChrisL: earlier ones were more vague and we took a lot of time to understand the comments. later ones are specced features from 1.2T so its either in or out 03:02:58 ChrisL: next, whatdo we have in fpwd - lots or a little (ipp implications) 03:05:50 CM: the other question is whether we go forward with this grand refactoring of the document that we talked about before 03:06:19 cabanier has joined #svg 03:06:57 … I think it would be better to not do that upfront 03:07:17 … instead we just add the features/changes according to the existing structure 03:07:24 … so we can get drafts published with them 03:07:41 … rather than having the first couple of working drafts just consist of reorganisation of existing text, with no other changes 03:08:57 ChrisL: would prioritise documenting new features over refactoringexisting ones 03:11:16 ChrisL: patent exclusions are at fpwd and last call, and are per-feature 03:11:37 ... so its better to at least list a feature even if the spec is incomplete or the syntax not stable 03:12:17 ChrisL: want to see tests early 03:12:32 heycam: so when new feature is added, add tests as well 03:13:41 ChrisL (explains how automatic test assertion annotation is added) 03:14:03 ed: good to get some tests using the new harness, to see how it works 03:16:26 ChrisL: we need to decide link mechanisms. WOFF used this new mechanism (but the files were mostly html) 03:16:47 action: chris to continue to work on test suite linking mechanism for new harness 03:16:47 Created ACTION-3212 - Continue to work on test suite linking mechanism for new harness [on Chris Lilley - due 2012-01-20]. 03:17:21 ed: we can update the milestones to add this testsuite item 03:18:48 http://test.csswg.org/ 03:19:55 birtles: good reftests use lime green for pass and red for fail 03:20:33 that is not the right link 03:20:34 http://w3c-test.org/framework/ 03:22:32 ChrisL (walks through the new reporting framework) 03:25:49 heycam: need stubs for ecery new feature for fpwd. say 3 months after the editors draft 03:26:11 ... so July 03:26:21 then another in October for TPAC 03:26:30 s/then/... then/ 03:27:09 vhardy: who can lead the spec editing effort 03:27:53 cyril: needs someone who already has ssh mercurial access 03:28:10 ed: tav has done most of the editing so far 03:28:38 s/ecery/every/ 03:29:17 heycam: last entry depends on the feature owners 03:30:20 vhardy: in reqts we have big sections then a lot of tiny ones 03:31:02 heycam: as we go through the list we can allocate owners 03:31:32 vhardy: we need to triage the requirements to prioritise the most important ones 03:31:58 heycam: we did not do that, so we accepted a lot of requirements some of which might not be for 2.0 03:32:12 vhardy: need priority on all the accepted requirements 03:33:10 cyril: once we have commitments for the popular features this will lead to priorities. if no-one commits its low priority 03:33:20 heycam: and if that is loo long we can cut it 03:33:35 cyril: up to individuals how many new features to take on 03:33:59 cabanier has joined #svg 03:34:07 vhardy: priority needs to be decided before fpwd 03:34:24 ... march is better 03:36:03 action: erik to remind people early March 2012 about prioritisation 03:36:03 Created ACTION-3213 - Remind people early March 2012 about prioritisation [on Erik Dahlström - due 2012-01-20]. 03:36:59 heycam: looks good for the milestones 03:37:22 vhardy: management nightmare to weigh the priorities 03:37:31 heycam: happy to make a form for that 03:37:55 action: heycam to make a form for priorities 03:37:56 Created ACTION-3214 - Make a form for priorities [on Cameron McCormack - due 2012-01-20]. 03:41:18 ChrisL: goot time for lc would be after tpac so (with holidays) jan would be good, finished by May/June and CR in August depending on need for a second LC 03:42:16 vhardy: for selecting requirements we could update - things thatare broken, graphical features 03:43:10 vhardy: for 2.1 2.2 etc we could put the theme that adds value for each iteration, nt too ambitious each time 03:44:44 vhardy: first priority could be graphical features, with animation and dom refactoring left for a dot release 03:45:06 heycam: seem to have a range of killer things that do not fit those themes 03:45:29 cyril: this discussion is easier when we have a prioritised list 03:45:42 vhardy: main point is to limit the scope to what is acheivable 03:46:02 heycam: ok so lets aim for LC in January 2013 03:48:50 Topic: GetBBoxOf 03:49:27 http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/getBBoxOf 03:49:47 s/Get/get/ 03:50:08 heycam: this is getting the bbox in a different elements coordinate system 03:50:14 ... often want to do this 03:51:24 ... proposal is to add getBBoxOf that you call in the element whith the desired coord system and you apss the element you want the bbox of 03:51:38 ... need not be a descendent 03:52:11 cyril: bbox is always axis aligned? 03:52:15 heycam: yes 03:52:28 ed: its like getScreenBox in Tiny 03:52:49 s/getScreenBox/getScreenBBox/ 03:53:36 cyril: (points out an error in the proposal, this and element are transposed 03:53:47 vhardy: do we want a rect or a swt of points? 03:53:49 http://www.w3.org/TR/SVGTiny12/svgudom.html#svg__SVGLocatable_getScreenBBox 03:53:53 s/swt/set/ 03:54:06 vhardy: (draws on whiteboard) 03:54:53 ed: agrees with vhardy, you want four points for a non axis aligned bbox 03:55:05 vhardy: want the points, or an option to get the points 03:55:24 cyril: last step is trivial, min maxso return the points 03:56:10 ChrisL: getBBoxCorners ? 03:56:24 birtles: what will people do more often? 03:56:39 vhardy: adding handles is common so the points would be better there 03:57:14 cabanier: illustrator gives the full bbox 03:57:37 heycam: we don't want to multiply the number of methods unecessarily 03:57:56 cabanier: if you miter corners and transform, miter will go further 03:58:42 ChrisL: recall that we also wanted to have an inked bbox that includes stroke and markers 03:59:17 ... so for this one which is geometric, stroke mitering does notaffect it 04:00:29 fat_tony has left #svg 04:02:08 vhardy: bbox is d=for dirty areas, editing 04:02:14 birtles: hit testing 04:02:31 s/d=// 04:03:43 ChrisL: for painted bbox we would need the analog of this (get painted bbox in another coord system) 04:04:08 cabanier: if transformed, miters would become sharper 04:04:18 vhardy: we do pre-transform stroking 04:04:39 ... illustrator gives you both 04:05:14 vhardy: non scaling stroke strokes the transformedgeometry 04:05:41 heycam: so maybe instead give a much easier way to get quads and then transform them to another coordsys 04:05:51 vhardy: like the quad idea 04:06:13 getBoundingQuad and then transform and getBBox on that 04:06:47 action: heycam to revise getBBoxof proposal based on this discussion 04:06:47 Created ACTION-3215 - Revise getBBoxof proposal based on this discussion [on Cameron McCormack - due 2012-01-20]. 04:08:59 Topic: Auto sized image 04:09:04 http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Auto-sized_image 04:09:43 http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Auto-sized_image 04:11:12 cyril: is it auto size or auto scale 04:11:51 heycam: (rapidly corrects proposal) 04:12:15 heycam: its the same rules css uses for intrinsic aspect ratio 04:13:04 vhardy: the initiial viewport is there is there is no bbox 04:13:46 ... defaults to 100% 100% and the width is known 04:14:00 heycam: so you dont use any 150 300 ratio 04:14:36 cyril: like the idea to not give w & h if you don't want 04:14:47 ... do no t want to break backwards compat 04:15:06 vhardy: at the end of the day, we need to align with the CSS 2.1 behavior. 04:15:37 heycam: prefer 1 over 2 but itdoes change existing meaning 04:15:44 ... second one doesn't 04:16:27 heycam: in old viewers, missing attrs gives zero so no display - do that all the time 04:17:12 vhardy: if you have w h and viewbox there is enough to work out the aspect ratio 04:18:33 ChrisL: people depend on missed attrs going to zero, so I prefer the second option 04:20:17 vhardy: common case of images with same width and variable height 04:20:26 cyril: so that leads to proposal 2 04:23:58 cyril: how aboutsizing="intrinsic" 04:24:45 ed: seen lots of js driven stuff that fills out w and h later and it does not render if zero 04:24:54 cyril: used for image preload 04:25:08 birtles: is the preload specced? 04:25:40 (we think not) 04:25:50 s/seen lots of js driven stuff that fills out w and h later and it does not render if zero/i've seen some (rather complex) js driven frameworks that fill out w and h later and it does not want it to render if zero/ 04:26:10 vhardy: to display an unknown image you load by script just to calculate the w and h 04:26:31 1 - two 04:26:43 2 - four 04:26:56 ppl voting 1 can live with 2 04:28:09 resolution: image resizing will use option 2 with sizing="intrinsic" as an attr not a property 04:28:19 ---break--- 04:46:39 scirbe: Cyril 04:46:43 scribe: Cyril 04:46:46 ScribeNick: cyril 04:47:45 Topic: test suite 04:48:09 CM: are we only having ref tests or scripted tests? 04:48:17 CL: they are not mutually exclusive 04:48:25 CM: yes 04:48:56 BB: the scripted tests have the advantage of finding the reason for a failure easily 04:49:00 ... you don't have to dig 04:49:18 CM: there is the CSS thing (ref test) and the testharness.js 04:49:50 ED: James Graham worked on making sure it works with our existing test harness 04:50:16 ... so it is possible to use the existing test suite if we had script snippets 04:50:34 ... but I' mot sure that's the best way to convert the tests 04:50:56 ... I don't know if the existing test set is the best test 04:51:40 ... Opera is working on publishing the existing animation tests for SMIL but scripted so that we don't have to look at the output 04:52:07 ... it has some requirements on the API: pauseAnimation, and setCurrentTime 04:53:36 http://w3c-test.org/resources/ 04:53:46 CC: at TPAC, the break out on testing was explaining how to use the harness 04:54:04 http://w3c-test.org/resources/apisample.htm 04:54:50 http://w3c-test.org/resources/apisample2.htm 04:57:46 ACTION: Erik to check in an example on how to use the testharness.js 04:57:47 Created ACTION-3216 - Check in an example on how to use the testharness.js [on Erik Dahlström - due 2012-01-20]. 04:58:15 CL: the current tests, we only have the image patches in the case where Batik does not pass 04:58:26 ... now we want one of all 04:58:35 ... and they need to be a lot simpler 04:59:00 VH: that could be a real time sink 04:59:13 ... I would like to say that we don't touch the old tests 04:59:20 CL: that's a good comment 04:59:37 ED: apart the animation tests, that should be fine for the others 05:00:01 VH: especially with the new Browser API, is there anything to do screen capture 05:00:29 CL: it has been proposed as modal and for the specific purpose of testing 05:00:58 but not enabled by default, for security 05:01:14 VH: do we agree to keep the old test suite 05:01:24 ... as is and work on a new one 05:01:26 CL: yes 05:01:28 ED: yes 05:01:42 CL: we can copy over if needed 05:02:16 CM: we would need to annotate the old tests for the coverage evaluation 05:02:29 CL: the current annotation does not have the granularity 05:02:34 ... that we need 05:03:05 ... you need an id and a class, the test points to that id 05:03:30 ... I did that with the WOFF spec and it's quite simple 05:03:45 ... an id on each assertion and a class for viewers, authoring tools .... 05:04:28 Topic: Spec review requests 05:04:38 CM: we got two requests to review CSS specs 05:04:54 ... we need to assign actions so that that gets done 05:05:03 VH: a third one is shadow dom 05:05:17 CL: CSS Values and Replaced Content 05:05:24 Title: CSS Image Values and Replaced Content Module Level 3 05:05:24 Temporary URL: http://dev.w3.org/csswg/css3-images/ 05:05:39 Title: CSS Basic User Interface Module Level 3: 05:05:39 Editor's draft: http://dev.w3.org/csswg/css3-ui/ 05:06:40 RC: the first one has gradients 05:06:48 CM: UI has pointer events and cursor 05:07:04 ... UI is meant to be reviewed by 14th of Feb 05:07:13 ... Image Values byt the 17th 05:07:59 ACTION: Vincent to review the Shadow DOM draft 05:07:59 Created ACTION-3217 - Review the Shadow DOM draft [on Vincent Hardy - due 2012-01-20]. 05:08:22 CM: it told dmitry we will find in the SVG spec, where shadow dom is useful 05:08:47 ... I didn't give him a timeline 05:09:19 ACTION: Chris to review CSS UI 05:09:20