This project is archived and is in readonly mode.
truncate with HTML ellipsis character entity
I found myself changing the default from project to project, so here's my patch for it.
This sets truncate's default :omission
from three dots (...) to the "proper" HTML character entity for an
ellipsis (…). This will render the ellipsis
properly as a single character and is more semantically
correct.
I think, in the context where truncate is used, this is nicer.
-
Jeremy Olliver- Tag changed from actionview, truncate to actionview, patch, truncate
I think this sounds like a good idea.
A concern that I'd have before this patch gets applied is that when specifying the total length, of the truncated string, the escape character is counting as an 8 character string "…" rather than the roughly 3 character space it takes up when displayed in the browser.
e.g. truncate("Hi my name is", :length => 10)
=> "Hi…"
where what might be expected is:
=> "Hi my n…"
I've added a patch to be applied ontop of your patch to show the behavior I expect in the tests. I'm not quite sure how best to change this behaviour (ie, treat "…" as not taking up the space of 8 characters) yet though
-
test_fail_patch.diff
2.32 KB
-
AupajoA trade-off might be to increase the default
:lengthby 5 characters.Another solution would be to treat length as the encoded character length, and treat
&etc;as single characters, thus changing the eight characters of the…to one. -
Rizwan Rezanot reproducible
-1 The patch doesn't work properly.
+1 The idea isn't bad. I think using proper HTML characters is always nice.
-
Rizwan Reza
- State changed from new to stale
- Milestone cleared.
Please post a patch where … is considered a three character string. This will be backwards compatible yet supporting correct HTML character. When making this patch, please make it against master. Thanks. You can assign it to me when done.
I am changing ticket's state to stale.
-
Josh Graham- Importance changed from to Medium
Actually,
…can be considered just 1 character (Unicode U+2026). When selected for copy/paste it's only one character and it only takes up 1 em space on the screen.Therefore
truncate("Hi my name is", :length => 10)should render
Hi my nam… -
Bernerd Schaefer
- Assigned user set to Rizwan Reza
Submitting a patch authored by Bernerd Schaefer bj.schaefer@gmail.com and Veezus Kriest mremsik@gmail.com for your consideration.
We have updated the truncate helper to use the Unicode ellipsis whenever possible. We check $KCODE under 1.8.x and Encoding.default_encoding under 1.9.x to decide whether to use "..." or "…". Regardless, we always treat the default omission characters as 3 characters in length. To accommodate this, we also added an :omission_length option to ActiveSupport's truncate method which is used in place of counting the omission's character length when provided.
This makes the new truncate method backwards compatible with the existing behavior, while giving everyone running in UTF-8 mode (the default application encoding) nice ellipses.
We were unable to use "…", because the results of truncate are not HTML safe and are passed through ERB::Util.html_escape when inserted into views (or passed through other methods such as auto_link which use the tag helpers).
-
Bernerd Schaefer
Just to be clear, in the preceding comment, the first "..." is three periods, the second is the Unicode elipsis, and the last is the HTML entity …
-
-
-
FjanEmitting HTML character entities like hellip and nbsp is a bad idea since you will no longer be able to use the rails helpers to generate plain text messages. If you simply use the UTF-8 character it will work in ActionMailer too.
-
-
-
Veezus KreistAttached please find an updated patch that applies to the master branch. This is essentially the same changeset that Bernerd and I posted in July.
Thanks!
-
Dan PickettVeezus' latest patch still applies cleanly to master with all tests in actionpack and activesupport passing.
Passing HTML character entities as the omission phrase is indeed a bad idea, but this patch doesn't add that as default behavior, it just verifies in tests that it can be done.
I can't think of a reason or use case why we would want the omission_length option to be a public part of the api - isn't that done just so that unintended behavior doesn't occur with legacy code? If it is decided we want to incorporate it into the public part of the api, the documentation should be updated to reflect the additional option.
-
-