0

Blank lines within and especially at the top of an HTML source file look untidy to me.

A common template code (in this case, Jinja2) may look like this:

{% block header %}

{% include "templates/partials/something_header.html" %}

{% endblock header %}

{% block body %}

{% include "templates/partials/something_body.html" %}

{% endblock body %}

{% block footer %}

{% include "templates/partials/something_footer.html" %}

{% endblock footer %}

Now, without even adding indentation issues to make the above more presentable, it already has the adverse effect of generating 2 empty lines due to the 2 carriage returns within the templating code:

.
.
<!DOCTYPE HTML>
<html>
<head>
    <meta http-equiv=....

Whilst I can utilize a minifier/post-processor in this particular case, I'm wondering what others do to keep their template code easy on the eyes whilst preventing unnecessary blank lines?

EDIT: To eliminate the blank lines at the head of the generated source code, the above example of template code would appear as below (much less readable):

{% block header %}{% include "templates/partials/grid_header.html" %}{% endblock header %}

{% block body %}

...
ljs.dev
  • 4,449
  • 3
  • 47
  • 80
  • 2
    Just for the record: What happens if you remove the blank lines in your template file? – Lajos Arpad Sep 14 '13 at 12:29
  • 1
    When balancing between the human-readability of the source code and the human-readability of the result, I'd favor the human-readability of the source code. If the HTML isn't human-friendly but still correct, browsers won't have a problem. But if the original source code isn't human-friendly then it'll be more difficult to support. – David Sep 14 '13 at 13:17
  • 1
    So you can solve your problem by removing the blank lines, but this way you introduce a new problem, because it is not readable for a human. In case you do not need those blank lines for functional purposes, only for readability, then you could write your readable file and then implement a tool which cleans the template and you can use that tool to generate the html, so you will have 3 layers: 1. The layer visible to the user (will be readable because of the tool) 2. The in-between layer where you have your clean templates 3. and the generated, tidy HTML. Hope this helps. – Lajos Arpad Sep 14 '13 at 13:34
  • @Lajos, added the alternative template code which prevents blank lines in the generated source code. Regarding post-processing to clean the HTML, I mentioned this in the question, but wondered if the majority users of template engines implement such a process, work with hard to read template code or deal with the extra lines. – ljs.dev Sep 14 '13 at 20:12
  • 1
    My last comment tends to solve both of the problems, please read it again. – Lajos Arpad Sep 14 '13 at 21:14
  • @LajosArpad, I think 3 versions of the code would add unnecessary complexity. Developer needs a template, user needs rendered html. A post-processor can obviously facilitate this and I'm gathering from lack of other suggestions that this is the way most people work (unless they ignore the untidy HTML, which seems the common practice at least with most of the CherryPy sites here: http://docs.cherrypy.org/stable/appendix/success.html) – ljs.dev Sep 14 '13 at 22:12
  • @LeonStafford, cleaning your templates has to be done whenever a template changes. If you do not need readable templates, or you do not need tidy Htmls, then the added complexity is unnecessary indeed. But in that case why did you ask this question? – Lajos Arpad Sep 15 '13 at 00:10

1 Answers1

0

My original question was a bit of an "I know this can be done, but is there another way?".

Thanks to the feedback from David and Lajos, confirming that post-processing of the generated HTML from the template engine is the most common way to alleviate unwanted blank lines and spacing.

Lajos also suggested a concept of maintaining both a "clean" and "correct" version of each template itself, whereby the developer may work unperturbed with clean template code and upon any modification, another version of the file will be ghost-written, but reformatted so that generating HTML from it would in fact produce clean HTML without any unwanted artifacts due to templating.

Whilst I tend towards the common post-processing method and chain any such cleaning up of HTML along with combining and minifying CSS/JS, etc, there would be scenarios that Lajos's implementation definitely would be beneficial (ie, if you don't/should't have control outside of the templating stage).

ljs.dev
  • 4,449
  • 3
  • 47
  • 80