News:

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

Antechinus

Oh it's basically the same head code as 2.1 index.template, except  that I want to call areas and subactions for targeting CSS.
So:

if (!empty($context['menu_data_' . $context['max_menu_id']]['current_area']))
$body_class[] = 'area_' . $context['menu_data_' . $context['max_menu_id']]['current_area'];


And yes it comes out of Subs-Menu.php, but if I can get a workaround to stop it throwing errors in index.template that would be really handy.

ETA: Nevermind. I think I've got it. The problem is only when bouncing around areas that don't call the sidebar menu (like board index, search, whatever). If you're in admin or profile or pm's or moderation, the menu is called so it's happy and doesn't throw errors.

So all I need is a check to see if current_action is already defined as one of those areas, then echo the code for finding current_area if you're in an action which will have current_area available. Should work, and shouldn't throw undefined's.

Antechinus

Ok, sorted. Looks like this:

// Allow setting body tag class by action or board.
$body_class = array();
if (!empty($context['current_action']))
$body_class[] = 'action_'. $context['current_action'];
foreach (array('admin', 'moderate', 'profile', 'pm') as $css_trix)
if (!empty($context['current_action']) && (($context['current_action']) === $css_trix))
$body_class[] = 'area_' . $context['menu_data_' . $context['max_menu_id']]['current_area'];
if (!empty($context['current_subaction']))
$body_class[] = 'subaction_' . $context['current_subaction'];
if (empty($body_class))
$body_class[] = 'action_index';

echo '
</head>
<body class="', implode(' ',$body_class), '">';


Echoes the correct classes everywhere, and doesn't throw undefined errors anywhere. :)

Antechinus

Turns out a few simple adjustments make most of admin pretty decent on a 320 screen. I'd done a couple of the easy pages already (core features, etc) but the majority of it is standard settings lists, and simply thumping them with this sorts things pretty well:

/* Equates to 512px at standard browser settings. */
@media screen and (max-width: 32em) {
.action_admin .content {
padding: 0;
}
.action_admin hr {
color: #bbb;
background-color: #bbb;
box-shadow: 0 1px 0 #fff;
}
.area_news tr, .area_news td {
position: relative;
display: block;
}
.area_news td {
margin-right: 40px;
}
.area_news td:last-child {
position: absolute;
top: 0;
right: 0;
bottom: 0;
width: 40px;
margin-right: 0;
padding: 8px 0;
}
.action_admin .settings dt,
.action_admin .settings dd,
dt.large_caption,
dd.large_caption,
.search_settings.floatleft,
.search_settings.floatright,
.msearch_details.floatleft,
.msearch_details.floatright,
.ban_settings.floatleft,
.ban_settings.floatright {
width: auto;
margin: 0;
float: none;
}
.msearch_details dt.righttext {
margin: 0 0 6px;
text-align: start;
}
.action_admin .settings dd {
margin-bottom: 9px;
padding-bottom: 4px;
text-align: right;
border-bottom: 1px solid #d4d4d4;
}
.action_admin .settings dd:last-child {
border-bottom: 0;
}
.subaction_mailingmembers .settings dd,
.subaction_sig dl:last-of-type li,
.subaction_bbc dl:last-of-type li,
.subaction_add dl:last-of-type div {
padding: 6px 0;
text-align: start;
}
.subaction_mailingmembers .settings label,
.ban_settings label {
line-height: 3em;
}


Antechinus

Quote from: Diego Andrés on September 25, 2019, 01:59:23 AM
This is probably pretty ****** but if you want to use it  :laugh:

I edited the stats_pie image changed the dent with a black background 20% opacity for the 20 icons
So now in css we can do something like this

.profile_pie {
    background-color: #5682B3;
    border-radius: 100%;
}


And the color will change for those horrible icons too

PS: Also didn't want to mess with the logic behind the usage of these images, whoever wrote the math for it and designed the icons was probably drunk because the rtl image isn't even the same mirrored :laugh:

I didn't give much thought to this yesterday (because I was thinking of how to fix that undefined error) but this isn't a bad idea. I think it could work well if the idea was switched around though, at least for themes with the default colour scheme, and have the dents done as white. That way it'd match the default pies that have lighter dents.

Then if the image is set to a pseudo element instead of the div, and set background-position to inherit, it will work for positioning and you can tweak opacity on the pseudo to adjust the lightness or darkness of your dents. So your proposed CSS to be adapted to something like this:

.profile_pie {
position: relative;
float: left;
height: 20px;
width: 20px;
margin: 0 1em;
text-indent: 100%;
overflow: hidden;
background: #6294ce;
border: 1px solid #6294ce;
border-radius: 50%;
}
.profile_pie::after {
position: absolute;
display: block;
top: 0;
right: 0;
bottom: 0;
left: 0;
content: "";
background-image: url(../images/stats_pie.png);
background-position: inherit;
opacity: .5;
}


The screenshot shows an opaque white .png (ie: dents only) with opacity adjusted to match the default. The border on the parent is optional.

Oh, the other thing about doing it this way is it's much easier if you want to change the colour of the dents, because you can just open the .png in PS or GIMP and throw a basic colour overlay at the one layer.




The RTL .png being wonky is funny, because what has happened is the PSD uses duplicates of the same groups for LTR and RTL, but has flipped the positions of the RTL ones. This is actually more work than doing it correctly, because all that needed to be done was save the LTR version as .png, then flip that image horizontally and save that as the RTL version. It would have been perfect that way. :D


Antechinus

Eh? No idea what you mean there.


Antechinus

No, I deliberately made them different sizes because otherwise there's no obvious way of telling which one does what. I figured different functionality should mean different styling in some way.

Come to think of it, I just noticed something really dumb about the stats page. In "Most Popular Boards By Activity" it has 100% of activity in
"Child Board Test", 79% of activity in "General Discussion". So that's 179% of activity in those two boards. Then there's another 50% activity in each of another two boards, for a total of 279%.

Brilliant. How the hell can someone have activity stats showing 2.79 times the maximum possible amount of actual activity? It makes no sense at all. The default stats are screwed. :P

It'd make more sense to ditch that entire section, since "boards by activity" is largely covered by "boards by posts" anyway, and at least the stats for the latter are accurate.

Biology Forums

I noticed that a very long time ago, it makes no sense at all. I'm assuming it has been corrected in 2.1

Antechinus

I think the sanest option here is to get rid of that section, which will save on some responsive CSS. I'm also thinking the pies are really crap anyway, and it'd be better to just have bars like on the stats centre and poll results. I have those styled up nicely now, so using the exact same classes for the profile stats (which frankly hardly anyone ever cares about anyway) would make a lot of sense. Then there are no worries about the silly pies. It's all basic CSS and consistent across the GUI. :)

Antechinus

Righty-o. Occam's effing Razor (also known as KISS - keep it stupid, simple). :D

No moar piez. Pi are not squared or rounded or anything else. Pi = 0. :P

Gave it the same classes and styling as the revamped stats centre. Hey, it's another stats page so why not? Saves a crapload of grotty CSS and a couple of images that everyone has always hated.

Also ditched the "Your activity level is 5 million and 93 thousand 7 hundred and 53 percent!" for even less silliness. I think I could even like this page now (I've always hated it before).


Antechinus

I'm looking at the thing and thinking "Why on earth didn't we do it this way to start with?". D'oh.

ETA: Bloody hell, I just thought of something else. Default CSS has the .lefttext class for situations where it's necessary to override text-align: center; inherited from a parent element or whatever (th's are an obvious example, since they are centred text by default).

Default index.css defines the .leftext class as text-align: left; which you might think would be sensible. It's actually really dumb, because then you have to define it as text-align: right; in rtl.css and there's no need to do it.

All .lefttext has to declare is text-align: start; and it will revert to the natural text alignment for any language, which is really what's wanted in that situation. This means the class doesn't need to be touched for RTL support. It will just work.

I'm going to go through my CSS and change any instances of text-align: left; to  text-align: start.

ETA again: w00t! The clever little munchkins have even included the opposite keyword in the specs. You can use text-align: end; too, which I just went and found out and am quite happy about. :D

This is very cool, because it means there's no need to re-declare any text alignment for RTL support. All declarations that used to use left can use start, and all declarations that used to use right can use end. Automatically turns out just how you want it, in any language. Yay! :D

Seriously, this should be default coding. It makes a lot more sense than using left and right.

Bloc


Antechinus

Be warned: IE and Edge don't support it. Everyone else has supported it for years. But it's not going to break usability in Edge anyway.

Antechinus

Hey rack your brains here a bit: I'm wondering which ul's in the SMF interface actually need padding or list-style.

I'm thinking not many. Offhand the only ones that spring to mind are bbc lists (which will have style declared inline anyway, and can have padding applied to the .bbc_list class) and the bullet list of stuff in the Help template. AFAIK, all the rest of them need to basically be the .reset class as a starting point.

I think it would save a substantial amount of crud in the CSS if the ul tag could be declared as a global reset instead of the .reset class, with the .reset class effectively becoming redundant in the markup. The reason being that there are quite a few ul's which don't have the .reset class in the markup, and then need CSS as if they were that class, and one global declaration is a lot simpler than editing a stack of templates or writing piles of pointless CSS. 

Arantor

The percentages of stats aren't wrong, you're reading them wrong.

Your posts account for 100% of the activity in the child board test, 79% of the activity in the other board etc.

Antechinus

Well, as you probably gathered, that made sense to nobody yesterday. :P It frankly doesn't seem like a particularly useful stat anyway, but I can easily drop the function back in if anyone is pining for it and likely to self-harm out of sheer, grinding despair. I do prefer it without the ruddy pies though.

And just as a FYI for anyone who wants to know: declaring a global reset on the ul tag seems to work very well.

ETA: Come to think of it, I might throw that function back in. Not because it's any real use to man or beast, but simply because the other one looks a bit bare and stretched on desktop. They can still stack on smaller screens. The currently-missing one could even be given a heading that explains it in terms that will make sense to most people. Radical notion. :)

Antechinus

Threw it back in. Also decided I liked it better with the "activity by time" thingy in its original position.

Not using the original images allowed dropping quite a bit of markup, both on this page and in the stats centre. While doing that I looked at the original logic. The default 2.0.x Stats.template.php has this sort of thing:

<div class="bar" style="width: ', $poster['post_percent'] + 4, 'px;">
<div style="width: ', $poster['post_percent'], 'px;"></div>


The second div is superfluous now, because it was only ever to do the left rounded end of the bar with the original image. That image is 400px wide, but the default coding restricts bar width to a maximum of 104px. IIRC this was because it had to support old browsers that didn't recognise media queries, so you were stuck with whatever you coded initially regardless of screen size.

This makes things look weird IMO, because on a wider screen (or even on tablet just after the stacking break point) you have bars which are supposed to be 100% but are nowhere near that width. So, I changed it to this:

<div class="bar" style="width: ', (.84 * $poster['post_percent']), '%;"></div>';

Which I think looks much better. It still allows enough space at the end of the bars for the necessary numbers, and scales nicely to any screen width.

The last block in the stats centre (time online) got a bit more breathing room due to the longer strings used there:

<div class="bar" style="width: ', (.67 * $poster['time_percent']), '%;"></div>';

Looks like the screenshots. I think this will do. :)

Advertisement: