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

Sir Osis of Liver

Just taking a quick look (been busy), would be nice if responsive dropmemu items highlight on hover, but it's way better than the tiny icons menu.  I had modded it back to text menu buttons on the couple of forums I used responsive curve.  Will catch up on this topic soon as I have time.
Ashes and diamonds, foe and friend,
 we were all equal in the end.

                                     - R. Waters

Antechinus

They should highlight on hover, if you mean the actual menu links. If you mean the hamburger triggers, I can easily make those highlight on hover if people think that would be better.

Sir Osis of Liver

You've double spaced the sidebar menu links in pc view, is that intentional?
Ashes and diamonds, foe and friend,
 we were all equal in the end.

                                     - R. Waters

Antechinus

Absolutely. Two reasons. First, I decided to style the top level links for consistency, to match the other menus. Second, the greater spacing will be more usable on touchscreen. "PC view" isn't just for PC's. It will also be seen on a lot of tablets. There's a third reason too. I just happen to like the look of the greater spacing.

If you want to reduce it slightly that's a very simple CSS edit. Bear in mind that this is just a base theme. I expect people to frig around with it. My job is just to get it functioning in base form.

Biology Forums

You did a phenomenal job. I made a small change, however, to the divider that appears when in mobile view. It's not necessary and makes the menu bar look out of place.

To replicate my change, in index.php, find

@media screen and (max-width: 960px) {

Add after:

#upper_section {
margin-bottom: 1em;
}

.navigate_section ul {
border-top: none;
}


Not it looks like (see 2nd attachment)

Make sure you remove browser cache to see it in action


Antechinus

Not a bad idea. I'll throw that in. :)

I have done some tweaking since the last zip, so I'll attach a new one in a few minutes (grab another coffee first, etc).

(I'm testing on local host, so I don't need to worry about the cache. A basic reload or page change updates the CSS when on local.)

Antechinus

Ok, next one. :)

Obviously it has the change mentioned just above (dropping top border from the linktree) but I coded it slightly differently for brevity (border: 0; instead of border: none; does exactly the same job, but saves a few bytes).

It also has another change to the linktree. I dropped the inline HTML entity (the >> thing) and substituted an ::after pseudo element to hold the dividers. This has the advantage that it can be easily changed in the CSS if you want different styling, or for RTL languages.

.navigate_section li::after {
font-size: 1.2em;
content: "\000BB";
}
.navigate_section .last::after {
display: none;
}


There are several other changes as well. The hamburgers now change to orange on hover, but with the menus being able to be keyboard activated I figured it needed some extra visual clues, so the hamburgers also now change to orange when the focus is on the hidden checkbox trigger. At this point you just hit your spacebar (if using Windows) and the menu will open. It functioned the same way before, but without the visual clue of the colour change it was not clear when you could trigger menu opening.

It also needed some tweaks for a11y, so the menus wouldn't be a PITA for anyone who wants to, or needs to, use keyboard navigation. And given that the menu opening is triggered by a checkbox and label, it made sense to give the label (the hamburger, for sighted users) some descriptive text so anyone on a screen reader wouldn't be wondering WTF that checkbox was doing in front of the menu.

So the hamburger markup is now done like this:

<input type="checkbox" id="main_menu_checkbox" class="hidden_checkbox" />
<div id="main_menu">
<label for="main_menu_checkbox" class="sidebar_toggle">', $txt['hamburger'], '</label>


With the text being:

$txt['hamburger'] = 'Menu visibility toggle';

Which should let people know "I can ignore that, since I'm using a screenreader anyway." This has required the use of a small ThemeStrings.english.php, but that's no drama. The descriptive text is hidden from sighted users by hidden overflow and 100% text-indent (simplest and easiest way of doing it).

I've also added skipnav links, for better usability with a keyboard or screenreader. The skipnav links are clearly visible on focus (but otherwise hidden) and of course have descriptive text. On page load, you can choose to skip the entire header and go straight to the content section. When in admin, profile, etc you can also choose to skip those menus (sidebar or drop) and go straight to the content on those pages. This saves a lot of tabbing through links you probably don't want at the time.

Next bit of trickery is this old dodge - Easy mod idea (multi language support stuff) - which basically means you don't have to worry about new.gif for your new post indicators. You can just style it up any way you want in your CSS and it will always have automatic support for any language. Speaking of which, those indicators are now sitting to the left of the topic title link, which looks neater and will also make them more usable on touchscreen (due to no other links around them).

Menu coding has also been cleaned up. I got rid of the superfluous spans, which makes CSS easier and saves some bloat, and the old $additional_items PHP and CSS is no longer necessary, since that was only a fudge to make things look reasonable if anyone had so many drop menu links that they would overflow the height of the old menu_gfx.png.

Apart from that there is some minor clean up stuff: dropping a bit of daft stuff, re-ordering CSS declarations so things are in a more sensible arrangement and easier to find, tweaking of eye candy, etc, etc.

Re daft stuff: the old compat.css, ie6.css, ie7.css and webkit.css are never used these days. I emptied those files of their content, but have left them in place. This is mainly so I don't have to scroll past their crap when running recursive searches on the default theme folder, but it also saves a few kb of storage space. They're left in place just to prevent the slight possibility of occasional back end errors.

By the way, the images/theme folder is largely redundant now. The only one still in use is the quickbuttons.png sprite. All the other images in that folder are deprecated, so can be removed if you like.

This zip is the same deal as the previous ones. Just copy it all over. It should work. :)

Aleksi "Lex" Kilpinen

Just wanted to say it's nice to see you fiddling with themes again, I'm still using a couple of your variants for 2.0 myself actually.
Slava
Ukraini!


"Before you allow people access to your forum, especially in an administrative position, you must be aware that that person can seriously damage your forum. Therefore, you should only allow people that you trust, implicitly, to have such access." -Douglas

How you can help SMF

Antechinus

Oh cool. I didn't mind those. Prince of Darkness was always one of my favourites. :)

I'm thinking I might update them with this CSS once it's been tested some more. Could be useful for some people, and wouldn't be hard to do.

True story: At the time I made PoD, Bryan had the same idea. IOW, making a basic colour inversion of the default main_block.png and then adding a few tweaks to go with that. He wanted to call it "Negative". I convinced the team that "Prince of Darkness" sounded much cooler. :D

Aleksi "Lex" Kilpinen

Yup, I like Prince of Darkness as well, that would be one of them :)
Choc being the other one.
Slava
Ukraini!


"Before you allow people access to your forum, especially in an administrative position, you must be aware that that person can seriously damage your forum. Therefore, you should only allow people that you trust, implicitly, to have such access." -Douglas

How you can help SMF

lurkalot

Great job on this again.  Just testing the latest files on my local.

I have noticed, that for me, the recently added "Go Up" button in the footer changes back to the old WAP link when you log out.

I'll get a chance to play more tonight.

Antechinus

That's an odd one. Doesn't happen with me on local host. Offhand I'm not sure what the cause would be. The coding there is very basic, and there is nothing that relies on user settings.

<li class="last"><a href="#index_top" id="go_top">', $txt['go_top'], '</a></li>

That's all there is to it. The only global is $txt, which was already declared by the default template anyway, and if the correct text is showing when logged in then the ThemeStrings file is loading correctly. Got me stumped at the moment.

I'd check if it is actually changing the url back to wap2, or if it is just changing the visible text and leaving the url as #index_top.

Not that I currently have a clue why it would do either of those weird things, but it's worth a look.

ETA: Oh hang on, I just thought of something. Is this a site where you have the real default Curve as site default, but where you have made a copy of the default for testing all this stuff? Because that would explain it. When logged in you'd be seeing the test copy, but when logged out you'd get actual default Curve, with the default wap2 link in the footer.

lurkalot

Quote from: Antechinus on September 06, 2019, 02:58:43 AM

ETA: Oh hang on, I just thought of something. Is this a site where you have the real default Curve as site default, but where you have made a copy of the default for testing all this stuff? Because that would explain it. When logged in you'd be seeing the test copy, but when logged out you'd get actual default Curve, with the default wap2 link in the footer.

:-[ You're bang on, that's the reason, I had switched theme quickly via my profile instead of making it overall default. So apologies are in order. Sorry.

Antechinus

Lol. I've done plenty of dumber things than that. :D Ok cool. It works the way it should then.

This messing around has got me thinking I should finish a mod I made (but never submitted) yonks ago. The default page index has got to be crap on touchscreen. I know this because it's crap on desktop, so has to be worse with fingers. :D

The mod I had mostly finished a while back replaces the page index with what is shown in the attached screenshot. The arrows each side of the select are next/previous page links, which is why there's only the "next" one visible on page 1 of the thread. The shots should make it clear how the things works. It's ideal for touchscreen and for keyboard activation. All of the gnarly bits of code are already done. It just needs a bit of tidying up here and there.

I just dragged it out of my stash of Jurassic files and tested it on this current little Curve clean up" thing. It would be perfect for use with this.

Kindred

lol.., I use that on on fx-sabers with Bloc's Studio003 theme (well, it was that theme before I tore into it. :D)

using your memberlist replacement mod too... 

Слaва
Украинi

Please do not PM, IM or Email me with support questions.  You will get better and faster responses in the support boards.  Thank you.

"Loki is not evil, although he is certainly not a force for good. Loki is... complicated."

Antechinus

Ha! You must have grabbed a test copy out of the Fiends board, coz IIRC that's the only place I ever posted it.

I'm thinking what it really needs to finish it off is edits to gets rid of the "Pages:" crap everywhere. Which is 67 edits in 21 files, but they're very trivial ones and are highly unlikely to ever conflict with anything else. Plus I'll set the XML operations for them to ignore the edit if there is a conflict, so extra safety there. Worst case scenario is a few stray ones might be left, and someone might have to edit them out of the template manually if they want the cleaner look (which I obviously would).

The other thing is I'm still thinking of the best way to mark up and present the rather cluttered combination of page index, buttonlists, up/down links, and next/previous links in Display.template.php so they all hang together in a sane way on smaller screens. I think I'll have that sorted soon. I'm getting a few ideas. :)

Kindred

take a look at the way Bloc (with further modification from me) did it
https://www.fx-sabers.com/forum/index.php?topic=52766.0

I think that displays pretty nicely
Слaва
Украинi

Please do not PM, IM or Email me with support questions.  You will get better and faster responses in the support boards.  Thank you.

"Loki is not evil, although he is certainly not a force for good. Loki is... complicated."

Antechinus

Yes that's very similar to the original. The pseudo elements appear to be identical.

Could do with a bit of tweaking. The select height doesn't match the heights of the anchors each side of it, which looks a bit dodgey. You have to define the sizing of selects quite tightly to get them consistent.

Yours appears to be inheriting a height of 1.8 em from line 189 of your index.css. That's not odd in itself. What is odd is that it's apparently overriding the line-height, max-height, and min-height that are set by the mod's CSS. Damned if I know why it would, because usually max and min height would win out in the cascade, but form elements are weird things.

Suggested fix:

Code (Find:) Select
.navPages_select {
margin: 0;
padding: 0.3em 3.8em 0 3.4em;
line-height: 2.1em;
min-height: 2.4em;
max-height: 2.4em;


Code (Replace:) Select
.navPages_select {
margin: 0;
padding: 0.3em 3.8em 0 3.4em;
line-height: 2.1em;
height: 2.4em;
min-height: 2.4em;
max-height: 2.4em;


That should nail the mongrel. If it does, I'll add it to the mod XML for belt and braces.

Antechinus

Had me a cunning idea. Turns out with the board index table you can do a nifty trick with very little code.

If you declare the td's as display: block; you can suddenly re-arrange them just like they were divs. Result is you can keep all information visible and neatly arranged all the way down to a 320 wide screen.

I'm still dropping the stats columns well before then, and also dropping the board description once things start getting tight, but essentially that's just to save extra scrolling. They wouldn't break the layout at all, and could be stacked like the others if you wanted to do that. This is all done with CSS (see screenshot). The basic table markup is the same as default.

Oh yeah, and there's none of that new-fangled grid or flex stuff involved either. It's just basic Jurassic floats. Doesn't need anything else. :)

.table_list td {
display: block;
}
.table_list .icon {
float: left;
width: 50px;
padding: 8px 0;
background: none;
}
.table_list .info, .table_list .lastpost {
width: auto;
margin-left: 50px;
padding: 6px;
}
.table_list .lastpost {
padding: 0 6px 6px;
line-height: 1.4em;
}


Now having come up with that trick for the board index, I naturally had a go at the message index/new replies/unread tables as well. They turn out to be more problematic, just because of the way their various bits and pieces are arranged.

This includes possibly having, or not having, participation icons and quick moderation checkboxes or icons, and having to keep the various background images and floated last post link images all behaving nicely together. It's a bit of a nightmare, so the message index etc topic tables are best left as boring old tables. Not quite as smooth to look at, but still perfectly usable.

Bloc

Thats is perhaps the biggest trouble with table using display: block - it only works on the more simplified  boardindex...

The question is perhaps if tables are wise to use for the layout of these collections of data in the first place. In essence, what do we require of messageindex?

1) a way to get inside a topic
2) see the subjects BEFORE we click

Thats all really. The other stuff is just extra info that ALSO are inside the topic and can possibly make us WANT to click/read it - or not. IMO that means messageindex should treated as a list, with possible extra info as a sublist or even just a text within the list - rather than a full blown table. Yes, its a table if you treat all the info equally important but it should not be, not to stay true to what a forum is: discussions and ways to categorise and interact with them.

Of course, this topic is about not changing existing markup and thats perfectly fine of course. Just wanted to point out some obstacles, IMHO, that stands in the way of creating truly responsive designs.

Advertisement: