Inconsistent list-item sizing

[ericscheid]

Ordered lists get rendered as either rendered text directly within a <li></li>, or rendered text wrapped inside a <p></p> inside <li></li>, depending on whether a blank line exists between list items. This is a Marked behaviour and not the issue.

When lists are embedded within a <blockquote>, the .phb CSS adjusts the font-family and font-size to match the <p> elements within a block quote. That is, they become ScalySans 11.98px.

However, the .phb css rules are incomplete, in that an blockquote ol li has a different font-size than blockquote ol li p, blockquote p, blockquote ul li, and blockquote ul li p.

Examples of the various cases here:
https://homebrewery.naturalcrit.com/share/h-ppujWlgKDG

[ericscheid]

In bundle.css in the browser, there is this css rule:

.phb blockquote p, .phb blockquote ul {
    font-size: .352cm;
    line-height: 1.1em
}

There is no similar rule for ol. There should either be a rule for ol, or we change that "ul" to "li".

[ericscheid]

Here is a sample brew code to demonstrate the different behavior (because that share link will go poof eventually)

Observe the different line lengths due to different font-size:

> 1. THIS IS TEXT OF SAME LENGTH
> 1. THIS IS TEXT OF SAME LENGTH
> 
> 1. THIS IS TEXT OF SAME LENGTH
> 1. THIS IS TEXT OF SAME LENGTH
> 1. THIS IS TEXT OF SAME LENGTH
> 1. THIS IS TEXT OF SAME LENGTH


This doesn't happen with a non-blockquoted ordered list:

1. THIS IS TEXT OF SAME LENGTH
1. THIS IS TEXT OF SAME LENGTH

1. THIS IS TEXT OF SAME LENGTH
1. THIS IS TEXT OF SAME LENGTH
1. THIS IS TEXT OF SAME LENGTH
1. THIS IS TEXT OF SAME LENGTH

This doesn't happen with unordered lists:

> - THIS IS TEXT OF SAME LENGTH
> - THIS IS TEXT OF SAME LENGTH
> 
> - THIS IS TEXT OF SAME LENGTH
> - THIS IS TEXT OF SAME LENGTH
> - THIS IS TEXT OF SAME LENGTH
> - THIS IS TEXT OF SAME LENGTH

[calculuschild]

Right, so just to double-check, I found PHB page 189 with a numbered list and 190 which has a bulleted list in a green note. The font size looks identical to the normal text within a note, so you're right we just needed to bump up that weird smaller font.

[calculuschild]

Fixed by #1108 !

[ericscheid]

Ugh .. https://www.reddit.com/r/homebrewery/comments/k0ou1l/issue_notes_size_increase/

Seems there are brews that were relying on that smaller font size for .notes li and this change bumps them up, breaking page/column layouts.

So, in the interest of not breaking brews I suggest we diverge from strict phb style with the following:

<style>
  .phb blockquote li, 
  .phb blockquote li p { font-size: .317cm } 
</style>

(The font-size difference between .352cm and .317cm is barely noticeable, except where it impacts on line-length and word-wrap)

[Gazook89]

In my opinion, I don't think there is an issue going ahead with changing the font-size on these lists to match the PHB just because previous brews will break a little bit. The perceived purpose of the Homebrewery is to quickly make homebrew content in a particular style, and if a version of the tool is not following that style then it should be updated.
It would be great to have the ability to separate out versions as I'm pretty sure you are planning to do, and update only new brews. But otherwise, matching the desired style should be the ultimate goal. Brews that bump into issues can have small adjustments to margins, line-heights, padding, on a case by case basis, as offered on that original reddit thread.

[calculuschild]

@Gazook89

Edit: I didn't realize how long this got. Sorry!

While I agree with you in principle, there are some nuances that became more apparent when we tried doing this kind of thing earlier. If you are actively working on your brew, sure, you can make some tweaks and fix them as you keep working.

This becomes quite a bit more obnoxious if your brew is large. You go to work on it one day and suddenly, half the pages are scrambled, and you can't quite tell what went wrong. So you spend hours re-arranging everything in your document to make things line up how they used to, except now it all doesn't fit because the font is slightly bigger, and maybe you don't know enough CSS to fix it. So now you're shuffling everything down page by page, for 45 pages. And then in a month something breaks again.

It's a bad user experience. The subreddit was swamped with complaints and rants and threats because we had, quite literally, destroyed hours of work for thousands of people. So we undid the update and learned our lesson (even if sometimes we still make a change that we didn't realize was going to have a huge impact, like this issue, and we have to repent again). Because we aren't just providing a CSS style file. We provide a place for people to create and store homebrew documents. And if we are carelessly destroying those documents, we are also failing in our purpose, just in a different way.

However, the real issue is for archival purposes. There are some very popular brews out there that are no longer actively worked on, but have tens of thousands of views and are accessed on a daily basis. Suddenly randomly corrupting them is extremely disruptive to not just the authors ( they might not even realize that the documents linked in their blog/website/etc. from four years ago are now broken ), but the viewers have no idea what's going on, and maybe don't know who to tell to fix it. Imagine all of the Word documents on your computer just suddenly going halfway off the edge of the page with no explanation.

So, yes, we aim to be accurate for a certain document style. But as a software package, we also need to consider the hundreds of thousands of registered users. To this end, we try to follow Semantic Versioning protocol as much as we can. If an update is going to break the expected outcome of our software, even if it is "more correct", it should technically be a separate major version number (i.e., if you created a document in version 2.5.3, later using version 2.10.4 will output the same thing. maybe 2.10.4 has new features added or bugs fixed, but it didn't break anything. Version 3.0.0, however, is free to break the rules.)

So... all of these potentially breaking fixes are going to wait for v3. We will also keep v2 around in the form of a "legacy" renderer for old documents, and we will let it stay untouched to preserve all the old documents, until a user voluntarily "upgrades" a brew and willingly goes through that fixing-up process.

That said, we will probably leave v3 in a sort of "beta" stage for the first bit. Let users try it out, give feedback, point out styling issues, etc., knowing that their work will be scrambled every so often. I think being up front that we are making changes in a new, opt-in beta will be much better received than imposing destructive changes on everybody whether they want it or not. And for that reason, having a Brew Guru like you to give us feedback as we try to get closer to that accurate styling would be incredibly helpful. So know that we appreciate your comments!

[ericscheid]

This appears fixed in V3, both with unstyled blockquotes and with a curly-block of class "note".

> 1. THIS IS TEXT OF SAME LENGTH
> 
> 2. THIS IS TEXT OF SAME LENGTH
> 2. THIS IS TEXT OF SAME LENGTH
> 2. THIS IS TEXT OF SAME LENGTH


{{note
1. THIS IS TEXT OF SAME LENGTH

2. THIS IS TEXT OF SAME LENGTH
2. THIS IS TEXT OF SAME LENGTH
2. THIS IS TEXT OF SAME LENGTH
}}

.. produces this on staging:

This fix might be accidental though, because the v3 renderer doesn't seem to create a mix of text-node and paragraph-node list-items. Editing the html in the inspector to reproduce the legacy html shows the V3 CSS handles this properly now.

The v3 renderer does seem to no longer facilitate spaced list-items inside note blocks. Which is a separate issue for another day.

[calculuschild]

The CSS has been fixed, yep. (Font size and line spacing is now the same for each item)

If the paragraph/text node generating is not working, that would be due to differences in Marked.js versions. Should be fixed in the new Marked though once it comes out. markedjs/marked#2112

[calculuschild]

Added to the V3 changelog finally. Closing.