Attached is a screen shot from my phone showing what I mean.
yep, that's one of the items on my todo list .. the memberlist isn't mobile compatible as of now.. I'll check that soon.
Oops, I scanned for topic titles that matched but not todo lists. Sorry.
it's in my mind, not noted here ;)
/me files a feature request for a search function in
@TE's mind :P
With appropriate word censoring :P
As long as you're going to have a look at the member list, here's another one. Only tested this in desktop view but when I click on the community drop down and select members it always comes up with some letter in the first row then starts the member list. (even with one member.)
See attachment. (And the letter is different on my more populated test forum, debug output?)
:D It's supposed to do that. It splits the member list according to the starting letter of the username. Your example has one member called scripple, so the header is an "S".
TBH I think the formatting could be a bit better, since the lower case letter gets a bit lost in the middle of the page. It could do with a bit more oomph, and probably left aligned would help to make it look more like a heading (which is what it is).
Well, I guess I should feel stupid now. :P But I'd say you're right it needs some different formatting as it looked nothing like a header to me.
I hadn't looked at it since that change was implemented (never used to have it). I can see what they mean it to be doing, but agree that in its present form it does look more like a bug than a feature.
Hey found another bug (a real one). The zebra striping of the member list is broken. It should start at the beginning of the list, but it doesn't. It only comes in near the end of the page (specifically, in the "C" group).
The striping on my more populate test site actually starts right after the A, but then stops after b starts and stays off the rest of the page. Looking at a few more pages the pattern I see is if the letter bar is on white that section is striped. If the letter is on gray (the slightly darker color) that section is all gray.
It seems to be all over the place. Just check a few pages of the list here.
ETA: Issue - https://github.com/elkarte/Elkarte/issues/1459
I'm currently migrating the memberlist from tables to list elements, basic draft is:
<ul class="mlist">
<li class="basic_row"><span>Rowdata1</span><span>RowData2</span>... </li>
<li class="alternate_row"><span>Rowdata1</span><span>RowData2</span>... </li>
</ul>
It's mainly needed for proper styling, especially on mobile devices..
@Antechinus Objections?
I'd be more inclined to use divs than spans (same as board index and message index) but sure, nothing wrong with using a list for the main part.
It's going to get quite complex with the number of "cells" you'll need for a memberlist though, particularly if people start adding custom fields. You can't know in advance how much width each "cell" will need. For this sort of thing, a table really is the best solution. It's exactly what they were meant for, but if you need to use lists......
I still think the headers that split the list into letter categories need something extra. They aren't really just another row. They're dividers between section of content. You could drop an h3 into the li for those, and style that.
Yep, absolutely and I'll switch from span to div, it's more consistent with BoardIndex and MessageIndex. Thanks for the hint :)
The letters separator was my doing. O:-)
Remember: if you find something broken is usually my fault, but I'll always blame Norv. :P
ok, the initial bug report will be fixed with PR1465
https://github.com/elkarte/Elkarte/pull/1465
I was looking at the mlist in "mobile" mode, what do you think about hiding the email and keep for example... position or website?
email is usually (hopefully) an empty field, so it is not very helpful. Website may be more likely to have an entry, but probably the "position" is the more helpful for "the community" and not being a link it gives some space to safely scroll the list with the touch.
yep, that's what I wanted to do.. but unfortunately the problem is more complex.
email is (if available -> it's for admins only) the second child of that list.. for others the second child is website.
Thus the usage of child selectors, e.g. n+3 would give different results for admins vs. non-admins..
Ohhh... mmm... then it may need some class?
Yup. If you want to hide things selectively, give them all a class. Child selectors end up being a PITA and more trouble than they're worth once things get past the simple stage. Classes are ideal for this sort of thing.
Not sure how custom fields would be handled though. That could be tricky (unless you give them all the same "custom" class and hide the lot).
See if that makes sense:
https://github.com/emanuele45/Dialogo/commit/59e10ff835f5977a5710876a5ac65c8b345517be
Hides:
email and date_registered at the first step
website at the second
* posts at the third
ETA: forgot to add,
@TE what do you think about removing the left and right borders of the mlist table in Be Social!? They have some small problem connecting with the rounded header.
yep, no objections removing the borders .. changes looking good :+1: