[WIP/Public beta] Apocalypse theme

[Dhayzon]

awesome  very nice

[Antechinus]

Haha, yes I hear you I noticed the comments about that particular item in the template files for SMF 2.1 both now and earlier

In SMF2.0 I simply changed all $context['page_index'] to calling it in a PHP function: this small function located in index.template removes the uneeded stuff and puts proper CSS on the page links. Thus its dead easy to style them as you want. A little challenge because of the hardcoded markup but it works(I have to change all templates because of it..but I was doing that anyway).

Yup, that's the sort of thing I was thinking of. Either that or I just write a mod. I'm also revamping all the templates anyway.

Correct me if I am wrong, but SMF 2.1(or was it Elkarte) made those pagelinks into a theme specific theme setting, right? But why? Isn't it enough to just add a list + container , possibly spans around each...and then leave it up to the theme? It seems a bit far fetched to let the theme also render markup. Not that I complain haha, but a bit over the top perhaps. In any case its better than the SMF 2.0 way.

TBH I don't really know why them back end types did it the way they did for 2.1/Elk. All I know is I was grumbling about insufficient styling hooks, so went ahead and threw spans into Subs on the principle that I didn't care how it was done as long as people could style the result. The other dudes made it more complicated and moved some of it to index.template.php. I could still style it, so didn't care.

I was thinking about this last night though. Really it should be a list rather than just a succession of anchors, although I can live with just anchors. The current spans inside the anchors for some of the kinks aren't so crash hot though. It would be better to simply assign extra classes to those anchors. This is more flexible, and is cleaner markup. That would require rewriting the sprintf stuff slightly, but shouldn't be that big a deal.

ETA: Needs another variable called in the classes section, like this:

Code Select Expand

$base_link = '<a class="navPages%lolcatz" href="' . ($flexible_start ? $base_url : strtr($base_url, array('%' => '%%')) . ';start=%d') . '">%s</a> ';

Where teh lolcatz would be a space followed by nextprev (or whatever, if required for that link) and the actual "Previous page" text would be where it is now. At the moment all of this stuff just shoves it in where %s is in the base link:

Code Select Expand

// Show 'Prev'
if ($start >= $num_per_page)
$pageindex .= sprintf($base_link, $start - $num_per_page, '<span class="nextprev">'. $txt['previous_page']. '</span>');

So it would still want:

Code Select Expand

// Show 'Prev'
if ($start >= $num_per_page)
$pageindex .= sprintf($base_link, $start - $num_per_page, $txt['previous_page']);

Needs something else to sprintf the lolcatz into the right place.  Now with my skillz being mostly limited to front end stuffz, I might have to trundle over to Coding Discussion and start me a thread.

Oh and come to think of it, I'd also change the base link to add li's, and use an li wrapper around an anchor that had no href set for the expansion-onclick dots and the current page. That would be easiest for styling.

Code Select Expand

$base_link = '<li><a class="navPages" href="' . ($flexible_start ? $base_url : strtr($base_url, array('%' => '%%')) . ';start=%d') . '">%s</a></li>';

And:

Code Select Expand

// Show the ... after the first page.  (1 >...< 6 7 [8] 9 10 ... 15)
if ($start > $num_per_page * ($PageContiguous + 1))
$pageindex .= '<li><a class="navPages pages_dots"> ... </a></li>';

// Show the pages before the current one. (1 ... >6 7< [8] 9 10 ... 15)
for ($nCont = $PageContiguous; $nCont >= 1; $nCont--)
if ($start >= $num_per_page * $nCont)
{
$tmpStart = $start - $num_per_page * $nCont;
$pageindex.= sprintf($base_link, $tmpStart, $tmpStart / $num_per_page + 1);
}

// Show the current page. (1 ... 6 7 >[8]< 9 10 ... 15)
if (!$start_invalid)
$pageindex .= '<li><a class="navPages current_page">' . ($start / $num_per_page + 1) . '</a></li>';
else
$pageindex .= sprintf($base_link, $start, $start / $num_per_page + 1);

Then the templates would have:

Code Select Expand

<div class="pagesection">
<ul class="pagelinks"><li class="stupid_bloat_for_teh_extra_uglies">', $txt['pages'], '</li>', $context['page_index'], '</div>
</div>

Which would mean you could easily hide the extra text crap if you were thinking everyone would know it was a frigging page navigation list.

[Antechinus]

Been playing with the message index some more, just trying things out.

I've added an extra conditional to the div that holds all the last post and quick moderation stuff, to assign an extra class if either the checkboxes or icons are enabled (different class for each). This lets me get away with floating everything in there, for maximum layout flexibility, without it getting borked by the different quickmod modes (0, 1 or 2).

The icons for quickmod mode = 2 have been given a visible border and a bit of padding and margin, which should make things a bit easier to use (especially on touchscreen).

I've also done a bit of tweaking to make the notifications of unapproved topics and posts more consistent across templates and cleaner in looks. The warning icon is now set as a background image on the message index notice (upper right of the "table") and also on the topic title link. This gets stuff out of the markup and into the CSS, where it's easy to handle if you want to change it.

The board index uses the same image, inline this time, to do the notification of and link to unapproved posts/topics. This means all templates now use the same thingy to do the same job, which should be good.

The other thing is that I'm playing with using pseudo elements to do the last post link "icons", and am rather liking this treatment of them. A11y is no problem since the link itself still has a title attribute on it, meaning it's fine for screen readers even though the pseudos are not shown in the markup.

Topic icons and quickmod icons are still WIP and currently crap.

[Antechinus]

Done a bit more. I'm starting to ask myself where I stop with this. Will probably have to draw a line soon.

Quickmod icons are now using a sprite. I'm thinking I'll amalgamate this sprite with the one for the quickbuttons. It seems silly to have two sprites when one would do both jobs.

The other thing is that IMO the quickbuttons one needs revamping anyway. At the moment the icons go out of whack with the text if someone is using a non-standard text size in their browser settings. If the quickbuttons are changed to show the icons on a :before pseudo element instead of directly on the anchor, that pseudo can be defined to 20px wide and the same line-height as the text. If the new sprite runs horizontally instead of vertically it can have the y-axis positioning set to 50%, which means it will always stay lined up perfectly with the text. This is easy to do, so might as well do it.

I'm also thinking these pseudos should probably be given their own class. That could then be re-used all over the place, on either pseudos or spans or whatever, to sprite up a lot more icons easily. Haven't fully thought this through yet, but I think it has potential. Advantage is fewer http requests, with faster initial caching and rendering. Disadvantage is more CSS, and slightly more difficult to n00bz to change individual icons.

CSS is getting up a bit already but still comes in at 56kb minified, which is the same as the default 2.0.x unminified file. I'm going to try and hold it at that level. It's only that high due to the somewhat extravagant use of CSS in this theme. If emulating the default theme look on the same markup, the CSS would be a fair bit leaner.

Anyway, table-less topic index is now on unread posts and new replies templates too, and has been tweaked a bit more for styling. I'm kinda over bold text for sticky titles. I find it looks pretty crude at standard body text size, so have gone with a slightly larger font size for sticky titles. This looks a lot better to me, adding emphasis without looking clunky. Topic sorting options have been changed to comma-separated lowercase for the same reason: it's just easier on the eyes than the old way (also happens to fit better on a phone).

Topic titles are now in an h4 too, for better a11y (screen readers users tend to do a lot of navigation by h* tags).

[busterone]

I love it already! 

[kat]

When it wants testin', shove a copy my way. If anyone can break it...

[busterone]

LOL, I second that. When you are ready, I am game as well.   

[Antechinus]

Just a bit of a warning here. This is based on me wanting a clean foundation for future custom theming, which means I have been going through 2.0.x fixing all the stuff that bugs me about it. This theme currently has 25 customised templates (half the default theme total) because I couldn't could get the result I wanted with less than that. Quite apart from anything else, you can't get 2.0.x responsive without rewriting some templates, unless you just rely on hiding stuff all the time and call that "responsive".

This will still preserve a fair degree of mod compatibility, but it will break some of them. Personally, I don't care. I can easily write custom xml or whatever for any mod I think is worth installing, and (within reason) may be prepared to help other people out with it.

It will also rely my forthcoming page index being installed. Wont work without it. I am not going to attempt to write installation instructions for multiple themes for that one, so this theme is built with the new markup, and will need the appropriate Sources and script.js changes to function properly. This shouldn't be a problem for most people, since it wont conflict with anything except other mods which change the page index, and those can be removed if someone wants to use this theme. The advantages will be better a11y and almost unlimited styling potential.

Will probably also rely on the browser detection mod, although I'll see how that goes. If it's possible to do a good job without it, I will. The current main concerns are fixed positioned elements in iOS, which is pathetically bad at handling fixed positioning (for some reason, Apple's wonderfully innovative people seem to struggle with basic CSS2) and also the perennial IE stupidity (by default, 2.0.x doesn't realise there have been any IE releases after 8, and still tries to deal with 4).

Since some people may flip out at the prospect of a theme that replaces half the default templates (even though they will all be coded to release package standards, and quite suitable as direct replacements) I may also pull out some of the features of this beast and whip them up as individual mods.

[Bloc]

Noted.

TBH I am bit concerned personally about making these kind of theme projects, it seems as when I am working through templates there are so many optimizations that could be made to Sources files simultaneously...almost to the point of scratching it as a theme, and rather put it into a forked version of SMF. I just don't know, as I already been down that fork(ed) road..

But thumbs up for sticking with your theme(project).

[ARG01]

Noted.

TBH I am bit concerned personally about making these kind of theme projects, it seems as when I am working through templates there are so many optimizations that could be made to Sources files simultaneously...almost to the point of scratching it as a theme,...

I understand this completely. Unless it's a complete custom job for a paying customer with specific desires, I have learned to keep things (as far as SMF functions go) as close to default as possible. This helps in the long run when it comes down to users desiring custom mod use and keeps support down to a minimum.

However, I do applaud what Antechinus is doing here. Very impressive. 

[Antechinus]

Oh I quite understand all of that, and yes it certainly is tempting to rewrite larger chunks of Sources too. The thing is that I don't particularly like the default SMF interface. Never have. There are so many details (I'm into detail) that could easily be changed for something that IMO is better. As I said, I don't give a rat's about mod compatibility since I can sort that anyway. What I do give a rat's about is getting a result that doesn't leave me feeling that I've wasted my time.

If I want to do something totally n00b-proof I can do that easily enough. However, I find that boring, restrictive, and unsatisfying in terms of what it can deliver. Since I'm doing this for my own pleasure, I am not inclined to turn it into something that is boring, restrictive, and unsatisfying. As a themer, I am constantly getting pissed off by wanting to do things that should be simple, but are made difficult by the default state of SMF. What I'm aiming for is something that should be mostly n00b-proof, and in some ways easier for them to handle than default 2.0.x*, but making enough breaks with default 2.0.x theme to deliver what I think it should deliver.

Once it's sorted, anyone who is freaked out by the entire thing can pull it apart and nick whatever bits they think are useful. If you just want to use the Display.template.php and the bits of CSS for that, you can. Plus, it has already made me write code for several mods that other people may find useful, and which I can easily package up (the attachments handling is one obvious example). So, it should still be a useful resource even for people who just want to play with their own stuff, and it will provide me with a solid basis for doing whatever the hell I like.

*Example: the default CSS contains declarations for things which aren't even in 2.0.x. They are leftovers from beta and RC1 and all they do in the 2.0.x index.css is break things up and confuse people. Then there's the way the same thing is often declared in different places throughout the file, which makes customisation and debugging harder. Not to mention the excessive specificity of many declarations, and often the excessive markup tied to them, both of which are bad for performance and a PITA for customisation. Only the other day I showed a bloke how to rewrite the standard .buttonlist declarations to make them far easier to customise by making them less specific.

I've also managed to eliminate some unnecessary classes and markup, which makes things easier because the same classes are now used in areas that previously required specific handling. The buttons in the moderation centre reports are now just the standard quickbuttons class, meaning no extra css is required for them. They'll just look good without any effort.

This sort of thing should be done if you want a n00b-friendly result, and will actually reduce support problems. So, not everything I'm doing is a case of "F@$k teh n00bz, I is l33t!". Quite the opposite.

Here's the beginning of the index.css file. This stuff is before any of the actual code. Everything is clearly laid out.

Code Select Expand

/* Apocalypse Theme - General Presentation */
/* --------------------------------------- */
/* This file is divided into sections, searchable via your code editor */
/* Highlight the name of the section in the list below, then search */

/* @TOP Brings you back here.
/* @BASIC HTML and body tag declarations, some other basics.
/* @LINKS Specific classes and ID's for links (up/down/skipnav, etc).
/* @FORMS Form elements - textareas, inputs, selects.
/* @HEADERS Generic header bars, used in many areas.
/* @GENERAL Common classes. Colours, divs, text classes, etc.

/* @BBC Everything from quotes to colour tags, for use in posts.
/* @AJAX Notification for quick edit (top of screen, says LOADING..).
/* @LISTS Standard lists of settings, etc.
/* @TABLES Generic tables for various areas.

/* @POLLS Polls, above the posts, and events (Display.template.php).
/* @POSTS Posts, personal messages, signatures, attachments, etc.
/* @QUICK Styles for the quick reply area.
/* @EDIT Editing of posts, polls or events (Post.template.php).
/* @TOPICS Split, merge, move, send, or report topics.

/* @WRAPPER The main wrapper, and stuff directly inside (header, etc).
/* @NEWS Random news lines, and recent posts box, above board index.
/* @BOARDS Board Index categories, and their boards.
/* @INFO The Info Centre, at the bottom of the main index page.
/* @MESSAGE The topic index and child boards (also unread/new replies).
/* @FOOTER Separate section for the footer content.

/* @DROPMENU The main forum menu, and the admin/profile/PM drop menus.
/* @SIDEBAR The sidebar menu for admin, etc (shares code with drop menu).
/* @LINKTREE Breadcrumbs, navigation list, whatever you want to call it.
/* @PAGES The page index links (1,2,3....etc) and next/previous links.
/* @BUTTONS The quickbuttons (quote, edit, etc) and buttonlist (others).

/* @LOGIN The log in pages.
/* @REGISTER The public registration pages.
/* @MAINTAIN The maintenance mode warning shown to guests.
/* @ERRORS Styling for error messages.

/* @PROFILE Profile sections (lotsa stuff).
/* @PM Styling specific to the Personal Messages section.
/* @STATS The statistics centre (not that anyone ever looks at it).

/* @CALENDAR Yup, it's the calendar stuff.
/* @HELP Help pop-up styling, and main help pages.
/* @SEARCH Search form and search results pages.
/* @MLIST The member list, including member list search page.

/* @MEDIA Responsive media queries, for print, tablets, phones, etc.

/* -------------------------------------------------------------------------- */


If a particular declaration has to reference two different areas of the file (for instance, specific header bar adjustments for when they are inside another class, like the info centre) this is noted in both places and a unique identifier is provided in the comment so that anyone can instantly jump to the other location to check for possible conflicts.

Code Select Expand

/* Classes catbg and titlebg are h3 or h4, except when */
/* specifically defined as th - see @TABLES for those */
.catbg, .titlebg {
overflow: hidden;
font-size: 1.357em;
line-height: 2em;
}

[Masterd]

Any news on this, Ant? I'm dying for some information.

[Antechinus]

Yeah. I took a bit of a break from it to catch up on some other things. I'll have another bash soon and finish it up.

Come to think of it, I have a confession to make. I don't really have much incentive to write responsive CSS. I can do it easily enough, but from my perspective it's just rather boring and irritating. Not at all exciting. I never browse on a phone myself and dislike working in postage stamp size windows. This means the responsive side of it will probably be fairly limited.

[live627]

I never browse on a phone myself

That makes two of us.

[Chalky]

I love it Ant!  Truly dark, truly beautiful.  I can't wait to get my hands on it 

[Masterd]

Any updates, Ant?

[Antechinus]

Yup. Been busy with other things. Will probably be just as busy for the rest of the month.

[Antechinus]

K, I should probably bundle this thing up at the weekend, so people can start kicking it around and seeing what falls off. That might get me motivated to finish up the really boring bitz (RTL, responsive, support for bloody IE stupidity, if I can be bothered with that, and whatever else).

At this stage I wouldn't be handing it out to all and sundry, because TBH it's not at a stage where I want to deal with lots of n00b questions. No offence to n00bs, since we were all n00bs once, but I'll deal with you guys later.

[ARG01]

Is it really necessary to worry about earlier versions of IE these days? I no longer give earlier IE a second thought.

[JBlaze]

Very nice theme. It reminds me of DzinerStudio's DarkBreak Theme.