AndySky21

And I hope that somebody else in this forum reads this post, and perhaps more developers can agree and maybe suggest to the HTML5 W3 editors to either drop off @srcdoc completely due to its inconsistency, difficulty and limited use, or (which would be more reasonable) to substitute it with internal content, maybe with variations from my idea depending on technology limits. Basically I believe that even if competent authors work on the project, this does not prevent authors to suggest sensible changes (and in an answer also WHATWG HTML Living Standard editor Ian Hickson seemed to suggest the same: https://www.w3.org/Bugs/Public/show_bug.cgi?id=24785#c7, "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.") and I don't think that you and several other idealistic author have, at least once, thought "well this feature really doesn't work and I can do something to improve it" about something. That is exactly what I wanted to say about PHP. If content is meant to be static, then it can be served by PHP and it is not about "embedded" content. If it located in a specific DOM subtree, then it can be done via <iframe> and JS is not really useful in that situation. JS is useful when a DOM traversing and manipulation in several points is requested, otherwise a page can live on its own with HTML and CSS. Thanks for having stated it clearly, though.

Initially I also thought like that, but I'm no longer that sure. So even if I appreciate your suggestion to use server-side languages like PHP "include" in order to provide content inclusion, of course they are different things and can (and must) be used differently. If embedded content is to be dynamically changed, server-side inclusion is useless. While <iframe> can be changed via simple link targeting the nested browsing context. Thus said, I suggest you to look at the example in the specs for @srcdoc. Embedded comments in a page, which can also include user-provided links to external content while the author prefers to open them in a safer environment. Or a user's page which allows to embed user-provided scripts while the author himself doesn't want said scripts to interact with the website. Sometimes an additional browsing context is desirable, but at the same time having an additional, initially empty element is not exactly the best choice. On the other side, having the server which elaborates and serves a new document for every fragment (e.g. a document for every comment, where there can be really many comments) consumes too much bandwidth, needs a separate request to the server for every instance and is globally a poor choice. Having such parts of content present in the page makes them instantly available, and they are more maintainable when the site needs manual integrations. Also think that having said elements directly embedded in the page would allow them to interact, e.g. with semantic markup already present in the iframe's owner document. Last consideration, in my opinion your argument involving backward compatibility aren't so compelling. Having the @src attribute taking precedence over <iframe> content would allow old pages to survive with the intended design, while the new feature would be effective only in newly designed webpages, where <iframe> could have the src attribute not defined initially (or auto-referring, this could be a way to show the content again: i.e., <iframe id="embedded" name="embedded" src="#embedded"><p>initial embedded content</p></iframe>) for the purpose of showing content. The actual idea of having @srcdoc prevailing over @src seems pointless to me. And of course if I use an attribute it would silly to have Javascript necessarily processing this attribute. Elements and attribute, except from data-* attributes, MUST have potential native support in UAs. Otherwise they are useless. Actually this use of initial content would also be perfectly compatible with fallback content the way it was meant. Fallback content is ALWAYS NEEDED for embedded content, as img and object cases underline, but it is now absurdly useless as elements are parsed as text and in XHTML documents it is not allowed. Like it made any difference if the document is HTML or XHTML! The author says that no UAs capable of showing proper XHTML aren't unable to show iframes. But he fails to understand that data mining tools, search engines, page crawlers, data extracting scripts are user agents too and they could take advantage in having a fallback for external content. And this way we would have a fallback which is both useful if a content is not defined, AND useful if the content is defined but the user agent cannot fetch it. THIS is why @srcdoc is fruitless. Because authors had the perfect substitute for it, only 100 times more powerful and easier, and they discarded it due to their short sight.

I'm also against the srcdoc attribute (I use the form @srcdoc in order to mean that it's an attribute, conventionally). But there are use cases for initial content in iframes, I just ask myself why using an attribute instead of native element content. Anyway, why are you against the iframe element? It allows a webpage to call other pages relying on basic language, instead of making use of Javascript XmlHttpRequest, which is the right way to work in my opinion.I'll state my question in other terms. Given that I have to use <iframe> in some points of the page, namely as a nested (secured) browsing context, and given that I could also need an initial content, wouldn't it be better if such content were defined at a markup-level instead of at an attribute-level? Does anyone know whether this has been proposed and why things don't work this way?

I wasn't clear perhaps. I refer tosrcdoc attribute in (X)HTML document, element iframe, spec HTML5 (http://www.w3.org/TR/html5/embedded-content-0.html#attr-iframe-srcdoc) - defines markup which has to be parsed twice and constitutes base document for <iframe> seamless attribute in (X)HTML document, element iframe, spec HTML5 (http://www.w3.org/TR/html5/embedded-content-0.html#attr-iframe-seamless) - boolean attribute, tells the browser whether to show the <iframe> document as if it were part of the iframe's owner document

Hi guys! I just went through difficult maintenance for a website project involving iframes with the necessity of short, not embedded initial content. I was using @srcdoc and it already was difficult enough as syntax rules. Then I changed mime type for the pages, converting them into proper XHTML, and the result was confusing and terrible: Syntax adjustments for the "markup model" inside the attribute's value made me double the length of the value. It is not checked by validator, so predicting errors is difficult. It relies on the support of @seamless in order to match the design of the page, or otherwise it needs style declaration/stylesheet embedding which make it longer and impact on page loading while using several iframes in the page. Anyway using both could lead to conflicts during the (future, eventual) transition phase when @seamless is implemented on some UAs but not all and/or we'll have to face both support and backward compatibility. inserting semantic markup is too long because it ends up being treated as external document, so there must me a link reference to the main argument which is pointless (IMO), as the content is actually part of the page containing the main argument itself. XML serialization is wrong also in those browsers which currently support @srcdoc: Firefox always parses it as HTML, while the other ones complete the srcdoc document with tags missing (following the spec rules about tag omission in text/html) also where this is not requested. @srcdoc syntax is difficult to find, read, parse and serialize for any client different from browsers, i.e. search engines, data mining tools, scripts which fetch documents, and even for the authors themselves which have to write proper scripts for retrieving data (perhaps from databases) and insert them in a so particular position (with a special syntax inside an attribute) it is theoretically confusing because it mixes elements and attributes. It forces authors to write unmaintainable document fragments, also denying them the use of common editing aids like indentation and markup highlighting. These reasons and many more make iframe@srcdoc practically unusable now and in the near future. It is not a case that in webpages fetched by webdevdata as of october 2013 no use of @srcdoc has ever been made. And I suppose neither is a case that iframe@srcdoc is the very only feature making use of a "markup model" inside an attribute value. Now, iframe is not a void element: the restrictions on content, different between HTML (content model: text) and XHTML (content model: empty) documents, have been introduced with HTML5. Has anyone ever thought that the very same results of @srcdoc, with better, richer and more practical result using the native <iframe>'s content?