Want to get involved in developing SMF, then why not lend a hand on our github!

Main Menu

Has anyone improved /main_block.png to have transparent rounded edges?

Started by Biology Forums, August 30, 2019, 11:35:58 AM

Previous topic - Next topic


Quote from: Study Force on September 14, 2019, 02:58:54 PM

Looking great. Can't wait to install!

Me too.  ;) I'm especially interested in the full width banner in the example above, I think I could make good use of that setup..


Quote from: Study Force on September 14, 2019, 02:58:54 PMLooking great. Can't wait to install!

Haven't looked @ the code yet, but the empty space after "Page 2" sort of bugs me, can that be removed?

It probably can, if you're prepared to throw enough code and determination at it. I'm not prepared to do that.

Obviously there's no point displaying a "next page" link when there's no next page, so the page index in Subs.php is coded to not echo it to the browser in that situation. I could recode it to echo an anchor with no href instead, but that will confuse somebody sooner or later.

The way it works is that the select has 40px padding left and right, and the anchors sit over that. This keeps it nice and compact if the browser doesn't allow styling of selects, and insists on forcing the default dropdown arrow. But obviously when there's no anchor you see the padding. It doesn't bother me. I'm happy with the overall size of that bullet staying consistent.

If you're not happy with it then you (meaning not me) are welcome to code something you prefer.

ETA: Hmm. Stuff it. Now I'm thinking again, and that always means trouble.

Personally I use a Gecko-based browser (or whatever they're calling Gecko these days) and that allows styling of selects. I think Webkit will also allow it if you declare -webkit-appearance: none; but since I've not been coding for a while I haven't tried that recently. No idea what Android does either. I could charge the battery in the old Android tablet I never use and see how it goes, but frankly cannot be bothered at the moment (serious dedication is a thing, y'know).

However, since I personally only give a rat's about Gecko (do they still call it that?) then I could style the selects up with a much smaller side padding. The anchors can still be positioned where I want them by simply changing the left and right declarations, so that's easy.

Naturally, if I do this, someone will rock up using a browser that does not allow styling of selects, and will demand that I sort a solution for them. :P At which point I may refer them to my previous answer. :)

Biology Forums

Once I get my hands on it, I'll see what I can do to make it look more pleasant to my eyes.

Thanks for the explanation


Damn. I had an idea. :P

Obviously the function in Subs.php knows whether there's a next or previous page. So, I can use that to append a class to the page index wrapper. Something obvious and idot-proof like .pageindex_wrapper.first and .pageindex_wrapper.last would be ok.

That way it becomes stylable in the CSS without any extra logic shenanigans. You'd just do it like this:

.pageindex_wrapper. {
    margin: 0 40px;
.pageindex_wrapper.first {
    margin-left: 0;
.pageindex_wrapper.last {
    margin-right: 0;

The reason you will need the switchable margins is that the anchors are absolute positioned, which means they don't have any ability to push other things sideways. All the pushing has to be done by the wrapper, so the margins have to be on that, and they have to be wide enough to keep things clear of the anchors when those are displayed (there will always be at least one).

Why not just static or relative position the anchors? Two reasons. First, absolute lets them hide default select ends if you can't style those away in whatever browser. Second, form elements like selects are notorious for inconsistent cross-browser and cross-platform behaviour.

Basically everyone just implements them in their own way, which makes predicting the height with any given font-size and line-height very tricky (read damned near impossible). But, if the anchors are absolute positioned they can be set to top: 0; and bottom: 0; and that makes them automatically stretch to the height of the wrapper, and the wrapper will be the height of the select, so it will always work.

Always work is good. :)


Ok, sorted. Now whatever you do, don't come up with any more ideas for improvements. :P

Biology Forums

Gorgeous 👍👍👍

Quote from: Antechinus on September 15, 2019, 09:06:07 AM
Ok, sorted. Now whatever you do, don't come up with any more ideas for improvements. :P

I can't make any guarantees once you've uploaded the latest version, but it sure looks sweet!


What happens if you throw a 100 page topic at it? 1000 pages? Do you end up with a 1000 item dropdown?


Firefox (and derivatives) seem to default to auto overflow on the options list once you have a few dozen pages. That's still quick to scroll via keyboard, but yes 1,000 pages would be a bit much. TBH my instincts are to say that anyone who allows 1,000 page threads deserves what they get.

OTOH, it's a bit much with the default page index too. That's a PITA once you have 100 pages, so I'm not sure this would be any worse on long topics. However, if you have any ideas on how to better handle long topics I'm all ears. The only ones I can think of would be first page and last page buttons, which shouldn't be hard to code, but then they take up extra gui space


Have been doing a bit more tidying up on this. One of the things I have been trying to do is keep the index.css file size down, without cramping it for formatting or skimping on comments. It's been a bit of a thing for me to keep it no bigger than the default file (55.1 kB) despite all the extra trickery it has. Have managed to do it too. :)

But then I was thinking about editor.css. That only had about a dozen lines of codes in it, which seemed like a waste of an http request, but it's going to be called anyway due to the back end code. A bit of messing around made it obvious that a chunk of stuff in index.css could be moved over to editor.css, which will save a bit of processing when not using the reply/modify page. So editor.css is now 3.3 kB of useful bits, including a little bit of responsive, and index.css is down to 53.8 kB.

If you're clever with teh mathematics stuff you might be thinking that 55.1 - 3.3 =/= 53.8, and you'd be right. I added a bit to the code that was moved to editor.css. Thought that while I was messing with it I might as well freshen the editor page up a little bit. Got rid of the old background gifs, ditched the dividers, threw a CSS gradient at the button backgrounds, and tweaked things a bit to make them more finger-friendly. The gradient is the same one as used in the theme's header, and I think it fits well here. I'm liking it a lot.

The other bright idea I had was fixing one of my old sins, namely the default bottom border on BBC links. This tends to look pox on linked images. :P The reason I talked the team into it originally was that people thought the links in posts needed something to make them more noticeable, but I was finding a standard text-decoration: underline; in the links' #346 colour was too distracting when reading. It sits just below the text baseline, and slices through any letters which extend down from there. I find the effect much like trying to read text that has a strikethrough. So we decided bottom border was the way to go, because that sits clear of the text, and linked images have been pox ever since. :D

So today I was looking up some CSS bits and found out that text-decoration: underline; is a bit like CSS borders. You can choose any colour you like. It doesn't have to be the same as the link colour. Which I never knew, after years of frigging around with CSS. :P This means you can get a nicer and more subtle underline. The other thing is that these days we have box-shadow too, and if you declare a box-shadow with a zero blur radius it makes a nice straight line, and if you declare it as inset then it will make a nice underline beneath your text, but if an image is linked it will be behind the image background. As long as the image has an opaque background, no border will be visible. If the image is transparent across the bottom edge the inset box-shadow is visible, but not particularly obtrusive.

The upshot of this is that links in posts, etc now have an inset box-shadow by default, but on hover or focus they also get text-decoration: underline; which gives a double bottom border effect. I think this is a good solution. I find it easy to scan while reading, it gives a clear indication on mouseover, and linked images don't look like pox. I'm quite chuffed with this simple little bit of CSS. :)

/* @WIP: Styling for BBC tags */
.bbc_link:link, .bbc_link:visited {
box-shadow: inset 0 -1px 0 #aaa;
.bbc_link:hover, .bbc_link:focus {
text-decoration: underline #666;
box-shadow: inset 0 -1px 0 #666;


Double underline on links? :) Its a different look no doubt..but not something I would use I think.


At least it's not dashed or wavy. :D

It's only on hover or focus. Single underline the rest of the time. The double-underlined link in the middle of that screenshot had my cursor over it, but that doesn't show up in the screenshot.

I like it. It's clear, but not harsh or crude (providing the colours are chosen well). The other alternative would be to simply double the width of the inset box-shadow on hover or focus, which is simply a matter of changing the y-axis value to -2px.

ETA: Come to think of it, that may be better.


Ok fearless beta testers: you asked for it. Here it is. Another effing zip. :D

I'm getting cocky and calling this RC1. I think it's good enough for that.

As before, this is a collection of loose files which need to be dropped into the folder of an existing theme (default, or a copy thereof).

Also attached is a zip for the page index mod, which is now gloriously titled the Dangerous Marsupial Page Index. :P

However, it should not really be all that dangerous. I just called it that for fun. I have tested it, and it installs and uninstalls cleanly on any theme I had to hand, although for some it would benefit from custom CSS for select sizing, colour scheme, etc.

Do note that the mod has not yet been checked and approved by the SMF mod team.


Nice, I will have a play with it...

first thing I noticed is that the layout still has the same issue with the quick reply box that responsive Curve has: the quick reply box is not responsive...
Running SMF 2.1 with latest TinyPortal at


Will need more details. You know how bug reports work. It's fine on my box, all the way down to 240px wide.

Just tested it on Opera (latest version) and on IE8 (because I could). Perfect in both.

ETA: Oh, if you're not testing it on local host, did you hard refresh to clear the old cached CSS?


Just checked the Responsive Curve mod code (v 1.0) and it doesn't contain anything that refers to the quick reply. So that bug you're seeing cannot be the fault of that mod. It must be coming from default 2.0.x code, or from interference from some other mod you have installed.


I am using Chrome, and Yes I have cleared cache.

This issue seems to occur in Chrome, not in other browsers...  :'(

As I stated: this issue also occurs in responsive Curve, so indeed you will not find any corrections for it there...

I think I reported this in the responsive Curve thread a while ago, can't find the report back ATM...
Running SMF 2.1 with latest TinyPortal at


Yeah I just had a look through that thread, and while there were grumbles about all sorts of things there were none about an overflow on the quick reply.

I'll grab Chrome and play with it. What width does it start breaking at for you?


Ok, downloaded and installed Chrome. Like Opera, it won't go below 480px wide on desktop. This seems to be hard-coded, in typical Google "We don't want this thing to be actually useful and we won't let you customise our precious interface" fashion. :P

However, the quick reply scales perfectly with Chrome, on Windoze 7, down to a screen width of 480px.


Aha! I had a bright idea, and installed TP 1.6.3 on my local 2.0.x site. Suddenly, the quick reply breaks in Chrome. Pretty clear where it's coming from then. Bloody mod authors. Go give them Hell. :D


TP does some stuff to textareas/quickreply..or at least it used to. Not sure now, but this might indicate it does still.

As always when testing: one with mods, one without(preferable this one first :D  )