Look into creating style properties as opposed to directing people to editing your CSS files.
I could do that, sure
All of XenForo's menu's are loaded at the bottom of the page if you look at the source, you have yours loading in a random div below the chat with display none.
Is there a difference? I'm not being sarcastic, I'm genuinely curious as to whether there's any actual difference in terms of how the page loads / looks.
Also if there's 200 messages in the chat box there would be 200 menus loading (although hidden)?
Like I said before, each menu has a different context. Consider the following scenario:
There are 4 people using the Shoutbox just now:
- User ID 1 (Administrator, in the Administrators user group)
- User ID 2 (Moderator, in the Moderators user group)
- User ID 3 (Member, in the Registered Members user group)
- User ID 4 (Annoy-o-tron, in the Squelched Users user group)
Simplified, that creates the following permission matrix:
- If you are viewing the SB as UID 1, you have the ability to edit/delete/prune shouts for user ID 1, 2, 3 and 4.
- If you are viewing the SB as UID 2, you have the ability to edit shouts for user ID 1, 2, 3 4
- If you are viewing the SB as UID 3, you have the ability to edit shouts for user ID 3
- If you are viewing the SB as UID 4, you have no editing capabilities at all
In other words, each combination of browsing user -> shout user creates an entirely different matrix, meaning I cannot simply have 1 menu item loaded as "one size fits all".
I can look into generating the menu on-the-fly, but I'm not sure if that would be more performance efficient than pre-loading them. However, it's also true that continuously loading/unloading DOM entries can have a negative impact on performance.
I'll definitely look into performing some tests on this once I have more of the actual functionality completed.
I'd suggest the username be linked to the membercard like default XenForo functionality and possibly add something near the date to edit/delete/report
I'm not sure how I would load extra membercard links only in that particular context, but it's definitely something I will be looking into. The design screenshot for that other Shoutbox was inspiring
(P.S permissions as if I can't delete/edit shouts I shouldn't be able to see them).
You don't have to tell me about permissions, this is handled via the jQuery Template. Options the user cannot access is not shown, hence why there's different menus. You don't have to teach me why permissions are a good idea
As for inline-styling you have a ton. A quick look at the source code would reveal that.
I will definitely look into that, it may have been a bodge to get Beta 1 ready and I forgot about it for Beta 2.
PS: I brought up with our Managing Director your feedback regarding the shout area on the left/right vs above/below, and we both agree that you have a very valid point. In Beta 3, we will be removing the left/right oriented shout area from the system. The Lite version will have the ability to choose to have a horizontal input area above or below the shoutbox
Fillip