This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 24747 - 3 questions: a) Why these many restrictions to iframe content if it ends up being treated as text? b) Why in XHTML there must be no content at all? c) Is it the same for palpable content of object ele [...]
Summary: 3 questions: a) Why these many restrictions to iframe content if it ends up b...
Status: RESOLVED WORKSFORME
Alias: None
Product: WHATWG
Classification: Unclassified
Component: HTML (show other bugs)
Version: unspecified
Hardware: Other other
: P3 normal
Target Milestone: Unsorted
Assignee: Ian 'Hixie' Hickson
QA Contact: contributor
URL: http://www.whatwg.org/specs/web-apps/...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-02-20 19:08 UTC by contributor
Modified: 2014-02-24 10:24 UTC (History)
4 users (show)

See Also:

Attachments

Description contributor 2014-02-20 19:08:58 UTC 
Specification: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-iframe-element.html
Multipage: http://www.whatwg.org/C#iframe-content-model
Complete: http://www.whatwg.org/c#iframe-content-model
Referrer: 

Comment:
3 questions: a) Why these many restrictions to iframe content if it ends up
being treated as text? b) Why in XHTML there must be no content at all? c) Is
it the same for palpable content of object elements in XHTML documents?

Posted from: 84.220.159.204
User agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1700.107 Safari/537.36
Comment 1 Ian 'Hixie' Hickson 2014-02-20 20:23:58 UTC 
a) It ends up as text only in new UAs; in (really old) legacy UAs the <iframe> element isn't recognised and so the contents get parsed normally.

b) In XHTML, it all gets parsed normally, so if there were contents it would end up in the DOM as elements.

c) I don't understand the question.

Can you elaborate on c)?
Comment 2 anakin_rendine 2014-02-21 14:59:44 UTC 
(In reply to Ian 'Hixie' Hickson from comment #1)
> a) It ends up as text only in new UAs; in (really old) legacy UAs the
> <iframe> element isn't recognised and so the contents get parsed normally.
> 
> b) In XHTML, it all gets parsed normally, so if there were contents it would
> end up in the DOM as elements.
> 
> c) I don't understand the question.
> 
> Can you elaborate on c)?

Thanks for a) and b).
About c), my request was, if there is a need that the content of <iframe> is not parsed as markup (and in XHTML there must be no content at all), is it fine that in both HTML and XHTML <object> has elements inside it?
Comment 3 Ian 'Hixie' Hickson 2014-02-21 17:38:36 UTC 
The difference is that <object> contents _are_ parsed in modern browsers, and even more importantly, the contents are _used_ when fallback is needed. So authors will be aware of its effects, and down-level users won't get unintended effects.
Comment 4 anakin_rendine 2014-02-21 17:50:19 UTC 
(In reply to Ian 'Hixie' Hickson from comment #3)
I thought that the issue was the fact that XHTML-based parsers are uncapable of distinguishing where proper markup is to be hidden rather than shown normally (a bit of the idea behind the unusability of <noscript> in XHTML). Now I see, the problem is actually in the parsing. Thank you.