Session Start (tolkien.freenode.net:#svg): Tue Jul 29 14:41:43 2003 [...] [15:34] what do you think of the idea of limiting text selection on to that text which is visible? [15:34] that is, when you select text, sometimes it will pan the view to capture the whole string [15:35] this looks ugly and broken for most forms [15:36] Nah, I think you have to be able to select everything, you're just moaning about how it looks in your viewer, moan to the viewer guys! [15:37] * JibberJim wants a select all, and I want to be able to link seperate into something that can be selected as a whole - which would need some kind of read-index attribute. [15:38] wwhere you there for the panel discussion with the GIS guys asking for features from the WG? [15:38] nope. [15:39] they asked for something similar? [15:40] the idea was brought up asking to logically connect path elements, to preserve identity while allowing the display to show different layers (weaving) [15:41] say, a road that has over- and underpasses [15:42] Ah yeah, nice point, did they have any suggestions how it might be worked? [15:42] seems that such a logical conection, divorced from rendering order, would work for text too... sort of an idref-based group [15:43] yes, it could be solved the same way. [15:43] the idea was just spawned at the time, no details [15:44] you could even perform DOM manipulations on that group, maybe [15:44] that'd be neat [15:45] by read-index, you mean logical ordering of text, like tab-index? [15:45]

etc. then you can do transformations/show hide etc. on the virtual group. [15:45] yes, the reading order of the text. [15:46] yeah, I like i [15:46] t [15:46] see why aren't we on the WG, we have such good ideas (and don't have to think if they make any sense, or are implementable, or anything else...) [15:47] I feel exactly the same way! :) [15:47] axuly, it was one of the WG guys who came up with the idea of virtual linking [15:47] so we already have support in the group! [15:48] ah, logical order would be determined by the painter's model [15:48] but we want a reading order independant of the painter's model, as that's f'ing useless. [15:48] within the VirtualGroup tag [15:48] I've been saying that for ages! [15:49] which is why I say SVG is less accessible than flash - which just gets me in trouble :-( [15:51]

[15:51] [15:51] [15:51] [15:51] [15:51] [15:51] One [15:51] Two [15:51] Three [15:52] this seems like a worthy idea [15:53] want me to write it up? [15:53] If you're up for it! [15:54] doing it rigt now [...] [16:47] virtual group... [16:47] that's a terrible name. [16:47] we should call them logical groupings. [16:47] logicalGroup? [16:47] hah. [16:47] zing. Session Start (tolkien.freenode.net:#svg): Tue Jul 29 22:12:11 2003 [22:12] *** Now talking in #svg. *** Topic of #svg: Logs available at (Link: http://svg.jibbering.com/latest.1)http://svg.jibbering.com/latest.1 - Some Vague Grumblings *** Set by JibberJim 50873 minutes ago *** Users on #svg: schepers collord darobin lllllllll Odysseus *** End of /NAMES list. -ChanServ- [#svg] "This channel is logged, prefix [off] to not have it logged" *** Mode for channel #svg is "+n" *** Channel #svg was created at Fri Jun 06 02:28:34 2003 [22:12] *** Join to #svg completed in 0 seconds. [22:21] *** JibberJim (~none@h24-77-118-79.vc.shawcable.net) has joined channel #svg [22:22] you think I hit the major points, jim? [22:24] yep, seems you did. [22:25] I thought about mentioning that it would help group things for use in scripting (rather than going through the hassle of collecting related elements by sorting through IDs, as I've sometimes done), but wasn''t sure how to state it [22:26] I think the "for toggling visibility and transformations does it" [22:26] yeah, I reckon so [23:18] Hmm, so if we have a what does that actually mean? [23:19] oh no, there's no problem it can mean the same as [23:21] except you get the problem where transforms can come from two places, I suppose it's implementable easily so long as the logicalGroup comes before the genuine stuff Session Start (tolkien.freenode.net:#svg): Mon Aug 04 10:20:01 2003 [17:31] have you seen Michel (Pilat)'s RCC samples [17:31] ? [17:31] (back to groupie mode) [17:31] his no-zoom is quite nice [...] [17:46] you know, the way Pilat is doing his preserve, it would be a good use of [17:46] Everything's a good use of them. [17:46] we ought to ask te WG to consider adding them. [17:46] * JibberJim was thinking of writing it up in spec speak. [17:46] oh, wait, we already did [17:47] nice idea [17:47] give 'em a chance of having a meeting! [17:47] the more I think of it, the better it sounds.... assuming UAs knew to check them [17:47] I want logicalGroup now [17:47] I want a feast! [17:48] I want a Bean-Feast! [17:48] *** protocol7_ (~none@as27-1-3.mt.g.bonet.se) has joined channel #svg [17:49] Jim, you sould spec-speak the logicalGroup, and I'll claim not to understand a word... that should make it acceptable [17:49] I so prefer schema to IDL, btw [17:50] BNR is a pain, that is [...] [21:37] we need tabbing in SVG... DOM3 doesn't have it [21:39] which is another problem with RCC, if you have 2 things tabbable to in your RCC component, where do they appear in the nav-index list? [21:39] logicalGroup, my boy [21:39] inside the RCC? [21:40] sure, or in the svg doc [21:40] but it needs to include elements from both... [21:40] grrr [21:40] that's true [21:40] hold it, why [21:40] ? [21:41] if I make a button, I just need to tab to the text [21:41] you are likely to make RCC components with more than 1 button in them. [21:42] yes, and each button will have a refContent that is indexed [21:42] doing it in RCC does seem the best way.... that way you can tab between widget sets [21:43] Yeah, that's what everyone says, see I don't buy it. [21:43] lay it down... what do you mean? [21:44] foafnaut for example, each blub has controls to do other stuff, get more info on the blub, kill the blub, and (more in future implementations) however the XML data which defines the foafnaut blub, doesn't have controls for this stuff, it's just the data, the controls are part of the view, so shouldn't be in the model bit which we're using RCC to seperate out. [21:44] I'm saying, if you had a logicalGroup in the extensionDefs, that was populated in a preset order, tabbing would flow within that shadowtree, and then step to the next set of widgets [21:45] Consider a window UI control, it has the ability to be resized, closed, minimised, maximised, all of those won't be reflected in the real tree. [21:46] tab order flowing into shadowTree's and then back out is fine yes. [21:46] I guess I follow you [21:46] but where does the problem arise? [21:47] if it ripples into the shadow that's not a problem. [21:49] that's what I assumed... always check for a shadowtree, and deal with it inline [21:50] that may not properly be the case, tho... have to get more data there Session Start (tolkien.freenode.net:#svg): Wed Aug 06 02:13:43 2003 [03:30] "13.4 [...] The most likely solution for specifying navigation order is to add a navIndex attribute, similar to XForms, or a nav-index property. " [03:30] [03:30] how would this affect the logicalGroup ordering? [03:32] nav-index can be independant to logicalGroup I think. [03:35] hadn't we talked about the interpretation of text-flow being predicated on lG? And isn't that a sort of nav-index? [03:36] no, nav-index is for tabbing through, you may not want to tab to a text element. [03:36] you'll want to tab to the button, not the text in the button for example. [03:37] also, most xml would no have a nav-index to it... you could use LG to externally give it an order [03:37] just a thought... [03:39] but, you may indeed want to tab between, say, paragraphs... in any case, there is a possiblyinteraction/conflict [03:40] that's one of the problems how do you put a nav-index on the XML definining RCC-component, do you wrap it in a g element just to put a nav-index on it? [03:41] yeah, also, any given RCC component may be internally tabbable... have several elements [03:41] I'm thinking of an XForms "select-One" [03:42] where it migh be a dropdown, or a list, or a gorup of radiobuttons [03:42] is that one RCC comp, or several? [03:43] you could simply add nav-index to each element of it, or you could create an LG navMap [...] [03:45] I didn't think it was that radical a notion [...] [03:53] what was? [03:53] [03:40] that's one of the problems how do you put a nav-index on the XML definining RCC-component, do you wrap it in a g element just to put a nav-index on it? [03:53] [03:41] yeah, also, any given RCC component may be internally tabbable... have several elements [03:53] [03:41] I'm thinking of an XForms "select-One" [03:53] [03:42] where it migh be a dropdown, or a list, or a gorup of radiobuttons [03:53] [03:42] is that one RCC comp, or several? [03:53] [03:43] you could simply add nav-index to each element of it, or you could create an LG navMap [03:55] I didn't see any of that! [03:55] there was a freenode crashe [03:56] we'll have to see what nav-index does. [03:57] I'm still interested on what they're going to say "having focus" means. [03:57] or how they intend to tab between elments without tab [03:57] well they have tab? [03:57] sorta... [03:58] it's not explicitly mentioned in DOM3 Keyboard events, and activeX plugins can't grab it [04:00] AX plugins can! [...] Session Start (orwell.freenode.net:#svg): Thu Oct 30 10:20:47 2003 [...] [11:01] so, what did the WG think of LG? [...] [11:06] oh we did talk about logicalGroups [11:06] * darobin is darobin again [11:06] no way! [11:07] except they didn't have that name [11:07] sure, that makes sense, since Jim and I were riffing off an idea by Jon [11:07] it's come up as a really cool thing to do many times, there are clear use cases [11:08] :D [11:08] I think mostly they talk about composite objects [11:08] I seem to remember that it was reject for 1.2 as being a complex problem, but there was general agreement that it would be on the 2.0 map [11:08] (this is IIRC) [11:09] well, "logical groups" makes more sense from a coding perspective, but "composite objecs" makes sense from a conceptual point of view [11:10] cool... so we shuld see it in the next few years, maybe [11:10] [off] but we'll all have wvg then, we won't need SVG 2.0 [11:11] well, given RCC who needs SVG 2.0 anyway... [11:11] schepers: yeah, I try not to go down naming rat holes too much ;) Session Start (tolkien.freenode.net:#svg): Fri Nov 14 10:31:57 2003 [12:04] I wonder if veJoin/veUnion fills the requirements for you logicalGroup [12:05] I'll have to rad closer, but I suspect not... logicalGroup is just a way of ordering things for programmatic purposes, not visual display [12:12] yes yes [12:12] but there's a use case solved by either I think, for people that do mapping [...] [12:20] darobin... where's this use case? [12:20] well if you have roads, which internally you define as several segments (as is often done) but you want to display them as a single path VE helps there [...] [12:24] darobin: hmmmm.... what if you have a road that crosses over a highway at one point, but under it at another? [12:25] schepers: you're screwed :) [12:25] not if you have logicalGroups [12:25] but maps don't often reflect that sort of information since it's not needed to get around [12:25] yes yes, I know, I'm just pointing at the low hanging fruits from what exists [12:26] the reason logicalGroups can't (imho) be done now is because to be useful they'd have transform, and that would make arbitrary bits of the tree suddenly share transforms [12:26] LG lets you declare a relationship regardless of its graphical representation... I think it's an elegant way of encoding rich arbitrary semantic into graphical elements [12:26] which I'm sure would mean *major* changes to the way viewers are currently built [...] [15:59] Anyhow - Doug, finally read your Logical Groups thing. Had questions. Mailed them to the list, so you could explain them, renew interest, drum up support. (But they're real questions, not just an excuse to send the proposal to the list again.) [16:02] Kevin and I are discussing them now privately, maybe I'll gel our talk and restate my case [16:07] Excellent. I think it's probably quite a good idea, but from that one email I didn't feel like it was fully fleshed out enough to understand Why it should be used, or what the ramifications were. [16:08] oh, I'm sure its crap, but I'll try to defend it [16:08] Heh. :) Given the painter's model, I know I'd like a way to set up 'real' parent/child relationships for DOM access to nodes. [16:09] (Though if it were rather than , I would be annoyed, because I'd want to manipluate the child objects directly. Session Start (kornbluth.freenode.net:#svg): Wed Nov 19 12:12:59 2003 [...] [13:32] navindex sucks.... it's too easy to duplicate a number [13:32] it should be integrated into logicalGroups [13:36] yeah, but we need something! [13:36] that was a netsplit, nothing to worry about. [13:36] for instance, logicalGroups? [13:37] one disadvantage to logical groups is that it would be more verbose than navIndex [13:38] logicalGroups wouldn't solve it anyway would it? [13:39] sure it would... the "tab index" is the order of inclusion in the group.. painter's model, no muss, no fuss [13:39] "" -> nice [13:40] That was for you boys in #svg! [13:40] and for anyone who uses google [13:40] yeah but to re-order the tabbing, you'd have to change the painters model! [13:40] yes, and? [13:41] thats a potentially expensive operatiion just to change tab order [13:42] to re-order the tabbing in tabIndex, you'd have to get each element affected and change its tabindex [13:42] that seems pricier to me [13:42] yep, but at least that doesn't effect the rendering at all. [13:42] logicalGroups changes the drawing order? I didn't think it did [13:42] no, it doesn't affect the rendering [13:42] that's the point [13:42] it's a logical ordering, not a graphical one [13:43] oh, you just change the ordering in the logical group. hmm. but then you could only tab to the entire logical group in one jump? [13:43] Then why are you two talking about the painter's model if you're not talking about rendering? [13:43] * JibberJim was confused [13:44] I think because the painters model requires certain non-semantic/logical ordering of items in order to get them to display properly. [13:44] thelonius: I was using shorthand to refer to the ordering being relative to the inclusion in the file [13:44] * RabYak thinks he missed something during the split, and gets quiet again. [13:45] JibberJim, say again? tab to an entire group? [13:45] Hmm, there should be a different term used to descibed logicalGroup ordering...like logical ordering or some sort [13:46] here's the beauty of logicalGroup... it can be extensible: first, implement stuff that isn't too hard, then think about it as affecting transforms and such [13:46] No, you want to tab to A B C, you're going to have to have a single logical group which contains all your tabbable stops? [13:46] Do you tab between logicalGroups and/or within logicalGroups? [13:47] good question.. I'd need to think more about that [13:48] yeah that's what I was trying to say thelonious. [...] [13:50] So, if you tab within a LG, then you can't get out of that LG unless you bring something into focus outside of that LG? [13:50] computer programmers can't do math [13:51] that's a tricky one, thelonious [13:51] I'd say, logical order within all LGs [13:52] first LG, first item, is tabindex1, last LG, last item is tabIndexN [13:53] since LGs themselves are in a logical order [13:53] Hrm...the ECMAScript specs themselves seem to have a mistake. [13:53] Nevermind, I'm just backwards. [13:53] Can you only establish tab-order with LGs or can elements outside of LGs be in the tab order? [13:53] and that way, Jim, if you wane to change the tabindex of an entire group, you could just move that LG [13:54] I would say the former [13:55] They're not gonna give us logical groups, so I think we gotta hope for navindex. [13:55] * JibberJim is desperately looking for a new PC... [13:56] well, no, wait, if you had an LG, then a tabbable element, then an LG... I dunno, that seems like it would get confusing, if the eement were also in one of the LGs [13:56] I'm going to revise LG as a proposal and ask for it [13:57] I don't think it's as complex as they say, and I see all sorts of uses for it [13:57] ...maybe for 2.0 [13:57] we'll have the coup before 1.2 comes out anyway I'm sure. [13:58] hehe [13:58] no, it needs to be earlier, or all sorts of bad precedents and conflicting structures will screw it up [...] [14:02] consider this, Jim... a dialog pops up, or disappears... how does that affect the tabindex? [14:02] They ducked out on our dialogTree idea, just said it'd be there. [14:03] I guess any element that has some display/visibility=none is skipped... [14:03] yep! [14:03] same with LG, I guess, nm [14:04] but with tabindex, what if the dialog was not static, but generated dynamically? where do the tabindices come from? [14:05] you generate them - see (Link: http://jibbering.com/accessibility/)http://jibbering.com/accessibility/ tab thingy, that uses dynamic tabindicies IIRC. [14:11] I see [14:12] it's easy enough to do, and pretty cheap in JS terms. [14:13] one Best Practice for tabIndex might be the old BASIC line numbering scheme.... numbering in the hundreds, so you can fill in at the tens and ones places [14:14] mind you, I still don't like tabIndex [14:15] yeah but you need some sort of solution. [14:15] what about RCC'ing SVG elements? [14:16] as a solution for tabIndex? [14:16] no. as an interesting thing? [14:17] *** Signoff: mop_ ("KVIrc 3.0.0-beta2-cvs "Eve's Avatar"") [14:17] hmmm... what's a use case? [14:18] changing all circles to rects? [14:18] those extended links. [14:18] and accessibility - being able to change every G to a G which also renders the metadata [14:19] Im nt as concerned at the mo as you, when it comes to styling extended links [14:20] I'll trust the UA to d it, mostly, and save me the effort [14:22] * thelonious wonders "What are extended links?" [14:22] links that go to more than one place. [14:22] rtfm:) [14:23] example use case? [14:23] it's a CAD feature... the classic example is a toilet with extended links: one to the manufacturer, one to a shopping site, one to the specs, etc [14:24] renders as a context menu [14:24] a list or URIs? [14:24] a list of URIs [14:24] or = of [14:24] oh, yes... [14:25] or, possibly, a list of semantic links that have associated URIs, which is where I think Jim has a problem [14:25] All URIs are in one xlink:href? If so, how is a context established for each URI? [14:26] so, it might be raw URIs, or labels for them [14:26] Sorry for all of the questions...just trying to catch up with your conversation [14:26] np [14:26] I'm not sure of the syntax... min [14:27] (Link: http://www.w3.org/TR/2003/WD-SVG12-20031113/#extended-links)http://www.w3.org/TR/2003/WD-SVG12-20031113/#extended-links [14:29] hmmm. they refer to it a both 'xa' and 'multiA'... must be an artifact [14:29] OK, basically a way to generate a context menu of URIs [14:29] ...when clicking on an element. [14:29] yes [14:30] * JibberJim isn't keen on extended links, (not backwards compatible, limited in how they're rendered etc.) but I couldn't have any sensible objections... [14:30] it's been requested by certain large interests... CAD and such [14:30] Hopefully we'll get RCC styling of SVG elements through it. Session Start (sterling.freenode.net:#svg): Mon Dec 08 13:34:18 2003 [14:19] I don't understand why people think ID doesn't have to be unique...? [14:20] batik does let me have all id="foo" id="foo" ... just not when they over lap with the css as in id="bla" .bla = css style class [14:20] odd [14:20] it doesn;t [14:20] forms use non unique ids all of the time, a thing can have multiple values [14:21] yeah, that's a bad legacy implementation [14:21] and .getElementsByID() has a "s" in it :) [14:21] they're names, not ID's lllllllll [14:21] no it doesn't lllllllll! [14:22] arg [14:22] they should have had a non-unique "group" attribute [14:22] getElementsByTagName [14:22] getElementsBy TagName does, but not ID [14:23] we need Logical Groups [14:23] ;) [14:23] I am thinking about going on a 'grid model" rant :) [14:24] please do... [14:24] as the "box model" is too limiting [14:26] it is not unthinkable to have some content, say logical siblings, and want them to be displayed in some 'snap-to-grid' manner [14:26] Everyone knows grids are the way to go, except those people in power. [14:26] like a combination of 'grid' in photoshop layout tools... & formal design & html legacy [14:27] you could specify no overlap, stacking.. in a much more straight forward way than currently [14:28] I'd like to hear how it conflicts with the current system [14:28] and snap to closest grid point 15degrees, 2nd choice of not close enough in defined margin of error [14:29] has anyone defined a grid model? I'd be happy to help make one [14:30] the box model is limited to thinking of things in a one box world, align left, top... [14:30] I think it comes from not thinking of the content as being an element in itself, but as something that has to redide in a container [14:30] reside [14:30] (Link: http://lists.w3.org/Archives/Public/www-html/2003Dec/0028.html)http://lists.w3.org/Archives/Public/www-html/2003Dec/0028.html [14:31] you could even have transformations and displacements on the grid itself, to get some effects you would want [14:31] No-likes grid, they think it's presentational for some reason, they seem to believe there's either linear information, or tabular information, failing to see that there's some information which is 2 dimensional without being a table. [14:33] that might be an implementation that makes sense, certainly conceptually close to the table tagging system [14:34] when doing layout by hand, things often look good by eye, and then if you measure and tweak to grid structure, they are often even happier [14:34] people like to see things that have "happy" structure [14:36] and it is possible to say here I have a bunch of things and I'd like to have the top,left corner of each thing snap to an intersectoin on a grid that I can define [14:36] and then certain things always have some vertex.. blablabla [14:37] you could claim that linear and tabular information are subsets of grid, [14:38] you sure could... [14:39] still I think that the model of showing 3D in 2D representaion using grid structure as rough outline may not only be conceptually nice, but mathmatically implimentable [14:45] was thinking recently of illustrating this grid model with paperdolls, the child/sibling and align left could be shorthand to mean go to the left until you hit the vertical grid line (of specified grid) [14:47] and it makes it easier to think of typography for languages and character sets that have other than Left2Right, Top2Bottom [14:48] ... [14:49] would the author be allowed to set the grid? do the vertical and horizontal axes have to be equally spaced? [14:49] why is it so difficult to have a layout system that allows you to have both a visible grid object and an underlying grid alignment structure [14:49] yes, no [14:50] you could set multiple grids, in essence that is what happens when a page has margins; and then columns, ... [14:51] and if you animated the grids, it could distort the items aligned to them [14:51] and while equally spaced grids are useful as rulers are helpful, page stucture can vary [14:51] make a flowText rect wider, for example [14:52] a 2unitX3unit base structure may be nice [14:52] distort or move [14:54] yes, move obviously, but a more interesting case, to me, is distort [14:54] for fun or purpose? [14:54] purpose [14:54] which would be? [14:54] like what I mentioned above, for example [14:55] or to simulate simple layered 3D... multiple grids, one getting smaller, the other getting larger [14:56] you could set a squishy factor to different grid sectors [14:56] like finding stuff on the desktop flyovers [14:56] you could even get some simple non-affine transforms, maybe, by tranforming different grid-lines [14:58] if you map the different information flows through presentation formatting, it would be intersting to see where that would cause grid distortion [14:59] yeah [14:59] write it up, L! [14:59] of you could attach mor importance to certain of the underlying grids, so the structure of the information presented would change [15:00] a simple example may be by title, date.. altho not sure how that maps to the presentation model [15:01] snap to grid, snap the grid :) [15:03] ok will do [15:03] I made some simple snap-to-grid code, it wasn't hard, bt this would be easier, and could be declarative [15:03] cool! [15:04] * JibberJim leaves... [15:04] i'd hope it could help some of the css,.. formatting uglyness go away, but who knows.. [15:05] bye, Jim [15:05] Logical Groups could also dispense with much of CSS [15:09] *** dfas (~none@as8-1-1.lio.s.bonet.se) has joined channel #svg [15:11] so now I have the crossword running in batik kinda, it says it is ready to play, but I see no grid or clues.. [15:12] :( Session Start (niven.freenode.net:#svg): Wed Jan 07 16:56:03 2004 [...] [01:39] we were talking aboiut how we need a logicalGroup expert ;) [01:39] ping [01:39] ping [01:39] I still need to write that up... I'm a slacker [01:39] indeed [01:40] I never really understood it :) [01:40] Well, I never took the time anyway [01:40] you needn't bother, it's madness [01:41] I reckon i have time, since it could never make it into 1.2 [01:41] I do need to ake some more comments on 1.2, tho [02:16] sure you do [02:16] I'm interested in learning more on logicalGroups by the way [02:16] is that sarcastic? [02:17] axuly, I discussed it at length with Kevin, and I might just send the logs to some people who are interested [02:18] it's a very socratic approach, since we were asking questions and receiving answers [02:18] I think some people won't like it, because it proposes, among other things a way to replace much of CSS [02:20] it adds semantic relationships to SVG elements [02:20] it chops, it dices, it adds flavor and nutrition [02:26] I wasn't sarcastic [02:26] Sounds cool [02:26] Actually, I tend to use CSS less and less [02:26] I think a major problem with it is that I don't know how hard it would be to implement it [02:27] just fire it to the WG, the experts are there [02:27] Jim has brought me around on that issue... I used to be quite pro-CSS, but I think now that attributes are often better [02:27] me too [02:28] RCC also sorts of minimizes the use of CSS [02:28] plus when we'll have the XPAth APIs + RCC, why not just have a different element with proper semantic, rather than class etc. [02:28] a notable exception, I think, is composing a long string of style properties, and appending once to a style attribute, since it requires only one DOM call [02:29] XPath: amen [02:30] Indeed. [02:31] Might be one DOM call but it might no be faster [02:31] CSS re-cascading might be longer to figure out [02:32] yeah, you make an excellent point... but that was the only pro-CSS argument that occurred to me [02:32] that isn't much pro-CSS then :) [02:32] oh, well:) [02:33] the fact that it doesn't play well with Tiny is strong argument against it [02:34] Logical Groups could be used in other XMLs as well, and we could dump CSS, then;) [02:34] Intriguing. Time to write that paper dude Session Start (niven.freenode.net:#svg): Thu Jan 08 17:23:58 2004 [...] [17:34] oi, thelonious, you don't mind if I share our chat logs of Logical Groups around, do you? [...] [17:40] I'd like to write LG up formally, so I want to get some feedback from brainiacs like graouts and JJ and darobin [...] [17:40] although the original idea was largely JibberJim's anyway... [17:41] We had some discussion here too that may be worthwhile to include. [17:41] feedback: yes, certainly a good idea. [...] [17:42] yes, I'll scour the #svg logs for references to it