If it's just a table, have you eliminated everything but the table? Or do you need other elements and have just removed the header?
The data protocol was/is intended for snippets of HTML.
Browser limitations generally point to need to test (with JS?) so that alternate code can be used. Same with the CSS. Hard to say without seeing the code.
What version of FMP/FMS are you using for IWP?
-- sent from my iPhone4 --
On FireFox, you could install the Firebug extension to inspect the code (IWP HTML + embedded HTML of the WV).
I have a <body> tag enclosing the elements, with inline styles. Here's a snippet (the tables are sometimes a little long):
<body style='font-family: tahoma, arial, helvetica, sans-serif; font-size: 12px;'>
<div style='text-align:center; font-weight: bolder; font-size; 18px; color: #3b5e33;' >Veterans Enrolled between 1/1/2012 and 12/31/2012</div>
<table style='border: thin #333 outset; border-collapse: collapse; font-size: 10px;' border='none' cellpadding='3' width='100%'>
<td style='border: thin #333 outset; text-align:center; font-weight: bolder; background-color:#7b9e73;'>Last Name</td>
<td style='border: thin #333 outset; text-align:center; font-weight: bolder; background-color:#7b9e73;'>First Name</td>
<td style='border: thin #333 outset; text-align:center; font-weight: bolder; background-color:#7b9e73;'>HMIS #</td>
<td style='border: thin #333 outset; text-align:center; font-weight: bolder; background-color:#7b9e73;'>Primary Phone</td></tr>
<tr><td colspan='4' style='border: thin #333 outset; font-weight: bolder; background-color:#7b9e73;'>Notes</td></tr>
<tr><td style='border: thin #333 outset;'>(last name)</td>
<td style='border: thin #333 outset;'>(first name)</td>
<td style='border: thin #333 outset;'>(registration number)</td>
<td style='border: thin #333 outset; text-align:center;'>(phone)</td></tr>
<tr><td colspan='4' style='border: thin #333 outset;'><br /><br /><br /></td></tr>
I'm on version 12, Pro and Server.
Thanks, Martin. Just doing a "view source" gives me this:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN" "http://www.w3.org/TR/html4/frameset.dtd">
<meta http-equiv="content-type" content="text/html; charset=utf-8">
<link href="res/favicon.ico" rel="SHORTCUT ICON">
if(window.iwp != null && window.iwp.setupTopFrame != null)
window.iwp.setupTopFrame( false, false );
<meta http-equiv="refresh" content="1; URL=/fmi/iwp/cgi?-noscript">
<frameset border="0" bordercolor="#D4D0C8" rows="12,*" frameborder="NO" framespacing="0" cols="*" onunload="window.iwp.handleUnload()">
<frame title="Toggle status area" id="controlFrame" frameborder="no" marginheight="0" marginwidth="0" name="controlFrame2" noresize scrolling="NO" src="res/control_frame.html">
<frame title="Database contents" frameborder="no" marginheight="0" marginwidth="0" name="bodyFrame2" src="/fmi/iwp/cgi?-open">
I get basically the same thing on Explorer. It captures my opening and closing <body> tags, but then ... nothing. Would Firebug show me something different?
Not sure about HTML 4.01 and framesets . . .
Yeah, me neither. Tell FileMaker. That's how they implemented web viewers in IWP.
1 of 1 people found this helpful
The sample HTML data was helpful - thanks for including it.
I can not speak with respect to IE, but I have observed that Firefox on OSX is choking on the # chars included throughout your HTML code. This appears to be the case regardless of whether the WebViewer has been configured to encode the URL.
A potential workaround appears to be:
Escape the # chars yourself, i.e. if the page is being served to a web client, then substitute # chars in your data url with the appropriate escape sequence of: %23
I'll attach a sample file to illustrate.
I'd be interested in knowing whether this appears to be a valid workaround for IE, as well. Since there is always the possibility that there may be a larger set of characters which are going to choke the clients, the work may not yet be done here, but I think it is a start in a good direction.
Tested over here using:
FMPA 12.0 v1 (IWP served from FMPA, not FMS)
Google Chrome 19.0.1084.53
Reference I used to check my thoughts about proper escape sequences in data URL:
rather than escaping the # throughout, I think I'd add a class to CSS style and call it in the table where needed. but if IE does choke on it, you only have one place to change the style! this also has the advantage of cutting down in the number of characters in the code (helpful with data URLs).
Here's my reference on data: (protocol) URLs:
data: URLs are defined by RFC 2397 (http://www.faqs.org/rfcs/rfc2397.html) , and are described as:
Some applications that use URLs also have a need to embed (small) media type data directly inline. This document defines a new URL scheme that would work like 'immediate addressing'. The URLs are of the form:
The URLs allow content creators to embed small files inline HTML documents, without complicated, document level formatting...
search for 'RFC2397' and/or 'data urls' for many links in addition to the faq above and Steve's wikipedia link.
Hey, Steve, thanks. That does indeed help on Firefox. IE, on the other hand, is still blowing up. It echoes the code out to the browser, and View Source reveals the "%23" string in front of every character, just like it should. But the web viewer is still blank.
Any other ideas?
Thanks, Beverly. I did something similar - created a variable at the head and just echoed that out.
Still no joy, though. IE is still giving me the royal "STOP" sign.
Thanks for the extra information. Until reading your post and taking a look at the RFC that you cited, I never really thought about size restrictions for the data URLs -- that's real helpful to know, and I'm glad to be aware of it.
As for centralizing the style definitions into one or two CSS classes, I'm all for that. I got the feeling from Mike's post that he might have already been doing that, but that in trying to experiment with getting it to work across all browsers he might have switched to the inline styles just to see if it worked any better.
Thanks again for the tip on the data URL.
Yes, Steve, I did have a stylesheet embedded in the document header ... when there was one. Stripped it back out and went to inline styles trying to get it to work across browsers, just like you said.
Right now, I'm even having trouble getting the solution to work consistently on Windows 7 - on any browser. I'm really beginning to develop an antipathy for IWP ...
Originally I was thinking about pursuing the idea that other chars may need to be escaped within the data URL to get this to work with IE.
Then I stopped and re-read the information at:
The above wiki article mentions that IE8 and IE9 provide only limited support for the data URL functionality.
In particular, the claim is that such URLs can be used for a small range of purposes:
link(data URI must be base64 encoded)
- CSS declarations that accept a URL, such as
The implication is therefore that IE will not support the data URL as we are trying to use it, namely, to populate the contents of an iframe element.
I poked around a bit to see if I could find any documentation to confirm this claim.
This page: http://msdn.microsoft.com/en-us/library/cc848897%28v=vs.85%29.aspx makes the same claim.
In particular, it states:
"For security reasons, data URIs are restricted to downloaded resources. Data URIs cannot be used for navigation, for scripting, or to populate frame or iframe elements."
The above was kind of a bummer to find out, but at least it means we can avoid banging our head against a wall that isn't going to move.
Message edited by: steve_ssh. Reason: Original message was longer and less helpful.
I appreciate your help on this. Your first example is right.
If you want to give the Opera checker another shot, by all means. I'd love the help. Right now, I'm getting a vicious hangup on one report that has to be fixed before I go any further. I can ask the users to load Chrome, but I can't deal with the system hanging up when they try to run a report.