Session Start (MSN - schepda:Kevin Lindsey): Fri Nov 14 11:28:34 2003 [...] [15:14] schepda: you read about logicalGroups? [15:14] schepda: it's something Jim and I came up with [15:14] Kevin Lindsey: Yep, but I think I'm missing the point...how does this solve the overlapping road problem? [15:15] Kevin Lindsey: Maybe for a later conversation, if you're busy [15:15] schepda: you have two different line segments, one under and one over, and you link them logically, but not "physically" [15:15] schepda: no, I'm ready for a little break [15:16] schepda: so, programmatically, they are the same line, but they are broken down into 2 differnt elements [15:16] Kevin Lindsey: So, let A be (, and let B be )... [15:17] Kevin Lindsey: How can bottom of A be on top of B and then the top of B be on top of A... [15:17] Kevin Lindsey: your saying you have more than just those two shapes to achieve that? [15:17] Kevin Lindsey: (imagine those shapes overlapping) [15:18] schepda: yes, 3 shapes... it doesn't solve all Z-index problems, but it solves some problems z-index doesn't [15:18] schepda: A = A1 and A2 [15:18] schepda: A1 [15:18] schepda: b [15:18] schepda: A2 [15:19] Kevin Lindsey: But you still have to "split" A into two pieces otherwise A2 will overlap B just like A would have, no? [15:19] schepda: yes, the order would be : A1 B A2 [15:20] Kevin Lindsey: Are A1 and A2 sub-segments of A? [15:20] schepda: but any transforms or logical opeations you do to logicalGroup A would apply to all its subelements [15:21] schepda: yes, they are, and they have their own physical placements in the file [15:21] schepda: but are linked by a declarative relationship [15:22] Kevin Lindsey: sorry to big thick here, but how would that be different than a with 's? [15:23] schepda: well, here are other uses for it as well, but in that case you would have to say... [15:26] schepda: as opposed to having any arbitrary ordering/rendering of elements as generated by, say, a program, which can then be linked ipso facto to the logical order... you don't have to "duplicate" the elements with , you just link them [15:26] *** Your previous message has not been sent. Reason: Maximum length exceeded. You can recall the last message typed with Ctrl-Up or Up, depending on settings. [15:26] schepda: [15:27] schepda: as opposed to having any arbitrary ordering/rendering of elements as generated by, say, a program, which can then be linked ipso facto to the logical order... you don't have to "duplicate" the elements with , you just link them [15:28] schepda: plus, logicalGroups is good for associating things as part of a "group", in a specific order within that group, but without them needing to be placed physically together in the file... [15:30] schepda: it's not just for z-index, though it's one trick to help there... it's a logical association of elements that need to be separate in the file... it a way, it's like creating declarative objects [15:30] schepda: in markup, rather than script [15:31] Kevin Lindsey: So, you're saying I have ...A.....C.....D.....B.. within my document stream... [15:31] Kevin Lindsey: and later I want to order them (logically, not in rendering order) to A,B,C,D, then I would use your system. [15:31] Kevin Lindsey: ? [15:32] schepda: right... it can also be used for tabindex [15:32] schepda: or for associating disparate text elements [15:32] Kevin Lindsey: You could probably use RCC for most of this, but not text selection [15:34] schepda: or, another use, say I have a group and a group, not nested, and subgroups within them... I could link a room and its furniture without changingthe rendering order [15:34] schepda: you could do some it with RCC, but that's overkill and proly uses script [15:35] schepda: "some of it" [15:37] schepda: I think that this is a pretty simple idea to understand, though I could be wrong, and would be relatively simple to implement [15:37] schepda: I am not yet sure how powerful it could be, though [15:38] Kevin Lindsey: Gavin just responded to Logical Groups on www-svg [15:38] schepda: bastard! [15:39] Kevin Lindsey: So, as he says, this doesn't effect rendering order, right? [15:39] schepda: not intrinsically [15:39] schepda: though transforms might do so [15:41] Kevin Lindsey: That's where it starts getting scary to me...of course the whole z-order thing feels kludgy to me anyway...I understand the need [15:41] schepda: z-index is actully several different problems rolled into one [15:42] Kevin Lindsey: but it doesn't handling grouping [15:42] Kevin Lindsey: but works for tab order [15:42] schepda: no, you're right [15:42] Kevin Lindsey: but does not work for linking text elements [15:43] schepda: how so? [15:43] Kevin Lindsey: how so no linking? [15:43] schepda: yes [15:44] Kevin Lindsey: You could have differing threads within a document. The best you could do with z-order is give them all the same value, but then you can't handle tab order [15:44] Kevin Lindsey: because they all have the same number instead of ascending values [15:45] schepda: in Gavin's example, if you selected and copied the text, because it is grouped logicall in the order it is grouped, it would paste as Hello World [15:46] Kevin Lindsey: Sure, I see how your approach works. I was saying that z-order may try to solve many problems, but linking is not one it would solve. [15:47] schepda: oh, yes, z-index doesn't solve that, nor does it solve things that need to be part of the same object but have 2 different z-indexes [15:47] Kevin Lindsey: Personally, I would rather see a grouping mechanism like you describe rather than a z-index. [15:48] schepda: same here [15:48] schepda: :D [15:48] Kevin Lindsey: At the very least it delcaratively defines the relationship [15:48] schepda: it does lots of stuff, and gives some z-index solutions to boot [15:48] Kevin Lindsey: As opposed to some invisible abstraction associated with numbers [15:49] schepda: right... that's fallible (you could mistakenly use the same number twice), where this follows the painter's-order algorithm [15:49] Kevin Lindsey: In Gavin's example, the member would inherit from logicalGroup, effectively ignoring the g attributes [15:49] schepda: yes [15:50] Kevin Lindsey: So, Hello World would be red? [15:50] schepda: correct [15:51] schepda: that's where logicalGroup differs from the strict ordering... it is resolved last [15:52] Kevin Lindsey: What happens when you have two logicalGroups each refering to the element but with differing inherited attributes? Say, one is red, the other is green. Which group wins? [15:52] schepda: BUT, in the order of logicalGroups.. so if 2 logicalGroups had the same member, they would be resolved in order of the physical ordering of the groups [15:53] schepda: lol [15:53] Kevin Lindsey: :-D [15:53] Kevin Lindsey: K [15:53] schepda: that's where it's a bit tricky, but still logical [15:54] Kevin Lindsey: This would have a big impact on the current viewers...it changes the rendering model considerably [15:55] schepda: errr... maybe... [15:55] Kevin Lindsey: but it may follow the CSS model and might be solved that way [15:55] Kevin Lindsey: using the same code logic, that is [15:55] schepda: right, true [15:56] schepda: not quite a shadowTree... more like a postTree [15:57] schepda: so, do you think it's workable? [15:57] Kevin Lindsey: I'm trying to picture the rendering model this would imply...not sure yet [15:58] Kevin Lindsey: I like the idea...just don't know how to implement it [15:58] schepda: it's not unprecedented, this reordering of elements... it's what use or defs uses... [15:58] schepda: I mean, they aren't rendered in the order they are declared, right? [15:58] Kevin Lindsey: But those elements exist in the DOM already, then you create "instances" of them; whereas, you are directly effecting the instances [15:59] Kevin Lindsey: I can add a shadowTree to to render it... [15:59] Kevin Lindsey: You already have an element that is being rendered and it is being altered...it's different [16:00] Kevin Lindsey: being altered because of LG [16:00] Kevin Lindsey: So, it looks more like CSS to me than [16:00] schepda: yeah, I have to agree [16:02] schepda: in fact... maybe it could be extended to replace CSS... but that's dangerous [16:03] schepda: politically [16:03] Kevin Lindsey: because MS is anti-CSS? [16:03] Kevin Lindsey: Personally, I would love to see an XPath-based styling language [16:04] schepda: no, because lots of people are pro-CSS, and this could be seen as an attack on it alone, so its other merits might be lost in the shuffle [16:04] schepda: me too [16:05] Kevin Lindsey: those baCSStards! [16:05] schepda: ouch! [16:05] Kevin Lindsey: sorry [16:06] schepda: you should be [16:07] schepda: maybe there could be more than one member type for a logical group... id-refs, and tagName/localNames [16:07] Kevin Lindsey: not sure what you mean [16:07] Kevin Lindsey: are these attributes of logicalGroup? [16:08] schepda: so, you could say all paths are part of this logicalgroup... it would be a reference to all path elements in the SVG [16:09] Kevin Lindsey: now you're definitely getting into CSS territory [16:09] schepda: and if you add in xpath, you could say, all paths with this attribute... [16:09] schepda: yes:) [16:09] Kevin Lindsey: CSS selectors or XPath expressions [16:09] schepda: that's exactly where I was going with it [16:09] schepda: xpath selectors [16:10] Kevin Lindsey: nm, you said it before I sent it :-) [16:10] schepda: since xpath is going to be in 1.2 anyway [16:10] Kevin Lindsey: We (I mean you) could prototype this with RCC when we have XPath. An example goes a long way. [16:11] schepda: yeah, when I have time....