milanvrekic / js-humanize Goto Github PK

truncatewords() appends a single space if it does not shorten the sentence.

I have made a fix in ae54bd3

This project looks useful! Can you add a license? MIT?

Without comments, the file size drops from 10kb to 5kb (or thereabouts). Why are there comments in the minified file?

Thanks for the cool library! I found a couple things…

naturalTime(time() + 3600) = "in 60 minutes," should be "in 1 hour"

naturalTime(time() + 3631) = "in about 1 hours," should be "in about 1 hour"

This is incorrect:

filesizeformat (1234567890 = 1.15 Gb)

Gigabyte is GB. Gigabit is Gb

Correct:

filesizeformat (1234567890 = 1.15 GB)

The functions date(), time() and number_format() are not namespaced and may conflict with other functions outside the library.

I have made a fix in 92b80b3

I wanted the tests to have expected results so I could make changes against them. I don't know what the intended behaviour of each of the functions are so I could see the result and think it is ok but not realise that the old behaviour was different.

I have made some changes, I just have to work out how to to a pull request now :)

Currently Humanize doesn't do any HTML escaping; any input contains HTML fragment could get executed on the page.

=> Humanize.truncatechars("<script>alert('yo');<\/script>", 30)
   "<script>alert('yo');</script>"

=> Humanize.linebreaks("<script>alert('yo');<\/script>")
   "<p><script>alert('yo');</script></p>"

If this library is used for rendering untrusted user input (such as comments) things won't be pretty. To protect some poor soul from using this little nice library without knowing such implication, I believe Humanize should escape HTML input by default with optional parameter to disable it (if you however decide this is not the job of JS-Humanize, I think there should be a note about this behavior somewhere, in bold, red, large text but that's likely never enough ;)

Either way, nice work!