Day 86 of 100DaysOfSpec, the iframe element

I am reading and taking notes on the HTML specifications for 100 days as part of #The100DayProject. Read the initial intent/backstory. I am a Microsoft employee but all opinions, comments, etc on this site are my own. I do not speak on behalf of my employer, and thus no comments should be taken as representative of Microsoft's official opinion of the spec. Subsections not listed below were read without comment.

Currently reading 4.7.2 the iframe element

“The iframe element represents a nested browsing context.”

• Considered flow, phrasing, embedded, interactive, and palpable content. Dang.
• Can set ARIA roles of application, document, img, or presentation.

Attributes, besides global:

• src: address of a page to contain

• srcdoc: content of a page to contain. “The value of the attribute is the source of an iframe srcdoc document.” Quote marks, ampersands, left angle brackets, and some XML whitespace characters within the srcdoc attribute have to be escaped. Check out this spec companion site for an example. The spec seems to suggest that these attributes should have an html root element, but none of the examples I’ve seen elsewhere include it. If you’re looking for cross-browser support, however, you may be disappointed.

• name: a browsing context name

• sandbox: extra security rules. Written as case-insensitive space-separated “tokens”, like how multiple class names are set on an element. “When the attribute is set, the content is treated as being from a unique origin, forms, scripts, and various potentially annoying APIs are disabled, links are prevented from targeting other browsing contexts, and plugins are secured.” You use the tokens in this attribute value to override some of these restrictions: allow-forms, allow-pointer-lock, allow-popups, allow-same-origin, allow-scripts, and allow-top-navigation. Would suggest reading the warnings in the spec as you can open up some security and/or embedding issues.

• width

• height

• When an iframe is removed from a document: “this happens without any unload events firing (the nested browsing context and its Document are discarded, not unloaded).” Good to noted if you’re trying to write a script listening for this event.

• The iframe attributes get re-processed whenever the srcdoc or src (if no srcdoc) attribute is manipulated.

• “When a Document in an iframe is marked as completely loaded, the user agent must synchronously run the iframe load event steps.”

• “A load event is also fired at the iframe element when it is created if no other data is loaded in it.”

• The iframe loading steps open up some vulnerabilities. “User agents may implement cross-origin access control policies that are stricter than those described above to mitigate this attack, but unfortunately such policies are typically not compatible with existing Web content.” :/

• The spec says that there is no fallback content for an iframe as a nested browsing context is always created, but then immediately follows this with “In legacy user agents that do not support iframe elements, the contents would be parsed as markup that could act as fallback content.” Uh?

• In XML, the iframe has to be empty. In HTML, the content model is “text”, where the parsing algorithm returns only error-free phrasing content, and there are no script element descendants. I’m a little unclear as to whether “text” refers to loose text or if phrasing content elements going into said algorithm are ok. Especially because the the markup is “treated” as text.