Brian Kardell: All right. So hi, I'm Brian Kardell. I'm a developer advocate at Igalia and this is the fifth in sort of a joint series that we do on blink ons and also on our own thing as Igalia Chats.This is about the history of the web with people who help build and form and shape the web early on. You can view the whole series on our Igalia chat site. We've had a lot of different guests and I think this one is really particularly interesting because I have my coworker and co-host of our Igalia Chats, Eric Meyer.
Eric Meyer: Hello. Thanks for having me, Brian. It's actually what old farts like me are good for is telling about how it was back in the day. You kids, anyway.
Brian Kardell: We have to work in get off my lawn at least one time. Okay, so just some interesting things. I know a common theme in a lot of these is these are people who were around before the web, which is a perspective that is rapidly disappearing, right? So somehow we got involved in some way and when the web was not at all a given that it was going to be a thing. And we're sort of early adopters, having access to a computer even was still pretty rare in a lot of cases. Having one with internet access and learning about the web in the first place was not a given. So I'm curious. I always like to ask this question. What put you in of the right place at the right time to learn about these things and how did you get involved with the web?
Eric Meyer: Okay, so first of all, I went to school in Cleveland, Ohio at Case Western Reserve University, which is not a military academy. And I went there to study physics and I graduated with a degree in history and minors in astronomy and English and a couple other things. I immediately went to work for the university figuring that if I worked there long enough I could make back everything I'd given them in tuition. So this was summer, fall '93, 1993, and I was a hardware jockey. I was installing, I think, there were 3 '86 PCs to be online card catalog terminals. The card catalog ran off a mainframe in those days, like an actual mainframe. There was, for some reason, I don't know, there was a grant or something, I'm not sure. Somebody had gotten the money to buy a bunch of these desktop PCs that were just installed all over the libraries, at least one on each floor, usually more than one on some floors.Then it would open a VT 100 emulator and then you could search the online card catalog because we were transitioning away from the paper card catalogs at that point. So I was doing that, which meant going out in the field, but it also meant sitting in the office and doing paperwork. But sometimes I didn't have a lot to do. My former roommate actually and now coworker and the guy in the office next to me and still a friend, Jim Nauer, showed the rest of us in this little library information department, this brand new thing called the web and this brand new program called Mosaic. Most of us, I think the rest of us were like, okay, and? But see, that was before embedded images when he showed it to us. And then when the embedded images came out, he was like, 'You really need to look at this.' And showed webpages with images and you clicked and went from one page to another, and that's when the light bulb went off in my head.So this was probably fall 1993. It was an early Mosaic beta and that's how I got involved in the web. I was immediately taken with it. I had some experience with hypertext in the past, having nothing to do with html or the web. So I was kind of pre-sold on the concept. I liked the idea of being able to go from one point to another, from node to node as it were, but seeing it on the internet and being able to, here's the homepage of CERN in Europe, and here's a different university and here's a library of whatever. That just immediately took me.I think at first I thought my initial reaction was, this is really cool, I can't wait to see what they do with it. And then Jim said, 'And here's how you make documents,' and had a printed copy of the html two specification, which was not very thick. I was like, 'Wait, we could do these. That's awesome.' So that's how I got involved.
Brian Kardell: Yeah, I think actually before you came to Igalia, you and I had a chat and we're very close to the same age, and you got involved just really a couple of years before me. But I actually learned a lot of things early in my career from you because you went to Netscape.
Eric Meyer: Yeah, I did. That's true.
Brian Kardell: And you got involved with the CSS working group.
Eric Meyer: It's actually the other way around with that.
Brian Kardell: But both things, right.
Eric Meyer: Both things did happen, but they happened in the reverse order. So one of the things that I started doing was I started making webpages for the university, and quickly realized how simple it could be. I thought most people could do this actually. Because I want to make it clear to everybody, at the time, we had html, right? There was no CSS yet. There was no JavaScript, none of that stuff. It was just markup. And what the browsers did is what the browsers did. So there wasn't even an emphasis on it has to look a certain way, it was just going to look however it looked. And you could do a little bit to tweak. I mean, this is before Table markup.But I thought, wow, maybe I could teach the librarians html. So I started doing html classes. And then I wrote some online html documentation and that actually got tutorials with little quizzes, and those got real, that got really widely linked. So I was able to leverage that into getting the university to send me to some conferences. I mean, I got a paper accepted, a coworker and I. So the vice President of Information Technology was like, 'You're going to present a paper. I will absolutely pay your airfare to send you to Paris.' We were like, score. And that's where I ran into CSS. And so I started documenting, testing and documenting CSS, and that led to various things. Then eventually I got hired at that NetScape in like 2001.
Brian Kardell: So you became before that and invited expert to CSS through your appearances at the conferences and your testing on CSS?
Eric Meyer: Yeah. So I eventually developed, I don't want to call it comprehensive, but it was a thorough test suite of CSS. It just went through the specification and each section was section 5.2, blah, blah blah. And so would have a test page for the stuff that was in section 5.2. If that was margin, then it was a margin test. If it was background color, it was a background color test, whatever. You could click from one to the next to just see what does this browser do. So in that Paris conference, I saw a presentation on CSS with Chris Wilson, now at Google, Hogan Lee, BurBoss, the two co-authors of CSS specification. I can't remember who the other panel member was, but it was this new thing. So this is 1996, CSS 1 isn't out yet. It's like this new thing that we're doing called cascading style sheets and it let's you do these things.It was really cool. So as soon as I got back, because back in those days, laptops weighed about as much as a desktop computer does now. So I did not travel with a laptop. I traveled with literal paper notebooks. So when I got back to the office, back in America, I immediately started using CSS and I immediately started loading it into browsers like Netscape. And it immediately didn't work. It didn't do what I thought I was going to do. So I started like, okay, am I wrong, or is the browser wrong? I can't tell. So I started to build these very simple test pages to do things like when I did this combination of styles, this happened. So I'm going to test each of them individually and simply. It's like, okay, background color is supported, great, and padding is supported. Okay, so it must be the combination of those two in Netscape 4 that causes this gap to appear between the borders and the background, which was a real Netscape bug.The background only filled out the content box. So if you had any padding, you could see the body background through that gap between basically in the padding. They fixed that early. But again, I'm just trying to figure out how does this stuff work? So I started to develop this set of pages, test pages, and eventually got it to the point that it covered all of CSS 1, which was again, not a very thick specification. It was like 50 pages or something if you printed it out. I don't remember exactly now.So I took those and I contacted Chris Lilly, who was then chair of the CSS working group. And I said, 'Hey, I put together this thing, would the working group be interested in this?' He wrote back and said, 'Would you mind if I shared this with browser makers and the working group?' I was like, 'Yeah, go for it.' That became eventually the official CSS 1 test suite. Because W3C at the time didn't have a tradition of testing and test suites, specifications did not carry with them the expectation that there was any sort of real world testing of whether or not things worked.
Brian Kardell: This is really unintuitive. I've talked about it a number of times in my own talks. I did a thing when it was technically, it depends when you measure from, but the 30th anniversary of the web would've been a couple of years ago, if you measure from Tim's original paper.
Eric Meyer: Which I do.
Brian Kardell: The interesting thing here is if you put together a timeline and then you look at when all the things happened, it's really clear that from that you can see things were really rough going at first. The W3C, it didn't call itself a standards organization. Tim was specific about that in his book. He wrote a book and they made a recommendation, not a standard. And there was no... You would think, I mean today we have web platform tests, but I think it was 2012 maybe. I mean talking the W3C was formed in 1995. So to put a time window on the things that you're talking about. And 2012, I think we had 1% coverage in terms of what the web platform was in 2012 because it was still a really new effort. So actually the thing that you did to make tests was huge and groundbreaking. The interoperability of things was really bad. I think it might be worth talking about some of that because then you went to Netscape and you ran, what was the Netscape, DevEdge? Is that what it was called?
Eric Meyer: Yeah, it's called DevEdge. What is now Mozilla developer network was at one time called DevEdge.
Brian Kardell: Yeah, it had some obscure things like the fish cam.
Eric Meyer: That amazing Netscape fish cam.
Brian Kardell: Amazing Netscape fish cam. Okay.
Eric Meyer: Which dates back to 1994.
Brian Kardell: Yeah, tell us about that really quick, just because nobody will know what that is.
Eric Meyer: So, well maybe a few people watching will. If Chris Wilson is watching, Hi Chris, he'll know. So somewhere in 1990, I think around 1994, I don't remember the exact date, not too long after the, was it MIT? Somebody pointed a webcam at a coffee pot. The whole idea was you could be sitting in your office and you could pull this up on the web to see if the coffee pot was full or not. But the URL got around because nobody was authenticating anything in those days cause there were 16 people on the web so it didn't really matter. So it was like this coffee cam.
Brian Kardell: Not like a heavily guarded trade secret, whether the coffee pot is full either. So yeah.
Eric Meyer: No, it was literally for the people in the office to know, oh there's coffee, somebody just made a pot of coffee, I'm going to go get some coffee. So not too long after that, I believe ,somebody in the JavaScript department of Netscape pointed a camera at the fish tank that they had. Have a big fish tank because of Californian corporate offices and proto VC culture. Of course they had a big fish tank, saltwater fish tank no less. And they pointed a camera at it and then the amazing Netscape fish cam circulated on the web. Because this was in the days when the NCSA, the National Center for Supercomputing Applications, which is where Mosaic was developed, they had a weekly thing called the NCSA What's New page. And every week it would be a list of new sites on the web, and there'd be a dozen, maybe a dozen and a half per week that were new.I mean it was short enough, there could be a link and whoever compiled this would write a sentence or two about why it was interesting. And it showed up on the What's New page as the amazing Netscape fish cam. And the entire web, which at that point was maybe 167 of us, went and looked at the amazing Netscape fish cam. It was like there's a fish swimming by. One frame per second, but you could see the fish swimming by. And they set up, here are some of the fish you might see and stuff like that. So DevEdge inherited that page, the amazing Netscape fish cam page, and I got to redesign it
Brian Kardell: Yeah, and you would talk about certain features, but a lot of the things they wrote about were also the quirks and incompatibility issues you wrote about. Which is interesting to try to talk about and convey. So before this we had a little organization where we talked about what we would want to talk about, and one of the things that we both went, 'Oh yeah.' That's like kids today. We had no dev tools, there were none. There were no dev tools.
Eric Meyer: No nothing.
Brian Kardell: You could use an alert. That's pretty much what you could use.
Eric Meyer: Your dev tools were alert, document.right, and view source.
Brian Kardell: And a lot of people watching this are like, 'Well what about console.log? Right. But no, there was not console.log because there was no console.
Eric Meyer: Cause there was no console. Exactly.
Brian Kardell: There was console to log to. And then long after, there were some kind dev tools. I think Venkman was the JavaScript tool.
Eric Meyer: Yeah, the JavaScript debugger as we would understand debuggers today, setting break points and stuff like that. So Venkman, yes, was added to Mozilla. Oh geez, I don't remember now. But it was kind of one of those very early things where it was like you could actually set points and step through your JavaScript code. That was mind bogglingly revolutionary at the time.
Brian Kardell: A lot of these things I think also started as extensions. They weren't even mainstream in the thing.
Eric Meyer: Yeah, Joe Hewitt's firebug became basically a web inspector.
Brian Kardell: Yeah. I think what's really interesting about this is that even once we had things like that, well first of all they were ragged, you had these longer release cycles. You had a really long period where Microsoft left the game and it just sort of stalled. So even long, long after we got something simple console.log, if you can believe it, it was not compatible in the most rudimentary of ways. Microsoft, I believe it was, I know it was six, but I believe it lasted until maybe even 10. It was a long time, anyway, where the console object, you're a developer so you open your computer and you open your dev tools because that's where you live and breathe.Once you have them, you're like, I just keep them open all the time while I'm developing this site. Then you click ship, and some people argue maybe you shouldn't be sending console.log stuff. In fact, Microsoft did argue that. You shouldn't be sending that to production. But I think there are totally valid and valuable reasons to have logging in production sometimes.And the thing is, when you close the dev tools in Internet Explorer, the console object would go away. So it would throw and then anything after that in that context wouldn't run. And so very frequently you could push something and it would work great as long as you had a dev tool open. But if you didn't, nothing would work.
Eric Meyer: Right. Then your [inaudible 00:18:48] broke.
Brian Kardell: Yeah, yeah. I'm curious from the outside, I've watched standards for a long time and I don't know how many people watching this watch standards to this level, but we did have this period where the W3C seemed very, very promising. I was all in. Anything that they would worked on or picked up, I would've assumed it was as if it was written on stone tablets. It was just a matter of time before we would get it interoperably in all the browsers.But it turned out to not be that way, and that's not unusual. And even today things follow a bumpy path. We get an idea, maybe even a browser gets interested, maybe they even develop it. And along the way, we find a better idea or something else comes along. I'm just curious, is there any standard thing that you saw come be a proposal, get serious consideration and be interested and excited about that ultimately just didn't happen or hasn't happened yet or...
Eric Meyer: Yeah, there were quite a few. The serious consideration though, that's an interesting question. I mean all the things that come to mind were seriously considered by at least the people who were working on them. Whether or not browser makers or the relevant working groups seriously considered them, I guess is a little more fuzzy. I don't want to comment on that. But there was a simple vector format before there was SVG. And the syntaxes are actually not very similar. SVF was not based in XML because I think it might predate XML.
Brian Kardell: Interesting.
Eric Meyer: That promise was fulfilled by SVG eventually. But it's '95 or 6, I don't remember clearly. I remember sitting in a birds of a feather meeting about people interested in vector formats, and SVF was heavily discussed. There was a P3P, which I'm still sad, didn't go anywhere. P3P stands for platform for privacy preferences. And the idea was that you could, as a user in your browser, set what levels of privacy you were comfortable with at a fairly fine grain level. Then servers would be required under the specifications to honor those.So I don't remember what the exact levers were, but let's say there was a lever for no third party cookies. You could set that at the browser preference level and you could set certain, I think the idea was that you could kind of do them on sliders. So the bottom would be never track me with cookies at all. Then we sort of got some preferences like that, but there were many levers you could fiddle with and it was designed as a specification it didn't prescribe only these levers and never anymore.It was more like here are the core levers, but then more could be developed. I really liked that one. I was sorry that it never went anywhere. There are various reasons we could speculate as to why. And I think the most sort of crucial things did eventually get set. So in browsers now, when it comes to cookies, you can say set all cookies, I don't care. Or only set first party cookies or never set any cookies.
Brian Kardell: There are a lot of per site things too in browsers.
Eric Meyer: Yeah, a lot of per site things. And that was, anyway. There were a bunch of html elements, particularly in html 3.0, not 3.2 that I really wish had happened, FN for footnotes.
Brian Kardell: This is a great segue I think into, I was going to ask about, we were talking about the things that you've seen come that you were like, I wish it had made it, specifically in terms of let's say html. We can do CSS too if we have time. But I'm curious about html and the sort of anecdote that plugs very closely into the thing that you were mentioning before about headings. I just would like to say that if you wonder about the H1, H2, H3, H4, those are legacy that were inherited by html that had been around for a really long time since the 60s.The very first real email that Tim sent to WW Talk, which was mailing lists where people were to discuss, it was set up to discuss the web. This is the current state of html in my one browser that has implemented. This H1 to H6 stuff is kind of, we should probably get rid of it. Just make a section with a heading tag. That would be great.
Eric Meyer: Yep. Just H.
Brian Kardell: That is my biggest gully. I wish we had got that. So what about you? Can you tell me some? Do you like the person one?
Eric Meyer: I like person. I like note and footnote. There was a credit element so you could, here are the credits for this page or here's the... In a figure or a block quote, you could give credit. There were several others. They're not instantly coming to mind. But there was some interesting, I think there was an AU tag to implement represent the authors.
Brian Kardell: Just to note where Australia is.
Eric Meyer: Yeah, exactly. This is the Australian part of the page. AU crikey.
Brian Kardell: Yeah, it's really fascinating is that you can imagine so many semantic elements. And it probably has a lot to do with why we wound up going down a very deep semantic rabbit hole for a little while there. But if you look at the amount of time spent debating a lot of those and the implementation of them is almost like it's nothing. And you could use the element in your page today, and if everybody used it then we would have to write it down as long as you agree. That's how dictionaries work.
Eric Meyer: Yeah, pretty much.
Brian Kardell: Most dictionaries anyway. Yeah. I think it's really interesting. Address is another interesting element where we wrote it down and said it means specifically this, it must mean this. Nobody intuits that that's what it should mean. It was not supposed to mean a street address, right? But everybody used it as a street address. So we had to go back and say, I guess a street address is fine. That's along the lines of what you're saying. A lot of standards today they have to write down what people actually did ultimately. So we can prescribe a way, but if people don't use it that way and they use it some other way, we have to come back and write down the truth.
Eric Meyer: Right, and this is why JavaScript polyfills and pre-processor. Even though I don't hardly ever use either of them myself. I have nothing against them. It's just for what I do, not things that I use for the most part. But they're super useful for what are people doing? Let's write that down. There's stuff in the CSS color level, is it four or five, whatever the latest working draft CSS color specification is that has stuff like current color darkened 40%. Which is stuff you can do with SaaS mix ins, where you can have color shifting functions. And that's again, a thing where the working group saw what people were doing in the field and now is trying to write it down in a way that fits with CSS syntax and also does not clash directly with the syntax that's already in use in pre-processors. That's a whole rabbit hole we don't really have time to get into, but they try not to step on each other's toes for the most part.So yeah, that's why that I really like both of those things existing in the world. Predecessors and JavaScript polyfills. Cause with JavaScript, you can trial proposed specification. We worked on the temporal API, or still working on it. JavaScript API for time and dates here at Igalia. There's a JavaScript polyfill, or a JavaScript library that basically does its best to implement the temporal API. Before browsers had committed a line of code to supporting this API to sort of trial it out and figure out, okay, what have we not thought about? Super great. And that's moving forward and temporal is starting to land in browsers, at least parts of it, and working that forward. It's really cool.
Brian Kardell: It really is nice on multiple fronts. One is the standards can take a really long time and the more talk there is and everything, the more multiple ways it can go. Everyday developers, they have things to do. Most can't afford to track a feature for seven years. But they can, once you give them a standard, tell you did it meet your needs, or was it just terribly painful to use? The benefit of those things is they could really tighten the feedback loop, I think, where it is a good incentive if you have a need for somebody to say, 'Well there's not a standard yet, but there is a polyfill. And try it, and if it meets your needs, let us know. And if it doesn't bring your needs, also let us know.'
Eric Meyer: Yeah. How did it not work out for you? How did it break? How did it limit you?
Brian Kardell: Exactly. That is a big, big change I think. I think other big changes is lots of the teams, the players have moved and the sort of philosophy, how we think of the companies behind things has really changed. A lot of the people from Microsoft are at Google and people at Mozilla are at Google or Apple. People from Google are at Apple.
Eric Meyer: Yeah, it is interesting, because for a while there, there was that period where people became associated with organizations. So Chris Wilson was at Microsoft for a long time. And he's a Microsoft guy. Well he's been at Google for a decade, 15 years. I don't even remember. He's been there forever. I have to remind myself, oh yeah, Chris is not at Microsoft, he's at Google.
Brian Kardell: Definitely.
Eric Meyer: That's not new. But to watch people move around from one organization to the other, I suppose you could say the same of me. I was at Netscape for a couple years, 20 years ago. And now I'm at Igalia, which is another implementer, basically a browser manufacturer, and massive contributor to chromium and WebKit and stuff like that, and Gecko for that matter. But I did take 20 years doing other stuff on my own. But getting the perspective of people who have hopped from place to place is always really interesting.It's like, okay now I've worked at every major browser manufacturer and here's what I think about this process. Have to at least listen to that, in my opinion. Because someone who's been on the inside of these various processes, if they say, 'Look, here is the way to not go about doing X, because implementing such and so,' it's like you give that weight. It doesn't necessarily mean you blindly follow what they're saying, but you really have to give that weight because they've seen how the sausage is made in this case. And speak from the experience of, look, I've seen it from inside these teams and I can tell you right now, if you approach trying to get something done in this way, you're just going to bounce off a brick wall basically. If you try it this other way, you at least have a chance.
Brian Kardell: So we're rapidly running out of time, but there is one more thing that I would love to give you the opportunity to talk about which came up. I had asked you to think about what was one of your favorite projects that maybe even people don't associate you with or know about. Well, do you want to?
Eric Meyer: Yeah, so I have a couple bookends and I picked the term advisedly. One of the first projects that I did after making the university website was two of the professors of our history department. One of whom I'd taken classes from while I was getting my degree. Actually I think both of them now that I think about it. Anyway, they had written the encyclopedia of Cleveland history. So encyclopedias of urban history are just kind of a thing. There's an encyclopedia of Chicago history, New York history, San Francisco history, Cleveland history. So they had written the encyclopedia of Cleveland History and the dictionary of Cleveland biography, which was a separate volume that Viktor Schrekengost, who's a very influential mid 20th century designer, was a Cleveland native. Lived to be 102. Actually lived right near where I live. Anyway, so things like that. Jesse Owens, a Cleveland native. So he's in the dictionary of Cleveland biography, et cetera.So they had seen where, I think it was the Encyclopedia of Chicago history, had put some of their articles on the web. And they said we want to put everything on the web. So we did. We basically did it, it wasn't XML, because this was again, sort of before XML, but we basically made up our own markup language, stored it in a database and then had output filters that output that to html. The encyclopedia of Cleveland History is still online. I believe it's at ech.cwru.edu. Obviously, well maybe not, obviously, I haven't had a hand in it a couple decades now. But I led that project and it was the first example of the entire text of a encyclopedia of urban history being made available online for free.
Brian Kardell: That's awesome.
Eric Meyer: Yeah, and I have a degree in history. Clearly I have love for the subject. So that was really fun. And then just recently, literally this year, a colleague and I, Chris Griffith, we're both kind of space nerds and also students of nuclear history. My degree in history, I actually studied from World War II onward, sort of the Cold War and nuclear arms and their effects on international relations. So in the study, in the field of the study of nuclear weapons, there's a US government publication called The Effects of Nuclear Weapons. It went through three editions. The last edition was in 1977. It's the third edition and it's been available. You can get PDF scans of it, but that's it. And Chris and I each literally owned physical copies of it. That's how, everybody who has studied the field has a copy basically. We wanted to put it online.Again, full text, as accessible as possible, like html, raw text, none of this PDF scan stuff. Cause PDFs are not very accessible. Even if they've had the text OCR, sometimes the OCR software does not do a good job. So we did that, and that published. We put it online in August of 2022. So about a month ago as we record this. I'm kind of proud of that. I mean it's a US government publication. It's been in the public domain for year. I mean because it's a US government publication, it's in the public domain. It's all on classified stuff. My understanding is that there's a classified version of this book. I say it's classified so we don't get to see it. But this is the unclassified version. So I appreciated it for the history, for my personal interest and also for taking a text and putting it online as accessibly as possible using the most basic technology we could get away with.The only JavaScript we're using is actually MathJax because there are a lot of mathematical equations in the chapters of the book. And rather than try to render them all in SVG by hand, which is what we would've had to do, we were like, we're just going to use MathJax. We'll write it as latex, boom. Which works great. Hopefully MathML will start to become a first party market language again in part to the work that Igalia's doing to get it in a chromium. If we get to that point, I'm absolutely going to go back. And the things that can be rendered as native MathML, I'm just going to translate. I'm going to turn them over into MathML. And the things that for whatever reason can't, if there are any, then I'll leave them as MathJax. Anyway. So those are two things that I'm really proud of because they're taking information and putting it online.That's sort of what drew me to the web in the first place. This idea that you can take information and put it online so that anyone can access it, anyone can learn from it. But beyond that, xfn, the xhtml friends network, that [inaudible 00:38:28] and Matt Mullenweg and I created back in like 2003, which was a way of adding semantics to the web without having to invent new elements or entire new languages. It was a way of saying, okay, well if you class or you use these other attributes in certain ways in these patterns, then you can add semantics and xhtml friends network. Some people might not remember that, but people had blogs. And on those blogs there would be what was called a blog roll. There was a list of links to other blogs that the whoever's blog you were on were blogs that they liked.And so the xhtml friends network was a way for you to be able to mark use of those links to say HRF equals meyerweb.com. Rel equals colleague met, which is way of saying this is a colleague of mine and also I have physically met them in person. So there was the possibility of creating networks of trust. So if you had a link to my blog on your blog roll and someone's met you and maybe there was a way to expose that you have met me in person. Then I am less anonymous in a way. There's more reason to trust that I am a person who exists in a certain sense. That was fun. It was the foundation of micro formats, which in a lot of ways was a big influence on schema.org
Brian Kardell: And kind of socia graphs in a way.
Eric Meyer: Yeah. That was what xhtml friends network was for. Micro formats then took the design principles that we used and xfn and applied them to things like marking up calendar events so that you could say, this is the event title and this is the date and this is the time start time and the end time and blah, blah, blah. I'm blanking on one of the other. There were several micro formats. And again, this probably sounds familiar to people who are saying, 'Oh, so you ripped off schema.org.' Well no, the arrow goes the other way. I'm not saying that the schema org people ripped off micro formats because micro formats were absolutely a, here is a thing anyone can use and be influenced by.And it seems like they were influenced by. There was one other project. Yeah, it's time. So I have not... Maybe three people in the industry know that I did this. But back in 2005, there was a team at Apple responsible for the website, apple.com, who felt like they should get away from their table and space a GIF markup of their site and convert it to standards like Symantec, html and CSS.Through various set of circumstances, I ended up doing that project. I worked with my contact at Apple, produced a style guide, produced a markup guide, converted a bunch of top level pages from table and space to divs and CSS, or I made this markup as semantic as I could.
Brian Kardell: But it was internal, right? The look and feel didn't change.
Eric Meyer: Yeah, right. It was all about the code. There was no change to the design of the site. Then that was in fact one of the project constraints. And it was one of the challenges because if somebody did a thing that was difficult at the time to do in CSS, I had to figure out a way to make it happen. Which again, we didn't have grid, we didn't have Flexbox. All we had was floats and positioning basically. So I had to figure it out from there. So I did that. That's why actually, a thing that's been noticed over the years, anywhere there was a bit of legal ease.
Brian Kardell: It's in Wikipedia, this bit.
Eric Meyer: Okay. Okay. So if the legal notice would say class, I set a class of so sue me, which it's like a system seven, I think, or Mac OS 7 or 8 sound, like a system sound called so sue me. And I made this plinking sound. There's a whole backstory that I'm not going to go into, but it was-
Brian Kardell: You should look it up because it's great. It's great. Yeah.
Eric Meyer: And it's called so sue me, because sosumi is what it was. But it was written to look like it was a Japanese term or something. So it's sosumi. So as we were doing this and I got down to the footer of the site where there was a copyright 2005 Apple incorporated and all rights reserve, blah, blah, blah, blah, blah, blah, blah. Whatever the legal ease was at the time, I was like, okay, I want to represent this with a class because it's small and it's gray and it's... Anyway, I'm going to represent it with a class. And I said to my contact at Apple is, you okay with it if I call this class equals sosumi? Cause I think that would be a really fun little Easter egg in the markup. He was like, 'Yeah, totally. Go for it.' So I did. And so you can still find it in various little places. It's mostly faded away. So that's why I guess I feel comfortable talking about it now.
Brian Kardell: Yeah, it's noted. I mean it's noted. People have pointed ou.t you can search for it. Not that it was you, but that this sosumi class, a lot of people finding the Easter egg in there and getting a giggle out of it and sharing it.
Eric Meyer: Yeah. So yeah, it's been long enough. And when you asked the question and I thought, I was like, 'Should I talk about it? I've kept it quiet now for 17 years.' But yeah, it's time. I think that's long enough. I could have waited for 20, but yeah, whatever. 17 is fine. Yeah. But that was a really fun project because it was a real challenge. But...
Brian Kardell: Great story though.
Eric Meyer: It's fun working with Apple, even if on the down low because I'm mostly an Apple guy. Have been since my university days when I worked in a Macintosh computer lab. But yeah, it was a lot of fun and it was great working with people inside Apple, getting to visit the campus at one point. And between that and working with people, not working with as in being employed by, but interacting with people like Chris Wilson when he was at Microsoft and now at Google. A contact, when he was at Microsoft. Dave Hyatt when he was at Apple. And before that, when he was at NetScape.Getting a feel for what the people working on the inside are like I think has been a real benefit because it's easy to say Google, Microsoft, Apple, these huge titans, these monoliths of whatever, they're made up of people. And the people inside often, even if they can't say so, have very strong opinions about how these Titans products should behave and what they should prioritize. And those may sometimes be in conflict with what the organization as a whole might want, but they do their best to make it happen anyway. And it's been a real privilege actually to be able to see that.
Brian Kardell: This is a great final story. Thanks for breaking the news here.
Eric Meyer: Sure. Well thanks for giving me the opportunity to finally come clean.
Brian Kardell: Yeah, so we'll wrap it up and I guess I'll see you at work on Monday.
Eric Meyer: All right, thanks Brian. Talk to you later.
Brian Kardell
Eric Meyer