Igalia's Brian Kardell and Eric Meyer look back on things developing in WHATWG specs in 2004 and chat about what we've gotten and what remains outstanding.
Brian Kardell: Okay. Hi, I am Brian Kardell. I'm a developer advocate at Igalia.
Eric Meyer: And I'm Eric Meyer, also a developer advocate at Igalia.
Brian Kardell: On today's Igalia Chats, we're going to kick it off with asking you, Eric, if you noticed this trend. I've noticed it in blog posts and in the social media and on podcasts that's like, 'Boy, we have suddenly got so much stuff. What's the next thing going to be?' We've had this long list and it feels like we've sort of landed all of them. Have you seen a similar like, 'Boy, what's next?' What should we even ask for?
Eric Meyer: Yeah, to some extent, because when you think about it, in the last... Well, okay, it's 2023, so the last six years or so, pretty much since CSS Grid in 2017, which was roughly coincident with Flexbox settling into something stable. We've got so many things that have shown up, like just recently container queries, and that has selector which lets you do parent and ancestor and other crazy selection patterns. But, we also see cascade layers and cascade scoping and anchor positioning are all emerging. And then outside of CSS, there's been the dialogue element and JavaScript modules and classes in JavaScript and the Popover API and just so much stuff that it almost kind of does feel like, 'Wow, that's everything we ever asked for,' but it actually isn't everything we ever asked for, is it?
Brian Kardell: No, it's not. What I think is interesting is that a lot of these asks are pretty old, and so I got to thinking like, 'What if we could hop in the way back machine, go back in time to, say, a specific day in 2004, and see like, 'What did we think that we needed and what did we get from way back then?''
Eric Meyer: A specific day you say?
Brian Kardell: Yeah. Well, I don't know what specific day necessarily, but late in 2004, let's say. I think 2004 is the right time to look though.
Eric Meyer: Okay. Why's that?
Brian Kardell: Because 2004 is kind of like a watershed year. Recall that W3C declared HTML dead in 1998 in favor of new technologies.
Eric Meyer: I do recall that.
Brian Kardell: Yeah, and it was really kind of a bent toward... There's a lot of support for effectively Java plus Markup, not necessarily specifically Java, but the same basic model as Java, and all this kind of came to a head with this workshop that was called in San Jose in June 2004, called the W3C Workshop on Web Applications and Compound Documents, and it was sort of about what to do with all of this, and there were 40 position papers, and this is sort of where the WHATWG was born, because there was disagreement here.
Eric Meyer: Yeah.
Brian Kardell: This is where we get the split and the creation of what will become, was not then at the time, called HTML5. It was actually several specifications, not just one. But yeah, I think that's really the future of the web definitely pivots on there, right? It's sort of like The Under the Sea Dance set.
Eric Meyer: A little Back to the Future reference. Very nice.
Brian Kardell: Yeah. Back to the Future.
Eric Meyer: Yeah, I mean, there are certainly a lot of things that changed at that juncture. Like you said, the WHATWG spun out of that, and eventually HTML5, but there were those early specifications like web applications and web controls and Web Forms that all gradually coalesced into HTML5.
Brian Kardell: Yeah.
Eric Meyer: To at least some degree.
Brian Kardell: Yeah. So, if you're interested in this history, I just want to mention that I gave a talk in 2019 that goes into all this stuff and sort of the whole arc of the web platform, and I think it is a really interesting and good talk. I spent an incredible amount of time making the slides and then it promptly failed to record at the conference, so I only did it once. So I have posted it to YouTube though, and you can go and watch it there and we'll include a link to it. Yeah, let's talk about those three specifications. These are the three things that were in the WHATWG work. So, the first is web controls, and despite that name sounding the most interesting of all of them, is the least interesting of all of them.
Eric Meyer: Why do you say that?
Brian Kardell: Really the only interesting thing in here is that it had a way to do popups, which we're only getting today. So I do think that is interesting, but...
Eric Meyer: Yeah, I mean, it sounds like... I mean, I know there was a separate Web Forms specification right around that same time.
Brian Kardell: The Web Forms one is where we get... What do you think we get from there?
Eric Meyer: Well, probably form related stuff, but I'm going to guess that it wasn't combo boxes since those still aren't native.
Brian Kardell: Yeah, this is where we got all the form validation stuff, which is interesting. I think that is really underused. I think it's still a little bit clunky how to use some of it, but we also got most of the new input types are in there and-
Eric Meyer: New input types like?
Brian Kardell: New input types like date picker. I believe date picker is in there.
Eric Meyer: Okay.
Brian Kardell: I am not positive, but numeric range is definitely in there.
Eric Meyer: Okay. So sliders by-
Brian Kardell: Yeah.
Eric Meyer: ... another name perhaps or?
Brian Kardell: Yeah.
Eric Meyer: Yeah. Okay.
Brian Kardell: Well, it doesn't have to be a slider, but it could be.
Eric Meyer: Yeah.
Brian Kardell: There are also some classes in there related to that. Like valid. You know, classes-
Eric Meyer: Oh, like CSS classes. Yeah, pseudo-classes. Okay. So valid, invalid, that sort of stuff.
Brian Kardell: Yeah. Interestingly, I think that almost all of that is a mistake the way we did it.
Brian Kardell: Seriously, as soon as we're done recording this, you should stop what you're doing and go watch it.
Eric Meyer: I'm going to open a tab right now so that it's ready.
Brian Kardell: Yeah. It's such a good talk, but it gets into the things that are clearly wrong with doing it this way, but only some of them, and it's not a super surprise because it uses sort of classical inheritance and that's not always the greatest solution. So, almost nothing fits neatly into a linnaean taxonomy like that.
Eric Meyer: Okay.
Brian Kardell: So this is the Liskov Substitution Principle, or LSP 2008. She won the Turing Award for her work. We think about that as if that is progressive enhancement, like that's why we did that. We said, 'Okay, well, it's an input first, and that is a thing that lets you put in text, which is the thing that's submitted over the wire. We know how to serialize it.' Right? It already participates in form. All that stuff is the same and we just add this type, and then if your browser supports that type, you get a little bit nicer input, and we have other patterns for that in programming like with composition over inheritance. Anyway, I mean, I think we've kind of known this-
Eric Meyer: Yeah.
Brian Kardell: ... for a long time. I just think we chose the wrong thing there. There are lots of other things in there. There was a data attribute, but it wasn't the data attribute, and we never got it...
Eric Meyer: Okay. So it was just a bare attribute that was data equals blah, not data dash whatever you want.
Brian Kardell: So, it was for... I would note too that I don't think that we ever did get something like this, but basically you could attach it to a form and say, 'Here's the URL for the data that is in this form.' So, if you were building things... Like there's lots of sort of CRUD form applications, right?
Eric Meyer: Okay.
Brian Kardell: And lots of them have a... You have to update, you have to pull up a record and then you might want to update it, or even if it's read-only, you just have the same form and you just want to load lots of data for it, right? And this would have given you a way to do that. You provide a form without any data in it, and then you give it a URL, and it could populate the data.
Eric Meyer: Is this sort of a way of turning forms into spreadsheets, in a sense?
Brian Kardell: I mean, maybe it could used that way, but I think it's just more basically like the old mainframe idea is what we do even still today, it's just like, 'Here's a form that has a bunch of holes in it. Now, you just load some data from the server and put it in those holes.' And then you edit it and you click submit and it just submits the data back for those holes, right?
Eric Meyer: Oh, okay. All right.
Brian Kardell: Yeah, so I mean that was sort of like template and binding. You have this template and then there's binding that gets bound into there, and there actually was things like repeaters and templates. It was honestly a little bit confusing, but there were things in there too, sort of like template and stamp out HTML, and repeat. That, we still don't have. We have gotten pieces, like the template element that we have today kind of originates a little bit there, but it was a huge... I think that is an underappreciated element. That was a huge complex task. There's so much to it.
Eric Meyer: Yeah.
Brian Kardell: So, we didn't get what we had there, but we did get that. But yeah, those are the main interesting things in the Web Forms. I don't think it is anything super unexpected really besides those. I think all the really interesting stuff is in Web applications 1.0.
Eric Meyer: Okay.
Brian Kardell: I think that is the show. That is really the whole show is Web applications 1.0. There was so much stuff in there. This is where we got Canvas.
Eric Meyer: I thought that was a thing Apple just sort of made up out of whole cloth, was it?
Brian Kardell: They did, but they put it into this Web applications 1.0. Yeah. So this is also there it contained a solution for tabs. Tab box was the element, and we don't have that yet.
Eric Meyer: No. Yeah.
Brian Kardell: We did work on this idea called panel sets early on. We didn't know what to call them, so we called them spicy sections in that.
Eric Meyer: Oh, when you say we you mean the Open UI group?
Brian Kardell: Open UI, yeah.
Eric Meyer: Okay.
Brian Kardell: We're actually basically taken almost directly from here. That wasn't the plan from the beginning, but we came up with this proposal and then we found this tab box proposal that Hixie had in Web applications 1.0 in 2004, and we were like, 'Wow, we came up with the same solution.' That's probably pretty good, but we didn't do that.
Eric Meyer: That is a pretty good signal, usually.
Brian Kardell: Yeah. There are tricky reasons why it's not that way in both cases, but we won't get into that. That's another show.
Eric Meyer: Sure.
Brian Kardell: There was also this more general version of the showy hidey a bunch of sections thing.
Eric Meyer: The sort of accordion pattern kind of deal?
Brian Kardell: No, actually this was more like HyperCard or a carousel or something, where you have a whole stack of sections, but they're just mutually exclusively shown.
Eric Meyer: That still sounds like an accordion. How's it different?
Brian Kardell: Well, with an accordion you see something about all the sections, where with HyperCard, they're literally stacked.
Eric Meyer: Oh, okay. Okay. So there's a difference. Yeah, and in an accordion, you can see all the little tabs, but in this mutually exclusive sections, they're completely mutually exclusive, you can't even see the blank titles of the other things. Is that?
Brian Kardell: Yeah.
Eric Meyer: Okay. Got it.
Brian Kardell: I mean the element was called switch.
Eric Meyer: Oh, wait, see, when you say switch, I think of a light toggle switch.
Brian Kardell: Yeah, I know.
Eric Meyer: It's more like switch in programming.
Brian Kardell: It is more like switch in programming, but I think-
Eric Meyer: Okay.
Brian Kardell: ... not exactly like switch in programming either.
Eric Meyer: There's no break.
Brian Kardell: Yeah, right. Yeah, I don't know.
Eric Meyer: No. Whether it's like HyperCard or it's like an accordion or it's like neither, it's still do us... It does feel like there's probably a difference between that and tab box, because if switch acted like a bunch of accordioning tabs, then why would you need tab box or vice versa?
Brian Kardell: Right, yeah.
Eric Meyer: There's got to be some difference there.
Brian Kardell: Yeah.
Eric Meyer: But anyway.
Brian Kardell: Then there was a data grid and data trees, which is again this idea of basically like live binding some data model to DOM. So this one is-
Eric Meyer: Oh, okay. Like the data attribute you were talking about with Web Forms. It's the-
Brian Kardell: Yeah.
Eric Meyer: ... URL of some data source that will get sucked into the webpage into the DOM.
Brian Kardell: This I think is more like spreadsheety, right?
Eric Meyer: Okay.
Brian Kardell: Because you're talking about tables and tree tables and it's like, 'Yeah, there's lots of matrices that people load numbers and data for, and it's nice that they live on a server and we just load them up.' Them having some actual, like a way to define the data model, also opened the door to do other interesting things, like this included the Grid being able to be sortable, like provided by the browser.
Eric Meyer: Oh, so you could sort columns and rows of your...
Brian Kardell: Yeah, you could sort and filter and all that kind of stuff. Maybe natively from the browser itself.
Eric Meyer: Oh wow. Yeah, that would've been pretty cool.
Brian Kardell: Yeah.
Eric Meyer: I'm sure you also have implemented multiple times, sorting of grids or columns, or yeah, columns or rows, or both. Because I know I've done it more than once.
Brian Kardell: Yeah.
Eric Meyer: Yeah, and there's so many GitHub repositories and stack exchange questions about exactly that sort of thing.
Brian Kardell: Yeah, I just note that the last several that we talked about are all currently developing in Open UI, so there are things that are in that group of really old problems that we still haven't gotten and we're still actively working on. So, hopefully in the, 'What's next?' These are among the answers.
Eric Meyer: Yeah. Would you say we're still working on them because they're just fiendishly hard, or because...
Brian Kardell: I think a lot of it has to do with just funding, priority and attention. I think that we didn't pay attention to... We have paid almost exclusive attention to form participating interactive elements, so we don't have very many interactive elements in the web platform, right?
Eric Meyer: Okay. Yeah, like fully user interactive.
Brian Kardell: Yeah. We just don't have that many. And almost-
Eric Meyer: We don't have that many natively interactive. Yeah, they're basically all in forms, in one way or the other.
Brian Kardell: Yeah, so the ones that aren't are details, and just as of very, very recently, dialogue.
Eric Meyer: Right.
Brian Kardell: And that's that. End of list.
Eric Meyer: Yeah. If you want to make anything else interactable, so many event listeners.
Brian Kardell: Yeah. So we haven't done that. We haven't focused on it, because yeah, they are kind of fiendishly hard. I made a case a couple of years ago that, 'I think it's time to pay attention to those ones, specifically the ones that aren't foreign participating.' Because, in a way, they're harder problems, but they're also maybe easier than the form participating ones because they have a whole less dimension to them, and more or less there is like we should have this parody with ARIA, ARIA patterns, and a lot of these are well-documented ARIA patterns that, in theory, have a right way. I thought that for sure. I'm not entirely sure that that was completely true. So again, I think this is a topic for another show, but just very briefly, I will say that the tab box that's in this specification from 2004 and our spicy section/panel set solution that we came up with in Open UI, those were about sections of a document which you could display in tabs. Right? So, otherwise they would just be part of the same document. There's a strong argument that many tabs are not like that, and it's a definite, in many cases, like your browser tabs are not that, right? There is no use case for... Well, just show me all of the browser tabs in one continuous scroll, right? That's actually a window manager, not just sections in the same document. So yeah, it's a little bit more complicated and there's a question about whether those are actually two different things that demand different accessibility characteristics.
Eric Meyer: Yeah.
Brian Kardell: So yeah, you're right. They are very, very hard. But hopefully worth it.
Eric Meyer: Yeah. Anything else interesting in Web applications 1.0?
Brian Kardell: There was a calendar that's kind of interesting.
Eric Meyer: You mean like a calendar widget?
Brian Kardell: Yep. Used for displaying calendars and then also would have some interactive controls for a calendar maybe. But, also would have the semantics of calendars, which is nice. But also in semantics, there was a card.
Eric Meyer: Card.
Brian Kardell: I know that's one of those like, 'Could mean so many things.'
Eric Meyer: Right. Yeah.
Brian Kardell: But it is effectively like a vCard or an hCard kind of.
Eric Meyer: Oh, okay. Yeah, hCard, micro formats.
Brian Kardell: Yeah, it's basically just formalizing those practically into HTML itself.
Eric Meyer: So, sort of a business card structure kind of?
Brian Kardell: Yeah.
Eric Meyer: The sort of thing you would put in maybe a resume, or I guess on a contact me page, or that sort of thing?
Brian Kardell: Right.
Eric Meyer: Okay.
Brian Kardell: A business card. Do people still use business cards? I feel like that's becoming an increasingly dated reference.
Eric Meyer: Yes, but...
Brian Kardell: I mean I have them, but yeah, I can't remember the last time I got one. There was also lots of server sent DOM events. I think it was very, very cool. Like a stream of events that you send from the server that you could just listen for, so you could have an element in the page. The example that they use is stocks, so you could put one of these new elements in the page called event_source. They used a dash, which is interesting because later we reserve that for custom elements, but it was event_source SRC equals some URL, and then you give that an ID, and then you could listen for events on that element, and what it did is gave you a way to stream events from the server, to send things in a very simple format that would translate to events. So, you could listen for stock change events or whatever stock split events, or whatever things were in there.
Eric Meyer: Yeah. Okay. That just kind of goes along... It goes with the data grid and the data trees and the data attribute, and it sounds like there was a lot of thought early on there to turning browsers into thin clients, in a sense?
Brian Kardell: Yeah, I mean, I think, a lot because of that thing I said at the very beginning, which is like, 'Why this was born in the first place?' It was because there was this tension that HTML was dead, but nobody told HTML. And web developers who had this superpower called JavaScript kept doing more and more and more with it, and pushing it into more and more application uses, which I think is interesting all on its own because there are clearly bad things about that. But also, I think there are clearly good things about it, and this was trying to say, 'Well, how do we make that better? Because, I mean, we can plan whatever future we want also, but meanwhile, we should not probably just continue to insist that this one doesn't exist, we should make this one better for at least some of these use cases. There was also a connection object which would expose an API that will allow you to create a local broadcast connection or a local peer connection via Bluetooth or UDP or whatever. It's kind of interesting.
Eric Meyer: Okay.
Brian Kardell: Both of those two things, we didn't get them, but we have gotten, and there are things in development for both of those. So, we didn't get this particular service sent messages thing on an element, but we did actually get the API itself. I wasn't even aware of this, but apparently there is an event_source API, it's just not on an element. We did get lots of ways to communicate from the server. We got web sockets and push notifications, and what's the...
Eric Meyer: Are you thinking of WebRTC?
Brian Kardell: Yes. Thank you.
Eric Meyer: Sure.
Brian Kardell: That's the one I was thinking of. Yeah, so we got lots of ways to do that, and then all of the Fugu stuff is trying to do things like these, like local peer connections and stuff like that, to give you what Bluetooth and all that. So, I don't know. We haven't gotten those. Maybe we'll get those, but it's interesting. Of course, also the spec had all those new semantic things that HTML is really known for, article, main, aside, and so on.
Eric Meyer: Wow, okay.
Brian Kardell: There was a document focus interface, which I think is really interesting because I know a lot of people have asked for that over the years. Maybe I think I have as well. Then you get into it and you're like, 'Hmm, I'm not sure that I really have thought this through as much.' It seems very intuitive at the service, but I'm not sure.
Eric Meyer: What does, I mean, what does that do?
Brian Kardell: The API just has move focus and then a direction, so that can be forward, backward, up, down, left, right.
Eric Meyer: Okay, so this is user focus?
Brian Kardell: Yeah.
Eric Meyer: Got it.
Brian Kardell: That is actually surprisingly hard to do, especially the directional ones. We have defined sequential focus pretty well, right?
Eric Meyer: Okay.
Brian Kardell: Here's how sequential focus works. You use tab or shift tab, you move through the thing, but the D-pad ones is much, much harder.
Eric Meyer: Yeah, I would imagine that that's, like many accessibility things, that's one of those things that seems like really clear that it's needed, and then when you think about all of the different interaction modes that there might be, that's when, yeah, you realize, 'Oh, this is way harder than I thought it was.' Because you got the D-pad and the sequential and the eye tracking and et cetera, et cetera, et cetera.
Brian Kardell: Yeah.
Eric Meyer: Yeah. You know, how do you manage it in a voice directed interface? That sort of thing.
Brian Kardell: So there were all kinds of things in that specification is the point. That we got approximately zero.
Eric Meyer: Yeah. We got article, main, aside.
Brian Kardell: Yeah.
Eric Meyer: And I think of everything else you mentioned, we didn't get anything direct. We didn't get exactly what they wrote down. Like you said, there're pieces of these have been addressed in other ways. Like Fugu handling that connection object and stuff like that, but no direct implementation of this stuff.
Brian Kardell: It's interesting too to think back what a major leap all of those would been. Most of those would be a pretty huge leap today, to be honest. But, at the time, the state-of-the-art in browsers was, 'Get elements by class name.' That returned a node list, which was much less array like than... It was a very strange cumbersome API at the time, and we did get, since then, we dealt with that. We got querySelector, querySelectorAll, matches. None of those were in that spec. We've got made them increasingly array like, and made it super easy to put them in array, because there's all these great array methods and things that you do with arrays to filter them and remap them. We also improved a lot of the just simple DOM APIs, and the state-of-the-art for communicating asynchronously was still XMLHttpRequests.
Eric Meyer: Right.
Brian Kardell: In fact, that had a synchronous mode.
Eric Meyer: A lot of the stuff we were talking about, the data grids and trees and communications, felt like ways to do cooler XMLHttpRequests.
Brian Kardell: Yeah, I mean, that was one of those things where we got this new primitive concept, this new fundamental thing in the platform, and people were like, 'Imagine all that I could do,' and they started imagining really a lot, right? And it was pretty terrible as an interface.
Eric Meyer: Yeah.
Brian Kardell: It was born from Java, I think.
Eric Meyer: Yeah.
Brian Kardell: Also, it was strange because even though it had this... You could make it asynchronous, which a lot of people didn't until later on, because that makes it more complicated, especially because there also were no asynchronous primitives to the platform. There were no Promises, definitely no async/await. There was no Fetch, there was no streams. So yeah, I mean, that would've been a huge, huge leap to get any of those things.
Eric Meyer: Yeah.
Brian Kardell: We got a lot of lower level stuff instead of that. We got also template and slot, which are both huge, huge things, like comparatively an hCard is almost nothing.
Eric Meyer: Yeah.
Brian Kardell: You mentioned like, 'Why don't we get those? Is it just because those are ridiculously complicated?'
Eric Meyer: Right.
Brian Kardell: This even was discussed in 2004 even at that meeting, and cited in the taking up of HTML that we are just bumping up against the edge of maybe with those elements, like tab box being specifically about this, like there's a bunch of sections and you just happen to be able to display them as tabs. Like Hixie said, 'Tabs are a matter of overflow.' Right? They're just like scroll bars, in a way. He was saying that it seems like we were not ready to pick up all these super complicated things. All of the people in 2004 wanted to do really advanced stuff. They wanted a super rich toolbox that ran on a virtual machine and all this stuff. He has this quote that I thought I wrote down. It says, 'I was quite amused to see that, of all companies, Microsoft, Red Hat, and Sun Microsystems actually all agreed on something. Namely that trying to standardize an API for sophisticated applications is simply a non-starter. The argument which I agree with is that such an API is insanely complicated.' Just that's like literally what you said, right?
Eric Meyer: Yes.
Brian Kardell: 'And that making interoperable implementations is nigh on impossible.' The detailed spec is really a big issue. There simply has never been a web specification written in enough detail for this kind of work. If you're going to start doing that really detailed stuff, you probably don't start there, right?
Eric Meyer: Yeah, probably not. Yeah, what people will either may not have experienced or may have forgotten over the years is that, at the time, 2004, the state-of-the-art in web specifications, web technology specifications, was generally, 'Here is thing, here is what thing is meant to do. We leave it to implementers to figure out how to make that happen.' Right? The CSS specification in particular was kind of notorious for intentionally not giving all of the details on how a thing should be rendered. They would say something to the effect of, 'Implementations may vary.' And that was regarded as a good thing at the time because the specification authors were coming from a place of, 'This capability should exist. But we do not pretend to know the best way to do that.' So, the one that comes to mind is if you say something like font style oblique, and there's no oblique face for that font, then you're supposed to computationally slant it. The browser is at least invited to do that, but the exact process is not defined, which was basically the spec author saying, 'Implementers might find different ways to do this, and then if one of them is obviously the best one, then we could write that down later.' What that led to, as we saw over the years, was just not quite interoperable implementations, because this stuff wasn't written down, there were no detailed algorithms for how to lay out an element or how to deal with parsing weirdness in the HTML or whatever, and that there's been a big shift in the last 20 years towards specifications having... If you look at the HTML Specification now, most of it is, from what I can tell, is detailed step-by-step algorithms for how to deal with this situation and this situation and this situation.
Brian Kardell: Yeah, absolutely. I mean, so like I said, you don't start that at the top end of the most complex interactive widgets and all the things that could be wrong, that need to be specified. You have to start somewhere much lower, and so they actually start at the HTML parser because, believe it or not, that was the source of just a million bugs. We introduced in '98, I believe, the DOM, like the actual Level 1 DOM.
Eric Meyer: Yep. It was right around then.
Brian Kardell: By this point, in 2004, browsers didn't all even agree that the DOM was tree shaped.
Eric Meyer: Yeah.
Brian Kardell: Like with a tree, it would be impossible for something to circle back on itself, right? But I think in internet explorer, you could create graphs like that where you could circle back.
Eric Meyer: So, I'm My Own Grandpa. Nelson
Brian Kardell: Yeah, exactly.
Eric Meyer: It's an old novelty song, for those who don't recognize that.
Brian Kardell: Or a reference, Back to the Future.
Eric Meyer: Yeah. Also, Back to the Future. Although, fortunately, he did not become his own grandpa.
Brian Kardell: That's true. Yeah, so I do think that that is super interesting, and we had to do a lot of low-level work on the parser, and learning how to really tightly specify things, and getting really good interoperability by creating web platform tests, because they didn't exist before that.
Eric Meyer: Yeah.
Brian Kardell: So, yeah, I mean, I do think we got a lot of stuff, and that I also wish that had been sooner. Really need to write a blog post about why I got into all this, but I was writing rich internet applications that used a lot of that stuff that we wanted at the time. I kept using the web because it was the tool we had, but I was very much looking forward to that other future. So, I get why we had to go the way we've gone, and it's been, at times, very slow and painful. I am glad that we're really making a lot of progress now.
Eric Meyer: Yeah, absolutely.
Brian Kardell: I'm not sure it could have gone another way.
Eric Meyer: Yeah, we may have had to... Yeah, as a field, we may have had to do things the wrong ways in order to figure out better ways to do them.
Brian Kardell: Absolutely. That is sort of the lesson takeaway from the future is next, or What Comes Next Is the Future, is that a film? You we're in that film.
Eric Meyer: I was. It's true.
Brian Kardell: Yeah.
Eric Meyer: That's how I now have both a Wikipedia and an Internet Movie Database entry, just like my best friend from high school actually, and we're probably the only two people who ever graduated from our high school who has both.
Brian Kardell: That's interesting.
Eric Meyer: Yeah.
Brian Kardell: Do you want to say what they're famous for, or?
Eric Meyer: Yeah, so my best friend... He's still a very good friend. My best friend in high school is David Johnson, now known as David Leslie Johnson-McGoldrick. He wrote the screenplay to Aquaman and its sequel.
Brian Kardell: Oh, yes.
Eric Meyer: As well as Orphan, a couple Conjuring movies, some episodes of The Walking Dead. He's produced a couple of indie films, that sort of thing. So yeah, he has a much larger Internet Movie Database page than I do, because he's done a lot more in Hollywood, but then he also has a Wikipedia page.
Brian Kardell: That's kind of cool. Congratulations to your friend if he ever manages to listen to our show.
Eric Meyer: Yes.
Brian Kardell: Well, I doubt it. It doesn't seem like they are overlapping careers, but...
Eric Meyer: We talked about ChatGPT and AIs recently, but...
Brian Kardell: Sure.
Eric Meyer: Yeah. They're not hugely overlapping, but yeah, it's kind of weird, but also kind of cool that it's just the paths that he and I took, we ended up doing that.
Brian Kardell: Yeah.
Eric Meyer: Anyway, moving on.
Brian Kardell: Really unique set of boxes to tech next to one another.
Eric Meyer: Yeah, seriously.
Brian Kardell: Yeah, I mean, I think we covered a lot of the stuff. I did find one historical note that I thought was maybe worth including. So, one of the things that comes with pouring the detail into specifications is that they get much longer, right?
Eric Meyer: Yeah, they sure do.
Brian Kardell: He made a comment, Hixie made a comment on the mailing list. I'm going to quote. 'Another point that was mentioned at the workshop was that the DOM 3 Core was a long specification checking in at some 216 pages. HTML is 1,523 pages.
Eric Meyer: That's even longer than the book I wrote.
Brian Kardell: Yes. That is quite a long classification, and it's not going to get shorter. It's only going to get long.
Eric Meyer: Yep.
Brian Kardell: So...
Eric Meyer: Yeah, 1500 pages, and like I said, a lot of that is real detailed, step-by-step algorithms.
Brian Kardell: Yeah. There's a separate edition of HTML called the HTML edition for developers, and it's more the kind of stuff that we should read. Currently, it's the level of detail that goes into this spec, it's really for implementers, not for developers of-
Eric Meyer: Right.
Brian Kardell: ... [inaudible]-
Eric Meyer: So there's a version without all the wacky algorithms.
Brian Kardell: Yeah.
Eric Meyer: Well, they're not wacky, they're just insanely detailed.
Brian Kardell: Some of which they have to be.
Eric Meyer: I wonder how long that version of the HTML Spec is once you take all the algorithms out.
Brian Kardell: That is a really good question.
Eric Meyer: That's a thing to look up.
Brian Kardell: That is a thing to look up. Let's do it. It is five pages. That can't be right.
Eric Meyer: But that would've been hilarious if it were correct.
Brian Kardell: I guess there is no single page edition to this? No, that's unfortunate. Cool, I don't really have anything to add beyond this really, other than I love looking at these old lists. I've looked at them for... I turn back to them all the time myself, like look at these history things, because something comes up and I'm like, 'Boy, I think I've seen that before.'
Eric Meyer: Yeah.
Brian Kardell: And sure enough.
Eric Meyer: Right.
Brian Kardell: I just thought it'd be really interesting to talk about in the context of, 'What are the things that we have been desiring for a long time?' Because those are the really satisfying wins, right? When we get has... It's like, 'Wow, we've been asking for that since 1998.'
Eric Meyer: Yeah, thereabouts.
Brian Kardell: That's a long time, so-
Eric Meyer: Yeah.
Brian Kardell: ... it feels good to get it done.
Eric Meyer: Yeah, I mean, the interesting thing is that when you look back at this sort of thing, and like you say, you can see this stuff we don't have yet, even though it feels like we have everything we could have ever asked for, we actually don't. There are a bunch of things. What's interesting to me here is that the expected path of the web in 2004 is both not alike and like the path that the web actually took over the next 19 years. There was this expectation that it would be really important to have a calendar element.
Brian Kardell: Right.
Eric Meyer: And that hasn't really panned out necessarily. Even with all of the calendaring solutions that there are, that hasn't risen to the point of one of the browser engine makers saying, 'This is a priority and it needs to be done.' They haven't gone to their browser team and said, 'Make this happen.' Things like accordions and tabs and that sort of thing is being worked on, didn't quite get there yet, and some of the same ideas are coming up, and other ideas are realized. Over the 19 years, it's been realized that, 'Okay, that seemed like a good idea in 2004. Turns out that it's not because of these reasons.' But yeah, it was sort of to compare what was being expected with what actually happened, is a little interesting. Of course you can play the game of, 'Well, if we had actually gotten those things in 2004, maybe the web would look very different now, and be more,' whatever. Yeah, maybe that's true and maybe it's not. But, I think, I feel like the big thing that was expected then, that we don't have yet, is all of the native event and data transfer, and I guess the interesting question is, much like calendar, like, 'How important is that really? How common is it to want to be able to do that kind of live updating and event monitoring?'
Brian Kardell: Yeah, I mean, I don't know. I think the bigger thing that we haven't gotten is the sort of template stamping kind of thing, and that hasn't gone away. I mean, all the thing about React and all the React, Angular, Ember, Lit, all of them, they all are kind of addressing this very common need that... HTML is really nice because it's a serialization at the end of the day, but then there's the HTML Specification that tells you about what does that mean in terms of how's this supposed to work and are there interactions with the network CSS security, right? But, at the end of the day, HTML is also... There's the name for the serialization, right? It's like the name for, 'Here's the big string that describes all that stuff.'
Eric Meyer: Right. Yeah.
Brian Kardell: And boy, that's just really handy. I mean, there's just no way around that. If you can munch strings together, you can make HTML, and boy, are we good at making strings.
Eric Meyer: Yeah.
Brian Kardell: So, there is this desire to do that and to be like, 'Okay, well, I know that whether it gets pushed to me or whether I go check on it every once in a while, that sometimes I have to trade data, and I don't trade HTML, and I also I don't just trade form data. I trade JSON back and forth.'
Eric Meyer: Yeah.
Brian Kardell: Then I got to update my UI somehow, and how do I do that? That's what all those things are trying to do. HTML, not the serialization, but the whole specification, it doesn't have a way to do that currently. There is work on that between people at Google and people at Apple. It's been going on for a long time, but it's really making a lot of progress and I'm hoping that we see something there. It will probably mostly at first just make those libraries better and not make something particularly natively better for the average Joe. But I'm hopeful that we can get there.
Eric Meyer: Yeah. Templating would be pretty cool. I still use server-side includes. It'd be nice to have something a little more robust, dynamic.
Brian Kardell: Yeah, that's a fascinating one. Everybody wants that, right? Just basically some kind of client-side include.
Eric Meyer: Right.
Brian Kardell: Right? That it seems so obvious, right? I mean, among the very first things that we did with the web is create frame sets, because we're like, 'Well, I'm not going to rewrite that every time I want to create a new page. That's just madness,' right?
Eric Meyer: Yeah.
Brian Kardell: 'Why, I don't want to put the sidebar on every single page. Wow. Why would I do that?'
Eric Meyer: Right.
Brian Kardell: I mean, yeah, it's really obvious. Why would you do that? You could say, 'It's over there. Just it's the same one. It's just on every page.'
Eric Meyer: 'Go grab that.'
Brian Kardell: Yeah, and you can't do that. There have been lots of proposals to do that, and there's a lot of hesitancy to do it. For one, because it would really affect performance, right? You have to leave... Just like there is for... We have the import in CSS, and people say, 'Yeah, don't use that, because every import that you use means that you have to stop where you are and go do a network fetch, and you don't know how long that's going to take,' right?
Eric Meyer: Yeah.
Brian Kardell: Just use links in the page itself and do them all, like prefetch these things, make it as eager as you possibly can, get out of the way, because those are the rules you need to render the page in the first place. For all the same reasons, I think, they're hesitant to add, effectively, a client-side include.
Eric Meyer: Fair enough.
Brian Kardell: Yeah.
Eric Meyer: [inaudible].
Brian Kardell: All right. Hey, this was a really fun discussion.
Eric Meyer: Yep. History is always a good time.
Brian Kardell: Yeah. Hopefully people found it interesting.
Brian Kardell
Eric Meyer