Re: [Django] #4555: New html-util/filter: unescape
Django
-------------------------------------+-------------------------------------
Reporter: Johan Bergström | Owner: nobody
<bugs@…> | Status: reopened
Type: Uncategorized | Version: master
Component: Template system | Resolution:
Severity: Normal | Triage Stage: Design
Keywords: unescape util | decision needed
filter | Needs documentation: 0
Has patch: 1 | Patch needs improvement: 0
Needs tests: 0 | UI/UX: 0
Easy pickings: 0 |
-------------------------------------+-------------------------------------
Changes (by anonymous):
* status: closed => reopened
* severity: => Normal
* resolution: wontfix =>
* easy: => 0
* ui_ux: => 0
* type: => Uncategorized
Comment:
I think this ticket should be re-opened.
Anytime a library gives you escaped HTML (eg. Django Rest Framework's
auto-generated documentation) a tag like this is super-useful. Plus, it's
just kind of strange that core Django has fifty different template
tags/filters to escape/not-escape stuff, but 0 tags/filters to unescape
stuff.
--
Ticket URL: <https://code.djangoproject.com/ticket/4555#comment:7>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
-------------------------------------+-------------------------------------
Reporter: Johan Bergström | Owner: nobody
<bugs@…> | Status: reopened
Type: Uncategorized | Version: master
Component: Template system | Resolution:
Severity: Normal | Triage Stage: Design
Keywords: unescape util | decision needed
filter | Needs documentation: 0
Has patch: 1 | Patch needs improvement: 0
Needs tests: 0 | UI/UX: 0
Easy pickings: 0 |
-------------------------------------+-------------------------------------
Comment (by anonymous):
P.S. Just to be clear, no Django doesn't actually have 50 different
tags/filters; it has a bunch, and I was being hyperbolic
--
Ticket URL: <https://code.djangoproject.com/ticket/4555#comment:8>
Django
-------------------------------------+-------------------------------------
Reporter: Johan Bergström | Owner: nobody
Type: Uncategorized | Version: master
Component: Template system | Resolution: wontfix
Keywords: unescape util | decision needed
filter | Needs documentation: 0
Has patch: 1 | Patch needs improvement: 0
Needs tests: 0 | UI/UX: 0
Easy pickings: 0 |
-------------------------------------+-------------------------------------
* status: reopened => closed
* resolution: => wontfix
Comment:
The reason the unescape tag doesn't exist is because you shouldn't need
it. If you're ever in a situation where you need to undo escaping, then
you haven't been paying attention to where things have been encoded along
the line. The fix isn't to allow code to be bounced back and forth between
encoded and unencoded -- it's to make sure you're only ever encoding when
you need to be.
--
Ticket URL: <https://code.djangoproject.com/ticket/4555#comment:9>
Django
-------------------------------------+-------------------------------------
Reporter: Johan Bergström | Owner: nobody
<bugs@…> | Status: closed
Type: Uncategorized | Version: master
Component: Template system | Resolution: wontfix
Severity: Normal | Triage Stage: Design
Keywords: unescape util | decision needed
filter | Needs documentation: 0
Has patch: 1 | Patch needs improvement: 0
Needs tests: 0 | UI/UX: 0
Easy pickings: 0 |
-------------------------------------+-------------------------------------
Comment (by aaugustin):
In addition to Russell's answer, if a library hands you escaped HTML, the
right place to unescape it is "right when you obtain it", not "in the
template engine".
Always work with data in the canonical form, and not in an escaped
representation for an arbitrary output format.
--
Ticket URL: <https://code.djangoproject.com/ticket/4555#comment:10>
Django
-------------------------------------+-------------------------------------
Reporter: Johan Bergström | Owner: nobody
<bugs@…> | Status: closed
Type: Uncategorized | Version: master
Component: Template system | Resolution: wontfix
Severity: Normal | Triage Stage: Design
Keywords: unescape util | decision needed
filter | Needs documentation: 0
Has patch: 1 | Patch needs improvement: 0
Needs tests: 0 | UI/UX: 0
Easy pickings: 0 |
-------------------------------------+-------------------------------------
Comment (by anonymous):
Well, that'd be lovely ... if my library wasn't handling the view layer
also (and therefore preventing me from unescaping the code in the view).
However, if Django REST framework is just following a bad practice, it's
certainly not reasonable to add a filter just for one bad case. I guess
I'll just have to dig through the source for some underscored method to
override or something ...
Thanks for the explanation on the re-close!
--
Ticket URL: <https://code.djangoproject.com/ticket/4555#comment:11>
Django
-------------------------------------+-------------------------------------
Reporter: Johan Bergström | Owner: nobody
<bugs@…> |
Component: Template system | Version: dev
Severity: Normal | Resolution: wontfix
Keywords: unescape util | Triage Stage: Design
filter | decision needed
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Collin Anderson):
I just want to note that I would use an `html_unescape` template filter in
pretty much every case where I use the `striptags` filter.
For example, I have a product.html_description field and I may want to
auto-generate a meta description like so:
{{{
<meta name="description" content="{{
product.html_description|striptags|html_unescape|truncatechars:400 }}">
}}}
`striptags` removes tags, but I also want to replace `—` -> `—` and
`'` -> `'` before running it through `truncatechars`. I especially
don't want to truncate in the middle of an `—` or other html entity.
The template engine will take care of auto-escaping the resulting text to
html. (And it's fine if the html is longer than 400 chars as long as the
text is <= 400 chars.)
I think some people use the insecure `striptags|safe` as a workaround to
"fix" html entities showing up in output, whereas a
`striptags|html_unescape` would solve the same problem and actually be
much more secure.
Or maybe it would help to have an `html_to_text` filter that is basically
just `striptags|unescape_html`. I assume most people who use `striptags`
also want to html entities unescaped too. Again, it might help cut down on
insecure `striptags|safe` usage.
--
Ticket URL: <https://code.djangoproject.com/ticket/4555#comment:12>