FIX: remove additional vertical whitespace in Firefox for list entries with line breaks

[violoncelloCH]

fixes #68 by excluding br elements from getting top and bottom margin applied to .prose > ul > li > *:first-child by adding :not(br)

I'm using @nuxt/content which uses remark and rehype for Markdown processing and generates this sort of html output:

<ul>
    <li>
        "A kékszakállú herceg vára"<br>
        ("Herzog Blaubarts Burg")<br>
        HERZOG
    </li>
</ul>

from Markdown content like this:

### B. Bartók:

* "A kékszakállú herceg vára"  
  ("Herzog Blaubarts Burg")  
  HERZOG

before:

firefox	chromium

after:

consistent styling in Firefox and Chromium

[violoncelloCH]

I'm not sure why the tests are failing. As I'm not familiar with the codebase and I didn't find specific documentation, I just assumed I'd need to manually adjust index.test.js . So any feedback would be more than welcome. Also a review by someone of the maintainers :) (cc @RobinMalfait as you seem to be currently working on tailwind-typography)

[violoncelloCH]

so I figured out how to update the test snapshots, I've also rebased this PR on current master and I've updated the description to be a little more precise
I'd be happy about a quick review from on of the maintainers :) (cc @adamwathan ?)

[RobinMalfait]

Hey! Thank you for your PR!
Much appreciated! 🙏

While I see your issue you are having, I feel like this is a bandaid and not a real fix. I think the real fix would be to not include br tags in the first place.

For example, imagine you have a markdown compiler and it has a bug that it spits out double p tags like <p><p>...</p></p>. In that case your output would look different as well. In that case you would have to open a pr and do something like :not(br):not(p > p) and so on.

This PR will also change some of the specificity that can have issues for other people.

So while I appreciate the PR, I don't think that this is our responsibility to fix the issue of having br's in there. To expand on that, what if people deliberately insert <br /> tags? In that case their styling would look wrong all of a sudden. So you could argue that we have to provide a configuration option for it, but that just seems like to much hassle.

So if you do want to fix this, than I think the best solution for you would be to:

1. Delegate this issue to the tool that converts your markdown.
2. Or, modify the typography styles in your tailwind.config.js

Here is an example on how to put a simple version in your own tailwind config: https://play.tailwindcss.com/77Q5Mhpghf?file=config

[violoncelloCH]

Thank you very much for your detailed feedback!
Did I understand you correctly that putting <br /> tags directly into a <li> element is wrong in the first place? So what would be the correct way to do it? Wrap the content of the <li> element in a <p> like this?

  <ul>
    <li>
      <p>
        "A kékszakállú herceg vára"<br />
        ("Herzog Blaubarts Burg")</br>
        HERZOG
      </p>
    </li>
  </ul>

thanks in advance for a quick confirmation, so I can report this correctly to the markdown processor!
And thanks for the play example which I'll probably use until this is fixed in the markdown processor...

[LostKobrakai]

While I can see that you don't want to fix issues of markdown compilers I don't think this it that kind of issue. Firefox does apply margins on <br> elements on the whole line before the <br>. Any other inline element I tried doesn't have such a behaviour. So at best this may be a bug of firefox. Having just text and inline elements as children of an <li> is legitimate html, just drastically more noticeable when being based on markdown.

[LostKobrakai]

Did some more digging: There are a few more inline elements, which make the <li> grow with the additional margin, but <br> and <wbr> are so far the only ones working differently in ff than in chrome/safari (all mac):

https://codepen.io/LostKobrakai/pen/ExgejOa

[violoncelloCH]

interesting find @LostKobrakai
I tested your codepen on GNU/Linux in Firefox, Chromium and a Webkit based Browser (Gnome Web) and get the same result: Firefox behaves differently than the other two and adds the top margin to <br> and <wbr> elements. The other Browsers don't threat those elements as candidates for li > :first-child

[LostKobrakai]

Even other inline tags are considered li > :first-child. That's not the issu, but margins on inline elements should overlay any other content instead of increasing the li's height.