Build a Responsive Iframe Widget

Build and deploy an iframe widget that resizes to fit its content.

Introduction

30 Second Summary

A comment box can outgrow the space a website gives it. Readers end up scrolling inside a tiny box or staring at a large empty gap.

In this project, you will build a host page that embeds a comment widget. You will replace its fixed-height frame with responsive iframe sizing so the widget grows as comments appear.

What You'll Build

Open your host page, add comments inside the embedded widget, and watch the frame grow to fit every new line without showing an inner scrollbar.

By the end of this project, you'll have:

A before-and-after embed that shows the fixed-height scrollbar problem before expanding to fit the full widget.
A dynamic comment widget whose frame grows with each new comment without JavaScript messaging.
A public demo URL that resizes in a supported browser while keeping a sensible fixed-height fallback elsewhere.
Secret Mission: Add controls that expand and collapse the widget so you can prove the frame follows content in both directions.

Are there any prerequisites?

Use Chrome 154 or later for the responsive sizing test. You also need a text editor, a local static server, and an account with a free static host.

Before We Start

Responsive iframe sizing depends on support in Google Chrome. An older browser or a page opened directly from disk can make correct iframe markup look broken.

This step prepares the testing kit for the project. Each tool gives you a clear way to edit the pages, serve them through a local static server, or compare browser behavior.

In this step, get ready to:

Prepare Visual Studio Code for editing the host page and widget page.
Verify Chrome version 154 or later for responsive iframe sizing.
Prepare a fallback browser and a local static-server tool.

Prepare your code editor

A code editor keeps the host page and widget page easy to find. Visual Studio Code provides the file editing workspace used throughout this walkthrough.

Press Cmd+Space on macOS or the Windows key on Windows to open system search.
Type Visual Studio Code into the search bar.
Press Enter.

✔️ Visual Studio Code opens

Your editor is ready. You now have a dedicated workspace for the two pages you will build.

ⓧ Visual Studio Code isn't installed

Install Visual Studio Code using the instructions for your operating system.

macOS

Open the official Visual Studio Code download page.
Choose the Universal .dmg download.
Open the downloaded .dmg file.
Drag Visual Studio Code.app into the Applications folder.
Press Cmd+Space to open Spotlight.
Type Visual Studio Code into Spotlight.
Press Enter.

That completes your editing setup. Visual Studio Code is ready for the project files.

Windows

The installer uses a short setup wizard. The default choices work for this project.

Open the official Visual Studio Code download page.
Choose the User Installer download for your computer.
Open the downloaded .exe file.
Complete the setup wizard using the default options.
Press the Windows key to open system search.
Type Visual Studio Code into the search bar.
Press Enter.

Your editor setup is complete. Visual Studio Code is ready for the project files.

Visual Studio Code not opening?

Confirm that you downloaded the installer for your operating system. Run the installer again if system search still cannot find the editor.

Ask for help with your specific installation problem: Help me troubleshoot why Visual Studio Code will not open after installation.

Prepare supported and fallback browsers

Chrome version 154 or later provides the responsive iframe sizing behavior tested in this project. A browser without support shows whether your fixed-height fallback still works.

Press Cmd+Space on macOS or the Windows key on Windows to open system search.
Type Google Chrome into the search bar.
Press Enter.
Click More in the top-right corner if Chrome opens.
Select Help.
Select About Google Chrome.

The version number appears beneath the Google Chrome heading. Choose the tab that matches what you see.

✔️ I see version 154 or higher

Chrome is ready. You have the browser capability this project is designed to test.

ⓧ I see an older version

Chrome checks for updates while the version page is open. The update may take a minute to download.

Keep the About Google Chrome page open while the update downloads.
Click Relaunch when the button appears.
Return to About Google Chrome after Chrome reopens.
Confirm that the version number is 154 or higher.

ⓧ Chrome isn't installed

Open the official Chrome download page.
Download the installer for your operating system.
Open the downloaded installer.
Complete the installation prompts.
Repeat the version check above after Chrome opens.

Chrome is ready once its version number starts with 154 or a higher number.

The fallback check needs a separate browser without responsive iframe sizing support. Firefox gives you a second environment for that comparison.

Press Cmd+Space on macOS or the Windows key on Windows to open system search.
Type Firefox into the search bar.
Press Enter.

✔️ Firefox opens

Your fallback browser is ready. You can compare the same embed across two browser environments.

ⓧ Firefox isn't installed

Open the official Firefox download page.
Download the installer for your operating system.
Open the downloaded installer.
Approve the system permission request if it appears.
Complete the installation prompts.
Open Firefox through system search.

Your second browser is now available for the fixed-height fallback test.

Prepare the local static server

A local static server gives both pages an HTTP origin. This avoids the different behavior you can get from opening files through file://.

Python includes a basic server for local testing. It serves files from the folder where you start it.

Press Cmd+Space on macOS or the Windows key on Windows to open system search.
Type Terminal on macOS or PowerShell on Windows.
Press Enter.

Check whether Python is available using the command for your operating system.

macOS

Check the installed Python version by running this command:

python3 --version

What does this command do?

This asks the Python executable to print its installed version. A version number confirms that the command is available in your terminal.

Windows

Check the installed Python version by running this command:

py --version

What does this command do?

This asks the Windows Python launcher to print its installed version. A version number confirms that the launcher is available in PowerShell.

Choose the outcome that matches your terminal.

✔️ I see a Python version

Python is ready. Its built-in server can now serve the project pages locally.

ⓧ Command not found

Install Python using the official instructions for your operating system.

macOS

Open the official Python downloads page for macOS.
Download the current macOS installer.
Open the downloaded installer package.
Complete the installer using its default options.
Close Terminal after the installation finishes.
Open Terminal again through system search.

Windows

Open the official Python downloads page for Windows.
Download the current Windows installer.
Open the downloaded installer.
Complete the installer using its default options.
Close PowerShell after the installation finishes.
Open PowerShell again through system search.

The server keeps control of the terminal while it runs. You will stop it after confirming that the browser can reach it.

Before you start the server, what do you expect Chrome to show when it connects to port 8000?

macOS

Start the local static server on your computer by running this command:

python3 -m http.server 8000 --bind 127.0.0.1

What does this command do?

This starts Python's built-in static server on port 8000. The bind address limits the server to connections from your computer.

The server shares files from the terminal's current folder. This server is designed for local testing.

Windows

Start the local static server on your computer by running this command:

python -m http.server 8000 --bind 127.0.0.1

What does this command do?

This starts Python's built-in static server on port 8000. The bind address limits the server to connections from your computer.

The server shares files from the terminal's current folder. This server is designed for local testing.

Keep the terminal running.
Enter http://localhost:8000 in Chrome's address bar.

You should see a browser page listing files from the folder where the terminal started. That response proves Chrome can reach your local static server.

Can't reach the local server?

Confirm that the server command is still running in the terminal. Restart it if you closed the terminal or stopped the process.

Check that the address uses port 8000. Another port points Chrome at a different process.

Ask for help with the terminal result: Help me troubleshoot why Chrome cannot reach my Python local static server.

Press Ctrl+C in the terminal to stop the test server.

Your editor, supported browser, fallback browser, and local server are ready. Next up, you will serve the first host page and widget page to expose the fixed-height iframe problem.

Serve the Fixed-Height Embed

A widget can outgrow the rectangle its host page reserves for it. When the widget becomes taller than that rectangle, an iframe clips the lower content or adds an inner scrollbar.

In this step, you will use the local static server already available to serve a host page plus a comment-style widget page. You will inspect the fixed-height baseline in Google Chrome before changing its sizing behavior.

In this step, get ready to:

Create a widget page with enough comment-style content to exceed its future frame.
Create a host page with a deliberately short fixed-height iframe.
Inspect the served baseline in Google Chrome.

Create the widget page

The embedded page needs a real content body so the frame has something measurable to display. Its initial comment-style content must be taller than the fixed frame you create next.

Use your code editor's file explorer to create a widget folder on your Desktop.
Use the editor's new-file control to create widget/index.html.

You should now see widget/index.html inside the widget folder in your file explorer.

Write a complete HTML page in widget/index.html with enough initial comment-style content to fill more vertical space than the host frame will allow.
Save widget/index.html.

Your file explorer should show the saved widget/index.html file inside widget.

Create the host page

The host page controls how much space the embed receives. A deliberately short fixed height creates the baseline you need for comparison.

Use your code editor's file explorer to create a host folder beside the widget folder on your Desktop.
Use the editor's new-file control to create host/index.html.

You should now see the host folder beside widget. Each folder should contain an index.html file.

Write a complete host page in host/index.html that embeds ../widget/index.html in an iframe with a deliberately short fixed height.
Save host/index.html.

Your editor should show saved copies of host/index.html plus widget/index.html.

Test the fixed-height baseline

Serving both folders from the same local location lets the host page load the widget through its relative path. The server must remain running while you test the embed.

Set your available local static-server tool to serve your Desktop.
Start the local static server.

You should see a local address from the static-server tool. Keep the server running while the browser uses that address.

Server Not Showing Both Pages?

Confirm that the server is serving your Desktop.
Check that the Desktop contains sibling host plus widget folders.
Confirm that each folder contains an index.html file.

Ask for help with the server root or local address if the files still do not load. Help me troubleshoot why my local static server cannot serve my host and widget pages.

Before you load the host page, predict whether the complete widget fits inside the fixed frame.

Use the app search on macOS or Windows to launch Google Chrome.
Enter the local server address for host/index.html in the browser's address bar.

You will see the widget inside the host page. The lower content is clipped or available through an inner scrollbar.

That cramped result is intentional. You now have a working baseline that exposes the fixed-height embed problem.

Do You See the Whole Widget?

Confirm that the iframe in host/index.html points to ../widget/index.html.
Reduce the iframe's fixed height until it is shorter than the widget content.
Add more comment-style content to widget/index.html if the widget still fits inside the frame.

Use this prompt if the host still does not show the intended baseline. Help me find why my fixed-height iframe is not clipping or scrolling.

Leave the local static server running.

✔️ Awesome, I've got everything!

Your host page now displays the deliberately constrained widget in Google Chrome.

Keep the server running with the host page open for the next step.

ⓧ I'd like to double check the full code

Your local static server should be running locally and serving the host/ plus widget/ static pages.

Your host/index.html file should be a host page served locally with an iframe that loads widget/index.html. The iframe should use a deliberately short fixed height that produces the baseline clipped or scrollable widget.

Your widget/index.html file should be a widget page served locally with enough initial comment-style content to exceed the host iframe's fixed height.

Your local embed now demonstrates the fixed-height problem. Next, you will add the sizing opt-in on both sides of the embed.

Enable Responsive Iframe Sizing

The fixed-height iframe from the last step proved the baseline problem. Its box cannot account for taller widget content.

Visitors see clipping or an inner scrollbar. Chrome 154 uses a double opt-in for responsive sizing.

The host requests the widget's content height through CSS. The widget separately grants permission through HTML.

These two signals let the browser fit the initial widget content without JavaScript messaging.

In this step, get ready to:

Add the embedding-page opt-in while preserving the fixed-height fallback.
Add the embedded-page opt-in inside the widget.
Verify that Chrome 154 fits the full initial widget without an inner scrollbar.

Opt in from the host page

The embedding page controls how the iframe is sized within the host layout. Its CSS opt-in asks Chrome to use the embedded document's content height.

Switch back to host/index.html in the code editor from earlier.
Locate the CSS rule that gives the iframe its deliberately short height.
Keep the existing fixed-height declaration as the fallback.
Add responsive sizing by copying this declaration into the same iframe rule:

frame-sizing: content-height;

What Does This Declaration Do?

The frame-sizing property lets the iframe use the embedded document's intrinsic size.
The content-height value selects the embedded document's content height.
The existing fixed height continues to serve as the fallback.

Before refreshing, do you think the host's request can reveal the widget's height before the widget grants permission?

Save host/index.html.
Switch back to the host page in Chrome 154.
Refresh the host page.

The frame continues to use its short fallback height. This confirms that the host-side request needs permission from the embedded page.

Opt in from the widget page

The widget controls whether its layout size can be exposed to an embedding page. A meta element grants that permission during the initial document parse.

Switch back to widget/index.html in the code editor.
Locate the document head above the widget's visible comment content.
Add the embedded-page opt-in by copying this element inside the document head:

<meta name="responsive-embedded-sizing" content="allow-origins=*">

What Does This Opt-In Do?

The responsive-embedded-sizing name identifies the widget as a document that permits responsive embedded sizing.
The allow-origins=* value permits embedding origins to use the exposed size.
Placing the meta element inside the document head makes the permission available during the initial parse.

Before refreshing, what height do you expect the host iframe to use now that both pages have opted in?

Save widget/index.html.
Switch back to the host page in Chrome 154.
Refresh the host page.

You have the two-sided handshake working. The iframe now expands to the widget's full initial content height.

You can read every initial comment without an inner scrollbar. No JavaScript messages are involved.

Frame Still Stuck at the Fallback Height?

Confirm that frame-sizing is set to content-height inside the iframe rule in host/index.html.
Confirm that the responsive-embedded-sizing meta element sits inside the document head in widget/index.html.
Save host/index.html.
Save widget/index.html.
Refresh the host page in Chrome 154.

Help me diagnose why my responsive iframe remains at its fixed fallback height.

✔️ Awesome, I've got everything

Great. Both pages are saved with their side of the responsive sizing handshake.

ⓧ I'd like to double check the full code

Compare these checkpoints with your existing pages while keeping the styling and comment content from the previous step.

Confirm that host/index.html still loads widget/index.html in its iframe.
Confirm that the iframe's CSS rule retains its fixed-height fallback.
Confirm that the iframe's CSS rule sets frame-sizing to content-height.
Confirm that widget/index.html retains its initial comment-style content.
Confirm that the document head in widget/index.html contains <meta name="responsive-embedded-sizing" content="allow-origins=*">.

Your embed now fits its initial content. Next, you will make the frame respond as new comments appear.

Grow the Widget With Comments

Your iframe already fits the widget's initial content in Chrome 154.

A fixed first render does not prove that the frame can follow content that changes after the page loads.

In this step, you will add an Add comment control to widget/index.html. Each click adds content. Chrome recalculates the iframe height without JavaScript messaging.

In this step, get ready to:

Add a control that inserts a new comment into the widget.
Confirm that the iframe grows after every click.
Verify that the embedded page keeps no inner scrollbar.

Add the comment control

The widget needs a repeatable way to increase its document height. A button provides that trigger while a fixed comment string keeps this demo focused on responsive sizing.

Switch back to widget/index.html in your code editor.
Find the initial comment-style content.
Place your cursor directly after that content.
Add the control with its click behavior by pasting this code:

<!-- Add a control that creates more widget content -->
<button id="add-comment" type="button">Add comment</button>

<script>
  // Find the control once so every click can add content beside it
  const addCommentButton = document.querySelector("#add-comment");

  // Insert a comment before the control to increase the document height
  addCommentButton.addEventListener("click", () => {
    addCommentButton.insertAdjacentHTML(
      "beforebegin",
      "<p>New comment: This widget keeps growing.</p>"
    );
  });
</script>

What Does This Code Do?

The <button> element gives the widget its visible Add comment control.
The addEventListener() method runs the callback whenever the button receives a click.
The insertAdjacentHTML() method adds another paragraph to the DOM.
The beforebegin position places each new comment immediately before the button.
The inserted markup is a fixed project string. No visitor-provided content enters the page.

Save widget/index.html.
Switch back to the host page in Chrome.
Refresh the host page.

You should see the Add comment button below the widget's initial content. The iframe should still fit the complete widget without an inner scrollbar.

Button Missing?

Confirm that you pasted the code into widget/index.html.
Check that the button sits inside the widget page's body content.
Save the file before refreshing the host page.

Help me find why the Add comment button is missing from my embedded widget.

Test the automatic growth

Dynamic comments increase the widget document's intrinsic height after it loads. The existing opt-ins let Chrome follow that change from inside the embedded page.

Before you click the control, do you expect the iframe's lower edge to stay fixed or move with the new comment?

Click Add comment once inside the embedded widget.

You should see one new comment above the button. Chrome 154 moves the iframe's lower edge downward to fit it.

You should not see an inner scrollbar. The host page makes room for the widget's new height automatically.

Click Add comment two more times.

You should see three added comments in total. The iframe should grow after each click while the host page remains unchanged.

Frame Stays Fixed?

Confirm that the host page remains open in Chrome 154.
Check that the existing responsive-sizing opt-in remains present on the host page.
Check that the existing responsive-sizing opt-in remains present on the widget page.
Confirm that the new button code is saved in widget/index.html.

Help me debug why the iframe does not grow when I add comments.

What You Proved

The local static server continues to serve the host page and widget page.
The host page still embeds the widget with responsive sizing enabled.
The widget now includes initial content plus an Add comment control.
Each click increases the widget's document height.
Chrome grows the iframe without JavaScript messaging or an inner scrollbar.

Your embed now follows live content changes. Next up, you will test the fixed-height fallback in a browser without responsive iframe sizing support.

Set a Fallback Height

Your widget already grows with every added comment in Chrome 154. The host page still needs a predictable layout when responsive iframe sizing is unavailable.

In this step, you will expose the fixed-size fallback in a non-supporting browser. You will set it to 300px before confirming both browser paths.

In this step, get ready to:

Test the existing fixed-size behavior without responsive iframe sizing support.
Set the host page fallback to 300px.
Compare the fallback with automatic growth in Chrome 154.

Test the unsupported path

A non-supporting browser cannot apply the responsive sizing behavior. Testing this path reveals whether the host page still gives the widget enough room.

Before you load the page, predict whether adding comments can change the outer frame's height without support.

In Chrome 154, select the current host page URL in the address bar.
Copy the selected URL.
Switch back to the non-supporting browser or configuration from earlier.
Paste the copied URL into the address bar.
Press Enter to load the host page.
Click Add comment until the widget content extends beyond the visible frame.

You will see the outer frame keep its original fixed height. The extra widget content becomes clipped or receives an inner scrollbar in this browser path.

Why does the frame stop growing?

The responsive sizing opt-ins only affect browsers that support the feature. Other browsers continue using the fixed height supplied by the host page.

This result is the intended baseline. It shows why the fallback must provide enough space for the widget to remain usable.

Set the fallback to 300px

A fallback height gives non-supporting browsers a predictable viewing area. A value of 300px leaves useful room for the widget while keeping the host page compact.

Switch back to host/index.html in the code editor.
Locate the existing fixed-height value attached to the iframe.
Replace the current fallback value with 300px.
Save host/index.html.
Return to the host page in the non-supporting browser.
Refresh the page to load the saved fallback.

You should see the iframe keep a steady height of 300px. Added content stays inside that fixed fallback area.

Fallback still looks unchanged?

Confirm that host/index.html is saved in the code editor.
Refresh the host page served by your local static server.

Help me check why my iframe fallback height is not updating.

Compare both browser behaviors

The fallback is only half of the check. The supporting path must still follow the widget's changing content height.

Before you compare the browsers, predict which one will change the outer frame's height after another comment is added.

Switch back to the host page in Chrome 154.
Refresh the page to load the updated host file.
Click Add comment to increase the widget's content height.

You will see the iframe grow with the new comment. It does this without JavaScript messaging or an inner scrollbar.

Switch back to the host page in the non-supporting browser.
Refresh the page to reset the widget content.
Click Add comment until the content extends beyond 300px.

You will see the iframe remain 300px tall. This confirms that the fixed-height fallback remains active without responsive sizing support.

Your embed now has both browser paths covered. Next, you will deploy the host page and widget page to a free static host so the demo works at a public URL.

Publish the Responsive Embed

Your local host page now lets the iframe follow the widget's content height in Chrome 154. The 300px fallback also holds in your non-supporting browser or configuration.

A demo on your machine is difficult to share. In this step, you will publish both pages with Netlify Drop so the same behavior works at a public HTTPS URL.

In this step, get ready to:

Deploy the existing host page and widget page together.
Record the public URLs for both deployed pages.
Verify the live responsive sizing and fixed-height fallback.

Deploy both pages with Netlify Drop

The host page depends on its existing path to the widget page. Uploading the folder that contains both directories preserves that relationship on the public site.

Why Netlify Drop?

Netlify Drop publishes a folder of static files without requiring Git. It gives the deployed project a public link that you can share.

The Free plan costs $0 and has a hard monthly usage limit. No payment details are needed for this static demo.

In Chrome 154, visit Netlify Drop.
Create a Free account if Netlify asks you to sign up.
Sign in if Netlify asks you to authenticate.

After authentication, you will see the Netlify Drop zone.

In Finder (macOS) or File Explorer (Windows), locate the folder that directly contains host and widget.
Drag that folder into the Drop zone.
Wait for the deployment to finish.

You will see a Preview URL ending in netlify.app. Your two static pages are now online.

Copy the Preview URL.
Enter the Preview URL followed by /host/ in a new Chrome 154 tab.

You should see the deployed host page with the widget loaded inside its frame.

Record the live host page URL here: your public host page URL.
Load the Preview URL followed by /widget/.

You should see the standalone widget page with its initial comments and Add comment control.

Record the live widget page URL here: your public widget page URL.
Return to your public host page URL.

The host page should still display the deployed widget inside the iframe. That confirms both public paths survived the deployment.

Deployment missing one page?

Confirm that the uploaded folder contains host and widget as sibling directories.
Add /host/ to the Preview URL if the generated root page does not show the host.
Upload the containing folder again if you accidentally dropped only one directory.

Help me fix my static deployment when the host or widget page is missing.

Test the live responsive iframe

Deployment changes where the files are served. The responsive sizing opt-ins remain inside the same host and widget files.

Before you load the live host page, do you expect public hosting to change the iframe's initial height?

Load your public host page URL in Chrome 154.

You should see the iframe match the widget's initial content height. The live frame should have no inner scrollbar.

Before you add another comment, do you expect the public iframe to follow the new content height?

Click Add comment once inside the live widget.

You should see the frame grow to fit the new comment. No inner scrollbar should appear.

Click Add comment two more times.

The live iframe grows after each click. The deployed pages retain native sizing without adding JavaScript messaging.

Live frame staying fixed?

Confirm that Chrome reports version 154 or later.
Confirm that you uploaded the folder containing the latest versions of both pages.
Reload the public host page after the deployment finishes.

Help me debug why my deployed iframe stays fixed in Chrome 154.

Confirm the fixed-height fallback

The public deployment still needs a useful result for visitors whose browser does not support responsive iframe sizing. Your existing fallback gives those visitors a stable frame.

Before you load the public page there, do you expect the frame to follow the widget or keep its fallback height?

Load your public host page URL in the non-supporting browser or configuration from earlier.

You should see the live iframe remain at its 300px fixed height.

Before you add more comments, do you expect the outer frame to grow in this browser?

Click Add comment twice inside the widget.

The widget content increases while the iframe remains 300px tall. That confirms the live fallback works for visitors without feature support.

That is the full demo published. Your public embed now shows native responsive sizing in Chrome 154 with a fixed-height fallback everywhere else.

Secret mission

Stress-Test the Responsive Embed

Your live embed already resizes as comments appear. Now stress-test it with repeated content growth, a narrow layout, and the fixed-height fallback to build a repeatable compatibility check.

Clean Up Your Resources

Your public demo can stay online as a reference. The free static host adds no ongoing cost for this project.

Resources you used:

The public HTTPS deployment for the live embed.
The local host/index.html page.
The local widget/index.html page.
The local static server process if it is still running.

Keep everything running

No action is needed. This option keeps the public demo ready for future testing.

Leave the public deployment online.
Keep host/index.html in the local project from earlier.
Keep widget/index.html in the local project from earlier.
Leave the local static server running while you are actively testing.

Pause - I'll come back to this later

Pausing ends the local server process while preserving your files. The public deployment remains available.

Return to the terminal running the local static server.
Press Ctrl+C to stop the server.
Reload the existing public host URL.

You'll see the terminal return to its prompt. The public embed still loads from the free static host.

Delete - I don't want to use this again

Remove the public deployment if you no longer want the demo online. You can also remove the local copies of both pages.

Return to the terminal running the local static server.
Press Ctrl+C to stop the server.
Return to the free static host from the deployment step.
Remove the deployment using that provider's documented project deletion procedure.
Reload the public host URL after the provider confirms deletion.

You'll see that the public host URL no longer serves the embed.

Return to the local project from earlier using Finder on macOS or File Explorer on Windows.
Delete the host folder.
Delete the widget folder.

You should no longer see host/index.html or widget/index.html in the local project.

Nice Work!

You did it. Your live iframe now follows the widget's content height in Chrome 154 without JavaScript messaging or an inner scrollbar.

What you learned:

Reproduced the fixed-height iframe problem from a local static server. You saw the widget clip inside a scrollable frame.
Enabled responsive iframe sizing on the host page and widget page. You proved that the frame tracks both initial content and added comments.
Added a 300px fallback height for browsers without support. You deployed the complete demo to public HTTPS URLs.
Secret Mission: Extended the responsive embed through the optional project challenge.

Ready to quiz yourself?