Hello,
I’m not going to veto whitespace control in Django templates. Mostly I’m
uncomfortable with rushing this feature to fix the much narrower problem
discussed here.
If we want to provide whitespace control in templates, we should review use
cases, other implementations, and figure out something reasonable.
I hope this clarifies my position,
--
Aymeric.
> On 4 Jan 2017, at 23:53, Tim Graham <timogra...@gmail.com> wrote:
>
> Aymeric, we have a difference of opinion. I feel that if {% include %}
> removed the trailing newline, it would result in far more intuitive
> whitespace control (which may be needed in plain text email templates, for
> example). I think the change has merits outside the context of this issue.
> For example, I checked view-source on a djangoproject.com
> <http://djangoproject.com/> page that uses a {% for ... %}{% include %}{%
> endfor %} construct and noticed that it's much shorter without all those
> extra blank lines. I'm not advocating for additional controls to craft well
> formatted HTML but I think there's some advantages to not having blank lines
> everywhere. (I don't like the keep_trailing_newline option either, I'd rather
> call it a bugfix and make a backwards-incompatible change but my projects are
> unaffected as far as I checked.)
>
> There are many questions on Stackoverflow about how to suppress newlines from
> {% include %} and even a django-include-strip-tag third-party app that offers
> the feature.
>
> In the context of multiple template engines, I think it would be useful if
> DTL templates could be written in a similar style to Jinja2.
>
> I'd like to know from Carl, Adam, and others, how much effort would be
> required to adapt the templates in your project for the new behavior. I
> imagine a script could be written to add newlines after all {% include %} in
> all plain text templates, for example.
>
> It won't be the end of the world if we can't get consensus to change the
> behavior -- I'm okay with removing the trailing newlines in the source files
> as needed, although it will add some inconvenience.
>
> On Wednesday, January 4, 2017 at 4:26:43 PM UTC-5, Aymeric Augustin wrote:
> If I understand correctly, we have to choose between:
>
> 1. breaking backwards compatibility for {% include %}
> 2. breaking backwards compatibility for widgets HTML
> 3. having a handful of single-line, non-newline-terminated files
>
> I don’t think option 1 is reasonable. Whitespace control in templates is an
> exercise in frustration. In my experience more flexible tools such as {%-,
> {%+, -%}, and +%} in Jinja2 increase the frustration. I don’t think Django
> should get itself into this mess just for fixing the problem discussed here.
>
> Option 2 seems acceptable to me. This is the "do nothing” option. I don’t
> think the exact HTML string rendered by widgets is considered a public API.
> We made changes to that output in the past, for example when we switched to
> HTML5.
>
> Option 3 also seems reasonable to me. Files could end with {# no newline, see
> issue #xxx #} and no newline. A test could validate that the rendered output
> doesn’t contain a newline. This would be enough to catch accidental
> regressions caused by editors automatically adding the newline.
>
> The quote from the POSIX standard says “should”, not “must”. If we interpret
> it as if it was written in capitals in a RFC, this means we can make an
> exception if we have a good reason.
>
> (At this point surely someone will suggest that we can write an editorconfig
> to specify that these files mustn’t end with a newline. Whatever works.)
>
> I don’t have a strong preference for 2 or 3, however, I have a strong
> distaste for anything more complicated.
>
> Best regards,
>
> --
> Aymeric.
>
>> On 4 Jan 2017, at 20:58, Tim Graham <timog...@ <>gmail.com
>> <http://gmail.com/>> 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
>> <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
>> <https://github.com/django/django/pull/7769>
>> [1] https://code.djangoproject.com/ticket/9198
>> <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-develop...@ <>googlegroups.com <http://googlegroups.com/>.
>> To post to this group, send email to django-d...@ <>googlegroups.com
>> <http://googlegroups.com/>.
>> Visit this group at https://groups.google.com/group/django-developers
>> <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
>>
>> <https://groups.google.com/d/msgid/django-developers/8124d314-eb26-4465-9fc8-5b04fe2ba618%40googlegroups.com?utm_medium=email&utm_source=footer>.
>> For more options, visit https://groups.google.com/d/optout
>> <https://groups.google.com/d/optout>.
>
>
> --
> 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
> <mailto:django-developers+unsubscr...@googlegroups.com>.
> To post to this group, send email to django-developers@googlegroups.com
> <mailto:django-developers@googlegroups.com>.
> Visit this group at https://groups.google.com/group/django-developers
> <https://groups.google.com/group/django-developers>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/980cf18c-20e2-411a-9536-acea1e4d3556%40googlegroups.com
>
> <https://groups.google.com/d/msgid/django-developers/980cf18c-20e2-411a-9536-acea1e4d3556%40googlegroups.com?utm_medium=email&utm_source=footer>.
> For more options, visit https://groups.google.com/d/optout
> <https://groups.google.com/d/optout>.
--
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/C2FCE114-288D-4D12-B3B7-3C869AACDF7A%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.
