[Greasemonkey] Long literal strings of html

Julien Couvreur julien.couvreur at gmail.com
Wed Apr 20 15:47:06 EDT 2005


On 4/20/05, Steve Krulewitz <shooz at mm.st> wrote:
> /*
> ==String:<varname>==
> ...
> ==/String==
> ==String:<varname2>==
> ...
> ==/String==
> */

+1
I like this approach better (like you said: one comment can contain
multiple literal strings).
Also in the other proposed solution, /*= can appear by accident if you
format a comment with /*===============

Just to clarify, the return characters  after ==String:<varname>== and
before ==/String== would not count as part of the literal string.

For example:
==String:<varname>==
ABC
==/String==
represents the string "ABC", not "\rABC\r".


> Whatever we chose, care will have to be taken to allow for the embedding
> of the literal string delimiters as well as JavaScript comment tokens in
> the text block.

The only sequences that need to be escaped are ==String:, ==/String==, /* and */
I think we don't really need to provide solutions for escaping any of these...
==String: and ==/String== are pretty rare.
You can use // comments instead of /* and */ in the javascript in your
literal string.


> Another possibility that we haven't talked about yet is using this to
> embed images or other binary data.  We could allow for MIME encoding,
> and perhaps make a gm_GetLiteralStringAsDataUrl(name) method?  It might
> look like:

If you go thru the trouble of base64 encoding the gif, you might as
well put the data: url "header" on it too. So I don't think that is
needed.
On the other hand, we discussed having a tool like the hixie page that
would make generating such literal strings easy, especially when you
have more than 1 file (maybe a whole directory of images).


Cheers,
Julien


More information about the Greasemonkey mailing list