Actually, that's a *very* good point.
Right now we inject the colours inline. What we should be doing is converting them to a class, e.g. groupnn where nn is the group id, then passing the styling in through a dynamic include (like menu items and languages do)
This would offer up all kinds of options to admins for styling, in theory. And it'd probably save bandwidth if you have multiple instances of the same groups on the page.
Posted: March 22nd, 2013, 02:17 AM
Now that I think about it, there is an extra saving - it doesn't even need to be pulled every page, as such. You still need to get the groups of everyone, of course, but you wouldn't need to get the group details every page. Every little bit helps :)
You would have to flush the CSS cache, at least wherever it is that the group styling would be, but that's a minor detail by comparison.
@Nao, what do you reckon?
Hmmmm I dunno.
If you feel like doing it, do it. I don't like that the icons are so big though. It'll take adjusting.
100% agreement on group colors.
What would be the class name? I'm thinking mgroup-ID. With a numeric id.
Which reminds me I wanted to test waters: how about we use only dashes in selector names instead of underscores? I have a feeling it would compress better... and it looks better, too.
Posted: March 24th, 2013, 08:20 PM
PS: bugger, I could have seen an easy movie reference for rev 2019 :P
Anyway, I have a working version of it using classes rather than inline styles. I haven't benchmarked it for size, but it should perform a little better because I don't need to fetch all the colours as such, I only need to fetch (and thus *cache*) the actual name->primary group association, because colours are already cached elsewhere.
This also means the usual gamut of appropriate cache flushing, which I think I've nailed.
There are some other interesting possibilities that come out of this. I've implemented it as top level classes, i.e. quite literally .group1, .group2 etc for all groups that actually have colours. What it does mean is that the often-requested 'Blizzard style posts' can be done *crazy* easy, because now the principle styling of groups is not tied into the group itself.
So if you want to style an entire post with the same formatting, just add the relevant class in - which shouldn't really be a problem from my perspective. There are all kinds of weird exceptions, like quotes, but I figure that's all fixable too. What I want to know is whether people would genuinely find it useful to have that, or whether I shouldn't bother making it an option or anything. Doing it as a plugin would be possible but not particularly pleasant (it would be better to make it core rather than not)
I haven't figured out what I want to do with things like offering easy options in the admin panel about group icons or anything like (but that could actually be a plugin!) or styling things like bold, italic etc. (which I'd rather were core than not, because while it's possible to do the UI side of it, doing the admin side is going to be... not so nice)
/mecontinues to ramble on late into the night.Posted: March 28th, 2013, 03:45 AM
Oh hell I just found a problem, and I'm really not sure how best to fix this.
The profile links in topic display all have class .umme attached to them, and currently the rewriter is adding two class attributes. I presume similar would happen with the mentions tag too (since the member bbc converts to include a class="mention", though I don't see what it's doing at present)
I might try and modify wedge_profile_colors() to get pre-existing classes, but that's where I'm up to.
Posted: March 28th, 2013, 04:07 AM
OK, I think I fixed it, by modifying wedge_profile_colors() but also that feels hacky; strpos and string slicing seems not how I should be doing this but it is at least linear in operation.
Posted: March 28th, 2013, 04:30 AM
Yup, fixed it, wedge_profile_colors now does it correctly. I think Imma go commit this.