Jump to content

AndySky21

Members
  • Content Count

    5
  • Joined

  • Last visited

Community Reputation

0 Neutral

About AndySky21

  • Rank
    Newbie
  • Birthday 06/21/1988

Previous Fields

  • Languages
    HTML and mainly XHTML, CSS, some Javascript, some PHP

Contact Methods

  • MSN
    anakin_rendine@live.it

Profile Information

  • Location
    Italy
  • Interests
    Frontend development, basic interactive pages, spec questioning.
  1. 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 sa
  2. 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 exte
  3. 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)
  4. 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
  5. 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,
×
×
  • Create New...