Artifacts Gallery Guilds Search Wiki Login Register

Welcome, Guest. Please login or register. - Thinking of joining?
June 03, 2026 - @581.42 (what is this?)
Activity rating: Four Stars Posts & Arts: 73/1k.beats Random | Recent Posts | Guild Recents
News: :cry: Are u having fun? Guild Events: Happy Pride Month Fibre Artists!

+  MelonLand Forum
|-+  Life & The Web
| |-+  ✁ ∙ Web Crafting
| | |-+  Help me propose a new HTML element


« previous next »
Pages: [1] Print Embed
Author Topic: Help me propose a new HTML element  (Read 130 times)
IndigoGolem
Sr. Member ⚓︎
****
View Profile


What's personal text?
⛺︎ My Room

Artifacts:
Joined 2025!
« on: May 22, 2026 @817.40 » Embed

Some months ago i had an idea for an element a kind of like iframes. I know that sounds bad, but hear me out.

Many sites have the same information on every page, like a navigation bar or footer. The ways to do this, as i understand it, are to use Javascript (breaks if users disable JS), user Server-Side Includes (not available in Neocities, i don't know how hard it is to set up), use frames, or manually copy it into every page (makes updating and maintaining more tedious).

An easier way to do this could be the element i'm proposing, which i'll call a <stamp>. It's like a frame but lighter and simpler. Instead of embedding a whole page, it embeds just a section of plain text or HTML.

Stamps are kind of like external CSS. If you decide one day that all your headers should use a new font, you can just change that in your CSS file instead of editing every header. If you decide one day that you don't like the wording of a footer on every page, you can edit a single footer file that every page loads instead of editing every page individually.

Maybe that looks like:
Code
<p>All code ©20XX Bob Webman. <a mailto="bob@example.com">bob@example.com</a></p>
and that line sits in its own file footer.html, while pages that use it have <stamp src="footer.html">. If you used a frame for that, the linked file would probably look more like

Code
<!DOCTYPE HTML>
<html>
	<head>
		<meta charset="UTF-8">
	</head>
	<body>
	<p>All code ©20XX Bob Webman. <a mailto="bob@example.com">bob@example.com</a></p>
	</body>
</html>

because it's a full HTML page rather than just a little code snippet.

Stamps don't embed pages, they copy the content of a file and treat it as if it were in the page you're reading. If your page's code contains
Code
<p>Today i'm feeling <stamp src="mood.html">.</p>
it should be possible to select and copy (and read with a screenreader) that text as if it said
Code
<p>Today i'm feeling hungry.</p>

There are some issues i can already see with this. What happens if you put a <stamp> inside a styled <span>, or an element like &lt;em>? What if you do that and then the stamp contains the closing tag for one of those? What happens if an element opens outside a stamp and closes inside one?

Or nesting? What if your stamp contains another stamp or a frame? Should browsers refuse to load nested stamps like some do for nested frames? Probably, but i'm no expert here.

That's why i'm here asking for help. I'd like to go propose this to.. i think it's WhatWG now who actually decide what HTML is. I'd like to propose this to them, but i'd like it to be a bit more polished first. What other problems does this have? What can be done about the ones i've already pointed out?

I've discussed this a little with Melon before, in the shoutbox. I think it was he who pointed out the styling issue.
« Last Edit: May 22, 2026 @822.35 by IndigoGolem » Logged

-Indigo, Anve Ozo %
Dan Q
Hero Member ⚓︎
*****
View Profile WWWArt


I have no idea what I am doing
⛺︎ My Room
RSS: RSS

Guild Memberships:
« Reply #1 on: May 22, 2026 @829.49 » Embed

(quick warning: many of the code snippets in this post don't work; don't copy-paste without reading!)

So, there's good news and bad news.

The good news is this element already exists. It's called <embed>, it's already standardised, and it looks like this:


Code
<embed type="text/html" src="mood.html">

I'm sure you can guess the problem, though... no contemporary browser implements it like this. The code above will work in... almost nothing.

An earlier competing option, even less-standardised, was partially-supported once, but never caught on (and had other problems:


Code
<object type="text/html" data="urltofile.html"></object>

This is, of course, a problem that keeps coming around. HTML5 defined this pattern:

Code
<link rel="import" href="/path/to/file.html">

That one was even supported, kind-of, by Chrome for a little while. But now it isn't.

Why do I provide all of these examples of code that won't work? To show that standardisation isn't the problem: we've already had at least two and possibly three "standards" for this, but the problem was that they weren't widely-implemented!.

And they'd have to be! Because unless they hit a critical mass where the vast majority of your visitors support the new element, you really can't use it! There's no "fallback" for this kind of functionality...

...or is there? Maybe, just maybe, this is an opportunity for a Progressive Web Component to the rescue. There's nothing to stop you from using e.g. something like (my) <embed-html> component in a progressive way, like this:


Code
<embed-html src="mood.html cache>
  <embed type="text/html" src="mood.html">
</embed-html>

That will, by default, use the <embed-html> component. But if it fails for some reason, e.g. JS fails, then it will fall-back to the <embed> pattern.

This kind of nesting pattern means that we can solve the problem in a way that's "good enough" today, and you can choose which standard you want to back long-term. This is the way that the Web is supposed to work: that's why you can, for example, do things like this:


Code
<video src="my-video.mp4">
  ...(some fallback code, e.g. Flash, or maybe just a hyperlink to download the video?)...
</video>

To recap:

1. Sorry to burst your bubble, but this isn't a standards issue because we've already standardised it several times: the problem is that no mainstream browser maintains a long-lived solution, and even if any did you'd need basically all of them to do so to depend upon it.

2. But... a Progressive Web Component (like mine!) lets to get the functionality you need today while still supporting whichever standard you favour in the long-term (but I wouldn't hold your breath on implementation, 'cos it's not going to happen.)
Logged

https://danq.me/_q26t/badges/dan-q-88x31-lighter.gif https://danq.me/_q26t/badges/dan-q-88x31-peekaboo-scroller.gif https://beige-buttons.danq.dev/beige-buttons-88x31.gif https://embed-html.danq.dev/embed-html-88x31.gif

Artifact Swap: I met Dan Q on Melonland!Polyamorousradio polyRainbow ConnectionJoined 2025!
Dan Q
Hero Member ⚓︎
*****
View Profile WWWArt


I have no idea what I am doing
⛺︎ My Room
RSS: RSS

Guild Memberships:
« Reply #2 on: May 22, 2026 @841.53 » Embed

Okay, preemptively: I'm sure some folks are asking why none of the existing standards for this caught on: why didn't browsers implement this functionality on any of the previous ocassions?

(By the way: I didn't even list all the standardisation attempts that have already come before: some other SGML dialects implemented this kind of functionality and they never made it into HTML: there's even a video somewhere of Tim Berners-Lee doing a tech demo that does exactly what you're asking for back in 1993... in a browser you'll probably never use or see.)

Personally, I think it's a matter of prioritisation by major browser manufacturers... differing from yours! Sever side includes (and similar technologies), server-side scripting languages, static site generation, framesets/iframes, and JavaScript are considered to be "good enough" solutions to this problem, and browser manufacturers are far too busy shovelling AI shit into every orifice they can implementing other features to focus on something they consider a mostly-solved problem, especially if it won't help anybody until all their competitors implement it too.

But let's take a less-pessimistic view. What are the other challenges with making a new standard about this? There are a lot: it's about more than just styling! E.g.

1. What context is the inner page loaded in? Can JavaScript interact with it? Can JavaScript on it interact with the outer page (in either case, this is a huge change to the Web because everybody who allows user-generated HTML needs time to be able to choose whether to censor/blocklist it or not!). Are global variables shared between the two?

2. How does it load? Something like the Fetch API? What if that's disallowed by a Content-Security Policy? What if it 404s? What if what comes back isn't HTML: does it get embedded anyway? What about content where it's uncertain whether it's HTML or not (e.g. MathML? SVG? XML? Something with custom elements?)?

3. Can requests be intercepted by Service Workers? How are caching header handled? If a sub-page has a longer cache duration than the parent page, does the cached version get re-used even when the parent page get refreshed? If the sub-page has a shorter cache duration, cos it get re-loaded even when a cached version of the parent page is loaded?

4. Can requests be made cross-domain? If so, how does this interact with CORS? Do cookies get sent? Do client side SSL certificates get sent? What happens if the sub-page responds with a redirect? If it's a permanent redirect, does that get cached? If so, does that introduce a risk of evercookie tracking?

5. If a stamp appears multiple times on a page, is it requested multiple times or fetched once and re-used?

6. Does the sub-page get its own thread? This affects the run order of JavaScript if it features on both the outer and inner pages. Yes = better performance, but more chance of race conditions; no = worse performance, and new questions to answer like does JS run in the order it appears on the page "as if" the sub-page were a full part of the outer page?

7. If a sub-page loads extremely slowly, does that block rendering of the outer page? Normally modern browsers wait until the entire DOM has been loaded before they start laying out content to prevent a FOUS: would that happen in this case too?

These are the kinds of things that have to be thought about by anybody implementing such a standardised element, and they're the kinds of things somebody proposing a standard ought to think about too! And, indeed, it's probably (IMHO) the lack of answers to some of these questions that might have hindered implementation in the past...
Logged

https://danq.me/_q26t/badges/dan-q-88x31-lighter.gif https://danq.me/_q26t/badges/dan-q-88x31-peekaboo-scroller.gif https://beige-buttons.danq.dev/beige-buttons-88x31.gif https://embed-html.danq.dev/embed-html-88x31.gif

Artifact Swap: I met Dan Q on Melonland!Polyamorousradio polyRainbow ConnectionJoined 2025!
IndigoGolem
Sr. Member ⚓︎
****
View Profile


What's personal text?
⛺︎ My Room

Artifacts:
Joined 2025!
« Reply #3 on: May 23, 2026 @696.34 » Embed

<embed>
...
<object>
...
Code
<embed-html src="mood.html cache>
  <embed type="text/html" src="mood.html">
</embed-html>

That is good to know. It hadn't occcurred to me that this would already exist, probably because so many people want it and don't use it.

1. What context is the inner page loaded in? Can JavaScript interact with it? Can JavaScript on it interact with the outer page (in either case, this is a huge change to the Web because everybody who allows user-generated HTML needs time to be able to choose whether to censor/blocklist it or not!). Are global variables shared between the two?

2. How does it load? Something like the Fetch API? What if that's disallowed by a Content-Security Policy? What if it 404s? What if what comes back isn't HTML: does it get embedded anyway? What about content where it's uncertain whether it's HTML or not (e.g. MathML? SVG? XML? Something with custom elements?)?

3. Can requests be intercepted by Service Workers? How are caching header handled? If a sub-page has a longer cache duration than the parent page, does the cached version get re-used even when the parent page get refreshed? If the sub-page has a shorter cache duration, cos it get re-loaded even when a cached version of the parent page is loaded?

4. Can requests be made cross-domain? If so, how does this interact with CORS? Do cookies get sent? Do client side SSL certificates get sent? What happens if the sub-page responds with a redirect? If it's a permanent redirect, does that get cached? If so, does that introduce a risk of evercookie tracking?

5. If a stamp appears multiple times on a page, is it requested multiple times or fetched once and re-used?

6. Does the sub-page get its own thread? This affects the run order of JavaScript if it features on both the outer and inner pages. Yes = better performance, but more chance of race conditions; no = worse performance, and new questions to answer like does JS run in the order it appears on the page "as if" the sub-page were a full part of the outer page?

7. If a sub-page loads extremely slowly, does that block rendering of the outer page? Normally modern browsers wait until the entire DOM has been loaded before they start laying out content to prevent a FOUS: would that happen in this case too?

These are the kinds of things that have to be thought about by anybody implementing such a standardised element, and they're the kinds of things somebody proposing a standard ought to think about too! And, indeed, it's probably (IMHO) the lack of answers to some of these questions that might have hindered implementation in the past...


This is what i expected before you said this already exists twice.

2, 5: How are existing embeds like frames and images loaded? I assume images are fetched once and reused, but i don't really know. I don't see why doing it the other way would ever be preferred.

7: I guess so, or if it takes too long you just get a placeholder saying it didn't load, like with images.

4: You mean having the stamp/embed/object hotlinked from another domain/server? It seems like a lot of this stuff has already been answered for images and stamps, but i guess there's more to it that i don't see.

1, 3, 6: I don't know how to start answering these. There's a lot that goes into this stuff.
Logged

-Indigo, Anve Ozo %
Pages: [1] Print Embed 
« previous next »
 

Melonking.Net © Always and ever was! SMF 2.0.19 | SMF © 2021 | Privacy Notice | Send Feedback | Supporters ♥ Forum Guide | Rules | RSS | WAP | Mobile


MelonLand Badges and Other Melon Sites!

MelonLand Project! Visit the MelonLand Forum! Support the Forum
Visit Melonking.Net! Visit the Gif Gallery! Pixel Sea TamaNOTchi
MelonLand @000

Want to Login or Join ?

Minecraft: Online
Join: craft.melonking.net