Code block extra blank lines.

Can we remove the extra linebreaks from [ code] sections?
The software is inserting BR tags with each newline, but [ code] (really the pre it contains) tags already have the breaks they need.

these lines should appear
one after another
but they are all spaced out
vertically

should be:

these lines should appear
one after another
but they are all spaced out
vertically

---

Also reset.css is overriding the font from monospace back to default (reset.less, line 23). This probably should not apply to code and pre tags (reset.less, lines 7 and 8). I can add a fix for that once the flex CSS changes settle, but the BRs are probably in PHP which I am not looking at.

Assume my tag names have angle brackets around them, but I can not type them here. :)

Reset resets. That’s its job. It’s probably one of the standard resets. If it were me I’d put the styling back in using gamesplane.less. But, yeah, let’s wait for the new css.

I imagine the newlines are in the markitup php file. I can look at that after the last PR has been merged or rejected. I don’t want my codebase to get too out of sync.

I am also holding off on changes.

If changing the PHP ends up being too much work, we can hack it with some CSS
code > br { display: none; }
can hide the erroneous linebreaks.

We can take a look at when reset.css applies and maybe add !important to the rules it breaks, but I don't like !important! I would rather have it just not apply to 'code' and 'pre' tags, but we would need to test what that breaks (i.e. what it resets and why).

Resets are there so all browsers start from the same place, but I agree with the avoiding !important. I’d be surprised if reset isn’t at the start (I’m on a phone at the mo so it’s tricky to check).

I should probably go back, harvest todos, and plant them here ready for the next dev batch.

Fixing it in the PHP is probably the best way to fix it, but I love the ingenuity of this:
code > br { display: none; }

Urgh.
Code blocks are also stripping out backslashes, anywhere in a line, but doing weird things with them at the end of a line, even when followed by whitespace.

Well, everything fails to display backslashes \ but they are still there if you quote (check and see), or edit, so it is a display issue, unlike the < sanitization which will strip this out if I edit.

Code blocks should display as they appear, but we need to be careful of allowing dangerous characters.
So much for ASCII maps. :(

You are correct, reset loads first. Disabling it reverted back to the 'user agent stylesheet' for me.
This is a simple fix of adding the correct font lines to the gamesplane.less to override the reset.

Pretends to understand code stuff and nods approvingly.

The newlines is clearly a bug.

The question before the council is whether code tags should appear in a monospace font.

They do everywhere else, it is the default assumption, reset.css is changing that from what the browser sets.
code tags are the standard way to get something to show up exactly as it is typed, and monospace is the only way to get that. If they are not monospaced, then they serve no purpose and I can't see how they would be used. What would they do?

They might be used to describe how to use GP's tags - in which case the monospace could be confusing.

e.g.
This is how you make things bold for when your character is speaking

[b]"Ho thar!"[/b]

We tend to use italic for when your character is thinking

[i]Uh-oh,[/i] thought Stochastia [i]this looks bad[/i]

---

Otherwise, people end up doing that thing where they say "it's like this but without the spaces". Code is a little cleaner.

I don't see a problem with those examples being monospaced. I would expect those examples to be monospaced, they represent code and we don't want the user's funky font choices making that /i look like a /l or a /1 or a l1.

The path of least surprise says they should be monospaced like all other code blocks. This is the default, if we did nothing --if our css failed to load-- they would be monospace.
We have changed it from the default, I am proposing putting it back.

Sure. That might be what you expect. Me? I don’t know. I only discovered the tag existed recently.

The point of having a group of users discuss these is so that the community decides.

I’m abstaining on this one, because I have no preference (except for the newline thing which looks like a bug).

Understood. Just presenting the case.
I can always get my monospaced font via other means.

Not even pretending to understand any of the code talk: I just want the stuff inside the [code] tags to look like any other typed stuff. No special font, no double spacing. Just exactly as I type it, except the tags dont activate

'Tags don't activate' is a valid use case. Except that the code tag already does all sorts of other things. Important to this thread is that it sets the 'white-space: pre;' CSS attribute, which is why the blank lines are appearing. Normally HTML collapses multiple white-spaces into one, 'pre' --be it the tag or the attribute-- tells the engine to display exactly what was typed, including every space or newline.

The reason monospace comes into this is that we want it display what we saw, and other fonts can not assure us of that.

for instance         this line's gap should line up with
 this line's         gap, they do on my system. Do they on yours?

No way to know without a font that treats all characters as the same width. As seen below.

for instance         this line's gap should line up with
 this line's         gap, they do on my system. Do they on yours?

If you want to 'display exactly as typed' then a monospaced is required.

Okay, I see the point there. I'm just thinking of what I would use this tag for on GP and the only use I have is to explain tags to people. And for that, just being able to embed the code into a paragraph would be perfect and all I need.