Bulleted Lists

Continuing from the discussion in the 'Game Wiki' thread [ref]:
The erroneous blank lines seem to be gone.

This seems to have broken the ability to nest lists. It was working yesterday, but now we get a [ list] and [ /list] line and the original list continues as though they were not there.

I should have take screen-shots, but you can see this on the example post on staging [ref].

The nested lists now show up like this:


'C outer' is strangely indented and spaced, and the [ /list] appears to be the final one, outside the list, so it is unclear which one is closing the list.

[list]
[*] A outer
[*] B outer
[list]
[*] A inner
[*] B inner
[/list]
[*] C outer
[/list]

I believe the syntax is to denote the starting number by using that number as the signifier, not as a separate number. But the bbCode 'spec' is very loose.

The most common way to do this is [ list=2] or [ list=b] or [ list=ii] to start at the second number. This has the benefit of using the same format to specify numbers as letters as numerals, but it does have the downside that the code needs to interpret all the options and turn them into a number for the HTML. If it is much easier to look for a number and use that for the `start=` value, then this looks like a very workable solution.
I have not seen any other problems from the changes. But I don't know what CSS you changed (just version numbers?). Everything else seems to be working as it used to.

Regex gonna regex. I'll look at it.
I looked and found 4 different syntaxes, so I just made one that made sense to me. If anyone has a preference, I'm open to it. We can always do something like
Yah, if I wanna do it where you put in the start point in the format you want it to run, that'll require a bit more work, basically some sort of code that determines what format you're using and what the start value stands for. The HTML spec is the number of the value you're starting at, so I went with that, in a compressed format. If we'd prefer a more readable/approachable format, I can do it, it'll just take longer. And has potential flaws. Is list=i a roman numeral list or a alphabetic list starting at i?
I changed the reset behavior for all lists (not just posts) as well as padding for lists. This means anywhere there's a list on the site, it could have potentially broken. I don't think it has, but I always add that caveat.

Are you using straight regex or the nestedReplace function? I only know it from Adam mentioning it could help in this sort of situation [post].
Unfortunately true. :(
Very good point. Sticking with =format,startValue is looking like the safest bet. It even works with [ list=2] with 2 being both the format and the start, so it is pretty nice.

That's it! I forgot to make it recursive!
Yah, I made sure to set that up, because I felt list=1,4 was too verbose.

Will this be added to the BBcode Guide thread?

@vagueGM Nesting should be fixed, as well as any list marker display cutoffs.

The previous test page does not load properly anymore. Can you see https://staging.gamersplane.com/forums/thread/21901/?p=1818483#p1818483?

All pages seem to be broken after the first post, second post on a page is empty and then the page ends.

Fixed that bug

That looks great now.

I'm hoping at least one other person checks it out, and if it looks good, I'll put the code live this evening.

In terms of formatting, maybe the numbers should be bolded?

This CSS does it for me:

ol > li::marker {
  font-weight: bold;
}

Bolded markers are definitely a design choice. Some people like them, some don't. I could add a flag for that to make it optional?

Additionally, @Chalrytharendir points out that the padding is insufficient for larger roman numerals. So we have 3 choices as far as I see:

1) Write logic that tries to figure out how many characters in a marker and add padding appropriately (this could be pretty tough, at least for a quick fix)
2) Add left padding sufficient to handle bigger numbers always, but leaving it intended a fair bit (something about 3x the current value)
3) Add left padding if it's a roman numeral list, but then different lists would look differently.

Maybe if it is not too much work and does not clutter up the bbCode. It is only an issue when using complex nested lists. In the first screenshot, below, the inner list is easy to lose, in the second the bold number make it a little easier to find, but not enough to justify it if some don't like it.

---

---

Actually it looks insufficient for all lists that need more than two places. [ list=99] gives the numbers 99, 00, 01, ...

@Keleth Could you add an argument to give the user control over the padding? Use the current for default, then user variable changes it by a factor of x.
[ list=type,start,paddingfactor]
That way most use cases work by default, but for edge cases that get cut off, the user can fix it themselves.

Or what about something like this?
< ol style="list-style-type:upper-roman; list-style-position:inside;" >
< li style="text-indent:-1em; margin-left:1em;" >

I think it would something like this:The dots of each item don't always line up, but the numerals are never cutoff.

list-style-position:inside; does weird things with the alignment and indentation. We should think about reserving this for lists that are going to break because of too long items (†) and not as a default which breaks all lists.

((†) Roman numerals are more common on an second level list, where there is already space to the left.)

This is also caused by something in reset.css, excluding that from a page fixes these list problems, so it may be worth looking at what reset.css is doing and patching out the bits that break things.

I've been playing around with spacing, and I found a value I like for non-roman numerals. It works for numbers < 10000, but falls apart at roman numerals with more than 4 characters. The problem is because the box that contains the post itself doesn't allow content larger than the box to show (a safety measure for an image too large, or something like that).

So I see one of two solutions: a flag you can add to the list to allow for approximately 1.5x spacing or 1.5x the spacing for roman numeral lists.

'Solution' three: Accept that long lists of roman numerals are going to be a problem for many reasons and leave it as is?

Solution usually implies solving the problem, heh, but yes, that is a third possible outcome.

:) 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.