h14 / jsprettify Goto Github PK

prettifyHtml currently operates by returning a prettified deep clone of the 
DOM subtree it's told to prettify. The theory is that this makes it more 
"functional" in the sense of referentially transparent---prettifyHtml has no 
side effects, making it easier to test, analyze, and reason about.

Unfortunately, this breaks down in practice since the common case is to 
simply replace the old subtree with the new one anyway, and this turns out to 
be a pretty huge side effect. In particular, only the DOM content is cloned, 
and not any event listeners (unverified), references to the originals 
(verified; causes problems, see issue 28), et cetera. So, prettifyHtml should 
be changed to operate in place; if the former behavior is for some reason 
desired, it can just be given a pre-cloned subtree anyway.

This issue was created by revision f81d190748.

The test for prettifying quotes at the start of the line is broken: it assumes
greedy replacement, so this revision causes it to fail.

Update issue 14
The test case specified now passes, but the issue is still outstanding, as
evidenced by the failure of testMatchesQuotesAcrossTags. This will probably
require some extra fiddling with prettifyHtml and prettifyStr alike.

This issue was created by revision a689788e57.

This string:
  '"Here I am", said Sam'
Should look like:
  ‘“Here I am”, said Sam’
But looks like:
  ‘"Here I am”, said Sam’

What steps will reproduce the problem?

1. Type a sentence containing a word with a contraction at the
   beginning, such as some Macbeth:

    If it were done when 'tis done, then 'twere well
    It were done quickly.

2. Use the bookmarklet.

What is the expected output? What do you see instead?

I expect:

    If it were done when ’tis done, then ’twere well
    It were done quickly.

I see:

    If it were done when ‘tis done, then ‘twere well
    It were done quickly.

Please provide any additional information below.

Pandoc does this properly when you pass --smart to it.

Buzz appears to use textareas for its input fields, but for some reason the 
bookmarklet can't fix typography inside of them. Note that the bookmarklet 
works fine with GTalk IM windows.

This issue was created by revision 7fc65bdcc8.

The string:
  ("")
Should look like:
  (“”)
But looks like:
  ("")

And similar with single quotes.

Right now, the bookmarklet is limited to text fields. It'd be nice if it also 
handled rich content. One way to do that is to find fields that have 
contentEditable set, and pass them through prettifyHtml. This is a reasonable 
stop-gap approach on the way to getting full dynamic prettification of rich 
content.

This issue was created by revision 41b665ba49.

The string:
  "/"
Should look like:
  “/”
But looks like:
  ”/”

We sometimes want to quote punctuation characters, but we also don't
want them to interfere with other quoted phrases. This and the test
before it might together make the case for making the double quote
matcher non-greedy.

The example.html demo is boring and static. It should be a textarea that 
live-updates an output box containing the prettified version of the input 
text.

The string:
  'x "x 'x "x 'x "x" x' x" x' x" x'
Should look like:
  ’x “x ’x “x ’x “x” x’ x” x’ x” x’
But looks like:
  ‘x “x ‘x “x ’x “x” x’ x” x’ x” x’

Revision 374c3ed4f634 introduces a failing test for this. It takes 6 levels 
of nesting to trigger this.

When a site includes both jsprettify and Hyphenator.js 
<http://code.google.com/p/hyphenator>, hyphenated blocks will have their 
CSS visibility set to "hidden" after the page has finished loading -- that 
is, they won't be visible.

It looks like this is a problem with the currently recommended manner of 
calling jsprettify (assigning it as the onload function). As a workaround, 
remove this script block from the document head:
    <script>
      window.onload = window.prettify;
    </script>
And add this as the very last element in the document body:
    <script>
      window.prettify();
    </script>

This at least appears to work. Probably we should make jsprettify callable 
via window.jsprettify.run(); or something though.

jsPrettify should support TeX-style quotes (``'') and should implement 
dumb-quote prettification in terms of a dumb-to-TeX conversion step.

The advantage here is that prettifyStr would get a lot simpler with quote 
matching factored into a different function---just simple string 
replacements without any advanced RegExp voodoo.

One possible problem: TeX quotes are sometimes ambiguous. Does ```''' mean 
“‘’” or ‘“”’? The obvious answer is to always assume 
double-in-single for 
cases like this, but it's uncertain if that will cause problems.

Pulling out the quote matching into its own function also means we can get 
fancier with it without cluttering prettifyStr. We can also be greedier 
with prettifyStr: we only ever need to track local context when prettifying 
e.g. a text input being typed into, whereas the current implementation 
needs the whole string---prohibitive if we're prettifying a large document 
as it's being edited.

What steps will reproduce the problem?
1. Go to Facebook.com
2. Type some text.
3. Use the bookmarklet.

What is the expected output? What do you see instead?
Expected: your text is prettified.
Instead: nothing happens; on some pages, Facebook throws an alert at you.

Please use labels and text to provide additional information.
This appears to be a recent occurrence; my best guess is that some Facebook 
code isn't playing nicely with Closure.

Noticed in Chrome on Linux.

This issue was created by revision a08b291721.

By having the bookmarklet grab a copy of prettify-comp.js from Google
Code, we could ensure that I wasn't doing anything malicious: any
modification made to the script would show up in the revision log. Now,
there's nothing stopping me from redirecting the script to evil.js which
harvests your credentials and sends profane emails to your boss.
Granted, I promise not to, but if you're paranoid, that might not bew
good enough.

Ideally, we could verify a hash or signature on the script file to
ensure it hadn't been tampered with. This is hard to do in a
bookmarklet, though, especially since XSS rules prevent us from
launching XMLHttpRequests to other domains (e.g. to grab the source
code).

bookmarklet.sh is doing things that could be trivially done in Perl instead. 
This makes it redundant; make_bookmarklet.pl should be modified and 
bookmarklet.sh removed.

This issue was created by revision d864a1da09.

When a contraction is surrounded by single quotes, jsprettify doesn't
catch the opening single quote.

Historically, the way to call jsprettify functions was with window.foo for 
foo in jsprettify. This polluted the global namespace, meaning that anyone 
else who wanted to define window.prettifyStr (for instance) would get 
clobbered. The new way to call jsprettify functions is window.jsprettify.foo, 
and as of rev 66cefaa067, the old way will now throw up an alert box. At some 
point, the old functions will be removed completely.

jsPrettify's prettifyHtml doesn't work in IE 7, 8, or 9 preview. Looks like I 
got so caught up in excitement over it working in IE6 that I never bothered 
with anything else. hg bisect reveals that it's never worked in IE7+.

The bookmarklet currently just replaces text in textareas and input fields. 
This doesn't work in rich edit fields like Google Docs. We might need to use 
jsprettify.prettifyHtml instead, and examine the rich editing forms to see 
what they're doing.

prettifyHtml is a little tricky. Our main benchmark for comparison, 
Hyphenator.js, appears to injudiciously hyphenate the entire document, tags 
and links included (correct me if I'm wrong.) In our case, we can't, since 
we're mucking with quotes. Instead, we need to walk the DOM tree and 
prettify e.g. all children of the requested node who have nodeType Text. We 
may have to do something special if some text nodes are bad to prettify.

What steps will reproduce the problem?
1. Go to the page of an event with multiple guests on Google Calendar.
2. Click the "Email Guests" link.
3. Use the jsPrettify bookmarklet on the form; now try to submit it.

What is the expected output? What do you see instead?
The form should submit normally, and the page should remain interactive. 
Instead, the links and buttons all stop working.

Please use labels and text to provide additional information.
Encountered in Google Chrome on Linux.

This issue was created by revision d9fd3b8d78.

prettifyHtml strips leading whitespace from text nodes that follow HTML
tags. E.g. "a <em>b</em> c" becomes "a bc" instead of "a b c". This
might be a problem with our usage of goog.dom.(get|set)TextContent.

This issue was created by revision c10aabb1a9.

When contiguous single quote pairs, e.g. "'a' 'b' 'c'", are prettified, every
other one ("'b'" in this case) doesn't get matched as a quote pair. The
problem is that the regex eats the space character in the previous match, so
the rule doesn't get triggered if it's only run once.

When window.prettify is called with a document that contains a node with 
class 'prettify' that is not nested directly under document.body, prettify 
raises an exception: NOT_FOUND_ERR. This makes window.prettify totally 
useless for non-trivial HTML.

This issue was created by revision 33d832367e.


The string '"---"' should appear as '“—”'. Instead, it appears as 
'“—“'.

This issue was created by revision 2b0f50f2cd.

The string:
  With---'imaginary'---dashes.
Should look like:
  With—‘imaginary’—dashes.
But looks like:
  With—’imaginary’—dashes.

The current bookmarklet requires manual intervention every time you want to 
use it. This is no good; ideally, you'd be able to enable prettification 
once per page and then have text prettified manually. Such a bookmarklet 
shouldn't be too hard to write: just store original input in a buffer, and 
stick the prettified version into the input field.

This issue was created by revision aa6e12c47e.

When prettifyHtml is given a quoted element inside of a tag, it doesn't
properly recognize apostrophes. Using LaTeX quote shorthand, "'<em>foo</em>'s"
becomes "`<em>foo</em>`s", but it should be "`<em>foo</em>'s".

This issue was created by revision f73a0172e3.

The new quote matcher doesn't handle open quotes at the start of a line
properly, or close quotes before punctuation.

The most recent version of the bookmarklet is broken in Firefox. The 
compiled code tries to redefine window (locally!), which Firefox thinks is a 
constant.

This needs a bookmarklet to be useful in the broad sense. I'm thinking the 
most useful case is to prettify the contents of all textareas (and/or text 
inputs) on the page; that way things like status messages, blog posts, and 
tweets can be prettified with one click.