Igalia's Brian Kardell and Eric Meyer chat with GitHub's Keith Cirkel about new work that GitHub is spearheading to help solve what might just be the Web's oldest problem: Headings.
Brian Kardell: 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.
Keith Cirkel: Hey, my name's Keith Cirkel. I work for GitHub on the primer design system team.
Brian Kardell: And we wanted to have Keith on because recently Keith filed a Chromium intent that is near and dear to a topic that Eric and I have been talking about for years and years and years, which is about headings. And there's a whole bunch of things we would like to talk about in this, the history and how we got to hear and what the problem is. But Keith, do you think that you can describe the basic problem that this is aimed at solving?
Keith Cirkel: So I can kind of talk from GitHub's perspective, but I think there's a general case here, which is around user generated content. If you're writing a document and you own all of the stuff that goes in the document, all of the source, you can mark up a document structure that is H1 at the top, H2, and then underneath each H2 there's H3s and so on. And that is how a sensible document is laid out. It's kind of chapters in a book. It starts with the title. There's chapter titles, there's subtitles and so on. The problem comes with user generated content and especially for a site like GitHub, user generated content can come in different places and we call 'em markdown surfaces. So you can have a comment which is one markdown surface or a me, which is another, and those are injected into documents at different points. So an issue will have an H1, which is the issue title. It'll then have H2s for example, this user commented so that your markdown comment starts at H3, but a lot of people just write the hashtag, like a single hashtag for an H1 if they want to create their own mini document within that. So we need to somehow fix that up. But then there's also a problem, which is we can fix that up, but then we don't always know where those things are going. So a README for example, you might think it always starts at an H1, but if it's on GitHub, the repository title is the H1. And so the README should start at an H2, but that's not the case. For example, if you're looking at a README in like VS code, right? Because that's the H1. So it is actually impossible for us to know from a piece of user generated content until it's in the document where it should lie. In the heading structure, and maybe you can talk more about the history of this, but once upon a time there was this idea that documents would be able to outline themselves, but that kind of fell apart. I guess it seems like none of the browsers or it's too complicated to implement or something.
Brian Kardell: So I love the history of this. I mention it a lot, but this problem when you think about it is kind of obvious that you would run into this problem. So why did we even get to where we are with that being a problem? The story that I like to tell is that in the very first real thing that Tim Burns Lee sent about HTML to the mailing list, he set up to talk about HTML in 1991. He said, I would prefer instead of H1, H2, et cetera, for headings to have a nestable section element and a generic H, which at any level within the sections would produce the required level of heading. So this is a lot. We could also have had an ordered list which used actual numbers, but we didn't, right?
Eric Meyer: Just li(s). And you count on the user agent to do the counting for you.
Brian Kardell: And so if you nest them, it doesn't matter where you nest them because it will be taken care of for you. And so it seems like a very obvious kind of solution. And he said in it why we wound up that way Because Tim invented HTML in a lot the same way that Doug Crockford invented JSON, which is mostly he discovered and popularized it. There were a lot of documents at CERN that already used this DTD, it goes all the way back to SGML in the sixties. And unsurprisingly, the elements that were rarely popular are sort of the same ones you see in markdown or a rich text editor, just like bold, italic bullets, just these really simple semantics which are somehow about text itself. And then what happened is when we began using computers, we still were thinking about it like that and we processed them linearly like a document. And so we just thought like, okay, well there's the big heading that's H1, and then the slightly smaller heading is H2. So we wound up with this terrible thing. And then finally in HTML five, Ian Hickson thought, let's fix that. So created this thing called the document outline. And maybe Eric, can you sort of explain the…
Eric Meyer: I'm not sure that I can, I mean that's part of the problem, but it was my understanding is that it was more or less the same as what Tim was talking about originally, which was we'll just have sort of generic heading levels, or sorry, generic heading elements and the levels will be programmatically determined. So you could get back to that thing that Tim wanted to do.
Brian Kardell: So the rub here I guess is that there's not a mode switch or something where you could say this one works the new way and that one works the old way. And then there is always this what is its behavior and stuff. And so HX E'S proposal was that H1 basically is the H and that it will work a very particular way. The part that was really easy to implement about that was the user agent style sheet. So that was implemented in all the browsers. And so if you had a section and inside that you had an H1 and then inside that section you had another section and you had an H1 and inside that section you had another section, you had an H1, those headings would get progressively smaller. So people thought that it worked, but it didn't work because the actual semantics in terms of accessibility technology didn't change. So it never communicated itself as a H2 H3 basically. And it is actually this mixed problem and the fallback problem that made it really complicated to solve. And so in 2015, Steve Faulkner opened issue 83 in HTML, and I think that this topic has spawned more giga threads than any other topic in HT L history and burned more time than any topic in HTML history. But it's 83 was open in 2015 by Steve Faulkner that said, Hey, maybe we ought to admit that the document outline doesn't really exist. Maybe we should make a note that nobody has actually implemented it and it's sort of probably actively harmful if people think that it does. So maybe we should get rid of that.
Keith Cirkel: Because if the visible structure to a sighted user looks fine, but actually for a user using assistive technology, like a screen reader just gets heading level one announced for every heading, there is no heading structure. It's all level one. So it's very easy to lose your place in a document.
Brian Kardell: And this is very not straightforward even to come up with a plan and what are the implications and how bad are those implications because that's true, but also it's true that that would be the fallback behavior for people and it was deemed to be kind of okay. And the reason that it was deemed to be kind of okay is that basically what you get, what we think of is an outline, but most at doesn't have really an outline. What they have is more like the result of query selectors. So they have here are a collection of H2s and here are a collection of H1s and that kind of thing. So just being able to know that it is a heading is the most important part. And it is in part that way because today headings are screwed up and part of the reason that headings are screwed up everywhere is because well, very frequently you can't even know. And so anyway, we get many, many years. We did finally remove just in 2022, the document outline, and that was sort of like most of it, but there've been even more, there've been things like trying to remove most recently in Firefox, trying to remove the H1 styling experimentally to see if we can actually get rid of it. It's interesting because it's been stuck and it is tried to restart a number of times because there's a clear need. But what makes it really, really hard I think, is that everything has tried to solve this problem of how do you create the new thing and just make it work in documents that are the old thing. And it seems to me that is kind of the problem.
Eric Meyer: You Lost me there. Can you say that again?
Brian Kardell: Yeah. So when I say the old thing, there is no document structure. Even those at, they don't have a document structure necessarily as the main way of viewing a document. You know what I mean? There's parts of the structure that you can call out and jump to, but not necessarily an actual structure. And so you can have 12 divs deep H1 and then pop out of that back to the root and have H2. And that's completely fine in HTML.
Eric Meyer: Right? That will pass a validator.
Brian Kardell: That will pass a validator. And to most people, that's totally fine. That H1 doesn't matter how it's structured, it's the H1 that is in document order before the H2, and that's all that matters, right?
Keith Cirkel: There's also the issue that if you try and do automatic outlines and say your first section has three headings, so you've got an H1, an H2 and an H3 or you've got an H1 and two H2s, what does the next section do? And when you say out loud, it sounds simple, but what you're effectively doing is having to traverse the entire DOM to find the elements between the last section and the current section. And that could be thousands of nodes. I mean in theory that could be hundreds of thousands of nodes. It's like this depth first traversal problem where you kind of have to scan the whole document to find that layout. You could use advanced techniques like query selectors and stuff to try and help, but it's still a fairly complex problem to solve. And with every step of complexity in the browser becomes this area of more and more edge cases that people may run into. I dunno, I would say my general rule of thumb for web platform features as someone who doesn't often do a lot of this stuff, but it seems like the more complex, the harder it is to land, the more dissatisfied users are with it because they generally don't compose that well.
Brian Kardell: This is sort of what I mean about the sort of mixed mode because if we had headed it off at the pass in 1991 and said, okay, before we let this escape the laboratory, we have to fix this problem so that the only way that you get deeper headings is everything has to be structural. You need this section marker and H1 and that's all you have. Not H1, just H, sorry. Then it would be fairly trivial for the browser to keep track, I think because you only would, even if you had to calculate it on demand, you only have to walk to the root. At worst case, you have to walk to the root upward, and that's what every single CSS selector does. So we can do that. It's a short path. It's always a short path.
Keith Cirkel: That's where a solution is tenable is like if you can just walk up the tree, that's a viable option. The problem becomes, and even for simple documents, it's not the worst, but browsers need to think a lot about the pathological cases where what happens if you have a hundred thousand nodes or even 10,000 nodes or even a few hundred nodes, but you decide to mutate them a lot, how do you recalculate that if you're doing this depth traversal querying all heading elements and trying to walk backwards from there and restructure it, it gets very complex very quickly when you start talking about all of the edge cases, and that's where browsers live is all of the educators.
Eric Meyer: If you've ever looked at a spiderweb, it's all edges. And like you say, if you're changing the DOM a lot, if you have content that's dynamically changing and even structures that are dynamically changing, it becomes very difficult very quickly.
Keith Cirkel: We kind of have that in browsers and that's like CSS and CSS layout is incredibly complicated. We don't want to have another kind of CSS layout scale of problem on our hands with something like document structures. So I can see why with multiple heading levels and trying to apply those to sections, I can't see where it would work. And then the next problem is to get there, you have to break the web, and that is an untenable goal because we can't do that. We can't suddenly deprecate H2 to H6 and say, sorry everyone, you can't use these anymore.
Eric Meyer: But you have an intent to prototype of a possible solution.
Keith Cirkel: Yes. Yeah. So you opt in on any element by heading offset, so you add a heading offset to any kind of element, and if that element contains an H1 to an H6, then it will traverse up the tree, collect all of these heading offsets, accumulate them, and that then gets added to your H1 to H6. So if you had an H1 and its parent was heading offset one that becomes an H2, or if it has two heading offsets of one, one plus one plus one, that H1 then becomes an H3 and so on. So it's like an opt-in mechanism. It's still kind of preserves your H1 to H6 tags. And I think the key simplification is that it is just a traversal upwards in the tree. It just accumulates these attributes going up.
Eric Meyer: So in the GitHub case, when you're on the main page of a repository and it has a read me and the read me has an H1, you're going to wrap the read me with a heading offset of one, I assume.
Keith Cirkel: Yes, exactly.
Eric Meyer: Right. So whatever the heading levels are in that, read me. They get bumped down I guess by one.
Keith Cirkel: By one. Exactly. Yeah. So you as an author writing a read me, you'll use markdown heading level one, and that would be your read me starts at heading level one, and if we put it on github.com on a repository page, it will be wrapped in heading offset one, making that H1 and H2. And then on NPM or VS code, there'll be a different heading offset so that your H1 might be an H3 or an H4 depending on the context, which means that you don't need to think about it, you just continue to write H1s. And most people write H1s when they start their own piece of user generated content. And most people writing comments will start with an H1 unknowing that that is the incorrect document structure. There are quite a few people who are aware of the existing document structure in GitHub who will start their comments at H3. Those people will have to change their habits, I guess once we fix this issue. But we also have an extension, I'll have to find the link for it, but we have an extension that demonstrates this issue and it will style all of the headings on the page with a little marker saying what heading level they are respects things like aria level. And we use that internally to test accessibility of the page and document structures of the page. So when I look at GitHub, every heading has a little golden H1, H2, H3 next to it.
Brian Kardell: This is a really interesting thing because it gets to a thing I had in the notes that I wanted to point out that this is basically the opposite approach of the document outline in the sense that this is only about semantics, it is not about style, so the style won't change.
Keith Cirkel: So my plan beyond headingoffset, I dunno how viable all of this is, but as I understand it, these are all tenable. But my plan past heading Offset is to add a heading pseudo selector that will give you the computed heading level. So if you had an H1, but it's inside of a heading level start two, it will match a pseudo selector like colon heading level three because it's that two plus one. So you can in your own documents style them such that they match the heading levels that your existing style sheet expects. So you would just extend your style sheet to say right now it says H1 font weight size one or something in the future you might say H1 comma colon heading one and the role is size one or whatever.
Brian Kardell: Yeah. What I meant was that from the implementation point of view, you're focusing on not visuals. So there won't be at least in the short term a UA style sheet rule that changed that for you automatically.
Keith Cirkel: Right? Yeah. This only affects the 18 nodes in terms of the actual implementation. The way browsers work under the hood, as is my understanding at least, I'm still very new to all of this, but they have a separate accessibility tree and the accessibility nodes are in some ways simpler than HTML nodes. They're all of one kind of interface and stuff, but they expose a different set of properties. And so one of the properties that they expose is level, and that level is computed and literally inside of all of the browsers, there's just a switch statement that says if the HTML tag is H1, then the level is one. If it's H2, the level is two and so on. And there's a conditional clause above that that says if aria level is set, then the level is the aria level. So the code inside each of the browsers effectively says if aria level is set, then return that, but cap it to between one and nine, otherwise look at the tag name and there's a switch statement that says H1 return level one, H2, return level two, and so on. And so every accessibility node will have a level if it's a heading that relates to either aria level or the tag name. And so we just come in and say, well, if aria level's not set, just look up the tree, do a tree to reversal and look for all of these heading offsets and accumulate the level based on that. And so if it's an H1, the switch code becomes like rather than if H1 return one, it's if H1 return one plus whatever the accumulated result of this calculation is, and that's the only change so far. And so heading offset will only do that change, it will only change the accessibility tree, and then we can use other techniques like a colon heading selector or something to extract that data. But it is not going to change the tag name. It's not going to change style sheets. There'll be no built-in user agent style sheets, but there will be options hopefully to style it yourself.
Eric Meyer: It almost sounds like what you could use is an aria heading pseudo selector. I mean, I'd say that just because if the browser's already computing ARIA heading levels and this approach modifies the ARIA heading levels, just look at that. I Actually have a question. You said that Aria heading levels are capped from one to nine. That's three more than I'm used to.
Keith Cirkel: To. Yeah. Yeah. I actually have no idea why they go up to nine. Okay. I'm sorry. I don't have a better answer, but yeah.
Eric Meyer: Totally fine. So then with this heading offset, I presume that you can only offset things as far as level nine, and then everything sort of piles up at level nine.
Keith Cirkel: Okay. So I mean we're getting a little into the minutia, but I'm more than happy to do so, but —
Eric Meyer: Let's do it.
Keith Cirkel: Yeah. The way Aria level works is you can set Aria level one to nine. If you were to try and set Aria level 10, that would not work. Instead you would get an aria level of I believe two. Two, yes. Making perfect sense. Yeah. Yeah. This is one of those weird things with Aria. There's a load of history here and I don't know all of it. I'm kind of new to the scene, so I get to see the present day and go, why is any of this like this?
Eric Meyer: As so many of us do at some point or another? Why does it wait? And the answer is usually because that's what Mosaic did, but probably not in this case.
Keith Cirkel: No. Yeah. It's to clarify a little bit on, so if you're not using H1 or you're not using any of the headers, if you were to roll your own header, it doesn't matter what the tag name is, as long as it's a tag name that allows a roll of heading, and that's how you would create a heading is you would say roll equals heading, and that will expose that heading as a heading to the accessibility tree, this totally different tree aside from the DOM by default in Aria 1.0 and I think 1.1 that defaulted to a heading level of one. And then for some reason that, I don't know, it was either 1.1 or 1.2, aria one one or 1.2 changed it to B heading level two. So if you had a diviv roll heading and you didn't set RA level, it just defaults to two. I wonder if this is to do with some kind of idea around hearkening back to the document outlines and maybe there was an intent to H1 is the de-facto heading unit or something, I dunno. But that's where we stand at the moment. So if you have a role equals heading, it defaults to heading level two. If you set aria level, you can set it to the numbers 1, 2, 3, 4, 5, 6, 7, 8, 9. If you set it to a number 10, it will ignore aria level. And so it falls back to the role heading, which is the default of two. So yeah, it's not the best, I want to say it's not the best API, it's lumpy. It's a bit of a lumpy API.
Brian Kardell: Wanted to add really quickly to that. Every once in a while we get somebody like Scott O'Hara or Steve Faulkner or somebody who does a survey of checking this. And as of pretty recently, I think anything over six, you can't really trust it. It's not reliably exposed to at.
Keith Cirkel: That's the other big problem is that what browsers do and what assistive technologies do are two different things. And so a browser might tell the assistive APIs, this is a heading level nine, but that doesn't necessarily mean that JAWS or narrator or voiceover or any of these other assistive technologies are going to announce heading level nine. They might announce something different. And so there is a discrepancy. There's that kind of border between what you expect your HTML to do, what the browser will actually do, and then also what the assistive technologies will actually read out. And this is something that hopefully a tool like web platform tests can resolve on at least the browser side, although there's some additional complexities there because I don't think at the moment that computed level is exposed in such a way that web platform tests can test them.
Brian Kardell: Stay tuned for a future show on that.
Keith Cirkel: This is kind of one of the wonderful things about working on a project like this is making the change is kind of easy, but making the changes to make the change is where the real challenge is. And so we've prototyped this heading offset in Chrome and we have a patch and it kind of works fine, can't see any major issues with it, but now it's how do we get that into spec pros? How do we make the changes in the other browsers? How can we look at cross-platform testing for all of these things? And also ultimately when it's implemented, is this something that assistive technologies are going to use now because we're using the same APIs? Hopefully it is. I don't see a good reason why it wouldn't, but there is a potential challenge there as well. It's a huge cooperative task more than an engineering task, I think.
Eric Meyer: As most standards issues are. Yeah. Actually, I want to go back and clarify something just real quick. If you try to set a heading level of 10, it falls back to two because of the way that developed over time. At some point someone said, we're going to have all of the headings default to level one, and then that got changed to everything defaults to level two. And then with this, you can set from one to nine. If you go outside of that, rather than clamping to the nearest value, it just ignores it. And so you fall back to the fallback behavior and you get a two. So let's say I have an H6 and there are five offset levels above it, which would push it to an 11.
Keith Cirkel: So our intent is to clamp, so the maximum it will go is to nine. And it won't be surprising that if you end up in a combination that's greater than nine, then it clamps to nine.
Eric Meyer: So you won't suddenly have H2s appearing.
Keith Cirkel: Yeah, that seems like a failure mode. To me, that's like a bug, right? We don't want to go there. We want this thing to be intuitive. Ideally, people would test their document outlines, but reality is sometimes a little different. And so we need to make sure that we're giving people the best opportunity for success there.
Eric Meyer: And I mean, that's the thing, they can test their document outlines, but if it's a read me and they happen to get down to let's say H5 and then like you said on GitHub, that's okay because it's probably only going to push them one level and they'll get to six on NPM or wherever. It might get pushed three levels, and then you're getting up against that limit. That's kind of the thing by setting up the system to say, Hey, you don't have to really worry about the context anymore. If it goes somewhere else, then that's okay. It'll be handled for you. That does open that door. So yeah, like you say, you are designing it so that in this case it clamps rather than falls back, which is great.
Keith Cirkel: Right? Yeah, I think there was some commentary in the proposal issue. Oh, I should point out this started as a proposal by Muan who used to work for GitHub, A brilliant engineer Muan proposed this back in I think 2019 and it was originally headinglevelstart, and the name has changed a few times since then. There's been a lot of feedback on the issue, I think because there's different ideas. And at GitHub we have one very solid use case, which is this idea of we have markdown surfaces that contain user generated content and we just want to align those to the rest of the document, but we're in control of the rest of the document, and so we can properly structure that. I think throughout the issue, it became evident that there is this case of embedding other documents fairly ad hoc, I guess. So the most usable thing we could do is this kind of cumulative model. So it starts accumulating as you walk the tree, every heading offset adds up so that the whole document outline has this kind of accumulation.
Brian Kardell: There was a thing that I wanted to say very, very early when you were describing this initially, where when you talk about the user generated content, there is an aspect of that that's just very straightforward. It's like people who aren't from GitHub at all create content and goes up there, but then there's this other thing where you also said, well, we have people at GitHub who start with H3 or H2. They're doing that because they're trying to account and adjust. So even though technically GitHub owns the whole document and they can somehow coordinate, it's not easy to coordinate always. You have lots of different templates, lots of different layouts, and especially because the way that HTL works is, like I said, you can put that H1 12 levels deep and then somewhere else have your H2 and that's fine. That can really screw things up. And that's why we wind up with so many things that are messed up. And so I think in a sense GitHub has both use cases, just that one of them is more acute and there's no way to deal with this otherwise.
Keith Cirkel: Yeah, because especially, I mean, we could rewrite the user's markup for them, but one thing that makes that problematic is that's kind of confusing for users. But the other more serious problem is that it isn't just GitHub that we put readme's on. They're everywhere, right? They're in N pm. Other websites can use them. You can open them in VS code and you can preview them in VS code. And each of those comes with a different initial document outline. We can't just say every README starts a heading level three because it depends on where it is embedded into the document. A lot of the feedback in the issue was around this idea of embedding documents in other documents and how we can get a usable feature that kind of just works, that kind of does what you expect it to. And so you could have five embedded documents by quoting some other blog posts in your blog post or comment threads or something. And each of those needs to be additive so that you do get this structure and it walks the tree.
Eric Meyer: So I have a technical question. It might be two technical questions in one. So it's heading offset, you said, and that's expressed as just a integer?
Keith Cirkel: Yes. Yeah.
Eric Meyer: Can you do an offset of negative?
Keith Cirkel: One? You can't use negative numbers. So in the HTML spec, they have different ways of pausing attribute values, and the IDL reflection also is paused, so it's worth pointing out that it's not just heading level start as an attribute, but it's also a property on the element and that gets you like an integer back or a number JavaScript number back. But the IDL reflection is long and it is limited to non-negative numbers in spec pros, which is a really awkward way to say positive numbers.
Eric Meyer: Yeah, it's the way to say positive numbers and zero.
Keith Cirkel: I assume. And zero, yeah. Yeah.
Eric Meyer: Since every element will have a heading offset, the vast majority of them will have an offset of zero.
Keith Cirkel: Yeah, you could almost imagine every element today having an implicit heading offset of zero, and you can write that. You can have heading offset equals zero on every element if you so chose, I dunno why you would, but you're welcome to. And the IDL by default will return zero. So you can detect whether or not, I mean it will be helpful for feature detection, but it's also it will tell you zero if the attribute isn't present.
Eric Meyer: Right.
Brian Kardell: It's good that it's along so that when we make these adjustments, we can get heading level of a few billion.
Keith Cirkel: Yeah, yeah, exactly.
Eric Meyer: Absolutely.
Keith Cirkel: So you can't do negative numbers, but you can put a plus sign if you so chose. And so it was Jake Archibald who suggested we do Heading Level Plus as a micro syntax like plus one. But I think the way it shakes out is using a, along with all of the existing mechanics of HTML exist to make it easy to just do an IDL reflection of long, and if you want to put a plus in you can, but it doesn't mean anything.
Brian Kardell: Yeah, I believe that Jake's proposal was because the original thing was just heading level start, it was simpler. The original thing was simpler, or at least it read simpler. Maybe she had in mind the offset thing all along, but it seemed like it was like, well just start at this one. That's it. It's just really simple. Yeah.
Keith Cirkel: Mu-an's original proposal was very narrowly scoped to heading level start will be an absolute number. But I think from feedback from the issue, it was deemed that maybe the additive model is the best way to go. From my perspective, I'm not particularly opinionated either way, and the more complex one seems to be the additive model, and I would prefer to try that and see if there's a good reason why we shouldn't do that rather than starting with an absolute model and then being unable to change that at any time.
Brian Kardell: So what I love about the additive model is that it accommodates multiple use cases and a sort of an evolution path, I guess. So if you have some big complicated existing site today and you have this problem where it's like right here, I'm going to put some markdown, then it's pretty easy because you know the structure of the site and everything and you can say, ah, well heading offset three, perfect. You don't need to do anything that gets you pretty good. But there is that problem of we have these complex template assemblages and somewhere off in header fragment HTML, somebody decides that, oh yeah, should change this thing. That was a mistake. This should get rid of this H2 doesn't really belong there.
Keith Cirkel: Yeah, that's a really good point.
Brian Kardell: And now that number is not valid anymore, right?
Keith Cirkel: Yeah. You're not going to go and change all of the knockdown documents that you had to adjust their Heading structures just because you decided to remove a heading or add a new heading.
Brian Kardell: Exactly. So this is a good solution to just be able to do that and it's way better than it is today. But the problem of recomputing, all the things in the document is still there. You still have to babysit the document pretty carefully, and it's still prone to some troubles like that, but if you have a brand new document, you can make it use structural headings and then you'll never have that problem again.
Keith Cirkel: Yeah. And my hope beyond that is that we could reintroduce just the bare H element as an alias to H1 or maybe H zero, probably H1, but if we just had an H that people could outline their documents with, which obviously that was the original intent behind document outlines, but maybe coupled with this heading offset feature, maybe we could get there again.
Eric Meyer: Oh, interesting. So is your idea that anytime you use an H, it would implicitly cause a heading offset of one to the parent?
Keith Cirkel: I think it would just be an H1, but then you could structure your document using containers with the heading offsets appropriately so that your document is authored more around the series of containers rather than the headers, which I believe is the original intent of the document outline structure. So in the future, the distant future, when we all have the flying cars that we've finally been promised, we'll just be writing H tags. We won't be writing H1, and we'll have a heading offset attribute. Who knows? Maybe even we can make an implicit heading offset, have a new section element that has the implicit heading offset.
Eric Meyer: So you're doing this for GitHub, but I mean why does GitHub wants you to do this?
Keith Cirkel: I think a big part of this from GitHub's perspective is we want to make GitHub an accessible home for developers, and we want it to be the most accessible home for developers on the internet. We have an accessibility commitment, you can read more about it and accessibility.github.com. We are interested in making sure that it is the best that it can be. This is a small part of many larger parts that we're doing to make sure that GitHub is as accessible it can be.
Brian Kardell: Okay, so you have this problem. I assume that it's one of 80 bajillion problems that every engineering team is thrown how solve this impossible problem and you have a backlog of impossible problems. What was the thing that led to this one getting picked up? Who stood up and said, this is the thing that we need to do or whatever?
Keith Cirkel: So every quarter at GitHub, we have a hack week, and in that hack week we can kind of pick our own projects to work on. At the end of the last quarter, we wrote our proposals down and they don't need to get approved or anything, but we just kind of do that to solicit other GitHub employees. And so I mentioned this as something that Moan was pushing for a while, and then Clay Miller, who is an accessibility engineer on GitHub, was interested in this issue as well. I mean, Clay's been great. Clay's done most of the implementation work. He's built out a polyfill for the current iteration using this heading Offset and so forth.
Brian Kardell: Oh, that's awesome work. Can we get that? Yeah, I want it. Yeah.
Keith Cirkel: I'll drop a link in the notes, I guess. Okay.
Eric Meyer: Yeah. As a matter of fact, I could literally use that on my personal website where I had to write an entire WordPress plugin just to try to start to do this.
Brian Kardell: Same. Yeah, I remove a whole bunch of code from my website. Yeah.
Keith Cirkel: Awesome. He'll be very happy to know that. So I've got a little bit of experience doing some of this stuff. I mean, I helped out with Custom State set and a few other things, and I'm really interested in evolving the web platform. I think it's a really a super useful part of our tool set that we maybe take a little bit for granted, and I do think it needs more funding, and I do think a lot of these issues, I think just need a little bit of energy put into them. There are so many issues on the like what wig, h, tm, L repository, so many issues that engineers face with browsers every day. But I think that there's a little bit of a jump to get over, which is that you can fix those issues. All of these browsers are open source. There's fantastic companies like Alia who are there to resolve issues to help push proposals. I think more companies should be doing this kind of stuff.
Brian Kardell: Yeah. I wanted to say one thing in closing, which is to give GitHub some props for doing that work upstream and actually working on proposing the standard. And because you could easily have stopped at a polyfill, right? Because the polyfill will solve your immediate need. Obviously, it's better if you can get rid of that code and not do it in JavaScript and all that kind of stuff. But realistically, many, many companies do not push the work upstream and make the situation better for everyone. So props to you and to GitHub for taking that up because you're absolutely right. I have written a bunch of pieces about this, but there's one on my blog that's beyond browser vendors that talks about exactly this. And actually Eric gave a great talk about this as well. There are just a million issues that are out there waiting for attention, and that's also why they don't get attention because just this overwhelming pile of stuff. And you have to really choose what you pay attention to. And so when somebody comes along seriously and they bring with them some ability to do spec work and implementation work, suddenly other people say, well, maybe we should pay attention to that one because we might able to get it to go somewhere. And I think you're right. Just a little bit of energy really helps.
Keith Cirkel: Yeah.
Eric Meyer: Yeah. Massive kudos. Or as some of my Brit friends say, Q-DOS to GitHub for supporting this, right? Your time is not free to them. The work that you do on this is work that you are not maybe doing on something else. And yes, it helps GitHub, but GitHub is also supporting this work. They are meaningfully financially giving this support, and so that's great. More companies should do that, but it's really great that GitHub is doing that, and it's awesome that you are taking advantage of that in order to push this forward, to make the web better for everybody and not just for GitHub and its users.
Brian Kardell: As far as implementations and other browsers you asked, how do we get them? Give us a call.
Keith Cirkel: For GitHub. GitHub is the home for all developers, and that doesn't just stop at building our own stuff. We want to make the developer industry better as a whole, and that means working out in the open on open source, contributing to open source, contributing to web platform, the whole lot.
Eric Meyer: Hear, hear. And amen.
Brian Kardell: Thanks for coming on, Keith. It was a great talk.
Keith Cirkel: Thank you. Really appreciate it.
Eric Meyer: Thanks a lot. Is there any place people can find you on the internet?
Keith Cirkel: I'm around. You should check out Moan who originally wrote the proposal, who is on the internet as M-U-A-N on all the various socials. Clay Miller's been doing excellent work on the prototype and he's on the internet as smockle, S-M-O-C-K-L-E. I'm on the internet as Keithamus, K-E-I-T-H-A-M-U-S. But yeah, you should follow those folks because they're the real heroes in all of this. I'm just the front man.
Brian Kardell: GitHub is on the internet as GitHub.
Keith Cirkel: G-I-T-H-U-B is a capital H. That is the one thing that has been instilled into me over the time is that it is indeed a capital H.
Eric Meyer: Capital G. Capital H. Got It. Yes. Alright, Thanks Keith.
Brian Kardell
Eric Meyer
Keith Cirkel