#33405: Documentation for template filter 'escapejs' is extremely unclear
-------------------------------+--------------------------------------
     Reporter:  Jon Ribbens    |                    Owner:  nobody
         Type:  Bug            |                   Status:  new
    Component:  Documentation  |                  Version:  4.0
     Severity:  Normal         |               Resolution:
     Keywords:                 |             Triage Stage:  Unreviewed
    Has patch:  0              |      Needs documentation:  0
  Needs tests:  0              |  Patch needs improvement:  0
Easy pickings:  0              |                    UI/UX:  0
-------------------------------+--------------------------------------
Changes (by Jon Ribbens):

 * status:  closed => new
 * resolution:  invalid =>


Comment:

 This is not a support request, I am reporting a bug in the documentation,
 which is so garbled as to be essentially completely meaningless and to
 render a long-standing and potentially-useful Django feature useless.

 Your reference to #29055 is helpful as it helped me understand the
 documentation is even worse than I thought it was - when it says
 "JavaScript template literals" this doesn't mean "a JavaScript literal
 created from a Django template" which would be the obvious interpretation
 given that is precisely what this feature is for, it means the relatively-
 recent JavaScript backtick syntax.

 Add that to the fact that the second sentence has two clauses which
 contradict each other, and I cannot understand how you can possibly think
 the current text is "ok" - it's complete gibberish.

 Since you're asking for a concrete proposal I would suggest:

     Escapes characters for use in JavaScript strings. This makes the
 string safe for use in HTML and JavaScript or JSON string literals. Note
 that it does ''not'' make it safe for use in "JavaScript template
 literals" (i.e. the JavaScript backtick syntax).
     For example:
         <script>
         let myVar = '{{ value|escapejs }}'

 If you're tempted to reply that it ''doesn't'' make the string safe for
 use in HTML (or JavaScript) then I would suggest examining that idea
 briefly first. This filter escapes all of the characters that the 'escape'
 filter does, so it definitely does make it safe for HTML. And if it
 somehow fails to make it safe for a JavaScript string literal then I am
 failing to see how.

-- 
Ticket URL: <https://code.djangoproject.com/ticket/33405#comment:4>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.015420069482b5143af7aa9dce3d1abb%40djangoproject.com.

Reply via email to