Shortly after template widget rendering was merged, an issue about extra
newlines appearing in the rendered output was reported [0]:
For example, from django-money:
<option value="XFU" \n>UIC-Franc</option>
\n\n
<option value="USD" selected\n>US Dollar</option>
\n\n
The newlines aren't useful and they break assertions like this:
<option value="USD" selected>US Dollar</option> in form.as_p
--- end report---
The reporter suggested removing the trailing newline in the attrs.html
template but Adam Johnson reported: "POSIX states that all text files
should end with a newline, and some tools break when operating on text
files missing the final newline. That's why git has the warning \ No
newline at end of file and Github has a warning symbol for the missing
newline."
I suggested that perhaps {% include %} could do .rstrip('\n') on whatever
it renders.
Preston pointed out that Jinja2 does something similar:
http://jinja.pocoo.org/docs/dev/templates/#whitespace-control
- a single trailing newline is stripped if present
- other whitespace (spaces, tabs, newlines etc.) is returned unchanged
I noted that the issue of {% include %} adding extra newlines was raised in
#9198 [1] but Malcolm said, "For backwards compatibility reasons we cannot
change the default behaviour now (there will be templates that rely on the
newline being inserted)." I was skeptical this would be a burdensome change.
Carl replied: "It seems quite likely to me that there are templates in the
wild relying on preservation of the final newline. People render
preformatted text (e.g. text emails) using DTL. I probably have some text
email templates in older projects myself that would break with that change.
We could add a new option to {% include %}, though." Adam also said, "I too
have used DTL for text emails that would break under that behaviour. New
option to include sounds good to me."
Me again: In the long run, having {% include %} remove the trailing newline
seems like a more sensible default. For example, I wouldn't expect this
code to have a newline inserted between it:
{% include "foo.txt" %}
{% include "bar.txt" %}
An option for {% include %} seems superfluous given that if you were writing
{% include "foo.txt" %}{% include "bar.txt" %}
now you can write the first thing which is much more intuitive.
How about a keep_trailing_newline TEMPLATES option for backwards
compatibility for those who don't want to adapt their templates for the new
behavior? Jinja2 has that option.
Carl replied: An engine option may be better than an option to {% include %},
though it doesn't allow us to ensure that we strip the newline in the
specific case of attrs.
How we default the engine option I guess just depends on how seriously we
take backwards compatibility. If we default it to strip and make people add
the config to preserve the old behavior, that's not really backwards
compatible. Historically (as seen in Malcolm's comment) we would choose to
err on the side of actual backwards compatibility in a case like this, even
if it didn't result in the ideal future behavior. But the adaptation isn't
hard in this case, so I won't object if the choice is to break back-compat.
If it's not a per-include choice, of course, we have to break overall
back-compat to preserve form-attr-rendering back-compat.
----
What do you think?
[0] https://github.com/django/django/pull/7769
[1] https://code.djangoproject.com/ticket/9198
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/8124d314-eb26-4465-9fc8-5b04fe2ba618%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
