16:57:04 RRSAgent has joined #svg 16:57:04 logging to http://www.w3.org/2009/09/30-svg-irc 16:57:06 RRSAgent, make logs public 16:57:06 Zakim has joined #svg 16:57:08 Zakim, this will be GA_SVGWG 16:57:08 I do not see a conference matching that name scheduled within the next hour, trackbot 16:57:09 Meeting: SVG Working Group Teleconference 16:57:09 Date: 30 September 2009 16:57:58 Topic: modules status 16:58:04 scribenick: chrisl 16:58:09 fat_tony has joined #svg 16:58:15 (cam draws on whiteboard) 16:58:30 cm: to be published soon 16:58:41 1.1se, integration, color, filters 16:59:45 a bit later - transforms, compositing, vector effects 17:00:08 cm: need to find out status on mae and pin to clip 17:00:16 ... params 17:00:28 ... fonts on back burner for now, point to 1.1se 17:00:38 ds: no recent changes to params 17:02:57 ... ds: pinned clip is miniscule, should be folded into something else 17:03:09 ... (explains pinned clip for video) 17:03:35 ag: should go in clipping and masking 17:03:56 cm: do they participate in compositing? 17:07:53 cm: layout, no recent change but doing some prototyping software, kind of like spings and flexbox 17:08:32 ag: want to take stuff out of the normal painters flow for transforms 17:08:39 ... by default its painters 17:08:57 cl: 3d transformed stuff is taken into a different tendering pass 17:09:04 ... same as z-order actually 17:09:17 Pinned Clip spec -> http://dev.w3.org/SVG/modules/pinnedclip/publish/SVGpinnedClip.html 17:09:41 ... also the result of the main render pass has to be held as rgba since z-order passes could be behind as well as in front of it 17:09:54 ... same mechanism could do z-order and 3d transform 17:13:08 ag: think of a preserve-3d attribute that says when to pull it out of ther main flow 17:15:41 cm: (draws example on board with interleaved z index) 17:16:10 ds: andrew emmons had a ssystem which only allows z to be set on groups 17:16:36 ... layered g only allowed reordering within that group 17:18:58 ds: dont want to allow arbitrary setting of z throughout the document 17:20:58 cm: (tries to understand css stacking context. fails) 17:21:08 cl: (tries to explain it. fails) 17:22:02 z-index: no one understands me! 17:22:13 z-index: (tries to be consistent. fails) 17:22:22 zaki, mute z-index 17:24:08 ds: there is an accessibility interest here. for well structured documents, if we allow people to mix then grouping all labels and all objects does not work 17:25:23 ds: so putting all the text labels, one level up 17:25:52 ... logical order vs. rendering order 17:26:13 cm: html docs have reasing order and rendering order tightly coupled 17:26:33 ... not the same in svg due to rendering and transforms, grouping is different 17:27:24 ag: so how would transforms affect z-index 17:27:39 ds: want to talk about the connector element, i have an early proposal 17:28:33 cm: z-index is an ordering, not an absolute distance 17:32:10 ds: good to talk to emmons on layerd-g vs z-index. constrained and performant solution 17:33:35 cm: when you get the z index you store them and then work from lowest to highest index 17:34:10 ... and keep track of which z index are not used or are empty 17:35:05 ag: will fold this into the transforms spec, helps with describing the rendering model 17:35:57 ds: suppose it was called z-transform 17:39:24 cm: z-index is different in that it just changes layering of rendering, while the z-transform would place it somewhere in z space 17:39:28 ... and thus become larger or smaller 17:40:03 ... so i think they're pretty much orthogonal 17:40:13 ... i would specify z-index as part of the rendering model in the base svg spec 17:40:22 ... the 3d transforms spec wouldn't need to worry about it then 17:44:21 ds: lets not use css z-index 17:44:49 cl: and if ours has a different name, we also need to explain why z-index was not applicable to our rendering model 17:45:25 ds: explain exactly how it differs 17:46:15 ... that way, they search o=for z-index and find z-layer 17:47:31 cm: who will write up the proposal 17:48:44 action: anthony to work with chris to write up a z-layer and 3d transform tendering proposal 17:48:44 Created ACTION-2678 - Work with chris to write up a z-layer and 3d transform tendering proposal [on Anthony Grasso - due 2009-10-07]. 17:49:31 ag: should we match up our names to the css names? theirs have changed 17:49:45 cm: css wg did not seem willing to change theirs 17:50:58 ag: happy to keep svg transforms moving forward 17:51:14 c: their perspective tx could occur multiple times which was odd 17:51:28 s/c:/cm:/ 17:51:47 Scribe: Cameron 17:51:50 ScribeNick: heycam 17:52:19 DS: last i remember anthony was going to write up a description of why our 3d matrix transforms have only 12 values and the css one has 16 17:52:34 ... and about the compatibility with OpenVG 17:53:05 AG: to use theirs with openvg you'd need to do a bit more work 17:53:29 DS: is it a case where we have to choose to be compatible with openvg or opengl? 17:53:49 ... and if so, and there's an easy translation from one to the other, is there really any incompatibility at all? 17:53:59 ... and if there is, which one should we go with? 17:54:09 ... it's obvious why they went with opengl, because of the hardware 17:54:24 ... which one is a more compelling target in terms of market penetration? 17:54:27 ... if we can only pick one or the other 17:54:34 ... or is it easy to translate from one to the other? 17:54:55 AG: in the editor's draft that was updated a while ago i did put the equations that go from the 3x4 matrix to the 3x3, to pass to openvg 17:55:55 CM: and the extra three values from the 3x4 matrix just encode the perspective transform, which is supplied to openvg outside of the regular transform pipeline, right? 17:55:56 AG: right 17:56:09 AG: openvg is a 2d renderer, opengl is a 3d renderer 17:56:17 ... so in one you need to preserve z information, in the other you don't 17:56:29 DS: so compatibility with opengl is the one we should go for? 17:56:53 CM: but you can't do as many strange transformations, right? 17:57:00 ... if you just stay with the 3x4 one? 17:58:16 AG: i want to know what the use cases are for multiple perspective points 17:58:36 ... the also allow perspective transforms to be strung together in the transform string, which doesn't really make sense either 18:00:45 ACTION: Anthony to write up 3d transforms for svg model vs css model 18:00:46 Created ACTION-2679 - Write up 3d transforms for svg model vs css model [on Anthony Grasso - due 2009-10-07]. 18:45:56 ed_ has joined #svg 18:46:54 ed has joined #svg 18:52:27 ed_ has joined #svg 18:55:13 ed has joined #svg 19:02:13 ed_ has joined #svg 19:18:52 Zakim has left #svg 19:57:28 Zakim has joined #svg 21:24:05 ed has joined #svg 21:26:55 ed_ has joined #svg 21:28:40 ed has joined #svg 21:32:30 ed_ has joined #svg 21:36:12 ed has joined #svg 21:36:30 ed has joined #svg 21:39:27 ed_ has joined #svg 21:39:54 ed has joined #svg 21:40:32 ed_ has joined #svg 21:41:44 ed has joined #svg 21:43:16 ed_ has joined #svg 22:01:48 Zakim has left #svg 22:16:12 close action-2472 22:16:13 ACTION-2472 Fill in the currentTranslate/currentScale erratum to explicitly make using those attributes on inner elements undefined closed 22:16:50 issue-2001? 22:16:50 ISSUE-2001 -- Prose describing content model does not match DTD -- CLOSED 22:16:50 http://www.w3.org/Graphics/SVG/WG/track/issues/2001 22:16:57 close action-2415 22:16:57 ACTION-2415 Check the Tiny 1.2 Chapter to see if there is any text in there that can be used for ISSUE-2001 closed 22:18:24 close action-2635 22:18:25 ACTION-2635 Add wording to both 1.1 2nd and the filters module that clarifies the usage of optional numbers for kernal unit length closed 23:03:00 Scribe: Cameron 23:03:02 ScribeNick: heycam 23:03:06 RRSAgent, this meeting spans midnight 23:04:45 ISSUE: Inheritance of properties into SVG font glyphs not liked by all 23:04:45 Created ISSUE-2298 - Inheritance of properties into SVG font glyphs not liked by all ; please complete additional details at http://www.w3.org/Graphics/SVG/WG/track/issues/2298/edit . 23:06:13 Topic: Requirement to copy into shadow trees for SVG font glyphs 23:06:25 ED: this is from the 'use' element: 23:06:28 The effect of a 'use' element is as if the contents of the referenced element were deeply cloned into a separate non-exposed DOM tree which had the 'use' element as its parent and all of the 'use' element's ancestors as its higher-level ancestors. Because the cloned DOM tree is non-exposed, the SVG Document Object Model (DOM) only contains the 'use' element and its attributes. The SVG DOM does not show the referenced element's contents as children of 'use' element. 23:06:28 For user agents that support Styling with CSS, the conceptual deep cloning of the referenced element into a non-exposed DOM tree also copies any property values resulting from the CSS cascade ([CSS2], chapter 6) on the referenced element and its contents. CSS2 selectors can be applied to the original (i.e., referenced) elements because they are part of the formal document structure. CSS2 selectors cannot be applied to the (conceptually) cloned DOM tree because its cont 23:06:30 Property inheritance, however, works as if the referenced element had been textually included as a deeply cloned child of the 'use' element. The referenced element inherits properties from the 'use' element and the 'use' element's ancestors. An instance of a referenced element does not inherit properties from the referenced element's original parents. 23:07:00 http://dev.w3.org/SVG/profiles/1.1F2/publish/struct.html#UseElement 23:09:17 http://dev.w3.org/SVG/profiles/1.1F2/publish/fonts.html#GlyphElement 23:09:20 CM: there's a lot to reword 23:09:28 ... to avoid talking about cloning trees 23:10:21 CL: that's why we said "conceptual clone" 23:10:25 ... it's not an actual clone 23:12:15 JW: i agree with what roc saying it says clone, then you're better off actually implementing it as a clone because you'll find over time that doing it some other way will cause problems in the future 23:12:15 ... that's been my observation as well 23:12:16 ED: but i don't see why that will be, since it's a non-exposed tree 23:12:25 JW: sure, but you have to synthesize cloning 23:12:37 ... the spec says to pretend to clone, but not actually clone 23:12:56 ... but if you've not got an actual clone, then there's always a risk that what you have won't behave like a clone would 23:13:04 ... and various parts of the spec can rely on it being a clone 23:13:36 ED: we want to avoid clones 23:13:46 JW: if you're htinking of removing the word "clone", then specify exactly how it should behave, then it would solve the issue 23:13:51 ED: you still have the original subtree 23:14:06 ... depending on how you represent the use, it's implementation specific 23:14:25 ... the original nodes are there, but it doens't just work, you have to do other things like inheriting the style in 23:14:36 CL: if we say it's a clone, you have to say it's a clone and then do some other stuff 23:14:40 ... "conceptually" implies it's not exactly 23:15:10 JW: if the spec says it has to behave like a clone, then you'll find bugs and coming to the conclusion that it would be an actual clone 23:16:20 CM: perhaps it'd be better to talk about it in terms of the element instance tree, nodes of which then behave like the nodes they're pointing to 23:16:25 ... because you don't actually want clone-like behaviour 23:16:43 ... you want to essentially clone all state about the referenced nodes, and then keep them in sync afterwards 23:17:58 JW: if you don't have a clone you don't have the overhead of restyling the referenced elements every time you paint it 23:18:01 ... with clones you don't 23:18:13 ED: but with actual clones it has worse memory requirements 23:18:27 JW: probably restyling outweighs that 23:18:31 ED: i don't think that's true 23:20:16 ... for the glyph case, i could maybe see that it would be better to not have the property inheritance into the shadow tree 23:20:22 ... for use, on the other hand, i think that helps 23:20:26 ... it would break content if we stopped doing that 23:21:46 ... wouldn't be hard to see what opera is doing wrt memory usage 23:21:54 ChrisL has joined #svg 23:21:54 ... e.g. creating some use elements with huge subtrees 23:21:58 ... and see the memory usage of each 23:22:16 ... i don't know exactly how they compare, but i'd imagine it would be quite a difference 23:22:27 jwatt has joined #svg 23:25:11 action: cameron send out proposal for limited prefix processing in text/html 23:25:12 Created ACTION-2680 - Send out proposal for limited prefix processing in text/html [on Cameron McCormack - due 2009-10-07]. 23:28:39 CL: [explains the glyph inheritance problem to dbaron] 23:29:50 DB: my reaction is sort of that authors have expectations about how something called a "font" performs 23:30:00 ... and they expect that to get accelerated by things like generating the bitmap for a glyph once per size 23:30:15 ... essentially being what windows or osx does with a native font, in terms of performance 23:30:27 CL: right if you make an abritrarily complex thing with lots of content then it's going to be slower 23:30:39 DB: even for things like this, if you have to inherit stroke-width then it becomes a lot more complicated 23:30:46 ... compared to if you could convert the svg font to an opentype font 23:31:26 CL: we have an optimization for that, the d="" attribute on 23:31:26 ... but if you've actually gone to produce a multicoloured glyph then it's going to be slower 23:31:27 DS: we understand that the landscape has shifted since we started with svg fonts 23:31:39 ... in ASV that was pretty much the only way you could deliver a font for SVG content 23:31:47 ... you would convert an otf into an svg font and use that 23:31:53 ... but now we're going to have WOFF, etc. 23:32:06 ... so the kinds of use cases you're going to use svg fonts for are different from those for woff etc. 23:32:16 ... things such as richly styled glyphs 23:32:34 ... so we're cool with giving people copious warnings about how what they're doing is going to affect performance 23:32:46 DB: i'd almost be more comfortable talking about it as a glyph replacement mechanism instead of a font mechanism 23:33:54 CL: postscript type 3 fonts also could have arbitrary power 23:33:54 ... you got the benefits and the drawbacks of that 23:33:54 DS: authors should know why they're using svg fonts, what the implications of inheritng the style etc. are 23:33:58 ... within that context, i don't feel that it makes sense to limit how somebody can style/inherit from the text element into font glyphs 23:34:02 ... then it becomes less useful 23:34:53 JW: roc had a proposal for a magic value for color, that would reference back up out to the text element to resolve to the colour of the text referencing the font 23:34:53 ... so there'd be no style resolution each time you painted the glyph 23:34:57 DS: that wouldn't work with existing content/UAs, but... 23:35:06 DB: there are ways we can optimize that we don't do now 23:35:27 DS: what if you wanted the stroke to be thicker or thinner? or not there at all? 23:35:27 ... you just wanted fill and not stroke? 23:35:54 ... what if you wanted to change whether the stroke was rounded on the corners or square? 23:35:54 ... you can do that with any svg shape with 'use' 23:35:58 ED: i wonder how many of those real svg fonts with arbitrary child content and what they're using 23:36:07 ... whether they actually use inherited property values 23:36:18 DS: james deering did a lot of stuff with fonts 23:36:20 ... around 2003 23:36:47 ... it'd be good to talk to people who work with svg fonts to find out uses 23:36:47 ED: point them to the wiki page too 23:36:47 ... on the IG wiki 23:37:13 DB: the thing that seems difficult to me in svg fonts is how without svg fonts you have a nice layered system with css and markup up here, and they pass a bunch of information down to a graphics system that does fonts and font matching 23:37:17 ... and what fonts you want to use 23:37:29 ... svg fonts require a back thing reverses the normal layering of the system 23:37:55 CL: the reason we did that is because the people realised that others don't have the fonts they are using 23:38:04 ... so they can either fall back to system fonts and break the layout 23:38:13 ... or convert to curves (not text any more) 23:38:27 ... so turning into a font left it as text 23:39:04 ... interesting use cases are also manipulating the font in the dom 23:39:48 DB: one question is whether yo udo it for eveyr paint or whether you store that information 23:39:48 ... andi f you're storing it, how much memory does it take up 23:39:48 ... and if you're doing it for every paint, then how much time is it taking 23:39:51 ... if we did the restyling efficiently, it probably wouldn't be a huge problem 23:39:57 ... i don't know how long it takes to draw an svg shape compared to style computation 23:40:00 ... so it's hard for me to say 23:40:27 DS: seems to me that most svg content using svg fonts is not going to be dynamically chanigng much of the svg content 23:41:00 ... a lot of fonts people are going to be using are going to be woff, for the average text 23:41:06 ... there are many optimizations you could do 23:41:13 ... not like they're going to be changing the colour of every other glyph 23:43:22 DB: the amount we optimize something depends on the amount it's going to be used 23:43:22 ... the assumption for svg fonts is that they're not going to be used much, so we're not going to worry about it 23:43:23 ... so the main reason would be for acid3 23:43:35 ... maybe this isn't the case but i wouldn't be surprised if we did whatever subset is needed for that and then stopped 23:44:12 CM: which is just woff-style fonts 23:44:16 DB: has webkit implemented more than that? 23:46:55 ... given the other capabilities that are available, with opentype or woff, it seems like the rest of the use cases would be solved by having a mechanism for saying that a particular part of a graphic represents a certain piece of text 23:46:56 ... rather than a piece of text representing the fonts 23:47:16 ... it doesn't involve going backwards through the layers of the font system business 23:47:55 DS: for a system for building fonts in a web application, being able to use an inbrowser drawing program to draw a font 23:48:40 ... so making the font editable is a use case 23:49:28 ... animated fonts too, perhaps 23:50:12 DB: in terms of building a piece of software to do this, do you implement that by making the entire font matching system happen outside the graphics layer? 23:50:12 ... so you don't need this layering violation? 23:50:15 ... basically all of the features become harder when you're expecting it to be drawn at this weird time when you don't have the change to store the information 23:50:39 DS: i think it'd help us to have a diagram explaining how mozilla currently works, wrt this layering feedback 23:50:55 DB: it's changed substantially in the last couple of releases, and it's going to change more 23:51:28 DS: it'd be nice to understand the constraints under which we are working 23:53:11 DB: roc's probably a better person to talk to about this 23:53:37 JW: the other thing i wanted to talk about, related, is the 'use' element 23:54:18 ... in mozilla we create an anonymous clone 23:54:46 ... which is not how some other implementations do it 23:54:55 DB: there is stuff we could do to make the clone restyling faster 23:55:06 ... the style rule matching for rule aiui is that they inherit from something different 23:55:11 ... we could make it skip running selector matching 23:55:35 JW: it seems like you were saying that it shouldn't 00:01:55 DB: usemaps in html have similar issues in mozilla 00:02:07 ... came up with a neat solution, which i think found it's way into html5 00:02:15 ... where we do use one property on the area elements 00:02:19 ... and that property is 'cursor' 00:03:11 ... so we do the same thing that svg does with inheritance, for the cursor property, into imgmap areas 00:03:38 ... so you can style the cursor on the area and you can style it on the img 00:03:38 ... but that's relatively easy to implement, we can resolve style whenever we need it 00:03:38 ... we can even do that for every mouse movement -- it's just one style property resolution 00:03:39 JW: but you're saying it how opera's implement would be a lot harder 00:03:41 DB: maybe 00:03:59 ... right now we have this "multiple presentaitons" thing 00:04:15 ... we sort of don't have a mapping from content nodes to frames (i.e., rendering objects) 00:04:15 ... except we do, stuck off into a hash table 00:04:22 ... so you need it per use mapping instead of per presentation mapping 00:04:41 ... and stuffing pointers in the content elements 00:05:04 CM: could you specialise for just use? 00:05:18 DB: what you need is per use, not per presentation 00:07:38 [more talking about mozilla's internal style resolution] 00:08:15 ... our style data computation happens using what i've sometimes heard as a "lexicographic tree'< but not sure that's the right term 00:08:40 ... optimizes strongly for a bunch of cases that are common in css 00:08:40 ... i.e. relatively few properties are specified per rule 00:08:58 ... so a css rule is in the abstract something that provides values for some small set of properties 00:09:07 ... the thing that maintains the style data for an element we call a StyleContext 00:09:18 ... there's this additional object in between them in the rule tree 00:09:31 ... a node in the rule tree represents the sequence of rules the element matches 00:09:37 ... each style context points to a node in the tree 00:09:47 ... the path from the root of the tree to the node represents the rules that style context matches 00:09:54 ... in cascading order, where each node points to a single rule 00:10:04 ... then, beyond that, we group all the css properties into a bunch of structs 00:10:15 ... we do a related group of properties at a time 00:10:21 ... so e.g. all the ones in the font shorthand are in a single group 00:10:34 ... then the structs can end up getting cached in the rule tree or in the style context tree 00:10:44 ... if the values in the struct have no dependencies on inherited values, they can be cached in the rule tree 00:10:49 ... e.g. no em units, no inheritance, etc. 00:11:01 ... in the property groups, every group consists of all inherited or all non-inherited properties 00:11:12 ... in the case of "nothing specified", the structs of non-inherited properties will get cached in the rule tree 00:11:15 ... and shared between nodes 00:11:27 ... in the edge case of inherited properties, they'll get shared between parent and child style contexts 00:11:32 ... in both cases they use the same struct 00:12:03 ... in the style context case, it'll copy pointers down the tree, since inheritance can be pretty deep 00:12:18 ... but in the rule tree case we walk up the tree every time we need it 00:12:40 DS: [mentions an object oriented css proposal] 00:13:29 ... [nicole sullivan] 00:15:08 CL: if you're cloning whole trees, you can take all of their style contexts? 00:15:19 DB: we would make a new style context in the clones, but point to the same rule node 00:15:23 ... since the selector matching won't change 00:15:32 ... so we get data sharing for many cases 00:15:49 CL: so the inheritance changes, since it has a new parent, which doesn't affect selcetors, but there's a ne wsource for inherited values 00:16:15 DB: when changing a value, we make new style contexts 00:16:22 ... rule nodes and style contexts are immutable 00:16:30 ... which provides good comparison when things change 00:17:07 ... so if an element goes into :hover, and there are :hover selectors that might or might not match, we'll re-run selector matching on that element and its descendant 00:17:23 ... this was a big problem IE/5/6/7 only handled hover on links 00:17:49 ... when we started supporting hover on everything, other elements would colour on hover 00:34:43 DS: could pageX and pageY, offsetX and offsetY be defined usefully within svg? 00:34:53 ... if so they should be generalised out and put in dom 3 events 00:35:15 http://www.w3.org/TR/cssom-view/#extensions-to-the-mouseevent-interface 00:46:15 jwatt has joined #svg 00:46:17 http://www.w3.org/mid/20090830055001.GD27340@wok.mcc.id.au 00:47:59 topic: SVGLength behaviour tightening 00:51:32 ED: i don't think value should preserve the units 00:51:47 CM: i think you always want to rely on assigning to .value working 00:51:52 ED: yes 00:51:52 JW: i agree 00:52:08 ED: allowing an invalid length in the middle of a length list seems strange 00:52:13 CM: yeah, i'll propose something else 00:55:23 Topic: testing 00:55:23 JW: is opera looking at ref tests? 00:55:25 ED: yes, looks good 00:55:36 ... not sure about writing our own ones yet, but using the existing ones 00:55:55 CM: will you provide a public harness to run the tests? 00:55:55 ED: i suspect so, but don't know 00:56:11 JW: there's a runner, written by sylvain pasche, it pretty much works in any implementation 00:56:14 ... that you can run on a desktop 00:56:18 ... so you should be able to test it 00:56:23 ... it'll be slow, slower than mozilla's harness 00:56:42 ... but it will give people the flexibility to run the tests in the release builds, and check results, rather than relying on vendors reporting their results 00:56:55 ... there's a fair bit of work still to do on it 00:57:45 ... from my pov the testing project that started at the hackathon week, that doug, plh, fantasai, mikesmith and myself were at, is now mainly waiting on mozilla to actually figure out how best to push their tests into w3c's repositroy 00:57:52 ... quite tricky problems to be worked out there 00:58:03 ... such as there are existing tests that we're running on a per-commit basis 00:58:25 ... so we don't want to remove them from our tree, move them to w3c's, then start running the w3c tree 00:58:44 ... the question is how can we keep them in both places and synchronize them? 00:58:55 ... changes in moz local ones should propagate to the w3c one, and vice versa 01:00:22 ... especially complicated when renaming and moving tests around 01:00:22 ... we've also got to get consensus internally in moz on how to do this 01:00:23 ... figure out how to, first, technical issues on getting the w3c test suite automatically run on our build machines 01:00:26 ... then figure out how to sync up on that 01:00:28 ... people responsible for doing this 01:00:34 ... figuring out which failures that then crop up, what the causes are, what should be done about them 01:00:39 ... an ongoing process, fair bit of work 01:00:43 ... unclear how that should proceed 01:00:56 ... all this sort of stuff that makes it not straightforward to chuck our tests in the w3c repository 01:01:22 ... apart from the fact we haven't resolved whether we are using svn or hg, but probably we will end up using svn 01:01:28 ... i believe we're also waiting for plh to source a more robust server for an actual public facing site 01:01:33 ... instead of a testing server 01:02:10 ... the things that came out of the meeting included that basically we won't go with a centralized system for running tests at the w3c 01:02:16 ... simply because the resources that are needed for that are immense 01:02:42 ... once you start to multiply all the OSes, browsers, versions of browsers, plugins installed, etc. 01:02:42 ... it's a large number of different combinations you can have 01:02:56 ... probably more atractive to have a test swarm type system 01:02:57 ... external volunteers will run batches of tests 01:03:02 ... so they might point the test harness to 20-30 tests 01:03:11 ... which it will run, and send the results back to the w3c's results gathering then 01:03:16 s/then/thing/ 01:03:19 ... then get another batch, etc. 01:03:46 ... on a conversation with roc, doug, plh and myself, roc considered that it was a very low priority, especially at this stage for the w3c to be gathering results 01:03:58 ... and creating the test swarm system to do this 01:04:22 ... and given that there would be a w3c runner that could run the tests on end browsers, there'd be transparency for the results 01:04:22 ... we could then rely on vendors being honest about their results 01:04:59 ... which would save the whole complexity about the decentralized crowdsourced solution 01:05:00 DS: my take on it is twofold 01:05:15 ... yes, transparency would help 01:05:16 ... that would decrease the load, people could report their own results 01:05:22 ... but one, we need to collect these results anyway 01:05:33 ... part of our conformance testing 01:05:53 ... and second, roc had proposed that they could post them on their own sites, which is fine, but then there's no way of harvesting that 01:06:07 ... people should be able to trust the canonical results on the w3c site rather than individuals' sites 01:06:11 ... who might have another agenda 01:06:21 ... so we need them anyway for our (w3c's) processes 01:06:54 ... third, people shouldn't have to search for results all over the web when they could come to a single place to find the results 01:06:54 JW: i'm sympathetic to having the w3c collect results, but at this stage it's not high priority for me personally 01:07:05 ... once all this conference stuff is over i can get back to looking at testing 01:07:24 ... figuring out a system for moz to move their tests to w3c, and running them, is the first big issue that needs to be tackled 01:07:32 DS: we don't need to solve all these things at once 01:07:38 JW: so there are still some things to be worked out 01:07:41 ... about the test formats 01:07:50 ... a lot of moz specific stuff in the tests 01:08:02 ... and the formats rely on a few mozilla features, e.g. invalidation tests 01:08:22 ... they require you to paint the window after everything is loaded/rendered 01:08:25 ... so we have a specific event for that, not based on a timer, since that would make it very slow 01:08:31 ... our tests have that sort of thing in i 01:08:33 s/in i/in it/ 01:08:44 ... so the w3c versions might want to have that, plus a timer to fall back on 01:08:51 ... or we may want to standardize that event 01:08:57 s/sylvain pasche/Sylvain Pasche/g 01:09:32 ... changes would be required to the test formats which is another thing that needs to be worked out, what needs to be compatible with other browsers, and what moz needs internally 01:09:51 DS: there's a whole second part of this 01:09:57 ... there's another set of problems 01:10:03 ... MS submitted 7000 css 2.1 tests 01:10:11 ... it's appreciated, but at the same time all those tests need to be reviewed 01:10:21 ... the tests could be erroneous 01:10:28 ... not actually testing the thing they mean to test 01:10:39 ... they could accidentally align with some expected behaviour that's seen in IE that isn't per spec 01:10:49 ... it could be that something about the test points out an ambiguity in the spec itself 01:11:14 JW: also the issue that that many tests, to be practical, need to be in an automated format 01:13:00 DS: the csswg cannot review all these tests 01:13:06 ... it's time consuming doing review 01:13:21 ... the part fantasai and i were specficialy working on was a tes treview system 01:13:38 ... we have volunteers to do parts of the test suite, but using email, so it's hard for tracking 01:13:47 ... couldn't say which were reviewed, which needed review, which had priority, etc. 01:13:50 ... without doing a lot digging 01:14:22 ... she was interested in creating a system so that volunteers could review tests systematically 01:14:22 CM: from the wider community? 01:14:44 DS: more within a company 01:14:52 ... if we're making this system anyway, we should make it crowd sourceable 01:14:56 ... so anyone can come in and review tests 01:15:13 ... we could give them the more tests they reviewed and were accurate about, we could give them scores 01:15:33 ... also, since we're doing that, providng an interface so that people could submit tests for what they think are undertested 01:15:41 ... the review system would track the tests through different revisions 01:16:01 ... a revision could have comments on it, when a new rev was uploaded, people could look at the diff as part of their review 01:16:22 ... being able to move a test is good, since one test may apply to different test blocks 01:17:08 CL: the current way of doing it in css has multiple occurrences of a test in different parts of the report 01:17:15 ... their report is the type of thing that should be generated 01:17:18 DS: we have similar problems 01:17:23 ... the version is located in the test slide, e.g. 01:17:27 ... which causes no end of problems 01:17:35 ... we found we didn't know if the image had been updated or not 01:17:56 ... having the metadata part of the image is worse than having a system that keeps a track of this 01:18:46 DS: the review system would also be a test submission system 01:19:04 ... we wouldn't get the bulk through this, but parts of the spec people are interested in would get interest 01:19:17 ... that tells us that people are trying to use specific features 01:19:38 ... part of the goal of the crowdsouring review system is to connect more directly with the community, and get them involved in the process 01:20:11 JW: to become an actual accepted w3c official test, the reviewer needs to have his competence known 01:20:22 ... it's still useful for random community people to do some sort of review 01:20:58 ... if their pre-reviews of a consistently high quality, then that's a way to get people in later 01:20:58 ... if two people say a test is bad, then it's likely it needs looking at 01:20:58 ... if 5 people say it looks good, then it can have percolated up to one of the official reviewers 01:21:59 DS: so is this group willing to go to reftests for the bulk of its tests? 01:22:08 ... if so, jwatt should write up exactly what we want 01:22:22 JW: for those people not familiar with those, they should become so 01:22:29 ... that is partly waiting on me 01:22:33 ... there's some docs in the wiki, but concrete examples are necessary 01:23:51 ... the w3c testing wiki needs a lot of work 01:24:22 ... overall i think the test hackathon rocked, a major step forward 01:24:37 ... the conformance testing is important, but the huge step forward is the interop testing 01:24:49 ... in one or two years from now we can get all the major browser vendors running each others' tests 01:25:03 DS: it also saves each browser vendor reinventing the wheel with tests 01:25:14 ... it decreases costs, since they don't need as many people just dedicated to runnign tests 01:25:23 JW: as long as everyone pulls their weight 01:28:55 ... re too many tests, it's important that wide coverage and deep coverage is good 01:29:01 ... but need to minimize duplication 01:29:09 ... the length of time they take to run is a big factor in how useful they are 01:29:16 ... it impacts their development cycles quite substantially 01:29:30 ... the bigger the testing time, the bigger window there is to find regressions 01:31:28 AG: once the reftests have been reviewed, there'll be some process to package them up for members to get? 01:31:35 JW: they'd be in the repository 01:31:42 ... we could create zips too 01:40:22 RESOLUTION: we'll move to using reftests as soon as is feasible 01:41:12 Topic: Connectors 01:41:25 DS: we have in the past talked about this 01:41:32 ... i want to briefly go over some use cases for connectors 01:41:37 ... and details 01:41:48 ... we've avoided connectors because you can graphically represent something connecting something else 01:42:02 ... but it doesn't have a logical connection 01:42:02 ... there are a lot of use cases for things that are logically connected 01:42:21 ... circuit diagrams, flow chart diagrams, any kind of node-edge graph 01:42:26 ... we've avoided them in the same way as avoiding default symbols 01:43:07 ... so connectors could also be used for representing roads, or any kinds of routes through some thing 01:43:22 ... i think the class of uses for these things is large 01:43:42 ED: xlink:href on every element? 01:43:42 DS: there are a number of approaches 01:44:18 ... i think the basic idea is that there are two aspects to it 01:44:43 ... one, a logical connection, between two elements which represent two different objects 01:44:43 ... and one is a physical connection 01:44:43 ... an obvious thing people would like to do is [draws on board] 01:44:43 ... [two circles connected by a line, moving one circle should make the line follow it] 01:44:47 ... that could be done in the very simplest case, but i don't think people are going to want to do something where the line has to wrap around another shape, for example 01:45:01 ... implementors aren't going to want to solve that case 01:45:35 ... edge routing 01:45:53 ... but i think there is still a lot of utility in straight line connections 01:45:53 ... potentially in allowing the author to say "go through this point" when routing 01:46:05 s/potentially in/in the future, potentially/ 01:46:14 CL: this needs to be a new curve type? 01:46:18 DS: could be just straight lines 01:46:29 ... solve many use cases, not all 01:47:10 CL: curves that pass through particular points we've come up against before, so perhaps we want to add them 01:47:10 DS: making a rendering element is one aspect of the problem 01:47:12 ... making a logical one is another aspect 01:47:46 ... so are these connections directed, undirected? 01:47:46 ... that's part of the logical aspect of it 01:47:46 ... another part is "what is the relationship itself" 01:48:17 ... e.g. does that mean parent--child relationship, or what 01:49:54 ... that might be represented as a form of metadata, like rdf 01:50:03 ... or it might be, for a UI, some textual equivalent of that equivalent 01:50:29 ... if i'm following a map, so you walk from the subway stop to the building 01:50:54 ... maybe the metadata is "walk from from subway stop to building" 01:50:54 ... how would you express that? maybe you'd have a element 01:50:55 ... how do you represent the connector 01:51:08 ... i'm positing that we need a 'connector' element 01:51:14 ... what characterstics does it have? 01:51:18 ... it has a from and a to 01:52:49 ... so a connector, as i see it, is a special form of path that doesn't have a fill 01:52:49 ... what i'm thinking is that it would take path syntax so that if you wanted to do your own routing, you could say this is what it looks like 01:53:29 ... another way i thought of doing this would be to have role="connector" on a path 01:53:36 ... and that would mean logically that it is a connector 01:53:46 ... if connector weren't implemented, you could represent it as a path 01:53:56 ... what is the role of a connector? either as a separate element or a path 01:54:09 ... it's to present to a user to go from one thing to another 01:55:15 ... pretend we are in a flow chart, and we're navigating around it 01:55:15 [draws on board] 01:55:27 ... if you're in one node, and you want to navigate to another node that is connected from that one 01:55:34 ... the tilte of connectors could be read out, for example 01:55:37 ... and the user could choose 01:55:49 ... or maybe it's a popup that lets the user see what the relationship is 01:56:39 ... in terms of navigating documents in a logical order, a blind person could query the connector to find out where it's going 01:56:39 ... so they could step through a complex diagram 01:56:39 ... one use case i've seen for this is that they wanted to have all of their wiring diagrams for cars as svg files 01:56:45 ... apparently in japan, wiring diagrams for cars are done in svg 01:57:29 ... so when a mechanic is trying to sort out "is this circuit live or not", we set up a little animation to show them if they clicked a button which connectors are active 01:57:41 ... so in this scenario you might write a state machine and enable/disable certain connectors 01:57:57 ... it would be an accessible way to present these diagrams 01:58:21 ... right now, if i were navigating these elements, in 1.2T we could use the nav-* properties 02:00:54 ... but they only solve a physical case 02:01:00 ... with the connectors they define implicit navigation options 02:01:43 ... maybe its role would indicate the direction of the connector 02:02:09 ... so there's also a visual aspect of the problem 02:02:36 ... we should reuse existing path syntax, so if a person wants to do custom routing they can 02:02:36 ... failing that, it would just be a direct line 02:02:36 ... but when they use a direct line, dragging this element, the line would follow 02:04:50 ... so either you would take advantage of the auto routing, which would be a straight line in the first version, or you would write your own path 02:04:50 ... but you always get the logical connection 02:04:50 ... in later versions you could provide some way to tell it to do routing 02:07:49 ... there are two problems with diagrams like this 02:07:49 ... one is the line routing 02:07:49 ... the second is the node placement 02:07:58 ... we're also not going to solve that, unless it gets solved in the bounds of some layout algorithm 02:08:03 ... e.g. cameron's layout might take care of that 02:08:29 CL: you're not just going to point at an object, but then you to say i'm going from this point to this other point 02:09:45 AG: you could specify the endpoints as bounding box percentages 02:11:18 DS: i'm not sure that's going be satisfying 02:11:18 ... e.g. on a diamond shape, you don't want connecting lines going to one of its sides 02:11:19 ... so not necessarily the shortest path 02:11:23 ... we've already thought of the idea of svg point elements 02:11:25 ... it could act as an anchor point 02:11:27 ... so what if we defined the anchor points of children of the element 02:11:36 AG: how do you associate the connectors with an object? 02:11:37 ... i was thinking they might be a child 02:11:41 DS: can't be a child of two elements though 02:11:45 ... they can be in their own block somewhere 02:11:49 ... you can name the point you want to connect to 02:12:08 ... the default might be to choose the shortest path between the possible anchor points on the shapes 02:14:37 ... you could name these anchors and identify them explicitly 02:17:54 AG: could you have free floating svg:points? 02:17:54 DS: in future versions 02:18:05 AG: many-to-many connections? 02:18:07 DS: no, just one-to-one connections 02:28:04 CM: i wonder if you ever want navigation that is different from what the connections indicate 02:28:31 as far as semantics of relationships, you should be able to extract a triple from this diagram 02:30:35 as far as navigation goes, they don't ahve to render, might be a better way to define meaningful navigation with titles/descs 02:30:38 rather than using nav-next/-prev 02:30:48 s/prev/prev attributes 02:44:29 RESOLUTION: We'll consider the connector proposal 02:44:33 ACTION: Doug to write up the connector proposal 02:44:33 Created ACTION-2681 - Write up the connector proposal [on Doug Schepers - due 2009-10-08]. 02:48:17 Topic: timeline 02:48:30 CL: our charter expires in april 02:48:31 ... we have 6 months charter period left 02:49:04 ... we need to see what we will have achieved by that time 02:50:39 ... usually the aim is for a charter to be circulated before the current one ends 02:50:39 ... it's coming to the point where we show what we did during the charter period 02:50:39 ... also we have the roadmap document that needs a refresh 02:52:12 DS: we've talked about major revisions to the language 02:52:12 ... we've helped direct the discussion for svg in html 02:52:12 CL: we've engaged more browser vendors 02:53:31 DS: we've already talked about planning on doing the modules until CR, parking them, making sure they integrate together, then publishing independent modules as they are applicable to 1.1 or 1.2T 02:53:31 ... and folding them in to svg 2.0 02:53:31 ... as a single spec 02:53:53 ... so i think that's something we can talk about to people at svg open 02:54:13 ... whenever we publish something, we should update the timetable on the wiki 02:54:31 ... we need to make the home page better 02:57:17 Topic: telcons 02:57:18 CM: should we go back to two telcons per week? 02:57:54 DS: we could try one hour on one day another 1.5 hours on another day 02:59:16 CM: maybe not two telcons per week but one followed by working time 03:04:01 Resolution: we will update the timeline in the wiki whenever we publish a new WD 03:07:40 heycam has joined #svg 03:08:08 RRSAgent, make minutes 03:08:08 I have made the request to generate http://www.w3.org/2009/09/30-svg-minutes.html heycam 05:33:51 eseidel has joined #svg 05:34:13 eseidel_ has joined #svg 05:52:13 heycam has joined #svg 06:10:05 heycam has joined #svg 06:16:34 fat_tony has joined #svg 06:22:09 shepazu has joined #svg 06:24:08 hey, anthony / fat_tony 06:24:15 dude 06:28:29 good thing Jeff was driving 06:28:47 was good timing we got back when we did 07:10:47 ed has joined #svg 07:42:54 fat_tony: no kidding!! 07:42:59 perfect timing 08:23:21 hey, fat_tony, any luck? 08:24:16 getting there 08:24:23 working on the for loop that does the merge 08:29:21 cool 08:47:31 I'm going to have to finish this tomorrow 08:47:37 too tired to keep going