Anthony, I assume you're referring to the keep_trailing_newline option? If
we don't enable it for existing projects, then forms will render with extra
newlines. I think it's better to have projects opt-out of the behavior if
they're unable to audit their non-HTML templates due to time constraints.
Only enabling it for new projects means that the tests for projects like
django-money will break until the option is enabled. I consider the k
eep_trailing_newline option a temporary backwards compatibility measure and
would like to eventually remove it.
Sam, re: "Could this be set within the template rather than the include
tag?"
I'm not an expert in the inner workings of the Django template language,
but based on how template tags usually work, that doesn't feel feasible. To
be clear, I'm not proposing to add an option to the {% include %} tag. That
seems like the wrong approach to me since if {% include %} already strips
the trailing newline of its output, then you can control newlines by how
you structure the {% include %} tag. This seems far more intuitive and
readable.
I also considered a technique we've used to change template tag behaviors
previously: {% load include from future %} however, I feel that would be
really disruptive to force all projects to go through that deprecation.
On Wednesday, January 4, 2017 at 3:15:31 PM UTC-5, Sam Willis wrote:
>
> Could this be set within the template rather than the include tag? So for
> example have a new tag such as {% strip_final_new_line %} that when
> included at the end of a template immediately before the final new line
> would instruct it to be striped.
>
> This stops the user from having to remember to use a special option on the
> include tag for each use of a template that requires it - it also work on a
> normal (not included) template render as well, if that is wanted.
>
> An alternative tag could be {% endtemplate %} that can be placed anywhere
> in the template, forcing the end of rendering?
>
> On Wednesday, January 4, 2017 at 7:58:42 PM UTC, Tim Graham wrote:
>>
>> 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 django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
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/de92a16a-25c7-439a-95a1-3a2b43a6c1ac%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
