Update index.css #1006
Update index.css #1006
Conversation
Backgrounds are clear in some browsers because gradient is incomplete or does not have support for a default. This is my attempt to make the css more compatible. Edited ref: http://www.colorzilla.com/gradient-editor/ butchs 12/7/2013 <-- signoff? ;)
|
It would be useful to know which browsers are not supported by the current code I changed previously to shorten it down from 5 to 2 declarations for every gradient. But honestly if this is what we're supposed to do for every gradient we should just revert to the older method, the file is already in the 100KB range as it is. (100KB is larger than some browsers will cache) also please note that your signoff is not in the correct format. I don't know which client you're using and therefore no way to suggest what the proper signoff mechanism would be for you. |
|
Now what? If we use two declarations we minus well limit the browsers that SMF accepts. If we do that we minus well make a pop-up to warn users that the site is only optimized for X & Y browsers. But really, will that help SMF? Not like we are getting donations or anything for using a specific browser. All I know is that FF 3.6 and Safari 4.1 both show the menus as invisible. Link to a picture: http://www.smfhelper.com/community/index.php/topic,5786.msg53066.html#msg53066 If you really wanted t get lazy you could simply make sure that that you add a background statement that specifies s solid color for all the gradients. Then they would not be see through with older browsers and would have never posted this thread. Nevertheless, if you want gradients for all, using an image or browser specific css files (like SMF did in the past) is not that bad. I use many clients for security reasons. My favorite insecure client is my Mac. Apparently I have absolutely no idea what you are talking about "proper signoff mechanism". |
|
I'm not sure we should even be supporting Firefox 3.6 at this point. Even though it's not quite 4 years old, the latest version of Firefox is 25. Why on earth would someone still be using 3.6? Safari is a different issue, since that's only a couple versions of OS X behind current. The "proper signoff mechanism" he's talking about is the proper way to sign-off individual commits for whatever you're using to make them. If you're using command-line/shell, you just need to add the "s" flag for each commit ( |
|
Someone would be using Firefox 3.6 if for example they are on a G4 with OS X 10.4... however we are not obliged to offer support for old environments. We don't support IE below IE8, I don't see why we should support a version of Firefox 20 versions behind the current. As far as Safari goes, Safari 4 is nearly 5 years old (2008 release), Safari 5 is 3 years old but only supports OS X 10.5 and up. The thing is, while we are obliged to provide a reasonable branch of support - which is why IE8 is still on the table - but for versions that are that old, we have issues to contend with. Encouraging users to stay on older browsers does mean that they are likely to be left behind in terms of updates - including security patches. But here's the thing, I did a quick search of browser usage, found http://www.netmarketshare.com/browser-market-share.aspx?qprid=2&qpcustomd=0 - while not definitive, it puts FF 3.6 at 0.33% market share (below IE 6 and 7 which we're not supporting, which have 4.92% and 1.34% respectively), suggesting that 3.6 is a version far below that which we should be worrying about. Safari 4 doesn't even feature in the list, which is impressive since even IE 4 ist listed with a meagre 0.12%, suggesting that that's a non issue. I'm sorry but I cannot in good conscience penalise the majority of the user base with a larger CSS file to cater for something I can only describe as a minority. This is why I asked you which browsers were not being covered, because from the research I did, all the currently supported browsers are covered with the possible exception of IE8 without a fallback gradient - and we should be declaring backgrounds for those if we are not already. |
|
Stop looking through horse Blinders, fixating on my cheapness. 8~) There are how many gradients? Four or five? You guys are Pros in programming so I will not waste my time telling how to simplify things... Previous versions of SMF covered many browsers. I try to write my code to support all browsers. I am sure there are other "newer" browsers you currently neglect. Pick your poison. The proposed code covered many browsers. If you want to know what it look at the comments: Penalize? Really how much larger is the file vs todays computers? This is 2013, not 1995? How many users have dial-up anymore? What is the penalty? I remember back when men were men who programmed using text editor in assembly. Since the mod 90's things simplified. Code was bundled in subroutines, then nested subroutines. Yet computers remained the same speed... Today average upload speed of a AT&T DSL upload in USA is 850 KB/s (ref: http://www.speedtest.net/isp/att-dsl). What is the speed difference for a 96 KB vs 200 KB file with that speed? I doubt speed is the issue. Penalize? Who is to say that generating gradients is faster? Did we do it just because it was cool? According to webkit images are faster. Check out this link: https://trac.webkit.org/wiki/QtWebKitGraphics#Usestaticimages Why sacrifice compatibility if it is not faster? Maybe our users will be penalized because someone here decided to use new css code without researching... If you still prefer gradients all you need to do to be compatible is add Here we go... If I can... git commit -asm 'Commit message' |
|
Why, exactly, do we need to put in a bunch of code to support browsers that don't even have a tenth of 1% of the user base? The proposed code covers many many browsers that are out of date and unsupported. The only browsers that have more than 1% of the userbase that we're not supporting are IE6 and IE7, and I hope you're not suggesting we encourage supporting those. So what if the average speed of AT&T DSL is 850KB/s? We have a substantial userbase that doesn't have great DSL. Like me, for example here in the UK, I have never had a speed that good for DSL. More relevantly though, mobile. I don't get 4G, don't get good 3G here in the UK and we tend to pay for bandwidth by the MB. Other countries have something similar - and we have to bear that in mind. Speed of transfer is not the only issue. The thing is, 100KB is large enough that some devices will not cache the CSS file, meaning it will be downloaded regularly, and I'd quite like to reduce that if possible. And that 100KB repeatedly will be a decent sized dent in any mobile plan. Generating gradients isn't faster, but let's not conflate the two 'speeds'. The main reason for the move to gradients is because it's actually been demonstrated to be easier for themers to deal with - and we had feedback that themers would appreciate having it easier rather than saving the minuscule performance difference that entails. The practical reality is that we have to build something that needs to be relatively easy to extend and do interesting with - because Curve's image structure was so complex, the number of people who just made Curve variations rather than interesting things. Also that's still not a signoff, and it's not attached to a commit (so we couldn't use it anyway :() |
|
So now what? Read selective portions of my comments to make a case to ignore the core? Refuse all I say because you have the power? I really do not care because as I told you many times before I prefer to throw a bone every now and then and run off to beat a solo drum. I hate politics and Git hub. Maybe one day yall will finish 2.1? Once again regretting trying to support SMF. I do not wish to use software that allows client side code on my computer so I can and will not add your silly signature. :-p |
|
No, I was only answering the arguments I had to answer, preferably without conflating multiple issues under one title. I hate politics too - the thing is, I'm not being stubborn because it's you. You make a valid point in general, and in an ideal world we would be able to support even obsolete and unsupported browsers. But this is not an ideal world, we have to be pragmatic. Adding a ton of compatibility code for browsers that don't have support any more is not a productive use of our time as a whole - please remember that you are only one user, as am I, and we have to build something that has to scale for a lot more uses than those we might imagine for ourselves. I don't like Git (or Github, though my problem is with Git as a system rather than Github as an implementation of that system) either, my comments about it have been most scathing. If you don't want to run a git client from the command line, that's fine, it just means we can't accept your contributions under any circumstances except for us manually implementing and committing them should we choose to do so. Your suggestion of using a solid background is something I'm strongly considering doing, I thought it already did that but clearly not, but I also know there are other related changes required for other bug fixes. I just object to bulking out the CSS file for browsers we are actively not supporting. It is not personal that I am being stubborn about this, it is because in my judgement, it is more of a negative effect than a positive one for the bulk of our users. |
|
'hat should be the minimum. Now that I have a new browser 10forFox I thought I will try signing off. -s |
|
Unfortunately trying to use the -s command to sign off doesn't work in comments, only works on commits themselves. |
|
Yup github is annoying like that, I was just facing the same issue. You can't signoff using the web interface here afaik. |
|
No, trying to sign off with a comment to an issue is still not going to work, no matter what you do. You need to sign off the commit because only the commit will be guaranteed to remain in the repo since people who do checkouts of the repo won't get all the issues and all the comments. I really enjoy wasting my time repeating myself. I realise you're frustrated with Git. You're not the only one. But things are the way they are, and frankly I don't care whether you like it. Those are the rules of contribution - signing off a commit with the proper tools before it can be accepted. |
|
Sorry but I will not load a 3rd party application on my computer. |
|
Then we can't accept your commit directly and would have to manually go through and apply it ourselves. It's a shame but if you're not prepared to follow the requirements laid down, we can't accept your contribution directly. We do not want to get into a situation like SMF had before where contributors threatened to remove their contributions if the licence was not opened up (nb, I wasn't one of them before you suspect something) |
|
I don't think "http://www.netmarketshare.com/browser-market-share.aspx?qprid=2&qpcustomd=0" is accurate at all. Here are some stats I use, and they all seem to be in line with one another, so I believe them to be more accurate, although not completely: http://www.w3counter.com/globalstats.php Personally, from a designer standpoint, I don't like the way SMF 2.1 catbg/titlebg are setup. There shouldn't be html wrappers. Wrapper elements should only be used to replace margin with padding, in conjunction with box-sizing:border-box. It appears to be that one element has the BG color, and the child element is the highlight gradient(with transparency). Why? If I wanted to use an image, or a more modern design such as a flat color, that's more work. Not to mention, I'd still be stuck with a useless wrapper. The best way to solve both of your problems, is just don't use a gradient. Hence, that's why flat design is considered modern. Because of numerous debates like this across the web. However, if I had to pick a method(or use my own), it would be butchs. I know it seems redundant to have all those background declarations, but it's necessary. Internet speed does still play an important role. Simply because of mobile devices(folks like me to take my mobile device to a cafe), massively shared bandwidth(public wifi is sloooow), and smartphone 3G/4G speeds. While 4G speeds are fast, and even 3G isn't that bad, the latency(packet loss) is a major issue. Having less HTTP requests goes a long way here(so IMO, CSS trumph's images). As Arantor says, 100K isn't catched by some browsers, mostly mobile devices(some don't catch anything above 42k). This is why you have to use a minified version of jquery or nothing at all. Then again, on the flipside, some browsers don't read lines in stylesheet past 4000, or 6000(depending on browser). The size of the CSS file doesn't matter. It's been awhile since I've did any research on this, so don't quote me on it. When I design, I reduce HTTP requests as much as possible, keep page elements below 720, keep js/css files below 100k, and don't exceed 4000 lines in my css files. I also avoid images/sprites over 300px in height(unless it's an illustration, a.k.a photo), due to ram consumption by the browser(greatly effects smartphones). Even with sprites I avoid 300px in height, as it makes perceived speed slower. It's just faster (because of progressive load) to have a long short sprite, then a square or tall sprite(math: width * height * 4 - ref: http://blog.vlad1.com/2009/06/22/to-sprite-or-not-to-sprite/). Those are the guidelines I tend to follow. |
|
The catbg/titlebg markup is actually set up virtually identically to how 2.0 did it - div with h3 or h4 in it - intentionally for the purposes of retaining some concept of backwards compatibility with 2.0 themes. Ripping that out is not something we can easily do right now, and the b/c argument is quite strong (though weakening every time I add something), and don't forget that the original Curve did this wrapping of layers specifically to provide rounded corner support for IE6, so another tick in the box for legacy support there. The problem with going with the massively redundant solution is that it will definitely push us back over the 100K limit (I know, I did that to bring it back under 100KB in the first place!) It also already stands at 4400 lines. As far as the 'wrapper handles one thing and inner handles something else' that's not quite accurate. The wrapper (div.cat_bar, div.title_bar) handles both the borders and the gradient, while the inner (h3.catbg etc.) handles the text sizing, and text shadow. I'm not sure removing the wrapper is entirely a good idea - there is a reason other forum systems have even more layers (XenForo in particular, their category headers are div > div > h3, optional blockquote) and I'd argue that from a styling perspective it's probably easier to do interesting things with it than it is a single element... It's a tough one to call, certainly. But I don't want to just chase flat design because it's 'in fashion' right now. |
|
Also, what about breaking some of the less commonly used stuff out of the main index.css file? I'm thinking stuff like the calendar's markup (there seems to be quite a bit of it) |
|
why not? sounds like a good option to me. is there any markup just for the moderation center? that could be split too if so. |
|
There is alot of cleanup that can be done to the index.css. In my fork, I combined all of the other css files to it, except for the editor & old IE CSS files. After cleanup and condensing those files, I managed to get around 2800+ lines, all un-minified. Not to mention I added media queries, because it was a responsive theme based on default. I can't remember right off the top of my head, but the wrapper element css, moderation area, menus, tables, admin, and calendar had a lot of crap or junk CSS as I call it. Everything else was pretty clean. Backwards compatibility would be an issue on removing the catbg/titlebg wrapper, and most wouldn't really have the basic skills to fix it on their own. |
|
Except when I try to do cleanup I get complained at for not supporting older browsers. |
|
Well, your gonna get bitched at either way. Just do your best to find a balance, and take what everyone else says with a grain of salt. In 99% of cases, you know what's best anyway. |
|
Except I did do my best to find a balance which is how this issue got posted in the first place... |
|
Well, your working your ass off. People shouldn't get so upset with those that are doing the work. It's easy to sit around and point out mistakes, suggestions, or be a think tank, it's another story to take the time to make it happen. Those that make it happen deserve a little more respect, and more lenience in my opinion. Which I think overall you are getting, but not always. Keep up the good work. You've inspired me and I've been trying to contribute in anyway that I can (still working on those avatars, I've done redid them 3 times already; failing perfectionist). IMO, the only thing that is really missing with the backgrounds, is that it was missing the standard fallback. Perhaps we could get way with using:
That would be considered a graceful degradation and acceptable. Right? What do you think? |
|
Thanks :) That would, generally, work - except for the insane way that things are nested; h3.catbg and the like are actually declared at times as having no background so they grab the parent, but it's not a global thing, as there are other places where the h3.catbg doesn't drop the background. It really needs a proper going over. |
+1 |
|
When I posted this I felt like I stepped into a big pile. I thought the post would take a few minutes. I was wrong. There are way too many duplicate gradients. We all know that the template code is getting obsolete. Why not call the gradients once and fix the template code? I rather not see those changes but will try to live with it. Because I know if you reworked that, the code in my boardhover mod would require major rework. ;( |
|
I'm not actually entirely against that, now that I think about it. I'd love to hear what the themer folk think about this. |
|
I bet the themer folk would not be happy with 2.1 as it stands. I learned about the gradients two months ago when I downloaded 2.1. One of my goals was to get a jump on my site theme mod. My experience working on the css forced me to make 36 changes and I was not done. This is more than I expected with a minor SMF release. |
|
Given the scale of change from 1.0 to 1.1 (entirely new default theme) there is a certain amount of precedence in SMF's history for such a large change. I'd be quite happy to listen to feedback from themer folks - if I actually had any. Other than your comments, and some comments about using image sprites instead of bare img tags, it's not like we've actually had much in the way of feedback from anyone who makes themes :( |
|
Personally I hate the SMF 2.1 theme. The thing I hate the most is the hover effects. They should be strictly onclick. Also, UI should be almost invisible. In SMF user view there are way too many links, especially on topic view(throw all action links in one dropdown menu per topic/reply. User-info/avatar in posts should be moved to the right side, instead of having it on the left, as content should be first for rtl readers, and user-info/avatar should be on the left for rtl readers. Replies should be collapsible, those read = collapsed, and unread = expend. With this, you could load more replies per page(because of less scrolling), lessening the load on the server. Responsive design of course, but to do this properly, table HTML would need to be replaced with divs & table CSS(or float the table cells, but that would be semantic). Borders should be used lightly, as they are considered noise, and render differently in various browsers. HTML5 & Microdata = ezpz to implement. Not much room for branding, but be a minimal of 150px set aside for it. A user friendly action would be to fix menu to top onscroll(or just fix it to the top period). Menu should be centered, and can be with just CSS. I think "*, *:before, *:after {box-sizing:borderbox}" should be used, but I hear it breaks the menu, although when I did it on my fork I was able to fix this issue(don't remember how, it wasn't hard). Colors need some tweaking, and the gold bars stick out like a sore thumb, very distracting. Footer & header(where userinfo & search is) is a waste of space. Why is the "unread posts and updated topics" within the breadcrumb section? These links should always be close to the user-info areas. In this case, it would have been in the user-dropdown, because it's user-related, and covers the whole forum. The collapsible icon in the board categories should be on the far right side for consistency, rather than left side of the board category title, which makes it look cluttered. Because of the large screen resolutions, I think the number of posts and number of topics should not be stacked to try and fill-in some of the empty space. I can go on all day, but until I get the time to whip of some working examples, talking about it doesn't do much good. ATM, I only get 1-2 hours a day, and some days none at all to contribute, as I'm busy with my graphic design, web design, web hosting, and photography business. Lately, I've been overwhelmed with hosting support, even though I have staff. Not to mention I'm a full time dad, and get hired for marketing research, computer setup, and technical editing at times. Which reminds me, I need to get caught on the business plan I'm writing for another hosting company(due by Jan 1.). I wish I had more time, as I believe with all my heart in free open source solutions. I'll help when & where I can, with what little I know, but I'm afraid it won't be much or as fast as some would like. |
On the other hand it should still be all basically-usable without JavaScript being enabled... OK, no editor and some other stuff but the basic forum should be completely usable if not ideal.
Don't like that idea. The idea is to have the important stuff that you want to do often available (quoting, editing, liking) and everything else in the dropdown menu.
Unfortunately that would tend to violate the law of least surprises; WordPress, XenForo, IPB, MyBB, SMF... these all have the poster on the left before the content that they have posted, for LTR. There is something we have become accustomed to - having the author before the content in much the same way as "Arantor said..." We have this expectation, then. If we should change it, I need more to go on than the argument presented thus far :(
The load is not even remotely lessened on the server - it's made infinitely worse. And you lose the characteristics around pages being consistent in terms of permalinks.
Responsive design is a stupid concept for a complex forum. There, I said it. It's stupid because all you're doing is hiding content that you've already output, farting around with the layout rather than actually focusing on content to present. XenForo does a responsive design - and it's not the greatest but probably the best pure responsive design - except it doesn't work significantly better on a mobile device than their regular theme does. On the other hand, IPB has a full dedicated mobile skin - which does so much more than merely futzing with CSS. See, responsive is one of those things that works in certain contexts. For a blog, it's great - the main post is the main content, everything else is basically subsidiary in nature and can be juggled around without so much pain. But in a forum, every topic is equal, every post is equal to any other - because of this you can't just reduce one post's prominence to another the way you can with a blog, nor can you readily reduce things like the poster information. There's a reason IPB didn't do a responsive theme - and very likely the same reason I'm thinking of - we have a lot of meta data floating about that shouldn't just be juggled about and hidden, but rethought. Same reason the original wireless themes weren't just CSS strip-downs of the main theme. Plus there's a bonus to having a dedicated mobile skin - you save bandwidth to the user. Which for those of us on data plans this would be important to consider. If we were to drastically cut down what we had in the poster info area (a la XenForo), I could seriously see us making that jump. But too many people want to clutter that up beyond what's already there, so I can't really justify it at this time. (Mind you, if we did have a postercard like XenForo we would inherently be decluttering anyway, by moving some of the icons up there)
Most of the borders are fairly straightforward. There's a liberal use of border box-sizing going on to help with that.
Yes, it just requires someone doing it. I'd sort of like to release 2.1 sometime in the not too distant future, and I'm hesitant to make any really huge changes in this line. We have XHTML, it works. Even changing the doctype infers making other non trivial changes across the codebase. And it's not like we can just easily and quickly jump to using HTML5 elements because of the stated goal of IE8 compatibility, which means researching, implementing and debugging use of one or other of the shims out there for it. Everything's a tradeoff. Right now this is a tradeoff that doesn't seem worth it to me.
Which has side effects with respect to navigation to part way down a page, no?
I personally would prefer it not to be.
A friend of mine suggested a hue change on all of the oranges in the theme, adding more red to them for a slightly more brown look - preserving the blue/contrast but without being so unpleasant. I did suggest going the flat route but there is resistance to this idea at this stage.
So where would you put the user info stuff exactly? I mean, we're talking about 3 links now rather than an avatar and some other stuff...
Prominence. Putting in the user dropdown is a bad idea, not a good one, because it makes it harder to actually use. It's a function people want to use often. They don't want to open a popup (which is, btw, a server round trip!) to click a link. But I'm not sold on that location. I'd far rather gut the current 'quick navigation' and put a link in there (like XenForo), and move those somewhere else.
Uhh, it is... It certainly is for me on every browser I've tried.
That's nice and consistent: have it collapsed and hidden entirely on narrower (< 1000px) screens, one column on mid sized screens and then two columns on really wide screens... hmm. Not sure I like that.
Every little help is appreciated - even if I don't agree (and I'm vocal about it when I don't, though I try to explain why), it's always worth having the conversation because it still promotes everyone thinking about it. :) |
|
On most of these things, we'll have to agree to disagree. Although one thing keeps bothering me. You keep saying with responsive design is hiding alot of outputted data. It certainly doesn't have to be this way. I made my fork responsive, and the only data I hid on small screens was topic and post count on the boardindex. Everything else was there. Look at Elkarte, it's responsive, and it doesn't hide much data either(mostly board index stuff). Alot of people have a misconception about responsive design, thinking its' about hiding stuff if it doesn't fit. Responsive design is more about moving and re-sizing to fit. I just wanted to point that out, but I won't bring up responsive design again. It's clear that it's just not going to happen. As far as the unread posts and updated topics, it's used often by some, but other may rarely use it. I've ran forums for years, and I have never used it. As far as HTML, I keep forgetting SMF doesn't want to be dependent on javascript(even though it uses a lot of it anyway). You kinda have to think about the chances or odds. Last I read, about 10% of users browse without javascript. I wonder how little percent of that is using IE8 without javascript? As I said before, it can eb done easily, and here is an interesting read on how(without using heavy js files): http://tatiyants.com/how-to-get-ie8-to-support-html5-tags-and-web-fonts/ |
|
So how do you fit all the content we have normally onto a mobile sized screen, exactly? That's the problem I have with responsive - there's just way too much stuff to fit. It's not so much a case of 'not going to happen', it's more of a case of 'show me how it would actually work in practice' because all the cases I've seen of it rely on there not being a lot of content there to start with. Elkarte is a great example of what I've been saying - the bulk of the poster information (which is the single biggest headache IMO) is hidden by default even on desktop, with one of those terrible hover menus. The only way I can see responsive working on SMF is if we drop half the content that would normally be shown - like XenForo doesn't show a ton of stuff on the topic display. As far as browsing with JS disabled... that's actually going up in recent times rather than down, in the wake of the privacy scandals. But it's not just about having JS disabled, it's the fact that adding a shim means research, implementation and debugging - as does any change. |
|
I do think the poster area shows way too much info. Contact stuff really shouldn't be there at all, and post/karma stats are questionable. In my fork, I stripped everything out except name & avatar(but expanded profile pages) with information. I use online/offline by adding opacity:1/opacity:0.5 to the avatar. I didn't know browsing without JS was actually increasing, but can believe it. I'm one of those that have grown more conscience of privacy, when just a few years ago I wasn't worried about it(my government has proven they cannot be trusted). |
|
Talking about not wanting to use JS, perhaps that' something we can see if we can trim down? Is here a fiddle I whipped up, where I experimented with :target, using it as a dropdown replacement. Needs work, missing reverse action, but just experimenting with it: http://jsfiddle.net/9qFV6/ Doesn't work in IE8 though, but I was wondering if there was a javascript fallback that could be done. Which would make it easier in future to phase out IE8 support. I think we are getting a bit off topic though. EDIT: found an interesting read: http://www.vanseodesign.com/css/click-events/ An example based on above: http://jsfiddle.net/L9BBD/ |
|
I am not a big fan of JS and less a fan of java. There are over 2,206,519 users of No Script for Firefox. This program is used to block JS. Many web pages load without it. |
|
Well, Java is a no-go for the obvious reason, and JS has nothing in common with Java except for four letters. ;) The thing about using CSS like that is that we still have to provide a fallback in JS for IE8 which still means messing about having two sets of code. Right now, pretty much everything should work even if JS is disabled, just not as 'nicely'. The menus up top for example will just go to the relevant pages when JS is disabled (alerts doesn't because the page for it to go to doesn't exist yet but you get my point) As far as the poster info showing too much stuff, I don't disagree - but a lot of our users are very intent on adding more stuff, not less, to it. Karma's going at some point (when I get around to making it a mod, basically), but groups and post stats are actually quite important for a lot of people. I don't know what to do for the best, but I'm fairly sure going uber-minimalism isn't the way our users want - even if it does solve the original issue here. ;) |
|
It's a hard choice indeed. In my fork, I just wanted one centralized location for more info on a user, including profile commenting, small personal album, buddies viewing, and a few more profile fields. I removed alot of info from message view because it seems to be just for measuring ego's anyway between users. Which seems to increase activity gaps between lurkers, and power users. I don't remember where I read this, but overall user engagement was better when users didn't feel threatened by power users(not staff); thus participated more. One of the ways to resolve this, I thought, was to make it seem as though posters were equals, mainly by removing post count from message view. IMO almost all that say they need "post count", are power user's or wanna-be power user's, because they feel it creates more one-upmanship. As far as Karma, with likes being around, it would be best to take it out. Pretty much for similar reasons mentioned above, user's(mostly power users) whine or abuse this. In my fork I intended to take it out, but ended up trying something new. Instead of having "post-based" membergroups, I turned them into "karma-based" membergroups. My fork never went alpha(although it was ready for it), so I never got to test it out to see the results. |
|
My opinion is that the core SMF should be simple. Provide the essentials but allow for mod or theme modifications to elaborate the code. To me the De facto standard is VB. I always modify my themes for a VB like appearance. VB 5.0.5 does not have gradients. Maybe we are over-complicating things? |
|
I really should get around to trying vB 5 as I have a licence for it... |
|
vB5 is pretty good, but still doesn't look as nice as it could. Take a look at protendo: http://protendo.net/ , very clean, very nice. |
|
Nice is a very subjective definition. I'm not exactly a fan because I find it rather bland, and our needs are somewhat different to Bloc's. |
|
I'm curious does current code covers 90% of the users in total? If so we don't really need it. |
|
You do know that 'bottom' and 'to top' are the same thing and that 'bottom' and 'to bottom' are not? Yay for testing? |
Backgrounds are clear in some browsers because gradient is incomplete or does not have support for a default. This is my attempt to make the css more compatible. Edited ref: http://www.colorzilla.com/gradient-editor/
butchs 12/7/2013 <-- signoff? ;)