Bulleted Lists

:) Sometimes the 'solution' is 'if it ain't broke, don't fix it'?

reset.css is changing the defaults for ol, ul, and li, to 0 padding and margin, which also has knock-on effects. Adding a `padding-inline-start: 40px;` instead of the `margin-left: 3ch;` to ul and ol seems to mostly fix the left-cut-off (except for roman numerals more than 4 characters (on Chrome, Firefox works fine sans reset.css), but then I challenge you to tell me what 'cmxvc' equates to... keep your romans under control, people!).

`padding-inline-start: 40px;` is what was the default (computed) style on both Chrome and Firefox before reset.css broke it.

But then, removing `ol, ul, li,` from `styles/reset.less` line 11 also seems to 'fix' it.

Yah, it's an ancient reset, and I don't even know what folks do to reset these days. It's worth noting that 5ch (the current value) is equivalent to 41px. And using margin vs padding doesn't have any meaningful difference here. I'll wait till this evening, and if no one has any further feedback, or opinions on the roman numeral side, I'll put it on prod.

Fair enough, I have no idea. I was just going off of what the browsers did, and assuming they had a reason for favoring `padding-inline-start` over `padding-left` (I could not tell the difference there either).
So, you are using reset.css to remove the defaults and then adding those defaults (or their equivalent) right back?
Removing reset.css completely, did change the way the page rendered, but I did not look at anything else except for the lists (and the Preview/Post button, which was in view and wonky). Maybe, once the lists are done with, we can disable reset.css on staging and see what looks wrong. A lot of what is being 'reset' is being added back, so we may have some doubling up (the lists are double indented, for instance (margin vs padding)), but we may be able to simplify the css by not doing double work and using the browsers' defaults. I would trust the browsers to know better than me what works these days, I haven't seen a need for 'reset' since, like, ie8. But I have not looked into the current popular opinion on if a reset is still 'needed'.

The thing is, which browser? The default styles on Chrome are different than those on Firefox than on Opera, let alone smaller browsers. They're also different on mobile vs desktop. Best as I can tell, resets are still as necessary (some googling suggests that normalize is the new reset, which I like linguistically) as they were in the past, because each browser has a different default behavior. Every CSS framework I've seen has their own reset. In fact, a poll I found on a quick search suggests that of people who know what a CSS reset is, almost everyone uses one. And it seems modern resets mostly standardize things, but then rely on you to set up your base stylings (which makes sense).

Even if the reset wasn't necessary, the GP stylings are built on it, making removing it not an option. So it's not that I removed the default then added it back in. In this case, I'm using 5ch, meaning 5x the width of the 0 character. It happens to be 41px in this case, but lets say we modified the font size slightly? This would scale with that, whereas a static 40 doesn't. So it's not that a lot of what's in the reset is being added back, but rather because we don't know what value a browser may or may not be adding/setting, we set a bunch of rules to set a baseline, then build our own rules on top of that. You could argue they should be one file, integrating the settings where we can, but I'd also say it's like any other programming package that alters behavior... we could merge it, but what if we want to update the package (the reset) later? I know I've updated the reset file at least a few times over the years as browsers have evolved.

Fair enough. I am not a web developer. I only end up needing to look at this stuff when it breaks, and then it is almost always a 'reset' that broke it. :) If you had no reset the lists would have 'just worked'... up to a point, but the web seems to assume we won't be using excessively long lists (and, most of the time, that is probably true).
Yeah, it broke the buttons, I saw that much.

So I've been asking around, and sounds like I was wrong and you're right. There are still a lot of differences between browsers, but they're less breaking than before. With less of a focus on absolute pixel values and more on adaptive layouts, like my use of ch vs px, you'll likely end up overriding everything, but that's more of a deliberate choice rather than a reset, specially with the addition of sudo-functions in CSS.

The new code is live on prod. If someone doesn't mind adding it to the BBCode guide, I'd appreciate it, or I'll get to it as soon as I can.

I've rolled this back as it broke other stuff. I'd appreciate help replicating this on staging so we can figure out what's wrong.

Is it intended that bare bullets (with no [ list] tag) work? It is nice if all we need is a bullet that wraps with indent, but, if it is unintentional, there may side affects that need to be thought through. It works inconsistently, and breaks if it is the last thing in the post or sheet for instance, but I can not see any other side effects.

bare list

second bare

 code >>>
[*] bare list

[*] second bare

<<<

bare list

[*] second bare (broken, can be fixed by adding any character on the line below)

No, bare lists are not intended to work, nor do I want them to. They only work because of browser error catching. I didn't think browsers would bother. It actually does highlight a problem in the bbcode parser, which I'll address. I can add removing converting bare lists to li's, but it'll be low priority, as it's not super important IMO.