Other people's pixels: SVG, iframes, and embeds

An <svg> element is a canvas; inside it, each child element draws one thing. <rect> takes a position (x, y) and a size; <circle> takes a center (cx, cy) and a radius r; <line> connects two points; <text> writes real, selectable text. Shapes paint in source order - later elements sit on top.

<svg viewBox="0 0 320 130" width="320">
  <rect x="10" y="15" width="80" height="80" rx="12" fill="#E34F26"/>
  <circle cx="160" cy="55" r="40" fill="#F8A47F"/>
  <line x1="230" y1="95" x2="305" y2="15" stroke="#2B1D14" stroke-width="4"/>
  <text x="12" y="122" font-size="14">all of this is text</text>
</svg>

One paragraph on viewBox, because it confuses everyone once: viewBox="0 0 320 130" defines the drawing's own coordinate system - "my world is 320 wide and 130 tall". The width attribute then says how big to display that world. Scale the display up or down and every shape scales with it, perfectly, because the browser is re-running the instructions, not stretching pixels.

Stack a few shapes and you have an icon. This is genuinely how favicons, logos, and UI icons get made - a circle, a letter, done. And when shapes are not enough, <path> draws anything: its d attribute is a walk ("Move to 10,80. Curve to 150,80...") that pens out any outline you can imagine.

<svg viewBox="0 0 120 120" width="110">
  <circle cx="60" cy="60" r="52" fill="#FDF0EA"
          stroke="#E34F26" stroke-width="7"/>
  <text x="60" y="80" font-size="56" text-anchor="middle"
        fill="#A6300F" font-family="Georgia">P</text>
</svg>

<svg viewBox="0 0 320 100" width="320">
  <path d="M10,80 Q85,10 160,80 T310,80"
        fill="none" stroke="#F06529" stroke-width="5"/>
</svg>

You can use an SVG two ways, and MDN's vector graphics lesson turns on this choice:

• As a file: <img src="logo.svg" alt="...">. Simple, cacheable, reusable across pages. But it is a sealed box - your page's CSS cannot restyle its insides.
• Inline: paste the <svg>...</svg> straight into the body, like every playground above. Now every shape is a real element in your page - stylable with CSS, readable by screen readers via role="img" and aria-label, zero extra file requests. The cost: it bulks up your HTML and repeats on every page that uses it.

Rule of thumb: decorative or reused art → file. One-off diagrams you may want to style or tweak → inline. This course inlines everything, which is why you can inspect it all.

Two attributes matter from day one: src points at the document to show, and title describes it for screen-reader users - an iframe without a title is an unlabeled door, so treat title as required. Below, the guest page is written inline via srcdoc so it renders in our sandbox; in the wild you will almost always use src="https://...".

<p>This paragraph lives in YOUR page.</p>

<iframe title="A tiny guest page"
        srcdoc="<h2>Hello from inside</h2>
                <p>I am a separate document.</p>"
        width="100%" height="120"
        style="border: 3px solid #E34F26; border-radius: 10px">
</iframe>

<p>And this one lives in your page again.</p>

The pattern every "share → embed" button hands you is the same five lines. Our sandboxed playgrounds cannot load external sites, so this one is copy-paste for your own file - drop it in your project page and reload:

• sandbox is the safety belt. Adding a bare sandbox attribute strips the guest of its powers: no scripts, no forms, no popups. You then hand back only what it needs, like sandbox="allow-scripts". Embedding content you do not fully trust without it is lending your page to a stranger.
• loading="lazy" tells the browser not to fetch the iframe until the reader scrolls near it - free speed for below-the-fold embeds, same attribute you will meet again on images in deep dive 6.3.
• Some sites refuse to be framed. If an embed shows up blank, the site likely sends headers forbidding embedding (banks and login pages do this on purpose). Use their official embed URL, not the normal page URL.

Before iframes won, pages bolted on external content with plugins: <embed> and <object> were the sockets that Flash movies, Java applets, and PDF viewers plugged into. The plugins are gone (Flash retired in 2020), but you still meet these elements in older codebases, so recognize them:

• <object data="report.pdf" type="application/pdf"> - the one still-legitimate use: showing a PDF inline, with fallback content between the tags for browsers that cannot.
• <embed> - same era, fewer features, no fallback mechanism. If you are writing new code, you basically never want it.

Why iframe wins today: it embeds real web documents rather than plugin content, it has the sandbox security model, lazy loading, and a title for accessibility. MDN's own lesson title tells the story - "from object to iframe" is the direction of travel.

Everything inside a <template> is parsed and held in memory but never rendered - no display, no image loading, no effect on the page. It is a stamp waiting for JavaScript to press it, once per row of data, once per card in a feed.

<p>Before the template.</p>

<template>
  <p>Without JavaScript, you will never see me.</p>
</template>

<p>After the template. Notice the missing middle.</p>

Why it exists: before <template>, developers hid stamp-out markup in strings or hidden divs - which still loaded images and confused screen readers. The template element is the honest version: real HTML, officially inert.

Needs JavaScript - shown here so you recognize it in the wild, not to run it today. Custom elements (tags with a dash, like <user-card>) combine three ideas: a template for the stamp, a shadow DOM (a private, sealed subtree where the component's internals live, safe from the page's CSS), and <slot> - a labeled hole in the template where your content gets projected in.

Where you meet this daily: the <video> controls, browser date pickers, and design-system components (many Google and GitHub UI pieces) are all shadow DOM. When DevTools shows you #shadow-root, you now know what you are looking at.

web.dev's "HTML APIs" chapter makes one big point worth carrying out of this course: every element you have learned also has a JavaScript surface. The document is queryable (querySelector finds elements the way CSS selectors do), every attribute is readable and writable from code, and rich elements expose whole method sets - <video> has play and pause, <dialog> has showModal, forms can validate themselves on demand.

Nothing to do today. Just know the door exists: the clean, semantic HTML you now write is precisely what makes the JavaScript course after this one pleasant - scripts navigate pages by the same structure and meaning you have been building since Session 1.