I want to create data on the fly in a tooltip and not from a source such as an external file or a hidden div. Something like:

<img class="fbTooltip" data-fb-tooltip="contents:&#039;This is dymanically created data.&#039;" src="tulip.png"/>

The contents will be generated via PHP and be placed in a variable.

Thanks,
Steve

Easy. Just make sure the text to show has at least one HTML element in it, and assign that text to the 'source' option.

<img class="fbTooltip" data-fb-tooltip="source:`&lt;span&gt;This is dymanically created data.&lt;/span&gt;`" src="tulip.png"/>

The back-quotes are needed so that Floatbox can parse the option string correctly and the HTML entities like < and > must be encoded so the browser can parse the HTML correctly.

The Floatbox configurator actually does just this. It has a copy of the Options Reference attached to it below the big table. The initHelp() function constructs a direct HTML tooltip for each table cell by finding the corresponding Reference entry and assigning an encoded copy of that to the options of a dynamically created tooltip host in the table cell.

Thanks - That worked fine using the back-quotes. I searched every bit of documentation and couldn't find that information but I bet it's in there somewhere.

Do the HTML entities really need to be encoded? I tried it without encoding and it seemed to work properly although my editor did complain.

<img class="fbTooltip" data-fb-tooltip="source:`<span>This is dynamically created data.</span>`" src="tulip.png"/>

It's easy to encode, I just wondered if it is really necessary.

The documentation is deficient in this regard. The HTML section of the instructions says only

Quote

A string of direct HTML can be used as the source parameter to the fb.start() API function. Direct HTML content must include at least one each of '<' and '>' to be recognized as HTML content.

While this is true as far as it goes, direct HTML is not limited to the fb.start function, but can also be assigned to the source option. I'll rewrite that section.

Yes, encode html entities. You can probably get away with unencoded < and > in modern browsers. But are you positive there are no parsers out there that will terminate the open <img element at the first > character encountered in an attribute such as "go >>> here"? I'm pretty sure some older parsers did exactly that.

You most definitely have to encode " to &quot; so as not to terminate the attribute value prematurely and bare ampersands need to be encoded to &amp; in order to avoid parser warnings. Un-encoded < and > will likely work but encoded will definitely work, and you have to encode the others anyway so there's no point excluding these two.