668: Jake Archibald on Native HTML Includes  ## Metadata - Author: [[ShopTalk]] - Full Title: 668: Jake Archibald on Native HTML Includes - Category: #podcasts - URL: https://share.snipd.com/episode/70cce4da-6639-4605-a1de-70d1e0d57ac1 ## Document Notes ## Highlights - **HTML Can't Import Itself** - HTML cannot import itself like CSS and JavaScript can. - Iframes and object tags can embed content but don't behave as inclusive HTML imports. Transcript: Chris Coyier Because I am genuinely curious about the answer to this. I've wondered about this pretty much my entire career, and I'll do the setup for it in this way. CSS is a language that can import itself. Use the import keyword, and then you can have two CSS files, and they smash together as far as the browser is concerned. Or maybe it treats them as separate files, but you link up one of them, and you get two of them. JavaScript can do the same thing, perhaps only somewhat recently, with ESM, I guess, you know, within the import keyword. JavaScript is a language that can import itself. Can HTML import itself? No, it cannot. It can import images. It can import other languages. But there is no such thing as in what I'll call and we'll probably call for the rest of this episode an html include they don't exist it's not a thing that can happen is that true jake it's Jake Archibald True that is true yeah no it's it's it is not a feature that exists i mean yeah okay someone's going to be saying uh iframes are a thing but like yeah so that is the object tag could do that The object tag yeah okay when people say the object tag can do it, like there's no difference between the object tag and an iframe. Like in terms of this, in terms of document inclusion. Yeah, it is... Chris Coyier I mean, like just to be real specific about it, it does put that HTML on that page, but it really is like, it has like a brick wall around it. It's not the same thing. The CSS cannot like penetrate through that wall. It's intrinsic sizing doesn't grow with the content inside it and stuff. It's really just not a possible scenario here. ([Time 0:00:59](https://share.snipd.com/snip/97f0f146-5159-4289-b33c-31e27e59f63e)) - **Limits of Responsive Iframes Proposal** - Responsive iframes proposal allows height adjustment only once at load event. - It does not solve dynamic content resizing like form validation layout changes. Transcript: Jake Archibald And so so this is um are these there was a proposal a while ago called seamless iframes, where you put the seamless attribute on the iframe, and then it kind of grows for the content. Chris Coyier Would suck up some CSS or something? Jake Archibald It wouldn't do any of the CSS, but it wouldn't be a fixed size the way iframes are. It would just be as if you'd kind of inserted the content in, you know, you wouldn't get the CSS passing through, but it would just do height anyway. Chris Coyier Yeah, basically height. That's, that's fine. Remember, I, you know, one of my first startup jobs was at Wufu and it was a big deal for the business to iframe the form on another third-party iframe, essentially. But there's things that could go wrong. It would set the height. It would do its best to set their height at first. But then if you clicked a button and it had like a form validation problem or something and we wanted to put a big red box on the screen, well, guess what? The height of the iframe has changed. And it was really like early days for trying how in the hell are we going to tell the parent page to please increase the height of this iframe now that the the height is in it you know it ended Up being doable with post message and and complicated crap like that but yeah it's a classic problem the iframe does not do that so i'm interested to hear like how you feel about this this Jake Archibald Chrome proposal then so the way it works is you you need like you the embedding page opts into this behavior it's fire an attribute i think um or some css whatever and then the page that Is being embedded needs to have a meta tag that says it's allowed to be embedded in this special growing way. Now, what you get then is, yes, the iframe will adapt, will sort of become the height of the content. But here's the thing. It only does it once. It does it at the load event of the inner document. So it doesn't solve the woofoo problem, we'll call it. ([Time 0:03:00](https://share.snipd.com/snip/6955463c-608a-4faf-801f-e3f85b386b60)) - **Demand for Native HTML Includes** - Developers want HTML includes to avoid repetition of common elements. - Current solutions use tooling or repeats, but a native approach could improve developer experience. Transcript: Chris Coyier They power lots of stuff. But so another way to frame this then is, you know, I started out saying CSS can import itself, JavaScript can import itself, HTML cannot import itself. Why would you want to it? Well, the situation I always set up is this classic like, you know, it's week two of your front end web development class and you're making a three page website with a contact page, about Page and homepage. And all three of them have the same header and footer. What do you do on those three pages? It's unclear. The answer is you either repeat yourself or you reach for tooling. And both of those are kind of like, they're not the end of the world. It's not like a disaster that you would have to do either of those two things, but it's just funny. Like the web platform has always been, we use that term, pave the cow paths. What are developers doing? Can we solve it for them in a better way than what they're doing now? Like, can we prevent them from having to reach for a tool? Can we step in here and do something about that? It seems like, it almost feels like low hanging fruit a little bit like could we do this why am i just wrong is it not really a need or like or what i guess i'll pass it to you jake then to be like Jake Archibald What's going on here yeah i mean people absolutely want this right there's this we've seen your article as lots of people on github and on other social media saying like yes this is a feature We want so there's absolutely a desire for it so i thought what we could do is like talk about because i don't think everyone agrees on how this feature should behave so i thought like you Know the three of us could figure it out and then we can kind of have a look at what the the problems are what's kind of where where are the kind of complexities that people might not have Thought of so i guess one way that this could work is that like you've got this like like an include ([Time 0:08:40](https://share.snipd.com/snip/0411a008-8e04-45ce-bc58-636f0dbb6ee6)) - **Parser Blocking and Complete Trees** - HTML include tags would likely be parser blocking to avoid layout shifts. - Complete HTML trees should be required in includes to prevent parsing errors. Transcript: Chris Coyier What would we call that? Render blocking tags? It's partial blocking. Okay. And that's pretty low level. Jake Archibald That's even worse than render blocking because it's earlier. Exactly. So if you've got something that render blocks um like css does then in the background it can still make the browser can still be parsing the page it can start loading other things that It finds now browsers have a workaround for this in that they all have these kind of like token parsers pre-parsers whatever you want to call it where it although it's not parsing the Document and putting it, you know, putting the elements in the page, it will discover, this looks kind of like an image tag. This kind of looks like a link tag. This kind of looks like a script tag. I'll start fetching those because I'm probably going to need them when we resume. And that might not always be true because that document.write could obliterate it. Yeah. Well, it could start an html comment yeah and then all those things are gone it could open a template tag which means those things shouldn't load yet like but you know browsers have had Chris Coyier To yeah unfortunately had to solve this but it's still gotta imagine a theoretical future where document.write doesn't exist how happy that's where I'm going. Dave Rupert Why don't – let's kill the Batman. Chris Coyier Let's – if he's the problem, let's kill him. That's maybe a tangent. But isn't it theoretical that this is parser blocking at all? We just implied that as a constraint, right? We said this could be parser blocking. Jake Archibald Could you make the choice that it's not parser blocking? So if it wasn't parser blocking by default, then I think we'd be creating a feature that is just going to be layout shifts everywhere for all of the web, right? Because you're going to have different parts. So it would start to render, then it would get the HTML, then it would inject the HTML. Chris Coyier It's a little bit like fetching and injecting content, like an ad, and then gross. And not only gross, but I think we've learned over the past three years, thanks to, what do they call them, core vitals or whatever, that layout shifting is actually kind of a penalty For your metrics. I mean, every user knew it. Jake Archibald We just didn't really have a good name for it. Like that thing of where you start reading a thing and it moves around or you try to click a thing and it moves around. Like no one likes that. So it's good that Core Web Vitals are highlighting. Chris Coyier That would never get through then, right? There's no way a proposal for include would get through where it was not parser blocking. And thus, it wouldn't even sometimes happen. It would just always happen within clues. Jake Archibald Yeah, unless you are, you know, creating a fixed-size container with, like, scrolling and all that. But that's not... Oh, I see. Basically, CSS choices might prevent it, yeah. But I can imagine a solution where you put the async attribute on it and you get this version of it. ([Time 0:11:50](https://share.snipd.com/snip/bac0cba3-a43a-4c9a-b87d-7bc8a76cf693)) - **Security Implications of HTML Includes** - Security concerns include script execution when an include points to malicious content. - Opt-in mechanisms like meta tags might be necessary to handle security risks. Transcript: Jake Archibald That's one thing. Security is obvious. Yeah. But I've, yeah, I have something I, I've said in the past about this is like, you can commit a hate crime just using text. So like, what, what are we trying to protect people from here? I i think the the right way to think about it is you don't want to create a system that helps people do the wrong thing unintentionally and i think that's that's the bar so so if you um i got A little annoyed at a css feature that was uh was view transition name auto. And I didn't, and I found that there was a lot of complex behavior hidden behind that auto and a lot of things that could bite the developer that they wouldn't realize is there until it Was breaking in production. And so I think that's, that's the class of problem we want to, to, to avoid. So, so yes, if you know, if we release this feature but it's got these like hidden gotchas then i think that's problematic if people want to knowingly do the wrong thing then like the not Parser blocking by default would be one of those yeah but exactly the only one because that might you know on a local machine load so fast that they don't see the layout shifts and then Chris Coyier And that's like... So the layout shift sucks. We know that. And then... So let's say we make a parser blocking by default. That also has a negative implication of a little performance hit. So with all the people that chimed in that says, just let tooling do this, just let your eleventy thing smash the two pieces of HTML together before it ever goes out. Yeah, that's great. Like, you probably can't beat that at a web platform level, right? Jake Archibald But your argument that you made before stands like, like JavaScript has imports, and that was introduced relatively recently, and that creates this potential for waterfalls. Like, you know, it requests a thing to then discover it needs to request another thing. That means it needs to request another thing. Dave Rupert Times 10,000, yes. Sure. Jake Archibald We added to this problem in JavaScript land. And the advice is like, yeah, you can get around it using a bundler. So we could just say something per HTML. Right, all right. Yeah. Chris Coyier Very few people are anti-ESM, you know. Okay, yeah. So we're just moving the same, I don't want to call it a problem, but situation over to HTML. Yeah. Fair enough. I like that. Hmm. What about, can we go into the niche of the, like, can one of those imports import another thing? Is that a foregone conclusion that we allow that it feels like it should but i i mean it would be easy in me to or something to say you couldn't but it seems fine right like it i bring it up only Jake Archibald Because people are like well what if it imports itself ah gotcha i frames you can do this like this is already a problem right yeah yeah right cyclical whatever yeah i frames just has a It has some sort of limit applied to it but whereas with this new thing we could just say cyclical is not allowed right yeah if if accordion.html imports accordion.html continue like It's not continue semicolon yeah and if people want to give it a different query string to work around that then fine again like they're deliberately doing that that's okay okay so so Chris Coyier Far we're really scoping out this feature we got we're going to make it parser blocking by default we're going to allow it to import multiple things and we're going to require complete Jake Archibald Trees so we've scoped out the feature a little bit is there more to scope out the stuff around security and stuff around like adoption issues i think i think this features as we've described It is well it can't be third party right it would be relative urls only well you could say it's third party as long as it as long as cause you would absolutely have to pass a cause check um Okay and content type check and that kind of thing but okay put it this way you can already fetch some content as text from another website and then enter html into your page right and that But that has to go for cause so we're not you know we're not changing course okay yep wow check wow we're making a lot of progress here this is this is it like yeah this is good is there other Security problems is that on your list here okay it is it is so i think there will be systems out there there are definitely systems out there like old forums and stuff, which let people Put HTML in their posts, but they go, well, you're not allowed to do script because that would be, you know, that would allow you to hack the site. So no script, but you can kind of do, you know, none of this, none of this other thing. Chris Coyier Comment section of a WordPress site would be an example. You know, like you can, they have a white list of tags, you know, strong is allowed, script is not. But you're saying this white list or this blacklist is of one tag. Yes. Jake Archibald Well, so if it's, if it's an allow list, it's kind of fine. We're okay, but there will be things out there which operate on a block list, which means we've got a new, we're adding a new include tag. And that include tag can suddenly execute scripts because it can point at a thing which has a script tag. Chris Coyier I feel like your GitHub profiles existed before the details element went out. And then all of a sudden we got details and the people are like, check it out. My GitHub profile can have details on it now. Not because GitHub allowed it. Jake Archibald It's because HTML allowed it. I hope they deliberately allowed it, but I don't know for sure. I mean, who knows? Who knows? I got a bug bounty once for like some unescaped HTML in GitHub. I don't find security issues very often. That was one I did. Okay. Chris Coyier So a security issue is there's blacklists on who knows how much software in the world. And now all of a sudden they support this new include tag. Jake Archibald What could go wrong? What's the problem well it's it's just another way to execute script because you know it's you just you're pointing at something else you're injecting content yeah yeah and script It's just it's going to run on the same origin there's there's your problem i think one way you could get around this is if the instead of an include tag have a script tag with type document Include. ([Time 0:20:10](https://share.snipd.com/snip/48d3a06b-df66-47b8-bed2-f8fafad92a4b)) - **Adoption Issues and Polyfills** - HTML includes will be a bad experience in older browsers until fully supported. - Polyfills exist, but some services like LLM crawlers won't run JavaScript, limiting their utility. Transcript: Jake Archibald Hard to get the parser blocking thing. But sure, right, this stuff is doable. I think a bigger problem here is going to be other crawlers, like search engines and LLMs. LLM crawlers are dumb. They don't run a page with JavaScript. So if you're a client-rendered page, the LLMs aren't seeing it right now. So it was a guy, Sam Rose on Blue Sky, was saying he wants this feature because it would allow him to remove a load of the repetition in his head tag. So all of that kind of meta stuff, just social media includes. Social media includes. They're never going to process this. If this arrives in all browsers, Twitter or Excel or Facebook, they're not going to crawl those includes for the metasocial image and all that kind of thing. Dave Rupert If they found some value in it. That would make it maybe a unique tag in that it could be used in the head and in the body. Like that's maybe kind of a unique, if we were making this in HTML. The link element can be. Yeah, I guess so. Yeah, just kind of that level. Script, link, it's like that level of a primitive kind of. Yeah, of course. Style. Yeah. So yeah, so rollout is going to be rough. Chris Coyier You know, like nobody's going to use it until it's very well supported, probably, because it would be rough. Except for that it's kind of like polyfillable, so maybe. Jake Archibald Yeah, but it's not polyfillable in a way that these social media services and LLM scrapers and all that sort of stuff are going to understand. Maybe people would see the lack of LLM scraping as a benefit. I see, because it's polyfillable through JavaScript, which they don't run. ([Time 0:30:33](https://share.snipd.com/snip/6474e360-1294-479d-9bdb-b500d5e81ca7)) - **Streaming HTML Content as First Step** - Streaming HTML content fetch is the easier, more feasible first step. - This approach could improve performance and behave closer to native parsing than innerHTML injection. Transcript: Jake Archibald Because i feel like it's worth going there let's okay so there's two two arguments this is like is this feature that we're describing now better than the status quo or not and i think the Reason it keeps getting blocked in standards land is because they see it as a real drag on the status quo, like a real step down from the status quo. So the status quo being do it on the server. Right. And they're not wrong. A lot of the serverless hosts don't have some kind of basic include system. Because would we be even talking about this if GitHub Pages and Netlify and all of this supported like the old Apache style SSIs? Would this just be a non-topic? Yeah, if all servers had like Apache server side. Chris Coyier I've like counted them in the past. There are so different technologies that solve this issue it's it's absolutely unbelievable to me right down to the the fact that your web old web servers could do it is just weird to Dave Rupert Me like that's one of the weirder solutions to it like you let apache do it oh my. I, there's also like this. I don't like the answer of like, well, it works. I'm, I just use bun powered by zig to stitch up my page. And it's great. You know, like I don't like that. Cause again, it's like the, the education angle, like we should be able to use HTML to write HTML. We shouldn't have to like jump to another language. Oh, cool. You like getting your feet wet in HTML. Psych. You have to learn PHP has all these security issues. It sucks. Like, you know, it's fine. Don't stop. I heard a thousand Lambos coming at me, but it's the PHP is fine. When we're immediately pushing learners off to this whole other complex system, the second they want to automate copy-pasting, right? Jake Archibald Yeah, I think so. But this is why folks haven't wanted to add it, is because it's slower than what we have now. Unless you flip the question to saying what we have now is people calling fetch, getting a load of text, and then putting it in inner HTML. And I had this example I used to use in performance talks where I was on GitHub and I clicked the link to an issue. And while that was happening, I would open another browser window, copy the URL and paste it into the new window. And I would get content in that new window. Even though I started it later, I would get content in that new window quicker. And it was because of streaming. The way GitHub worked at the time still kind of works. You click the link, it goes and fetches all the content. And then once it's got all the content, it displays it. And this was a crazy long thread. And I was on airport Wi-Fi at the time, so everything was really slow. And it was faster for me to trigger a full page reload. And that content was, all it needed to do was just, as it was downloading the HTML, it was able to render it. Dave Rupert Probably hitting the Ruby endpoint with that streams in HTML response versus hit a JavaScript and then get all the JavaScript that that page needs to load, then paint the page, right? Assemble and paint. Exactly that. Jake Archibald So I think one of the things that we could do that I think standards people will be very happy with or not object is can that part of the problem be solved first? Like, can we create a slightly higher level than it is right now way of you call fetch, you get your response, and then you say, I want to stream this into this element. Start parsing this response as HTML and start putting it in this element. And I think that's also an opportunity to... InnerHTML does a bunch of stuff differently. It doesn't execute scripts that point to other URLs, that kind of thing. And I think this would also be a point of like, let's remove that weirdness. Let's make it behave as close as possible to just normally parsed markup. ([Time 0:34:10](https://share.snipd.com/snip/0cdd9ab1-ee41-4d64-b9b4-64b308de0e16)) - **GitHub Streaming Demo Anecdote** - Jake described a slow-loading GitHub issue page that rendered faster when fully reloaded due to streaming HTML. - This showed how streaming content improves perceived load times. Transcript: Jake Archibald And while that was happening, I would open another browser window, copy the URL and paste it into the new window. And I would get content in that new window. Even though I started it later, I would get content in that new window quicker. And it was because of streaming. The way GitHub worked at the time still kind of works. You click the link, it goes and fetches all the content. And then once it's got all the content, it displays it. And this was a crazy long thread. And I was on airport Wi-Fi at the time, so everything was really slow. And it was faster for me to trigger a full page reload. And that content was, all it needed to do was just, as it was downloading the HTML, it was able to render it. ([Time 0:36:38](https://share.snipd.com/snip/a13a75e2-871e-4d0a-a87f-c236d6de5d92)) - **Difference From Deprecated HTML Imports** - HTML imports were for packaging web components with templates, CSS, and JS but never rendered directly. - The discussed HTML includes proposal is fundamentally different and focuses on content inclusion. Transcript: Jake Archibald From that solution? Do you feel like? So we could have, because you can import JSON now in type assertions. With type assertions. And I'm kind of okay about that like it's not it's not changing my life like because it saves like three lines of code but cool exactly and if you're importing jason from somewhere else You want to deal with failure so you don't want to use a static import anyway because that that one external json fails brings down your entire app no thank you so you would you would be Using a dynamic import but that has a sort of side effect of like once it's imported it's imported forever it becomes part of the module graph if something else tries to import it again It just gets the response back that it already has which often isn't isn't you want to do with an external API. Dave Rupert So, yeah, when it comes to important dates, I'm like, data.json. Jake Archibald Yeah, change the query string, whatever. Yeah. So I'm kind of like, yeah, I'm glad we've got it because it's nice because it's something you can do in bundler tools. And it's nice to kind of have a web standard way of doing it. But it's not changing my life. That's funny. We use Apollo at work to do GraphQL requests. Chris Coyier And there's like a way in a GraphQL request that you can do a signify. Because if you run the same query again later in the app, it uses the cache that it already has, which is a benefit. That's kind of one of the biggest reasons to even use a tool like that. But you can, in a query, say network only. So when it hits that one, it won't use the cache. It will go to the network. I wonder if we need type assertions with network assertions. Redo it. Jake Archibald I think then it's kind of just so different to the, like how the module graph system works. So,'d be as you say it's so easy to just do that and use a land like you can because you can store the dates that you received the last thing and you can use that to decide if you go to the cache Or not and blah blah right like it's it's yeah but we could have an import that imports a document um but in the same way it's kind of like i don't know how this is different to um like xml http Requests you know getting a document i don't i don't think it solves any problems that we have like you you can fetch text and then put it into a xml parser you know there's apis for that Html parser and you can get a document out the other side and there are ways of doing that in a streaming way um they're kind of hacky but there are ways of doing it um so yeah i i think esm imports Dave Rupert Don't give us something to solve this problem um i'll say the the like css assertion type, which can then be an adopted style sheet. That's kind of cool. That's kind of not fully here yet, if I'm remembering correctly. There's also talk of HTML modules where I could write a template and import that into my React component and make that better, or my web component or whatever. That is also attractive to me. But again, I don't know the motion on those. But like in doing it in JavaScript is fine, but it gets us sort of away from this declarative idea of like using HTML to write HTML, right? Like that's not what I want. So this kind of proposal we've outlined, like, is it different than HTML imports? Like, we just didn't use a template tag, and so they're super different. What's different, you know? Jake Archibald So HTML imports were never, they never rendered. They were definition files, essentially. So they contained a, it was almost like a sort of package that contained a template, some CSS, and some JavaScript to define that web component. Chris Coyier Some sort of single file component. Right. So you didn't have to call.define element. It was implied that you did that. Jake Archibald So yeah, it's sort of a different thing. It didn't stream. I think we did the right thing by not, well, by unshipping that in terms of Chrome, but in terms of Firefox and Safari, like not shipping that. Some for the better, some for the worse. But I don't know. It was a slightly ugly part of the standards process that other browsers came to that so late and then wanted changes. But I think things ended up in a better shape in the end. Chris Coyier And I still think some of that stuff should... What about now, though? What if it came back? You don't think anything's fundamentally changed? It's still a bad idea? ([Time 0:46:30](https://share.snipd.com/snip/2d725ed3-adf9-406a-969a-34eac207d733)) - **Web Components and JavaScript Dependence** - Web components often require JavaScript even for simple visual elements. - Declarative shadow DOMs can help reduce JavaScript reliance but still have limitations. Transcript: Chris Coyier Is just like a card. It's a really nicely designed card element, and I call it my-card. And all it does is shadow DOM up a really nice looking card thing. There's no JavaScript at all. It's not necessary. That's not what this web component does. Isn't that feel stupid that I have to script that up for it to work at all that it would be nice if my cool little card component which is only job is to make a isolated thing look nice involves Javascript at all it would just be nice to not even involve it I think so although as soon as you start getting into like we've got declarative shadow dom now like you can create shadow Jake Archibald Dom without javascript um but right now you need to put that shadow dom inside every instance of the components yeah it's a little repetitive but hey that's what you that's that's okay To me because it makes sense somehow yeah i don't know but i think the bit where it starts to like make sense is that the shadow dom that you would have can be different per component instance, And often is. If you make a grid component, then depending on the attributes on that element will affect what shadow DOM is rendered in order to represent that number of columns, that number of rows. So I think being able to make web components that don't have don't require javascript we already got it with with the shadow dom thing well yeah kind of well or more that it's it's like You could literally do it for the simplest of cases but as soon as you hit that case where you need a different shadow structure depending on the when you then like we need an if statement We need an if tag we need a like you start you know creating conditional logic in html which maybe we'll have one day but like that's that's the reason we don't just have that yet but i do Think there is a i think of components as two separate types of thing um there is like an interactive component and then there's another thing which i refer to as html macro which yeah It's just like input in and it will generate some html as a result which i think chris is like the thing you're more referring to um and the nice thing in terms of server rendering the frameworks Do both pretty well, whereas web components don't do the HTML macro thing so well. ([Time 0:53:00](https://share.snipd.com/snip/9de9eaf4-9d06-4a50-9c4b-a91f5dd2f6f8)) - **Scoped CSS Without Shadow DOM** - CSS at-scope allows style blocks scoped to parent elements, enabling scoped styling without Shadow DOM complexity. - Duplicate style blocks could be optimized with constructible style sheets and reuse techniques. Transcript: Chris Coyier But we've shipped now at scope in CSS. Yeah. Dave Rupert Oh, that's some nice scoping you got there. Chris Coyier This was very fascinating to me that you can put it like an angle bracket script, or I'm sorry, style tag just in the DOM arbitrarily, you know, just put it wherever. And then if you do that, the at scope thing in CSS, that scope, you don't have to put any parentheses or after, and where's normally where you'd explain it is the scope just becomes whatever The parent element is oh do you know i didn't know that that's neat it is neat because it's that is as close as the web platform has ever gotten to selector scoping because otherwise scope Doesn't help with that so now you have the style block that's just it the styles as long as you put it in an at scope thing apply to only just that parent it will not leak outside of it but i Was like well that it's it's it has the same vibes as that declarative shadow dom stuff to me so like well then you use a hundred cards on the component each one of those hundred cards has Its own style block if that's how you want to roll but it is kind of like almost like tooling free sc, which I've never seen before. So I'm kind of into it, but how much? How painful is it to have 100 identical style blocks versus one CSS thing? How bad is that? I don't know how to test it. Jake Archibald It's not great. The CSS constructible style sheets are made to avoid that issue. So there is actually one of the big problems with declarative shadow DOM. You could put a link tag that has an href, but then that's forcing you to have a separate. Exactly. There is a Microsoft proposal, and I can dig out the link, we can put it in show notes or whatever, that they are looking at a way of inside your declarative shadow DOM to say, use this other Script tag that's already on the page. Oh, that rule. It's URL. Yeah. So it'll avoid that duplication at both a text and parsing level, which is really, really nice. ([Time 0:55:53](https://share.snipd.com/snip/a1aa13bf-c797-4208-9171-d832a8680a9a)) - **Include Element Should Be Parser Blocking** - The default for a new HTML include element should be parser blocking to prevent layout shifts. - Streaming included content should start immediately upon receiving it to improve performance. Transcript: Chris Coyier So you're welcome. And let's go. Did we solve the streaming one like would you say i want this to be parser blocking and i want it and i'm okay with no which means it won't we were saying parser blocking could be an opt-in Jake Archibald No i think i think parser blocking would have to be the default else it would else you get the layout shifting but parser blocking and it streams the alternative to parser blocking is Doing some kind of clever render blocking where it won't render. It can continue to parse, but it doesn't render the new elements. But that would be a new concept. But yes, it would need to visually halt. It can do work in the background, but it needs to visually halt. But yes, I think as soon as it starts receiving content from the include URL, it should stream. And that's like stream. That's that should be the selling point or anything. That's just how it should do it. Yeah. Yeah. Because that would be the thing that's better than the almost all of the hand-rolled solutions. Yeah. Dave Rupert I'm so like, let's see. Chris Coyier It seems like we, you know, the upsides are better than the downsides. Jake Archibald I do think the path to this is to do the low-level streaming part and then introduce the element. There's two battles. There's the initial battle of the JavaScript API, which I don't think is going to be much of a battle. Last time I spoke to browser people, they were all sort of keen on it. They just needed someone to do the work. It wasn't high priority for them. The bigger battle would be the special element for it but once you've got the building blocks it's a it's an easier proposition ([Time 0:58:20](https://share.snipd.com/snip/4b847e7e-a316-449d-b1d8-1d1cc636b5bb))