Test Artikel 2

Test Artikel 2

Posted by Pierre Mischler

Until now, trying to style an article, docu­ment, or blog post with Tail­wind has been a tedious task that required a keen eye for typo­graphy and a lot of complex custom CSS.

By default, Tail­wind removes all of the default browser styling from para­graphs, head­ings, lists and more. This ends up being really useful for building applic­a­tion UIs because you spend less time undoing user-agent styles, but when you really are just trying to style some content that came from a rich-text editor in a CMS or a mark­down file, it can be surprising and unin­tu­itive.

We get lots of complaints about it actu­ally, with people regu­larly asking us things like:

Why is Tail­wind removing the default styles on my h1 elements? How do I disable this? What do you mean I lose all the other base styles too?

We hear you, but we're not convinced that simply disabling our base styles is what you really want. You don't want to have to remove annoying margins every time you use a p element in a piece of your dash­board UI. And I doubt you really want your blog posts to use the user-agent styles either — you want them to look awesome, not awful.

The @tail­windcss/typo­graphy plugin is our attempt to give you what you actu­ally want, without any of the down­sides of doing some­thing stupid like disabling our base styles.

It adds a new prose class that you can slap on any block of vanilla HTML content and turn it into a beau­tiful, well-formatted docu­ment:

<article class="prose">
  <h1>Garlic bread with cheese: What the science tells us</h1>
  <p>
    For years parents have espoused the health bene­fits of eating garlic bread with cheese to their
    chil­dren, with the food earning such an iconic status in our culture that kids will often dress
    up as warm, cheesy loaf for Halloween.
  </p>
  <p>
    But a recent study shows that the celeb­rated appet­izer may be linked to a series of rabies cases
    springing up around the country.
  </p>
  <!-- ... -->
</article>

For more inform­a­tion about how to use the plugin and the features it includes, read the docu­ment­a­tion.

What to expect from here on out

What follows from here is just a bunch of abso­lute nonsense I've written to dogfood the plugin itself. It includes every sens­ible typo­graphic element I could think of, like bold text, unordered lists, ordered lists, code blocks, block quotes, and even italics.

It's important to cover all of these use cases for a few reasons:

  1. We want everything to look good out of the box.
  2. Really just the first reason, that's the whole point of the plugin.
  3. Here's a third pretend reason though a list with three items looks more real­istic than a list with two items.

Now we're going to try out another header style.

Typo­graphy should be easy

So that's a header for you — with any luck if we've done our job correctly that will look pretty reas­on­able.

Some­thing a wise person once told me about typo­graphy is:

Typo­graphy is pretty important if you don't want your stuff to look like trash. Make it good then it won't be bad.

It's prob­ably important that images look okay here by default as well:

Contrary to popular belief, Lorem Ipsum is not simply random text. It has roots in a piece of clas­sical Latin liter­ature from 45 BC, making it over 2000 years old.

Now I'm going to show you an example of an unordered list to make sure that looks good, too:

  • So here is the first item in this list.
  • In this example we're keeping the items short.
  • Later, we'll use longer, more complex list items.

And that's the end of this section.

What if we stack head­ings?

We should make sure that looks good, too.

Some­times you have head­ings directly under­neath each other. In those cases you often have to undo the top margin on the second heading because it usually looks better for the head­ings to be closer together than a para­graph followed by a heading should be.

When a heading comes after a para­graph …

When a heading comes after a para­graph, we need a bit more space, like I already mentioned above. Now let's see what a more complex list would look like.

  • I often do this thing where list items have head­ings.

    For some reason I think this looks cool which is unfor­tu­nate because it's pretty annoying to get the styles right.

    I often have two or three para­graphs in these list items, too, so the hard part is getting the spacing between the para­graphs, list item heading, and separate list items to all make sense. Pretty tough honestly, you could make a strong argu­ment that you just shouldn't write this way.

  • Since this is a list, I need at least two items.

    I explained what I'm doing already in the previous list item, but a list wouldn't be a list if it only had one item, and we really want this to look real­istic. That's why I've added this second list item so I actu­ally have some­thing to look at when writing the styles.

  • It's not a bad idea to add a third item either.

    I think it prob­ably would've been fine to just use two items but three is defin­itely not worse, and since I seem to be having no trouble making up arbit­rary things to type, I might as well include it.

After this sort of list I usually have a closing state­ment or para­graph, because it kinda looks weird jumping right to a heading.

Aussichten

Miau miau bla bla

Code should look okay by default.

I think most people are going to use high­light.js or Prism or some­thing if they want to style their code blocks but it wouldn't hurt to make them look okay out of the box, even with no syntax high­lighting.

Here's what a default tail­wind.config.js file looks like at the time of writing:

module.exports = {
  purge: [],
  theme: {
    extend: {},
  },
  vari­ants: {},
  plugins: [],
}

Hope­fully that looks good enough to you.

What about nested lists?

Nested lists basic­ally always look bad which is why editors like Medium don't even let you do it, but I guess since some of you goof­balls are going to do it we have to carry the burden of at least making it work.

  1. Nested lists are rarely a good idea.
    • You might feel like you are being really "organ­ized" or some­thing but you are just creating a gross shape on the screen that is hard to read.
    • Nested navig­a­tion in UIs is a bad idea too, keep things as flat as possible.
    • Nesting tons of folders in your source code is also not helpful.
  2. Since we need to have more items, here's another one.
    • I'm not sure if we'll bother styling more than two levels deep.
    • Two is already too much, three is guar­an­teed to be a bad idea.
    • If you nest four levels deep you belong in prison.
  3. Two items isn't really a list, three is good though.
    • Again please don't nest lists if you want people to actu­ally read your content.
    • Nobody wants to look at this.
    • I'm upset that we even have to bother styling this.

The most annoying thing about lists in Mark­down is that <li> elements aren't given a child <p> tag unless there are multiple para­graphs in the list item. That means I have to worry about styling that annoying situ­ation too.

  • For example, here's another nested list.

    But this time with a second para­graph.

    • These list items won't have <p> tags
    • Because they are only one line each

  • But in this second top-level list item, they will.

    This is espe­cially annoying because of the spacing on this para­graph.

    • As you can see here, because I've added a second line, this list item now has a <p> tag.

      This is the second line I'm talking about by the way.

    • Finally here's another list item so it's more like a list.

  • A closing list item, but with no nested list, because why not?

And finally a sentence to close off this section.

There are other elements we need to style

I almost forgot to mention links, like this link to the Tail­wind CSS website. We almost made them blue but that's so yesterday, so we went with dark gray, feels edgier.

We even included table styles, check it out:

Wrestler Origin Finisher
Bret "The Hitman" Hart Calgary, AB Sharp­shooter
Stone Cold Steve Austin Austin, TX Stone Cold Stunner
Randy Savage Sara­sota, FL Elbow Drop
Vader Boulder, CO Vader Bomb
Razor Ramon Chuluota, FL Razor's Edge

We also need to make sure inline code looks good, like if I wanted to talk about <span> elements or tell you the good news about @tail­windcss/typo­graphy.

Some­times I even use code in head­ings

Even though it's prob­ably a bad idea, and histor­ic­ally I've had a hard time making it look good. This "wrap the code blocks in back­ticks" trick works pretty well though really.

Another thing I've done in the past is put a code tag inside of a link, like if I wanted to tell you about the tail­windcss/docs repos­itory. I don't love that there is an under­line below the back­ticks but it is abso­lutely not worth the madness it would require to avoid it.

We haven't used an h4 yet

But now we have. Please don't use h5 or h6 in your content, Medium only supports two heading levels for a reason, you animals. I honestly considered using a before pseudo-element to scream at you if you use an h5 or h6.

We don't style them at all out of the box because h4 elements are already so small that they are the same size as the body copy. What are we supposed to do with an h5, make it smaller than the body copy? No thanks.

We still need to think about stacked head­ings though.

Let's make sure we don't screw that up with h4 elements, either.

Phew, with any luck we have styled the head­ings above this text and they look pretty good.

Let's add a closing para­graph here so things end with a decently sized block of text. I can't explain why I want things to end that way but I have to assume it's because I think things will look weird or unbal­anced if there is a heading too close to the end of the docu­ment.

What I've written here is prob­ably long enough, but adding this final sentence can't hurt.