From Web Education Community Group
Jump to: navigation, search

A proposal for the initial content

When I looked for the "iframe" page I already wanted to post my opinion about it. Then I saw the examples and the error which was made inside it (unescaped quotes in the srcdoc attribute) and I decided that I had to say something. Does anyone in this community knows why on earth an attribute has been chosen to do the work that markup should do? The Srcdoc attribute is a good thing done the worst way:

  1. it forces authors to write a document, or at least a document fragment as attribute value and makes it badly readable (and maintainable)
    • WYSIWYG editors cannot handle this attribute, because they cannot insert elements as attribute values;
    • code editors can, but often the useful visual syntax highlight is lost inside attribute values;
    • code snippets processing data that is to be served as @srcdoc need additional rules for entities escaping, which are completely useless in any other context;
  2. as far as the seamless attribute is not fully supported by browsers with the styles inherited by nested documents, it cannot have a nice visual layout, or better, it relies either on long style declarations (which become even longer due to the syntax constraints) or on links to external stylesheets (which make the document structure heavier and can also impact on the page load time).
  3. it requires in all cases strange and long escaping of characters (" for all attribute quoted values and for quotes in prose, double escaping for reserved characters in some cases and almost always for ampersand) and leads to more possible errors;
  4. in XHTML, and therefore also in polyglot documents (I'm interested in serving XHTML as HTML for those UAs which don't support XHTML) the character "open angle bracket - less than" is not allowed in attribute values. So EACH AND EVERY element must have its tags' starting character escaped. In order to be sure that "closed angle bracket - greather than" does not lead to premature element closure, this character should be escaped too. So if I am to write
    <p>Hello <b>world</b></p>
    in a @srcdoc inside an XHTML document I have to write it as
    &lt;p&gt;Hello &lt;b&gt;world&lt;/b&gt;&lt;/p&gt;
    ... Guess what happens in longer cases!
  5. the value cannot be a fragment, it is meant to be an entire document! And if in HTML documents, authors can rely on tag omission in order to shorten the value, (e.g. omitting <html>, <head> and <body> altogether and focusing on content), in XHTML tags are not omissible for what I know, or at least an incomplete document (without <html> as root, explicit <head> and <body> start/end tags) shouldn't be treated as XHTML. Moreover, without a root element it should also be invalid.
    • actually browsers which support @srcdoc always complete the document defined in the attribute as the tags were optional in XHTML too. And Firefox, as I saw, always serializes it as HTML, e.g. ignoring self-closing syntax.
  6. "elements" inside @srcdoc are always kept out of any document-level data analysis. I don't know about Google search results, as Google resolves <iframe@src> maybe it also serializes <iframe@srcdoc>. Apart from that, @srcdoc cannot be read by data mining tools, is not validated by validators (apart from entities escaping) and cannot be enriched via Semantic Markup: developing @srcdoc as document (fragment) is a passage that only a web parser can successfully do. A script which reads markup, unless instructed to parse the attribute, cannot read neither RDFa nor Microdata or the like, because for an instrument which is unaware of HTML mechanics, that text is only text and it's only an attribute. And even if an instrument were capable of parsing it, such user agent will NOT refer the resulting metadata to the parent document.

The very same effect could be obtained BETTER using the content of the iframe element and giving priority to the src attribute, so an iframe would show the content if it had no @src defined or maybe if @src had a value which refers to the content (e.g., a document fragment identifier matching the iframe's ID attribute value). What is your opinion about this? I know that there are limitations about previous usages of iframe's content and about current support for it, but I hope there will be someone to discuss them with.

--Andy Rendy (talk) 12:11, 27 March 2014 (UTC)