Category: HTML(5)

Serving Static HTML With Nodjs And Grunt For Template-Development

A Simple Nodejs/Grunt-Development-Environment for static HTML-Templates

Nowadays, frontend-development is mostly done with Nodjs and Grunt.
On npm, there are plenty of useful plugin’s, that ease the development of HTML and CSS.
For example grunt-contrib-less to automate the compilation of LESS-sourcecode to CSS, or grunt-svgstore to pack several SVG-graphics in a single SVG-sprite.

Because of that, I decided to switch to Nodejs and Grunt to develop the HTML- and CSS-Markup for the templates, that I need for my Spring/Thymeleaf-Applications.
But as with everything new, I had some hard work, to plug together what I needed.
In this article I want to share, how I have set up a really minimalistic, but powerful development-environment for static HTML-templates, that suites all of my initial needs.

This might not be the best solutions, but it is a good starting point for beginners like me and it is here to be improved through your feedback!

You can browse the example-development-environment on juplo.de/gitweb, or clone it with:


git clone http://juplo.de/git/examples/template-development

After installing npm you have to fetch the dependencies with: 


npm install

Than you can fire up a build with: 


grunt

…or start a webserver for development with:


git run-server

Serving The HTML and CSS For Local Development

The hardest part while putting together the development-environment was my need to automatically build the static HTML and CSS after file-changes and serve them via a local webserver.
As I wrote in an earlier article, I often stumble over problems, that arise from the Same-origin policy when accessing the files locally through file:///-URI’s).

I was a bit surprised, that I could not find a simple explanation, how to set up a grunt-task to build the project automatically on file-changes and serve the generated HTML and CSS locally.
That is the main reason, why I am writing this explanation now, in order to fill that gap ;)

I realised that goal by implemnting a grunt-task, that spawn’s a process that uses the http-server to serve up the files and combine that task with a common watch-task: 


grunt.registerTask('http-server', function() {

  grunt.util.spawn({
    cmd: 'node_modules/http-server/bin/http-server',
    args: [ 'dist' ],
    opts: { stdio: 'inherit' }
  });

});

grunt.registerTask('run-server', [ 'default', 'http-server', 'watch' ]);

The rest of the configuration is really pretty self-explaining.
I just put together the pieces I needed for my template development (copy some static HTML and generate CSS from the LESS-sources) and configured grunt-contrib-watch to rebuild the project automatically, if anything changes.

The result is put under dist/ and is ready to be included in my Spring/Thymeleaf-Application as it is.

Bypassing the Same-Origin-Policy For Local Files During Development

downloadable font: download failed …: status=2147500037

Are you ever stumbled accross weired errors with font-files, that could not be loaded, or SVG-graphics, that are not shown during local development on your machine using file:///-URI’s, though everything works as expected, if you push the content to a webserver and access it via HTTP?
Furthermore, the browsers behave very differently here.
Firefox, for example, just states, that the download of the font failed: 


downloadable font: download failed (font-family: "XYZ" style:normal weight:normal stretch:normal src index:0): status=2147500037 source: file:///home/you/path/to/font/xyz.woff

Meanwhile, Chrome just happily uses the same font.
Considering the SVG-graphics, that are not shown, Firefox just does not show them, like it would not be able to at all.
Chrome logs an error: 


Unsafe attempt to load URL file:///home/you/path/to/project/img/sprite.svg#logo from frame with URL file:///home/you/path/to/project/templates/layout.html. Domains, protocols and ports must match

…though, no protocol, domain or port is involved.

The Same-Origin Policy

The reason for this strange behavior is the Same-origin policy.
Chrome gives you a hint in this direction with the remark that something does not match.
I found the trail, that lead me to this explanation, while googling for the strange error message, that Firefox gives for the fonts, that can not be loaded.


The Same-origin policy forbids, that locally stored files can access any data, that is stored in a parent-directory.
They only have access to files, that reside in the same directory or in a directory beneath it.

You can read more about that rule on MDN.

I often violate that rule, when developing templates for dynamically rendered pages with Thymeleaf, or similar techniques.
That is, because I like to place the template-files on a subdirectory of the directory, that contains my webapp (src/main/webapp with Maven): 


+ src/main/webapp/
  + css/
  + img/
  + fonts/
  + thymeleaf/templates/

I packed a simple example-project for developing static templates with LESS, nodejs and grunt, that shows the problem and the quick solution for Firefox presented later.
You can browse it on my juplo.de/gitweb, or clone it with: 


git clone http://juplo.de/git/examples/template-development

Cross-Browser Solution

Unfortunately, there is no simple cross-browser solution, if you want to access your files through file:///-URI’s during development.
The only real solution is, to access your files through the HTTP-protocol, like in production.
If you do not want to do that, the only two cross-browser solutions are, to

  1. turn of the Same-origin policy for local files in all browsers, or
  2. rearrange your files in such a way, that they do not violate the Same-origin policy (as a rule, all resources linked in a HTML-file must reside in the same directory as the file, or beneath it).

The only real cross-browser solution is to circumvent the problem altogether and serve the content with a local webserver, so that you can access it through HTTP, like in production.
You can read how to extend the example-project mentioned above to achieve that goal in a follow up article.

Turn Of Security

Turning of the Same-origin policy is not recommended.
I would only do that, if you only use your browser, to access the HTML-files under development ‐ which I doubt, that it is the case.
Anyway, this is a good quick test to validate, that the Same-origin policy is the source of your problems ‐ if you quickly re-enable it after the validation.

Firefox:
Set security.fileuri.strict_origin_policy to false on the about:config-page.
Chrome:
Restart Chrome with --disable-web-security or --allow-file-access-from-files (for more, see this question on Stackoverflow).

Quick Fix For Firefox

If you develop with Firefox, there is a quick fix, to bypass the Same-origin policy for local files.

As the explanation on MDM stats, a file loaded in a frame shares the same origin as the file, that contains the frameset.
This can be used to bypass the policy, if you place a file with a frameset in the topmost directory of your development-folder and load the template under development through that file.

In my case, the frameset-file looks like this: 


<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN" "http://www.w3.org/TR/html4/frameset.dtd">
<html>
  <head>
    <meta http-equiv="content-type" content="text/html; charset=utf-8">
    <title>Frameset to Bypass Same-Origin-Policy
  </head>
  <frameset>
    <frame src="thymeleaf/templates/layout.html">
  </frameset>
</html>

A Perfect Outline

Point Out Your Content: Utilize the HTML5 Outline-Algorithm

HTML5 introduces new semantic elements accompained by the definition of a new algorithm to calculate the document-outline from the mark up.
There are plenty of good explanations of these new possibilities, to point out your content in a more controlled way.
But the most of these explanations fall short, if it comes to how to put these new markup into use, so that it results in a sensible outline of the document, that was marked up.

In this article I will try to explain, how to use the new semantic markup, to produce an outline, that is usable as a real content table of the document – not just as an partially orderd overview of all headings.
I will do so, by showing simple examples, that will illuminate the principles behind the new markup.

All Messed Up!

Although, the ideas behind the new markup seems to be simple and clear, nearly nobody accomplishes to produce a sensible outline.
Even the big players, who guide us through the jungle of the new specifications and are giving great explanations about the subject, either fail on there sites (see by yourself with the help of the help of the h5o HTML5 Outline Bookmarklet), or produce the outline in the old way by the usage of h1–h6 only, like the fabulous HTML5-bible Dive Into HTML5.

This is, because there is a lot to mix up in a wrong way, when trying to adopt the new features.
Here is, what I ended up with, on my first try to combine what I have learned about semantic elements and the document outline:

Example 01: Markup


<!DOCTYPE html>
<title>Example 01</title>
<header>
  <h2>Header</h2>
  <nav>Navigation</nav>
</header>
<main>
  <h1>Main</h1>
  <section>
    <h2>Section I</h2>
  </section>
  <section>
    <h2>Section II</h2>
    <section>
      <h3>Subsection a</h3>
    </section>
    <section>
      <h3>Subsection b</h3>
    </section>
  </section>
  <section>
    <h2>Section III</h2>
    <section>
      <h3>Subsection a</h3>
    </section>
  </section>
</main>
<aside>
  <h1>Aside</h1>
</aside>
<footer>
  <h2>Footer</h2>
</footer>

Example 01: Outline

  1. Header

    1. Untitled section
  2. Main

    1. Section I
    2. Section II

      1. Subsection a
      2. Subsection b
    3. Section III

      1. Subsection a
    4. Aside
    5. Footer

View example 01

That quiet was not the outline, that I had expected.
I planed, that Header, Main, Aside and Footer are ending up at the same level.
Instead of that, Aside and Footer had become sections of my Main-content.
And where the hell comes that Untitled section from?!?
My first thought on that was: No problem, I just forgot the header-tags.
But after adding them, the only thing that cleared out, was where the Untitled section was coming from:

Example 02: Markup


<!DOCTYPE html>
<title>Example 02</title>
<header>
  <h2>Header</h2>
  <nav>
    <header><h3>Navigation</h3></header>
  </nav>
</header>
<main>
  <header><h1>Main</h1></header>
  <section>
    <header><h2>Section I</h2></header>
  </section>
  <section>
    <header><h2>Section II</h2></header>
    <section>
      <header><h3>Subsection a</h3></header>
    </section>
    <section>
      <header><h3>Subsection b</h3></header>
    </section>
  </section>
  <section>
    <header><h2>Section III</h2></header>
    <section>
      <header><h3>Subsection a</h3></header>
    </section>
  </section>
</main>
<footer>
  <header><h2>Footer</h2></header>

Example 02: Outline

  1. Header

    1. Navigation
  2. Main

    1. Section I
    2. Section II

      1. Subsection a
      2. Subsection b
    3. Section III

      1. Subsection a
    4. Aside
    5. Footer

View example 02

So I thought: Maybe the main-tag was the wrong choice.
Perhaps it should be replaced by an article.
But after that change, the outline even got worse.
Now, Navigation, Main and Aside appeared on the same level, all as a subsection of Header.
At least, Footer suddenly was a sibling of Header as planed:

Example 03: Markup


<!DOCTYPE html>
<title>Example 03</title>
<header>
  <h2>Header</h2>
  <nav>
    <header><h3>Navigation</h333></header>
  </nav>
</header>
<article>
  <header><h1>Article (Main)</h1></header>
  <section>
    <header><h2>Section I</h2></header>
  </section>
  <section>
    <header><h2>Section II</h2></header>
    <section>
      <header><h3>Subsection a</h3></header>
    </section>
    <section>
      <header><h3>Subsection b</h3></header>
    </section>
  </section>
  <section>
    <header><h2>Section III</h2></header>
    <section>
      <header><h3>Subsection a</h3></header>
    </section>
  </section>
</article>
<footer>
  <header><h2>Footer</h2></header>
</footer>

Example 03: Outline

  1. Header

    1. Navigation
    2. Main

      1. Section I
      2. Section II

        1. Subsection a
        2. Subsection b
      3. Section III

        1. Subsection a
    3. Aside
  2. Footer

View example 03

After that, I was totally confused and decided, to sort it out step by step.
That procedure finally gave me the clue, I want to share with you now.

Step by Step (Uh Baby!)

Step I: Investigate the Structured Part

Let us start with the strictly structured part of the document: the article and it’s subsections.
At first a minimal example with no markup except the article– and the section-tags:

Example 04: Markup


<!DOCTYPE html>
<title>Example 04</title>
<article>
  Main
  <section>
    Section I
  </section>
  <section>
    Section II
    <section>
      Subsection a
    </section>
    <section>
      Subsection b
    </section>
  </section>
  <section>
    Section III
    <section>
      Subsection a
    </section>
  </section>
</main>

Example 04: Outline

  1. Untitled BODY

    1. Untitled ARTICLE

      1. Untitled SECTION
      2. Untitled SECTION

        1. Untitled SECTION
        2. Untitled SECTION
      3. Untitled SECTION

        1. Untitled SECTION

View Example 04

Nothing really unexpected here.
The article– and section-tags are reflected in the outline according to their nesting.
The only thing notably here is, that the body itself is also reflected in the outline.
It appears on its own level as the root-element of all tags.
We can think of it as the title of our document.

We can add headings of any kind (h1–h6) here and will always get an identically structured outline, that reflects the text of our headings.
If we want to give the body a title, we have to place a heading outside and before any sectioning-elements:

Example 05: Markup


<!DOCTYPE html>
<title>Example 05</title>
<h1>Page</h1>
<article>
  <h1>Article</h1>
  <section>
    <h1>Section I</h1>
  </section>
  <section>
    <h1>Section II</h1>
    <section>
      <h1>Subsection a</h1>
    </section>
    <section>
      <h1>Subsection b</h1>
    </section>
  </section>
  <section>
    <h1>Section III</h1>
    <section>
      <h1>Subsection a</h1>
    </section>
  </section>
</article>

Example 05: Outline

  1. Page

    1. Article

      1. Section I
      2. Section II

        1. Subsection a
        2. Subsection b
      3. Section III

        1. Subsection a

View Example 05

This is the new part of the outline algorithm introduced in HTML5: The nesting of elements, that define sections, defines the outline of the document.
The rank of the heading element is ignored by this algorithm!

Among the elements, that define sections in HTML5 are the article and the section tags.
But there are more.
I will discuss them later.
For now, you only have to know, that in HTML5, sectioning elements define the structure of the outline.
Also, you should memorize, that the outline always has a single root without any siblings: the body.

Step II: Investigate the Page-Elements

So, let us do the same with the tags that represent the different logical sections of a web-page: the page-elements.
We start with a minimal example again, that contains no markup except the header– the main and the footer-tags:

Example 06: Markup


<!DOCTYPE html>
<title>Example 06</title>
<header>Page</header>
<main>Main</main>
<footer>Footer</footer>

Example 06: Outline

  1. Untitled BODY

View Example 06

That is wired, ehh?
There is only one untitled element in the outline.
The explanation for this is, that neither the header– nor the main– nor the footer-tag belong to the elements, that define a section in HTML5!
This is often confused, because these elements define the logical sections (header – main-content – footer) of a website.
But these logical sections do not have to do anything with the structural sectioning of the document, that defines the outline.

Step III: Investigate the Headings

So, what happens, if we add the desired markup for our headings?
We want a h1-heading for our main-content, because it is the important part of our page.
The header should have a h2-heading and the footer a h3-heading, because it is rather unimportant.

Example 07: Markup


<!DOCTYPE html>
<title>Example 07</title>
<header><h2>Page</h2></header>
<main><h1>Main</h1></main>
<footer><h3>Footer</h3></footer>

Example 07: Outline

  1. Page
  2. Main

    1. Footer

View Example 07

Now, there is an outline again.
But why?
And why is it looking this way?

What happens here, is implicit sectioning.
In short, implicit sectioning is the outline algorithm of HTML4.
HTML5 needs implicit sectioning, to keep compatible with HTML4, which still dominates the web.
In fact, we could have used plain HTML4, with div instead of header, main and footer, and it would have yield the exact same outline:

Example 08: Markup


<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
  <head><title>Example 08</title></head>
  <body>
    <div class="header"><h2>Page</h2></div>
    <div class="main"><h1>Main</h1></div>
    <div class="footer"><h3>Footer</h3></div>
  </body>
</html>

Example 08: Outline

  1. Page
  2. Main

    1. Footer

View Example 08

In HTML4, solely the headings (h1–h6) define the outline of a document.
The enclosing elements or any nesting of them are ignored altogether.
The level, at which a heading appears in the outline, is defined by the rank of the heading alone.
(Strictly speaking, HTML4 does not define anything like a document outline.
But as a result of the common usage and interpretation, this is, how people outline their documents with HTML4.)

The implicit sectioning of HTML5 works in a way, that is backward compatible with this way of outlining, but closes the gaps in the resulting hierarchy:
Each heading implicitly opens a section – hence the name –, but if there is a gap between its rank and the rank of its ancestor – that is the last preceding heading with a higher rank – it is placed in the level directly beneath its ancestor:

Example 09: Markup


<!DOCTYPE html>
<title>Example 09</title>
<h4>h4</h4>
<h2>h2</h2>
<h4>h4</h4>
<h3>h3</h3>
<h2>h2</h2>
<h1>h1</h1>
<h2>h2</h2>
<h3>h3</h3>

Example 09: Outline

  1. h4
  2. h2

    1. h4
    2. h3
  3. h2
  4. h1

    1. h2

      1. h3

View Example 09

See, how the first heading h4 ends up on the same level as the second, which is a h2.
Or, how the third and fourth headings are both on the same level under the h2, although they are of different rank.
And note, how the h2 and h3 end up on different sectioning-levels as their earlier appearances, if they follow a h1 in the natural order.

Step IV: Mixing it all together

With the gathered clues in mind, we can now retry to layout our document with the desired outline.
If we want, that Header, Main and Footer end up as top level citizens in our planed outline, we simply have to achieve, that they are all recognized as sections under the top level by the HTML5 outline algorithm.
We can do that, by explicitly stating, that the header and the footer are section:

Example 10: Markup


<!DOCTYPE html>
<title>Example 10</title>
<header>
  <section>
    <h2>Main</h2>
  </section>
</header>
<main>
  <article>
    <h1>Article</h1>
    <section>
      <h2>Section I</h2>
    </section>
    <section>
      <h2>Section II</h2>
      <section>
        <h3>Subsection a</h3>
      </section>
      <section>
        <h3>Subsection b</h3>
      </section>
    </section>
    <section>
      <h2>Section III</h2>
      <section>
        <h3>Subsection a</h3>
      </section>
    </section>
  </article>
</main>
<footer>
  <section>
    <h3>Footer</h3>
  </section>
</footer>

Example 10: Outline

  1. Untitled BODY

    1. Main
    2. Article

      1. Section I
      2. Section II

        1. Subsection a
        2. Subsection b
      3. Section III

        1. Subsection a
    3. Footer

View Example 10

So far, so good.
But what about the untitled body?
We forgot about the single root of any outline, that is defined by the body, how we learned back in step 1. As shown in example 05, we can simply name that by putting a heading outside and before any element, that defines a section:

Example 11: Markup


<!DOCTYPE html>
<title>Example 11</title>
<header>
  <h2>Page</h2>
  <section>
    <h3>Header</h3>
  </section>
</header>
<main>
  <article>
    <h1>Article</h1>
    <section>
      <h2>Section I</h2>
    </section>
    <section>
      <h2>Section II</h2>
      <section>
        <h3>Subsection a</h3>
      </section>
      <section>
        <h3>Subsection b</h3>
      </section>
    </section>
    <section>
      <h2>Section III</h2>
      <section>
        <h3>Subsection a</h3>
      </section>
    </section>
  </article>
</main>
<footer>
  <section>
    <h3>Footer</h3>
  </section>
</footer>

Example 11: Outline

  1. Page

    1. Header
    2. Main

      1. Section I
      2. Section II

        1. Subsection a
        2. Subsection b
      3. Section III

        1. Subsection a
    3. Footer

View Example 11

Step V: Be Aware, Which Elements Define Sections

The eagle-eyed among you might have noticed, that I had “forgotten” the two element-types nav and aside, when we were investigating the elements, that define the logical structure of the page in step 2.
I did not forgot about these – I left them out intentionally.
Because otherwise, the results of example 07 would have been too confusing, to made my point about implicit sectioning.
Let us look, what would have happend:

Example 12: Markup


<!DOCTYPE html>
<title>Example 12</title>
<header>
  <h1>Page</h1>
  <nav><h1>Navigation</h1></nav>
</header>
<main><h1>Main</h1></main>
<aside><h1>Aside</h1></aside>
<footer><h1>Footer</h1></footer>

Example 07: Outline

  1. Page

    1. Navigation
  2. Main

    1. Aside
  3. Footer

View Example 12

What is wrong there?
Why are Navigation and Aside showing up as children, albeit we marked up every element with headings of the same rank?
The reason for this is, that nav and aside are sectioning elements:

Example 12: Markup


<!DOCTYPE html>
<title>Example 13</title>
<header>
  Page
  <nav>Navigation</nav>
</header>
<main>Main</main>
<aside>Aside</aside>
<footer>Footer</footer>

Example 07: Outline

  1. Untitled BODY

    1. Untitled NAV
    2. Untitled ASIDE

View Example 13

The HTML5 spec defines four sectioning elements: article, section, nav and aside!
Some explain the confusion about this fact with the constantly evolving standard, that leads to structurally unclear specifications.
I will be frank:
I cannot imagine any good reason for this decision!
In my opinion, the concept would be much clearer, if article and section would be the only two sectioning elements and nav and aside would only define the logical structure of the page, like header and footer.

Putting It All Together

Knowing, that nav and aside will define sections, we now can complete our outline skillfully avoiding the appearance of untitled sections:

Example 14: Markup


<!DOCTYPE html>
<title>Example 14</title>
<header>
  <h2>Page</h2>
  <section>
    <h3>Header</h3>
    <nav><h4>Navigation</h4></nav>
  </section>
</header>
<main>
  <article>
    <h1>Main</h1>
    <section>
      <h2>Section I</h2>
    </section>
    <section>
      <h2>Section II</h2>
      <section>
        <h3>Subsection a</h3>
      </section>
      <section>
        <h3>Subsection b</h3>
      </section>
    </section>
    <section>
      <h2>Section III</h2>
      <section>
        <h3>Subsection a</h3>
      </section>
    </section>
  </article>
</main>
<aside><h3>Aside</h3></aside>
<footer>
  <section>
    <h3>Footer</h3>
  </section>
</footer>

Example 14: Outline

  1. Page

    1. Header

      1. Navigation
    2. Main

      1. Section I
      2. Section II

        1. Subsection a
        2. Subsection b
      3. Section III

        1. Subsection a
    3. Aside
    4. Footer

View Example 14

Et voilà: Our Perfect Outline!

If you memorize the concepts, that you have learned in this little tutorial, you should now be able to mark up your documents to generate your perfect outline…

…but: one last word about headings:

A Word On The Ranks Of The Headings

It is crucial to note, that the new outline-algorithm still is a fiction: most user agents do not implement the algorithm yet.
Hence, you still should stick to the old hints for keeping your content accessible and point out the most important heading to the search engines.

But there is no reason, not to apply the new possibilities shown in this article to your markup: it will only make it more feature-proof.
It is very likely, that search engines will start to adopt the HTML5 outline algorithm, to make more sense out of your content in near feature – or are already doing so…
So, why not be one of the first, to gain from that new technique.

I would advise you, to adopt the new possibilities to section your content and generate a sensible outline, while still keeping the old heading ranks to be backward compatible.

Replace text by graphic without extra markup

Here is a little trick for you, to replace text by a graphic through pure CSS without the need to add extra markup: 


SELECTOR
{
  text-indent: -99em;
  line-height: 0;
}
SELECTOR:after
{
  display: block;
  text-indent: 0;
  content: REPLACEMENT;
}

SELECTOR can be any valid CSS-selector.
REPLACEMENT references the graphic, which should replace the text.
This can be a SVG-graphic, a vector-graphics from a font, any bitmap graphic or (quiet useless, but a simple case to understand the source like in the first of my two examples) other text.
SVG- and bitmap-graphics are simply referred by an url in the content-directive, like I have done it with a data-url in my second example.
For the case of an icon embedded in a vector you simply put the character-code of the icon in the content-directive, like described in the according ALA-article.

Examples

  1. Example 1
  2. Example 2

What is it good for?

If you need backward compatibility for Internet Explorer 8 and below or Android 2.3 and below, you have to use icon-fonts to support these old browsers.
I use this often, if I have a brand logo, that should be inserted in a accessible way and do not want to bloat up the html-markup with useless tag’s, to achieve this.

Disable automatic p and br tags in the wordpress editor – and do it as early, as you can!

Why you should disable them as early, as you can

I don’t like visual HTML-editors, because they always mess up your HTML. So the first thing, that I’ve done in my wordpress-profile, was checking the check-box Disable the visual editor when writing.
But today I found out, that this is worth nothing.
Even when in text-mode, wordpress is adding some <p>- and <br>-tags automagically and, hence, is automagically messing up my neatly hand-crafted HTML-code.

Fuck wordpress! (Ehem – sorry for that outburst)…

But what is even worse: after really turning off wordpress’s automagically-messup-functionality, nearly all my handwritten <p>-tags were gone, too.
So, if you want to turn of automatic <p>- and <br>-tags, you should really do it as early, as you can. Otherwise, you will have to clean up all your old posts afterwards like me. TI’ve lost some hours with usless HTML-editing today, because of that sh#%&*!

How to disable them

The wordpress-documentation of the build-in HTML-editor links to this post, which describs how to disable autmatic use of paragraph tags.
Simple open the file wp-includes/default-filters.php of you wordpress-installation and comment out the following line:


addfilter('the_content', 'wpautop');

If you are building your own wordpress-theme – like me – you alternatively can add the following to the functions.php-file of your theme: 


remove_filter('the_content', 'wpautop');

Why you should disable automatic paragraph tags

For example, I was wondering a while, where all that whitespace in my posts were coming from.
Being used to handcraft my HTML, I often wrote one sentence per line, or put some empty lines inbetween to clearly arange my code.
There comes wordpress, messing everything up by automagically putting every sentence in its own paragraph, because it was written on its own line and putting <br> inbetween, to reflect my empty lines.

But even worse, wordpress also puts these unwanted <p>-tags arround HTML-code, that breaks because of it.
For example, I eventually found out about this auto-messup functionallity, because I was checking my blog-post with a html-validator and was wondering, why the validator was grumping about a <quote>-tag inside flow content, which I’ve never put there. It turned out, that wordpress had put it there for me…