IFrame

[anonymous]

If an iframe added to the wiki, via the HTML formatter, this is not viewed.

[Emmanuel Blot]

<IFRAME> has been deprecated in XHTML 1.1 and Trac produces XHTML 1.0 strict code. There are few chances Trac will ever support iframes as long as it produces XHTML.

Ref: ​http://liorean.web-graphics.com/xhtml/comparison.loose-strict.html

[Christopher Lenz]

Well, we don't produce XHTML 1.1, so using <iframe> should be perfectly legal. We're probably being too paranoid there.

[Emmanuel Blot]

Well, we don't produce XHTML 1.1, so using <iframe> should be perfectly legal. We're probably being too paranoid there.

We need to check that <iframe> is legal for 1.0 STRICT, I'm not sure it is (I did not find the info from the official w3c web site). It is illegal with XHTML 1.1 *, but I'm not sure it is even legal in 1.0 STRICT (i.e. perhaps it is only legal in XHTML 1.0 transitional, which we do not support).

Moreover, <iframe> is "officially" not recommended (I need to find the reference…) because it is known to cause several issues with several well known browsers, so I'm not sure it is worth adding it to Trac.

I'll try to find some official references about the above point.
(as a side note: I can't quote your comment, the Safari+"ticket reply" bug is back)

[Emmanuel Blot]

Actually, <iframe> is not legal in XHTML 1.0 ​strict, only valid in XHTML 1.0 ​transitional.

[Christopher Lenz]

Replying to eblot:

Actually, <iframe> is not legal in XHTML 1.0 ​strict, only valid in XHTML 1.0 ​transitional.

Okay, I forgot about that. I agree with your original resolution then.

[ThurnerRupert <rupert.thurner@…>]

some links to iframe and xhtml strict:

• ​http://archivist.incutio.com/viewlist/css-discuss/42402
• ​http://archivist.incutio.com/viewlist/css-discuss/42408

[anonymous]

What is the accepted mechanism for embedding other html inline on Trac pages?

The expected answer of "You shouldn't do that," while a quick and easy solution from a Trac developer's perspective, is hardly acceptable from a user perspective.

If someone is savvy enough to install Trac and use the html processor, one would imagine they're savvy enough to know not to include dangerous embedded content.

Regardless, that isn't really the decision for Trac developers to make for the entire Trac user community.

[Emmanuel Blot]

Replying to anonymous:

What is the accepted mechanism for embedding other html inline on Trac pages?

HTML: you should not. XHTML/strict, you may use {{{#!html ... }}} blocks.

If someone is savvy enough to install Trac and use the html processor, one would imagine they're savvy enough to know not to include dangerous embedded content.

There are options (see TracIni) to disable sanitization of the inlined XHTML code. It does not mean you can write invalid HTML code, you'll still need to write proper XHTML - it will be displayed as expected.

Regardless, that isn't really the decision for Trac developers to make for the entire Trac user community.

No it's a technical limitation: you cannot embed some PDF file into a JPEG image, can you? This is the same for Trac: if you'd use HTML, the resulting output would be an invalid stream from a w3c perspective.

[anonymous]

The assertion likening this issue to embedding a PDF file into a JPEG image is entirely spurious. We're not talking about a binary file format. Whether XHTML or HTML, we're talking about a markup language. The entire point of it is to embed objects into it. Every element of XHTML represents an object that is part of an interpreted stream of data in the markup code. You want to be able to embed that JPEG image into a page, right? Why wouldn't I want to be able to embed a piece of formatted text from another place on the Trac wiki the same way?

Perhaps my question about "embedding" something in a Trac wiki page was not clear. I mean in the exact same way you embed an external image in the XHTML stream, what is the accepted way of embedding an external snippet of XHTML into a Trac wiki page? If you're saying that isn't possible without modifying these sanitization options, or if there's some other mechanism, that's fine. But I think that's clearly a major limitation, and this is definitely a bug, or at least a sorely lacking feature, even if it points to a deep underlying design flaw in Trac. At the very least, I should be able to embed in an iframe or an object tag other pages from the wiki. I don't think that's dangerous or something unreasonable to expect from the system.

[Emmanuel Blot]

Replying to anonymous:

Whether XHTML or HTML, we're talking about a markup language.

Yes, but incompatible ones.

The entire point of it is to embed objects into it. Why wouldn't I want to be able to embed a piece of formatted text from another place on the Trac wiki the same way?

If you want to embed the code, it's quite easy: a !xml block would suffice.
If you want the code to be rendered by the browser, you need to tell the browser: this part of the stream is XHTML, this embedded section is HTML. I'm not sure it is possible. You can try doing this with <embed> or <object> tags.

At the very least, I should be able to embed in an iframe or an object tag other pages from the wiki.

<iframe> is not a valid tag in XHTML. That's it, you can request for it, but it is not part of the standard, Trac complies with W3C standards. What to add?

You want to add something invalid. Call it a bug if you like, but it is definitely not a bug.
At best (or worse, YMMV) it's a design choice of producing a XHTML rather than a HTML stream.

[anonymous]

Using the latest version of Trac, I was able to turn off the sanitization of the XHTML stream, and it turns out including the wiki pages in an iframe or an object wasn't the right solution anyway, because the included pages had all the normal wiki headers and footers.

What I was able to do was use an XMLHttpRequest to parse out the content div of the wiki page I wanted to include on the parent. Here's some code for reference, in case anyone else needs a similar solution:

This is a list of features in Relase 1:

You'd actually need to strip off the form elements of the response to do it right, and place the node at the right point in the parent DOM, but this gets across the idea.

[anonymous]

This is the code referenced in the comment above:

open brace, open brace, open brace
hash-bang html

<div id="Release1"></div>

<script>
var req;
var a;
req = new XMLHttpRequest();
req.onreadystatechange=function()
{
if(req.readyState==4)
  {
    f = req.responseXML;
    c = document.getElementById("content");
    c.insertBefore(f.getElementById("content"), c.firstChild);
  }
}
req.open('GET', 'http://hadoop00.corp.millennialmedia.com/projects/mm/wiki/Feature1', true);
req.overrideMimeType('text/xml');
req.send(null);

</script>

close brace, close brace, close brace

[Noah Kantrowitz]

It sounds like what you are looking for is the ​Include macro which lets you include one wiki page in another.

[allyourcode@…]

I know iframe is not supported, but it'd be nice if there was some way to embed external resources like a Google Calendar. What is the recommended way of doing this?

[skull]

bump:

the lack of this feature is VERY anoying since sanitization breaks mostly anything usefull (i.e. things that you cannot produce using the wiki formatter) :

• can't use iframe
• can't use object
• cant use an external stylesheet
• can't embed one either…

actually, i really believe it is much more unsafe to allow html embeds using the wiki syntax than use iframes or equivalent XHTML valid tags (object i guess) which definitely cannot break the parent page and let the writer use any document type that a browser can handle.

[Christian Boos]

Well, in order to move the discussion past comment:12, we could consider that the <iframe> is making a comeback via ​HTML5, so we might support that once we get HTML5 support (probably requires ​#G108 first).

[mmitar@…]

I would just add that using render_unsafe_content you can include iframe with {{{#!html ... }}}. At least in my 0.12 installation.

[lkraav <leho@…>]

Is there no render_unsafe_content for Ticket system? I'm trying to render <iframe> in a ticket comment.

[lkraav <leho@…>]

Nevermind. Ticket system, somewhat non-obviously, uses wikiformatter's setting for this.

[anonymous]

So, is there a solution to incorporate a google calendar item (<iframe>), any alternative? Thanks

[Carsten Klein <trancesilken@…>]

Replying to anonymous:

How about a Django like approach, e.g. at the trac plugin / macro / processor level, one would use safe_content(HTML.IFRAME(src=…, …)) with Genshi then rendering out the content as is without filtering it out in during one of the sanitation steps?