Search engines and other tools can just open the iframe, so the text isn't needed.

As far as I know, there are no legacy browsers that support XHTML and don't support <iframe>.

Please reopen the bug if I am wrong on either count.

Yahoo and Bing as search engines don't open iframes, they could find it useful to show a hint to the fact that the page also consists of embedded content, exactly like an alt attribute.
Some browsers (Firefox and IE up to version 9, I think also 10 and 11 but because of technical issues I could not find out) can DISABLE iframes. Some extension in other browsers could do the same. Since it is a global setting, it could be useful if an iframe could suggest the user what kind of content could be shown.
Finally, text browsers (tested on my Elinks) show the fallback. If it is absent they show nothing.
HTML already has elements with text-only content. It's sufficient to state that in XHTML the content MUST be text, avoiding the reference to old markup content.

On what do you base the conclusion that Yahoo and Bing don't open iframes?

I can't test IE, but in at least Firefox's case, disabling <iframe>s doesn't show the contents, so that's not an argument for this change.

ELinks doesn't support XHTML at all as far as I can tell, so ELinks is also not a relevant argument for this bug.

Allowing text in iframe elements would indeed be trivial. The problem is, though, that it has no use, and therefore would be misleading authors into thinking it did something useful, and that's what we want to avoid.

(In reply to Ian 'Hixie' Hickson from comment #3)
> On what do you base the conclusion that Yahoo and Bing don't open iframes?
They don't expand the search result preview of a page to the nested browsing context's document, not even if the iframe itself is the large part of the page. They don't expand to the text content either, but if the content itself is going to disappear they will never move forward and show it.

> I can't test IE, but in at least Firefox's case, disabling <iframe>s doesn't
> show the contents, so that's not an argument for this change.
What about possible extension disabling iframes? Can you say that the content will be ignored as well? Maybe it could be useful. Again, if it remains.

> ELinks doesn't support XHTML at all as far as I can tell, so ELinks is also
> not a relevant argument for this bug.
I have version 0.11.6 for Windows and it does. Anyway polyglot documents exist and they can be served in both formats depending on UAs.

> Allowing text in iframe elements would indeed be trivial. The problem is,
> though, that it has no use, and therefore would be misleading authors into
> thinking it did something useful, and that's what we want to avoid.
It could end up being useful if it remains there. Otherwise the same could be said about all the _new_ feature which wait for support.

> They don't expand the search result preview of a page to the nested browsing
> context's document, not even if the iframe itself is the large part of the
> page.

I don't follow. Do you have an example I can look at that shows how bing handles iframes?


> They don't expand to the text content either, but if the content
> itself is going to disappear they will never move forward and show it.

I don't understand. If bing doesn't show the contents nor the frame, then why would you rather change the spec to allow text contents, rather than change bing to follow the iframe link?


> > I can't test IE, but in at least Firefox's case, disabling <iframe>s doesn't
> > show the contents, so that's not an argument for this change.
>
> What about possible extension disabling iframes? Can you say that the
> content will be ignored as well? Maybe it could be useful. Again, if it
> remains.

Disabling iframes makes your browser non-conforming. That's not legacy. If people are happy to ignore the requirements on handling iframes, why would they not be happy to ignore the requirements on how to author with iframes?


> > ELinks doesn't support XHTML at all as far as I can tell, so ELinks is also
> > not a relevant argument for this bug.
>
> I have version 0.11.6 for Windows and it does.

Can you attach a screenshot of that browser loading this page?:
   http://damowmow.com/playground/demos/xhtml/001.xhtml


> Anyway polyglot documents exist and they can be served in both formats
> depending on UAs.

Supporting polyglot documents is a non-goal.


> It could end up being useful if it remains there.

I don't understand what use it could have. Can you elaborate? What purpose is there that would not be better solved by either UAs supporting iframes completely, or not using iframes at all?


> Otherwise the same could be said about all the _new_ feature which wait
> for support.

The difference with those is that we actually want the UAs to support the new features, whereas with <iframe>, supporting the feature means ignoring the text you are saying we should allow.

(In reply to Ian 'Hixie' Hickson from comment #5)
> Do you have an example I can look at that shows how bing handles iframes?

If you trust on a page of an old website of mine
http://www.ncp-graglia.it/primopiano/primopiano_pages/4000_visite.htm
try searching: "ncp-graglia.it 4000 visite"
I can't succeed in seeing the content of the default iframe listed in the preview. If I try looking for it, I end up in the file containing the document shown inside the iframe, not the iframe's owner document.

> If bing doesn't show the contents nor the frame, then why would you rather change the spec to allow text contents, rather than change bing to follow the iframe link?

I have no voice in how a proprietary software works. What I can do is to request the responsibles of this spec NOT to support a brand-new feature, but only to extend to XHTML documents a behavior already maintained by HTML documents.

> Disabling iframes makes your browser non-conforming.

I know. But users can think that an iframe can be a potential security issue, either because they don't know about crossorigin blocks, or because their UA doesn't support sandboxed iframes. The fact is, these browsers DO allow it. So you want me to change Bing (and Yahoo). You want me to change browsers. And we can't change anything about the spec?
Anyway, browsers disabling images aren't conforming either, or at least they show something different from what was in the author's view. AND they don't even show alt attributes. But the spec keeps suggesting to use the alt attribute also because "the value of the alt attribute provides equivalent content for those who cannot process images or who have image loading disabled (i.e. it is the img element's fallback content)." The idea is, let users decide how they want to deal with potentially harmful content embedded seamlessly in a web page. And let authors specify if the content in the blocked iframe is just an adv, or the main content of the page, or side content.

> Can you attach a screenshot of that browser loading this page?

No I can't. It shows the page as text. As far as I can tell, that document has no legacy doctype, so even visual browsers would have trouble processing it.
But it loads http://www.ncp-graglia.it/selezione.xhtml

> Supporting polyglot documents is a non-goal.

For who? There are specs and rules for that, too. So those who work on polyglot documents lose their time.

> What purpose is there that would not be better solved by either UAs supporting iframes completely, or not using iframes at all?

Not using iframes at all is a non-goal. Otherwise they'd have fallen out of the spec, rather than gaining new consideration.
I'm not quite sure whether Google has done a good thing deciding to fully show iframes, as those can be used for lots of purposes. I don't know what happens when it finds out adv iframes. Or iframes containing secondary information, non-vital for the page. Anyway, like whatever embedded element in (X)HTML, iframes should have a fallback for those cases when a user agent, both AT or search engine or browser extension, prefers to show a sentence produced by the author himself, rather than connecting internal and potentially external information. In HTML this is already possible and it has been handled in a way that is not "content of HTML iframes must be ignored completely".

> we actually want the UAs to support the new features, whereas with <iframe>, supporting the feature means ignoring the text you are saying we should allow.

Also for the new elements like <meter> and <progress> you offered a fallback text, even if you want them to be implemented. I know, <iframe> is an old feature and you are not SURE that nobody in the future will exploit that text fallback. But if they do, because it is possible in HTML, why making a difference between the 2 languages?

(In reply to Andrea Rendine from comment #6)
> (In reply to Ian 'Hixie' Hickson from comment #5)
> > Do you have an example I can look at that shows how bing handles iframes?
> 
> If you trust on a page of an old website of mine
> http://www.ncp-graglia.it/primopiano/primopiano_pages/4000_visite.htm
> try searching: "ncp-graglia.it 4000 visite"

Thanks. This does indeed show that Bing neither looks at the contents of <iframe>s, unlike Google (a search for ["Commento musicale What the world needs now (is love)"] reveals the snippet "Commento musicale: "What the world needs now (is love)" (Burt Bacharach - canta Traincha). Clicca qui se non riesci a visualizzare la pagina ..." on Google but "Commento musicale: "What the world needs now (is love)" (Burt Bacharach - canta Traincha)" on Bing), nor that Bing supports returning pages that contain iframes based on the contents of the iframe (a search for ["avventura..... Con la sigla andyno, sinonimo di una grande"] on Google returns the same page as the one hit by default, whereas on Bing it returns the iframe itself).

Note that that's not an XHTML page though. It's an HTML page.


> > If bing doesn't show the contents nor the frame, then why would you
> > rather change the spec to allow text contents, rather than change
> > bing to follow the iframe link?
> 
> I have no voice in how a proprietary software works.

Right now, bing ignores the contents of iframes. So right now, putting content in iframes, for Bing, does nothing useful. So we have two paths from here:

 1. Get Bing to support <iframe>s natively.
 2. Get Bing to read the content between <iframe> and </iframe> tags.

Either way, we have to have Bing change. Hence the question, which do we think is better? Only if we think #2 is better does it make sense to change the spec's content model for XHTML <iframe>s.

It seems to me that #1 is far better than #2.


> What I can do is to
> request the responsibles of this spec NOT to support a brand-new feature,
> but only to extend to XHTML documents a behavior already maintained by HTML
> documents.

The behaviour in HTML is allowed because it does impact some legacy software. The same cannot currently be said, as far as I'm aware, for XHTML. Thus in XHTML, it would only enable authors to spend time doing something not useful. Hence the difference in the spec. It helps authors save precious time.


> > Disabling iframes makes your browser non-conforming.
> 
> I know. But users can think that an iframe can be a potential security
> issue, either because they don't know about crossorigin blocks, or because
> their UA doesn't support sandboxed iframes. The fact is, these browsers DO
> allow it.

But you're not arguing that disabling iframes should be made conforming (as far as I can tell, anyway), you are arguing that it should be conforming for authors to put content inside iframe elements in XHTML.

This seems inconsistent. Why are you concerned about authors violating the spec, but not about users violating the spec, given that the behaviour you are asking for is specifically to support users violating the spec?

I don't understand the logic here.


> So you want me to change Bing (and Yahoo). You want me to change
> browsers. And we can't change anything about the spec?

I'm not saying you should change anything. I'm saying there's no value in allowing content in XHTML <iframe> elements, because no software currently does anything with that content, and if any software is going to be changed, the way it should be changed is by making the software just support <iframe>s in the first place.


> But the spec keeps suggesting to use the alt
> attribute also because "the value of the alt attribute provides equivalent
> content for those who cannot process images or who have image loading
> disabled (i.e. it is the img element's fallback content)."

That seems unrelated to <iframe>s. There's lots of software that correctly uses <img alt> attributes, and it's conforming to do so (user agents are not required to support images, unlike <iframe>s).


> The idea is, let
> users decide how they want to deal with potentially harmful content embedded
> seamlessly in a web page.

<iframe>s can't do anything harmful that can't be done without <iframe>s, as far as I'm aware. Blocking <iframe>s is not technically a particularly interesting action.


> > Can you attach a screenshot of that browser loading this page?
> 
> No I can't. It shows the page as text.

How do you mean? (Can you attach a screenshot of whatever it does?)


> As far as I can tell, that document
> has no legacy doctype, so even visual browsers would have trouble processing
> it.

DOCTYPEs have no effect in XHTML.

But how about: http://damowmow.com/playground/demos/xhtml/002.xhtml


> But it loads http://www.ncp-graglia.it/selezione.xhtml

That page unfortunately could be parsed as HTML with no difference in behaviour, so it doesn't tell us if ELinks is actually parsing the file as XHTML or as HTML.


> > Supporting polyglot documents is a non-goal.
> 
> For whom?

For me. For the HTML spec.


> There are specs and rules for that, too. So those who work on
> polyglot documents lose their time.

Yes. There's no point working on polyglot documents.


> > What purpose is there that would not be better solved by either UAs 
> > supporting iframes completely, or not using iframes at all?
> 
> Not using iframes at all is a non-goal. Otherwise they'd have fallen out of
> the spec, rather than gaining new consideration.

Sure, I'm not saying either of those options is a goal. I just mean, given the following three options:

A. UAs supporting <iframe>s completely
B. UAs supporting <iframe> fallback in XHTML and otherwise
   doing what they do now
C. not using <iframe>s

What purpose does B address that doing either A or C instead wouldn't address?

The purposes for which we extended <iframe> (e.g. sandbox, seamless) aren't addressed by either B or C, only A.

If all the possible purposes are handled by one or both of A and C, then that means there's no point supporting B.


> Anyway, like whatever embedded element
> in (X)HTML, iframes should have a fallback for those cases when a user
> agent, both AT or search engine or browser extension, prefers to show a
> sentence produced by the author himself, rather than connecting internal and
> potentially external information.

This may be true, but that's an entirely different argument that you have been making so far. If you think we should be providing a way for users or user agents to toggle between showing <iframe>s and showing some fallback content, then please file a bug to that effect. (That bug would likely subsume this bug, but it would be a much more important issue and so we shouldn't reuse this bug for it since that would confuse other people reading up on it, especially given how long our comments here have been.)


> In HTML this is already possible

No, in HTML it is not conforming to not support <iframe>s. The only legal behaviour for an HTML user agent with the contents of <iframe>s is to ignore the contents.


> and it
> has been handled in a way that is not "content of HTML iframes must be
> ignored completely".

That's exactly what the spec says (in different words: "Descendants of iframe elements represent nothing.").


> Also for the new elements like <meter> and <progress> you offered a fallback
> text, even if you want them to be implemented.

Right, because that content _is_ shown in legacy UAs (HTML and XHTML), just like the content of <iframe>s in HTML UAs. <iframe> is special only in that its contents are _not_ shown in any legacy XHTML UAs, and in that the parsing rules for <iframe> in HTML are very unusual.


> I know, <iframe> is an old
> feature and you are not SURE that nobody in the future will exploit that
> text fallback. But if they do, because it is possible in HTML, why making a
> difference between the 2 languages?

Because the element is parsed radically differently in the two languages. For example, in XHTML UAs (legacy or modern), this shows an alert:

   <iframe><script>alert('surprise')</script></iframe>

...but it doesn't in modern HTML UAs.

Please reopen the bug if I have overlooked something here. Thanks.