[WIP/Public beta] Apocalypse theme

[Dragooon]

There is still more work to do, and it will probably be several weeks before the theme is up to a standard I would regard as ready for general release. This to-do stuff includes things like general code cleanup, finalising responsive CSS and RTL CSS, and deciding on the total range of features and variants.

I WANT TO SEE!

[Antechinus]

I'm only planning on doing responsive to usable stage, not to perfect on every obscure page stage. However, a lot of it is easy enough to sort.

I broke half of it after rewriting some of the classes and markup.   Some of the bits I had previously sorted still work. An example is the profile account settings page, which just required setting dt and dd elements to full width instead of floated, with a few tweaks to paddings, etc to make the spacings good for fingers. Still needs a bit of a clean up. This was just an early bash at it.

[DasVON]

Awesome Theme ... as always 

[live627]

dt and dd elements

What is the reason for using those semantically incorrect elements within forms?

[Dragooon]

dt and dd elements

What is the reason for using those semantically incorrect elements within forms?

They are definition lists, technically not semantically incorrect since a list can be of form inputs.

[live627]

Oh, I didn't know they could be used on forms. When  I first saw them in SMF eons ago in 2.0 C2, I thought they were replacements for tables to satisfy CSS purists.

[Antechinus]

Something I said about semantics the other day, in a PM.

Re the semantics: I thought of each category as a list of boards (with all the stuff each board entails). It may not be perfect semantics, but so much bollocks gets talked about semantics, and so much time wasted on it, that my 2c is if you can make some sort of reasonable argument for your choice it's probably about as good as anyone else's.

Another way of looking at it would be a definition list, with the dt as the category header and the dd's for the boards. I wouldn't argue if someone wanted to use that.

[Dragooon]

Boards is a list so you're right about that, it's not a tabular form of data as some people suggested in the past. Not sure if it fits definition lists but I guess you can make an argument for that.

[Antechinus]

The way I look at it, there are only two sorts of people who care about semantics. One is code junkies, who will argue about the finer points ad infinitum. The other is people who are not code junkies, and who just want to use the software, but happen to not be able to see and therefore need to rely on a screen reader.

IMO, the only group that really counts is the latter. They're who we do semantics for. As long as the result is a page that is easy for them to navigate, the job is done to a suitable level.

Sighted users, who aren't code junkies, don't give a rat's how you mark up a page. Makes absolutely no difference to them. Them just want it to work and to look pretty.

[Dragooon]

The reason I go for semantics is because it is almost always better and easier to write the templates once you have a definite structure for different kinds of elements. That's also the primary reason I choose to go with CSS frameworks like Bootstrap because I really suck at defining such structure .

[Antechinus]

Well yeah, but you're a code junkie. I am too, but I realise the semantics side of it has always been highly subjective. What matters is to get a decent result, and there is often more than one way of doing it. So, I probably can't be bothered telling someone they're doing it wrong if they have some sort of reasonable argument for their choice, and if the resulting page is navigable by users who already find navigation more difficult than we do.

Bootstrap? Never looked at it. I've only coded SMF stuff and some fairly simple sites, so have always just written my own CSS. Problem with frameworks is bloat. I'd rather just have the code I need, which isn't that hard to do for stuff like this.

[Antechinus]

BTW, I now have the footer columns running with proper admin inputs, PHP conditionals, and language strings. Works just fine.

ETA: Ditto for the social media icons. They also have custom language strings to do the title attribute on the link. This is just for better a11y, since the icons themselves are a sprited background image, and therefore useless for screen readers.

[Neekiinh0]

Excelent theme!

[Antechinus]

This thing has got me thinking about mods, for nice finishing touches. I've just written and submitted a mod to add the "proper" working links for the admin/profile/PM top level tabs on the drop menu system. This is just a straight back port of the Sources code we threw into 2.1.

Yes, I know you can do this straight in the theme but that relies on having a theme which offers this functionality. The mod can work with any theme, because the only template edit specifically targets href="#" in two places in GenericMenu.template.php, and that href is going to be the same even in heavily modified templates, like the one I currently have for this theme (yup, have tested it on Apocalypse and default).

That got me thinking of one of my other favourite things: next page and previous page buttons on the page index. There is a mod for this already, but I'm not keen on the implementation, because all it does is tack on "Next" and "Prev" each end of the pages lists. Again, I'm basically going to backport early 2.1 code (with a couple of minor tweaks) which will add markup/classes, and therefore comprehensive styling hooks, for every element in the pages lists. This mod will probably baffle most people, because by default it wont appear to do much. However, it will allow themers almost unlimited styling options. That means the CSS can be built into custom themes for very little extra effort, and as soon as the mod is installed the pages lists will look really spiffy.

[Antechinus]

Came up with another trick, regarding the old SMF javascript that calls stuff from the themes and mods sites.

This javascript is frankly horrible. The "theme of the moment" or "package of the moment" is often something way out of date, randomly dredged from the depths of the archives. Also, even for the latest themes and packages, which may be wanted, the way it works is still gruesome. If you open a link to read the summary, then close it, you jump to the bottom of the page. This is annoying.

Then there's the wait for the javascript to load from smf.org if you happen to have a slow connection that day, and you just want to get on with some administrating. All in all, it's  PITA and more trouble than it's worth.

There was an old grumbling thread about this back here, so since I'm so far up the spout with this monster anyway I decided to implement the required changes (this theme required a custom Themes.template.php anyway so...). The old javascript is now replaced with a simple and descriptive link, that goes straight to the Mod Site or Theme Site and calls up the list of the latest submissions.

Pix attached.

[shadow82x]

Oh man...this is going to be a great theme. Can't wait to see it in action.

[Antechinus]

Figured out a couple of tricks while doing this thing. Getting inputs and selects to line up in forms is a bit of a nuisance, as different browsers treat them differently (yay for effing web standards!).

After messing around a bit, I came up with a simple way of getting pixel perfect results in Webkit, Gecko and Trident running on a Windows box. Haven't tried it on Mac or Linux, but it will probably still work. The basics are this (no eye candy, just the minimum):

Code Select Expand

/* This is necessary as a separate declaration */
input, button, select, textarea {
font: 87.5%/150% "Segoe UI", Helvetica, "Liberation Sans", "Nimbus Sans L", Arial, sans-serif;
}
/* Cross-browser declarations for inputs, selects and buttons */
input, .input_text, button, select, select>option {
padding: 0 4px;
min-height: 1.8em;
max-height: 1.8em;
-moz-box-sizing: border-box;
box-sizing: border-box;
font-size: 1em;
vertical-align: bottom;
}

The way it works is this:

1/ Even though the body text sizing will be declared on the body tag, it still needs another declaration for form elements even if you are using the same size. I put it separate to the declaration for inputs and selects because I don't want to apply all the following stuff to textareas, and it saves having to declare font for textareas later. 

2/ You don't use any vertical padding. Horizontal padding can be anything you like, but the text tends to sort itself out better if vertical is 0.

3/ The max and min heights are set to something handy (doesn't matter too much, but should be in em rather than px, so IE can resize it to match the font size).

4/ You need to declare box-sizing as border-box for all elements and for all browsers, otherwise different browsers do different things with the various bits and it's a pig's breakfast.

5/ Needs the font-size declaration again too, set to 1em. If you don't have it, Webkit and Trident will do stupid things. Don't ask me why. Browsers are weird.

6/ You have to set vertical-align to top or bottom. This keeps them all lined up, even if you change font size in the browser settings. Using baseline or middle doesn't work, and I find bottom generally works better than top.

The only catch with having to set vertical-align to top or bottom is when you have a text label leading into the input, like with the message index template jump-to. The trick with sorting that is to set position: relative; on the form (or other container), and on the label, then set top to around 0.3em on the label. Example:

Code Select Expand

#message_index_jump_to {
position: relative;
}
#message_index_jump_to label {
position: relative;
top: 0.3em;
}

Pix attached. Starting from the top they show the perennial village idiot, IE, followed by that other idiot, Safari on Windows, then Chrome, then FF/Pale Moon at standard browser setting, then again with font scaled to 200%.

ETA: Oh and while I think of it, on dark themes like this one the selects, as well as radio buttons and checkboxes, tend to be eye-burningly bright against the dark background. What I've taken to doing is setting them to 0.7 opacity, changing to 1 on focus or hover. This works very well, IMO.

[Bloc]

The CSS works pretty good, thanks I have added it to UrbanLife too, and it behaves nicely it seems.

About the label problem..that could work, have to try. Right now I just applied same rule to labels, and made them display:block; to make them behave. Line-height was also needed. So far so good..but I bet there are spots where this breaks lol.


About the js for "theme of the moment: agreed, its not working effective at all. Why it was done this way have always puzzled me..maybe a way to show off js skills hehe. In any case: if its to be improved I would rather suggest it was used with a RSS feed instead, just a regular feed fetching routine with PHP(which doesn't delay everything like js does), and def. cached. Maybe even just forced update..so you had to press "update" to see the latest. If the date is logged when it was last fetched, one could simply add something like "there have 4 days since you last updated Theme of the moment - its bound to be new ones! Would you like to update now?"..you get the drift: not holding anything up and also entice admins a little when they DO want to check it out.

Another bonus of making it a RSS feed is that other systems/sites could also be fetching it. I did at one time a web crawler that took the actual theme site pages and grabbed the relevant info..but its not the best way to grab the items. I want to do something about this in UrbanLife theme too, and I want to show off SMF site themes..but a crawler is most likely the ONLY way at this time. Still, with forcing update rather than auto-update it could work.(and a bit of cache time of course)

[Antechinus]

Yeah I tried setting labels to inline-block with the same height and line height as the selects, but they still went funny when the label was right next to the select. The relative positioning trick sorts them out pretty well.

And yes it would be good to entice admins to check out mods and themes, but for this exercise I just went with the basic links. It could still be spiced up a bit. Allcaps and a marquee would be classy touches.

Anyway I went ahead and threw in a tableless message index, since that will be far more responsive than the old table. It uses the same basic markup and CSS as the board index, with a few different class names and some extra tweaks for the different purpose. Still thinking of styling it up some more, but will let it percolate for a bit.

I'm getting rid of the 5,973 stupid old "participation icons", and just having the one to indicate topics you have already posted in. None of that daft "oh hai we haz my hot and sticky poll gif".

And if I ever meet the person who thought it was a good idea to generate << topic pages >> markup in the depths of Sources, I'll kick them in the nuts. Anyone who thinks markup should be generated in Sources should not be allowed near a code editor.

I may have a crack at rewriting that to generate stuff in the template where it belongs. Should be possible to call the same basics from the db and go from there.

[Bloc]

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).

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.