Re: Iframe alternative content

On 2 Sep 2016, at 18:14, Michael[tm] Smith wrote:
> David Dorward <david@dorward.me.uk>, 2016-09-01 14:26 +0100:

> The spec should be more clear about this, because as it’s written 
> now, the
> part that’s maybe the most important thing for authors/developers to 
> understand
> is in the note that follows the language cited above. That note says:
>
>> The HTML parser treats markup inside iframe elements as text.
>
> So if the HTML source of a document has 
> `<iframe><p>Test</p></iframe>`, an
> HTML parser puts all of that `<p>Test</p>` part into the DOM as 
> text—that
> is, there is no `p` element in the DOM for that.

That’s what the HTML parser does, but the spec makes additional 
requirements about how that text should be structured. Shouldn’t the 
validator report on violations of those rules as it does (for example) 
for invalid URLs (like `<p><a href="http://example 
.com/foo">test</a></p>`)?

> Anyway, I think times the only reason the spec actually ever allowed 
> any
> content at all in `iframe` elements was for fallback in very old 
> browsers.

It is there as a fallback, but “very old browsers” is incorrect.

Lynx, for example, still makes use of it.

![](cid:111EAF68-E0EF-49E0-A4F7-FDA3F8B90591@dorward.me.uk "lynx.png")

> Notice that for the case of HTML documents served with an XML mime 
> type,
> the spec says:
>
>> The iframe element must be empty in XML documents.

Yes, I thought that was a very odd requirement (as was removing support 
for block elements as alternative content in the HTML serialisation).

> We should probably change the spec to say that same for text/html 
> documents—
> because at this point I don’t think we have any people any more 
> using
> browsers that don’t have iframe support.

Lynx still has a loyal following. There are certain cases where I find 
it partially useful (such as when wanting to access a URL from another 
network to which I have an SSH session open).