Brian Kardell: Hi, I am Brian Kardell. I'm a developer advocate at Igalia.
Eric Meyer: I'm Eric Meyer. Same.
Brian Kardell: And we wanted to do a special show about Interop.
Eric Meyer: Good old Interop 2024.
Brian Kardell: Yeah, we launched it recently.
Eric Meyer: Yep.
Brian Kardell: And it was big news, and we can talk about it. It has cool stuff in it and everything, but we've been involved with it since the very beginning. Specifically though, some of the things that we were seeing getting discussed on GitHub issues and social media, we thought maybe we should do a little show about that. There's a lot of people sort of talking a lot about why certain ones didn't get chosen. And if you don't provide an explanation, people will make one up.
Eric Meyer: I mean, they might make one up anyway, but definitely if you don't provide an explanation, there will be speculation to fill the void.
Brian Kardell: And I don't mean that people will make something up maliciously, I just mean that they'll fill in the gaps. They'll fill in the gap. But the thing is, we're on the committee that helps choose these, and so we have an insider view. We can't actually talk in super specific terms even because of rules that I guess we sort of helped design. But we can talk in generalities and I think that we can actually help explain and address why we get what might feel like some, even unintuitive to some people, results.
Eric Meyer: And I think it's also talking about why there is some confidentiality in this process.
Brian Kardell: Absolutely. I think it's key.
Eric Meyer: There have been people who have said, 'Why isn't this whole process transparent?' And part of the reason is that for Interop to do its job the best that it can, representatives, companies need to be able to say to the representatives of other companies in a confidential way, this isn't going to be a priority for reasons x, y and z, or We're really strong on this for reasons x, y, and z, and not have that become news stories. People get fired for that kind of stuff, but there needs to be a forum where the various teams can be forthright with each other. And there needs to be honesty in this process. A representative of one of these companies needs to be able to say, 'Look, guys, in all honesty, we're not going to support this thing that we're talking about right now. We will object.' Be able to say that openly.
Brian Kardell: Sure. That's true, by the way of W3C groups too. There's a facility to say that we're saying something off the record and wants to keep it so that we can have really, really honest discussions if that's necessary or appropriate. But I think far more than that for me at least, why do you not explain is because it's just really complicated. And you could take so many things completely out of context and make them seem like evidence of something or to support some preconceived notion because you only have filled in one gap. You still have the whole God of the gaps kind of problem here. I actually suggested this year that we write a sort of it's complicated and deeply unsatisfying why this isn't chosen, but it just wasn't. And I wish we could tell you more. It's not a commentary on we don't support it or that we don't like it or anything like that. Just the real answer is it's complicated. There's too much stuff.
Eric Meyer: Yeah. That's the problem that the project has faced I guess since the second year really, maybe the third, but there are too many things to do them all.
Brian Kardell: Arguably, it's why the whole problem exists in the first place, right? So the problem is that there is just too much stuff. And not just a little bit too much. There's a lot too much. CSS working group currently has over 3,000 issues open at this moment as we speak, and it has closed less than 5,000 ever in its whole history. So they just pile up, and then they pile up and they have to work their way through the gauntlet of independent prioritization in these different engines. And then those are subject to everything. Maternity leaves and sick leaves and this person got hired and this person got laid off, and teams are changing and restructuring all the time. There's no coordination historically to make sure that all of these things are making their way through engineering QA release cycles similarly. And so maybe very, very early in the web's history, it was a little bit easier to do that because there was just so much less stuff.
Eric Meyer: Yeah, that's true.
Brian Kardell: But also, we weren't good at it then. I mean, we didn't have good Interoperability. And so now, we wind up with this situation where say Chrome comes up with their thing and they do an implementation and they add these tests and it all looks pretty good, but then maybe Mozilla can't get to it for another year, and Apple is maybe unsure how they feel about it. Maybe they're like, 'Well, we're kind of on the fence still.' You can't give it the time to really figure out how you feel because you have to sort of manage all that time, all of it. Not just the implementation time, but how much time do you spend considering? And so then when the second one comes along, then the third one wants to take it more seriously too. So we could, if we just let everything to its own natural course completely independently, we wind up with sometimes many years between the first implementation and the last implementation. And by the time we get there, only then do we actually have all the tests that we should have had with the first one because every implementation that comes along improves the spec in the tests, and then we find that, oh, well, each one is passing 75%, and that's not bad.
Eric Meyer: Yeah, it's not bad. It's not great, but it's not bad.
Brian Kardell: So a lot of the pressure is off because like, oh, everybody's shipping it at least. But it turns out that in practice, a lot of times those are entirely ragged where each one of those 75% means that only 50% of this is actually Interoperable for developers.
Eric Meyer: Right, because everybody [inaudible 00:07:01].
Brian Kardell: Then you have another several years of pain. So that's how Interop came to be and why it exists in the first place.
Eric Meyer: The idea being that browser makers can coordinate on areas where they can agree. Because at the moment, I'm going to pick something that's outside of Interop's remit, but at the moment, Apple's going real hard on VR XR stuff for Vision OS, which to be clear, not part of Interop, but maybe Google's not interested in that right now. But to have a place where outside of working groups, working groups are where you talk about should we do a thing and if we're going to do the thing, how should it be done? Interop is where basically the different browser makers could come together and say, 'This is how a thing should be done, but we're not all doing it consistently. Let's get there.' And maybe in five years, VR, AR, XR, whatever they're called, will be a major feature because the Apple Vision headset will have gone through a couple of iterations. Maybe Google has its own coming out and so on and so forth. And so then maybe that becomes part of Interop. But right now, part of the reason it's outside of Interop is that there really aren't Interoperable standards for a lot of the things that are happening. There are some, but it's just not a place that browser makers are going to need to be coordinating right now. And many of the proposals for Interop this year were rejected simply on the grounds of there isn't a specification or there's not a finished specification. The specification is still under active development. It's not time for Interop yet. Or there's a specification, but there are no tests, so we have nothing to test against, and that actually is a really important part of Interop, is that there are web platform tests that can be scored and measured. That's where that graph comes from on the Interop dashboard, and it's how browser makers basically are able to look at, okay, if we're going to add this thing, how many tests are we going to need to pass and how difficult do we think that's going to be? And mix that in with how important is it to the forward progress of the web? How important is it to our customer base, to the wider web, to developers in general? This is why, like you said, a lot of the reasons are complicated and unsatisfying because you have 15, 16, 32 different incentive structures that are all coming together in this one place. And sometimes they can be completely a contradiction and sometimes they can all align. And where they can align, that's where things get chosen. That's where proposals get accepted into Interop. Also, I think we had at least a couple that we turned down on the basis of this looks like somebody's attempt to use Interop to get something standardized, but it's not standardized yet. This is not the place for that.
Brian Kardell: Right. So I think that's when we're talking about why did we create Interop and what is its purpose, I think there's definitely a sense that part of this is about giving developers some kind of voice, and I just want to talk about that a little bit. Everything about the web is about giving developers some kind of voice. There's very little that is done that anybody's spending money on because nobody's asking for it. But how do you know that? There are many ways that you know that, and there's unfortunately not a single funnel or even a single voice. And whatever voice you can get through Interop is through a lot of filters and also through the fact that it's completely voluntary participation. It is like people in good faith coming to meetings and saying, 'We will do our best to do the running back and forth between our companies to help find the things in here that we can get agreement on that we think are actually potentially achievable.' Conceivably, Interop is also not a promise. It's not a promise that everybody is going to get everything done, but it's like nobody in that room wants to hang some browser out to dry. Do you know what I mean? Everybody wants to say, where can we find really good consensus that we think it's at least possible, that we can find the resources to work on this, and everybody's going to work on this together and we're going to compete a little bit to achieve very high results. But it's completely voluntary. Even W3C, everything about web standards is voluntary standards. So the W3C, if the W3C could somehow determine, which also by the way, they cannot, that every web developer on earth was just like agreed this is the one that we should do, cannot compel Google, Apple, or Mozilla to do that thing. And even if they could somehow, definitely the people in that room are not the ones who could do that.
Eric Meyer: Yeah, I mean that is-
Brian Kardell: You can't, right? I can't.
Eric Meyer: Sure. That is definitely a part of the equation here is that the people in the room, part of the reason they need to be honest is that sometimes they're saying, 'look, this is the reality in which we are operating. We are not in charge. We do not make these decisions. If our company has said, we're never doing XR, don't even spend five minutes talking about it.' The people in the Interop room are not the people who made that decision. They're the ones who have to communicate to other people, 'Yeah, I know you really want to do XR VR, but we have been prohibited from doing it.' That did not happen, to be clear. I'm again using hypotheticals from way outside of what Interop was about and considered, but it's illustrative.
Brian Kardell: I have a sense that somebody might hear that and assume that XR is just a stand in for some other thing, but I'll just assure you that it is not that either. Basically there was none of that happening in Interop. I think it's okay to say that, but it is important for people to be able to be honest and for company to say, 'Hey, our team has a backlog already for the next six months, and we're also in the middle of some major part of our [inaudible 00:13:44] right, and as much as we are supportive of this, it is just not conceivable that we can do this.' But then there's the question too of how do you judge any of these things? Because we open the door and we get, I think, there are 108 submissions. And okay, now if I handed that list of things to a thousand developers, I would probably get a thousand different orders. It's really, really, really hard. And then if I asked every one of those thousand to explain why did you put masonry layout as number 23, but summary details as number 21, the answer is it's complicated and it takes a really lot of thought and time and reasonable people can disagree, right? And I can say this with absolute certainty because Eric and I do this ourselves and try to come up with an initial stab at it.
Eric Meyer: Yeah. We take the list of proposals and basically do stack ranking.
Brian Kardell: And we have-
Eric Meyer: We're going to put this one on top and then we can keep going through the list and then we find another one. It's like, oh, okay, should this one be on top, or should it be just below the one that we put on top before? Or maybe should be a little further down. Maybe it's a top five, but it's not a top three. Okay, great. We've placed that one and then you come to the next one. It was like, yeah, this is in the middle somewhere.
Brian Kardell: And we don't always agree.
Eric Meyer: No, we sometimes disagree. I'm trying to remember, there were at least a couple that I would put it about here and you said, 'Oh, really? That surprises me. I would put a much higher or much lower,' or whatever.
Brian Kardell: Yeah. I can tell you one is one of the ones that everybody was talking about is JPEG XL. We had kind of different takes on where that should stack up in terms of which things are higher on the list. Now you get into what are the kind of things that you consider, and the one that is pointed out a bunch is like JPEG XL had the most stars, the most GitHub stars, and it wasn't chosen. And some people think that's very damning. That's a terrible way to know anything other than it got a lot of stars. Do you know what was among the top few with stars, was MathML. It had way more stars than navigation, positioning, CSS, anchor positioning, CSS nesting, CSS style queries, masonry layout, declarative shadow DOM, custom media queries. Do you believe that that's really the order that developers, they want MathML more than all those other things?
Eric Meyer: Would the sum total of developers, if you could get them somehow all in one stadium and get a poll out of them, would they rank MathML above the navigation API or declarative shadow DOM? Yeah, probably not.
Brian Kardell: Yeah. When we also asked on social media, that was not reflective actually of what people gave us as feedback. Very few people had MathML as above those other things. And I'm saying this as Igalia is very behind MathML. It's very important to Igalia. We understand why it's important. In fact, this is one of those things when you're picking this, well, you could make an argument, hey, maybe browsers should all come together and prioritize this really highly because you have ignored it for more than a decade. You haven't spent any funds on it, so maybe now we should do that.
Eric Meyer: And yeah, we also, we had the discussion when we were ranking MathML. We think it's really important as a company, us individually, I think Math Markup is very cool and would give a lot of benefits, but we had the discussion sort of the real world discussion of where does MathML actually fit not only amongst all of these things, but in the regard of everyone involved in the Interop project? Because do we want to rank it number three, let's say because it's so important to us and just let that stand, or do we want to maybe put it mid-pack because we know that's where everyone else is going to put it and lend our weight to something that actually has a chance of moving forward. And reasonable people can disagree about how you approach that. Do you just absolutely do everything based on principles in a vacuum, or do you do everything based on what can actually get done in the next 12 months? And there are good arguments either way.
Brian Kardell: And even in a vacuum, you have to weigh, okay, well yeah, it's been ignored. We have Interop issues. There's been a lot of community. The community itself outside of web browser vendors has spent hundreds of thousands of dollars, including two individuals who've spent over 100 thousand dollars out of their own pocket. And I've said this a bunch of times, this is the language that we use to express the maths and sciences, which are really important in research and stuff, which is like the web's origins. And I said kind of a little bit snarkily during the process, like God forbid we had a pandemic or something and you wanted to share research via the web. Wouldn't it be really great if we had actual native math rendering? I think yes. So philosophically, it is important. There are good arguments you can make why it's important. On the other hand, masonry layout is popular and it currently requires JavaScript. We've gotten math out of where it definitely requires JavaScript. You can do a lot of math rendering without JavaScript now. So at least there's that. You have to compare those two things. You could say, well, I see masonry layout kind of a lot. The ebb and flow of much of the web is not math content, so maybe that's more important. That's a reasonable case. Maybe masonry layout is more important, maybe not more important, but maybe it's a better choice. Or here's why you should prioritize off-screen canvas. That one is incredibly unintuitive to me, but then when you hear the reason you're like, wow, that's a really good reason actually.
Eric Meyer: And masonry layout we ended up not selecting this year I think because again, specification is still in flux. It's not quite at the point where Interop is the place to be working on it. Hopefully next year that'll be worked out and there will be tests and it can be considered for inclusion in Interop 2025, but we're not there yet on Masonry specifically.
Brian Kardell: Yeah, I think there's another aspect of this too, that is there are over 100 things on this list. And we know we're not going to pick anywhere near 100 things, but if you just pretend that money is no object when it comes to actually if we choose them. So what we need is to just fully optimize this by taking in every possible piece of data to the fullest extent that we can. So we try to find the optimal path through every gauntlet. Even in that case, you would have to be deeply familiar with all hundred and however many of these in order to really reasonably make that case. I also see sometimes people make the case that, oh, well you didn't consider this carefully enough. But yeah, that goes back to the thing I said at the beginning where not everybody can afford to pay the same level of attention to all of the things. And so there probably is a bit of a bias in here.
Eric Meyer: And when you consider how long would it take for an entire engineering staff to go through a list of 100 plus proposals, and just within that engineering team say which ones they think are doable and which ones are not. Not even ranking them, literally just saying which ones do we think we could pull off in a year and which do we not? Or which do we think our engine can even handle and which do we not? How long would that take? That's at least a week.
Brian Kardell: It's impossibly complicated too, because if I ask you which of these things can you get done knowing that the list is five times too long, easily, you're going to say, 'Well, I can do A and C and D or I can do B and D, or.' You can't just say, 'I can do X, yes or no.' It's like it depends what else is chosen.
Eric Meyer: And like I say, it would be at least a week of an engineering team working through this, possibly longer. And literally for that entire time, they would be doing nothing else. How many times can you pull the engineering team off of what they're doing for a week to have this conversation? If the process goes to multiple rounds, it's like, okay, we took that week a couple months ago and now we've narrowed the list down by half and we got to go through them again. But you can't just have all the teams go and say, 'Well, this is the list that we've come up with,' and then assume that you're done because each team is going to come up with a different list and let's just make it easy and say it's just three engines. There are more people than that involved, but let's just say three teams do that. You probably have a list of 30 things, which is probably more than any one of those teams can actually commit to in the next year. So you got to go through it again. And this is one of the many challenges of winnowing down this list to a list of things that lends to the consensus that these are things worth working on that we believe we can make significant progress on in the next 12 months. Because it also doesn't do any good to say, 'Yes, that's a great idea,' and then not actually do anything about it because you have other stuff that has higher priority. Just from a public image standpoint, nobody wants to go in saying, 'Yes, we were going to do this,' and then at the end of the year when you check their scores, they have not changed at all. That just makes you look bad. But even beyond that, these are people who genuinely want to deliver on the promises and make things better for developers and users. People can be cynical about that, and I'm sure some people are. They're like, 'Oh yeah, sure,' but these people really do care about that kind of thing. And so they don't want to have something included in Interop and then a year later basically have broken that promise.
Brian Kardell: I feel like you can look at the time before Interop and the time to now and you can say things really do seem to have improved a lot. That goes both in terms of some legacy problems that we had that were painful, like the initial first year Compact 2021 where we're dealing with flex box and grid issues and stuff like that primarily. Through even now things launching with much higher quality Interop. And you can say it's easy to see why you could attribute that to well, sure, because we all focused on those things for this year. That's much, much more efficient if you look at a browser waterfall. When you can parallelize things, it gets done a lot faster. When they have to go serially, they can really, really drag out because things that you could be only doing way at the very end, you could have started much, much earlier.
Eric Meyer: And really one of the advantages of that parallel approach with everyone's working on it at the same time, the tests get much better much more quickly. Somebody creates a test and then another browser team which is checking their work against the tests says, 'Wait, suddenly we're failing this test, this new test, or this new set of tests. Why are we failing that?' And they look at it and they say, 'No, these tests are wrong.' They go back to the other browser team, the other browser team says, 'No, look at the spec. It says right here,' but this is how we read this spec. And then they can go to the working group and say, 'We had two different readings of this. What's the actual answer?' That working group ideally says this is the answer. The tests are either updated or preserved as they were, and whichever team on the other side of that has browser, this failing test fixes it. And I think that's a crucial component to that efficiency that you were talking about, that when things are being done in parallel. It's not just efficient in terms of time where you go from zero to mostly done in the course of let's say a year. But also you go from zero to much better done, and you have a lower chance of at the end of it, having incompatibilities that can't be resolved, which we've seen in the past where first team to do a thing, first browser to implement a thing implements it, and then other browsers come along later and try to follow that implementation, but they have disagreements with how the spec was interpreted. And then you end up with, well, the working group really wants this to be the answer, but that would make the spec incompatible with this implementation that's been there for five years, and that's a problem, or can be a problem. Sometimes browser makers will say, 'Oh yeah, according to our telemetry, nobody's actually using this anyway, so it's not going to hurt us to change it.' But sometimes they'll say, 'Nope, our users depend on this. We cannot change this.' And then what do you do?
Brian Kardell: Yeah, totally. And to your earlier point about people want to see it succeed, I think that there's a part of that that you can say isn't just about wanting to look good to the larger world, but also wanting to keep the project going. And so if you go out there and you're like, okay, so we're just going to say yes to everything and then you only can hit on 20%, your organization probably doesn't want to continue this effort. But if you go out there and things look reasonably good and you get mostly positive press from this and also your engine is getting better and people are happy about it, then yeah, that's an effort that we want to keep investing in. So I think that we're all just kind of aware that it doesn't really behoove anybody to promise a bunch of things that we can't actually even remotely hope to deliver. We can be optimistic, we can be whatever, but it's just like when your boss is like, 'Well, I need an estimate. How long is this going to take?' You're not helping anybody if you're not telling the truth there, right?
Eric Meyer: Correct.
Brian Kardell: So we want to do as good a job at those estimates as we can. But then at the end of the day, you do have to pick some things, and even if you could explain all the rationales for why you pick things, at the end of the day, we are doing a little bit of averaging of a million different opinions and inputs. And so that is how you get to some things that are even to us occasionally like, wow, wouldn't have expected that, but that is the result. We came up with the algorithm and you put the input in and this is what came out the other side. And it's not a bad result, it's just not what I would've expected.
Eric Meyer: Right. Sometimes you get surprised by what there's actual consensus on. You could start the process when you look at the list of 100 and probably pick, yeah, there's never going to be consensus on blah, blah, blah, blah, blah, blah, blah, blah, blah. And then if you compare that list at the end, you probably find, oh, one of those actually is one of the ones we picked. Weird.
Brian Kardell: And it is a lot averaging and things that are difficult to explain. I think in any country who's elected to the office, they're the ones that survived all the things and turned out the vote, and it doesn't mean they're the best person for the job. It doesn't mean even that the majority of the country actually likes them. Just means that that's what the process turned out.
Eric Meyer: Yeah, exactly. And we should also say Interop is not a constraint, like browser teams are not going to work only on Interop and nothing else. And things that didn't get picked, a browser team might end up hiring somebody who part of their deal is that they really want to work on that thing, and so they do it and push things forward. So if anyone had the idea that this is sort of a browser team's giving a list of here are the things that we will work on. No, it's here are the things that we agreed together that we could work on making them more interoperable, which is a very different thing. And masonry layout, I'll go back to that one since that one didn't get picked because the spec is still under development. Let's say the spec gets finished up in the second quarter of this year, and it's really solid and we know people really want it, can we make this happen? And that could easily happen in the latter half of this year if that's how things turn out. And so it could end up being that layout type is never part of Interop because by the time the next Interop rolls around, someone proposes it and we look at the test and say, Yeah, everyone's already above 95%. We're good here.'
Brian Kardell: Yeah, absolutely. I mean, that's-
Eric Meyer: Yeah, sorry. And let me be clear, I'm not making a prediction about masonry layout. Do not take that as a, oh, masonry will be done by the end of this year. It may not. The spec be done by the end of this year. Just that is the kind of thing that can happen where just because the thing got passed over for Interop does not mean that browser teams will then just ignore it and not look at it again.
Brian Kardell: Yeah, I was looking really quickly to see, I wish that I had thought to prepare this because it's such a good point, but I'm sure that if we looked, we could find something that was actually a pretty exciting thing that happened that wasn't on Interop 2022 or wasn't on Interop 2023, but actually still happened that year and actually got Interop independently. I bet that if we looked a little bit, we could find something that just got done because browsers were like, yeah, we have the resources. Or it was already on our radar to do it, but we were just waiting for this other thing to come unblocked and we didn't think that we could do it. We didn't know if we would have the budget. So-and-so was on parental leave, and they came back and suddenly we hadn't accounted for that resource and now they can't get it done. All these things are totally unpredictable, and obviously all the engines want to do as good job as they can. This is not a complete exhaustive list. Everybody's going to try and do as much as they can and will prioritize absolutely things that are not on this list. If you think that Chrome is only going to ship the stuff on this list, think again. Anyway, I think we could probably talk about this just literally forever probably, but I just thought it was worth us taking some time to talk about how you get to there. That a lot of the speculation, I don't want to get into which speculation or whatever, but I think we can just say, assume it's wrong. The chances that it's right are infinitesimally small, and I feel fairly comfortable saying it's okay for us to say that most of the things that I have seen are incorrect, and I wish it were not phenomenally complicated. And every year so far, we have had joint discussions to talk about is there a way we can make this somehow more explainable or transparent or whatever? Because for the most part, I think everybody doesn't want to have it's complicated be the answer. It just is.
Eric Meyer: Yeah. Sometimes reality is less satisfying than we would like it to be.
Brian Kardell: Yeah. Do you have anything else that you think we should address here?
Eric Meyer: I think we can say the Interop team is taking feedback on board and considering how to do better with communicating and that sort of thing for the future, but it's always going to be on some level disappointing to a lot of people, either because your favorite thing didn't get in or because it doesn't feel like it's enough. I think it's worth celebrating that the effort exists at all, that there's any effort between these teams to coordinate in any area. Because there sure was a time when that was not at all the case and you would've been laughed out of the room if you had suggested that maybe the different browsers should coordinate even a little bit. So yeah, it is, as you say, huge, that this effort exists at all. It's an iterative process. It's never really been done in this way. So the team is learning as they go.
Brian Kardell: Trying our best.
Eric Meyer: Hopefully improve not just the web, but also the process of improving the web.
Brian Kardell: Absolutely. I was just thinking before we get off here, I know everybody has already done shows covering what is in 2024. I don't think we need to do that. We already have talked about a few of them, like nesting, declarative shadow DOM, custom properties, but I think you can say that at least a number of them are pretty predictable. Popover, I think, we would have predicted. Declarative shadow DOM probably [inaudible 00:36:34] nesting. They're just very popular in all the venues. They're maybe not the top of anybody's list, but very near the top of a lot of people's lists that we saw. So I don't think that anybody was surprised with some of those. Other ones, maybe they were. But the thing that I wanted to point out is that we did this, what, a couple of weeks ago. So the numbers that we have are almost an example of the thing that I said at the beginning. So Chrome, Edge, Firefox, Safari, the numbers are 75, 73, 58, 75. But the interoperable intersection of those things is 48%. So at the end of the year, that number is going to be definitely in the 90s.
Eric Meyer: That is the goal.
Brian Kardell: On all of those things. I don't think that there ever has been a year where it wasn't up in the 90s.
Eric Meyer: Okay. Yeah. The interoperable score, you mean?
Brian Kardell: Yeah. There's a number of good features in 2024, and the fact that we can go from close to zero to up very close to 100% within the span of a year across all these engines is, I just can't overstate how huge I think it is. So I'm with you. I think we got to celebrate all the good that it does do and also continue to iterate and work on how we do even better. All right, so thanks for agreeing to chat with me about this, Eric. Hopefully people found it enlightening or at least interesting.
Brian Kardell
Eric Meyer