Force messages with the same nick use smaller padding

[lizmat]

Looks great! Thank you very much!

However, this appears to have some repercussions on the special styles used for camelia messages and commit messages, and on the live view: for date changes:

They're not vertically centered correctly, or their top border is too tall.

Looks like the config for "special-test", "special-code" and "special-commit" also need the same type of tweaking? Or tweaking to counteract the tweaking?

[ogdenwebb]

@lizmat I've update styles, but probably it's all that I can achieve without changes in template right now. At least we need to append class="message" or something like that to normal message, because it's hard to select normal messages. System messages don't have padding before them, but I can't implement that using table tag in any way.

Furthermore, using HTML table for such complex layout isn't a good idea at all, because it prevents us from tweaking margins to get different padding for different rows. Table is not suitable for this case. :/

[lizmat]

@ogdenwebb: the use of tables for this, is simply because of my background in HTML 0.9 :-) I used to be able to do layout stuff by using <table><tr><td>. There is no other reason than that.

Marking "normal" messages with a class, is definitely an option. It would be but a simple tweak to the template.

So if you could give me some pointers for a non-table approach, I could do the necessary changes. If you think it'd be easier to do them yourself, that's also fine by me. I could give you write access to this repo, if you want.

[ogdenwebb]

Currently I'm working on homepage, so I wanna push those changes next. Besides I will think about a better approach for the message log, maybe an extra class for "normal" messages would be enough.

[lizmat]

@ogdenwebb: there is already a class special-same-nick. You'd want the opposite of that?

[lizmat]

@ogdenwebb: FYI, I've moved the message rendering logic to a subroutine in common-subs, to ensure the scrollup/scrolldown message rendering is automatically in sync.

[ogdenwebb]

there is already a class special-same-nick. You'd want the opposite of that?

Yes, if a message not special-* type -> it needs a specific class, I suggest something like message. For now I can't say in styles something like "select normal messages after special-same-nick" simple because there's no such class.

[lizmat]

I've just added an initial class, which will be set on each message that would not need to be closer to its predecessor.

@ogdenwebb: that's what you wanted, right?

[ogdenwebb]

@lizmat nah, it's not what I wanted. I wanted to get a class for normal messages, i.e. messages without any other classes.

I will try to example with this pseudocode:

if msg-class not in [special-same-nick, special-camelia, special-commit, special-thread-header, ...]
    add class "_class_name_" 

[lizmat]

@ogdenwebb: I can also make that happen. But I thought that the idea was to easily identify the messages that should not have their vertical spacing reduced? "initial" will do that, because all of the "special-" class cases should not have vertical spacing reduced?

[ogdenwebb]

Well, I take a look at the message log again, and I can't see a way to implement it with this table layout. Top margin for elements like special-commit is prolly impossible, because other messages have padding which add some space on top within their container, but I can't actually add extra padding to special-commit, because instead of

<empty space>
----border----
_special_commit_text_
----border----

It will do that

----border----
<empty space>
_special_commit_text_
----border----

Alas limitations of CSS don't allow us to choose the last element in subsequence, so I can't properly select each last element in group of special-same-nick.

So @lizmat would you accept the PR like is or it needs a better solution? If not, you can close this request.

[lizmat]

Almost ready to close this request. :-)

What would be needed for a better solution? Could you elaborate (other than "not using <table>s" :-)

[lizmat]

Also, as to doing things differently: would it make sense to make 3 different templates, one for mobile, one for pad, and one for desktop, and use an outer <iframe> to make the decision which form to use?

[ogdenwebb]

What would be needed for a better solution?

Rewrite that not using table. :)

Could you elaborate (other than "not using table's

As I said, it's related to table tag/CSS limitations, not because I want to see more work on that. As you can see now, I tried to rewrite this keeping current layout with minimal changes, but sadly without success.

and use an outer