Stuff for playing with (here be mutants)

[Antechinus]

So this is the basis for a revamp of some of my old themes. Yes, I know, everyone is going bonkers about flat design and whatever these days, but some of us really don't like it all that much. The best of it is very good, like the best of any genre, but it's not the be all and end all of aesthetics IMO. I still like depth and shading and texture and whatever. YMMV.

Anyway, this is basically a front end coding playground for me at the moment. Some of these things are stuff I have already posted as "Tip and Tricks", some is stuff I wrote for 2.1, and some of it is new. The idea is to incorporate a range of tweaks to the basics of 2.0.x, to make the thing more useful these days and to encourage people to try stuff.

So this means responsive CSS and markup, at least to the stage of making the most commonly used pages pleasant enough to use on a phone. This only requires a few kilobytes of additional CSS. The default 2.0.x CSS is also a bit all over the place, and needs some cleaning up, commenting and re-ordering to make it less of a pain to edit.

Also, click activation of drop menus is useful on touchscreen. Improvements to the sidebar menu can be made by adding flyouts (to hold all the content available through the drop menus). The old huge and complex 2.0.x  images can disappear and be replaced by a combination of CSS and a few small, light images. Avatars, etc can be resized on the fly with CSS, for display in different areas and different screen resolutions. Blah blah blah.

What it should end up being is a sort of "2.0.x default theme" that is still compatible with the vast majority of mods, but offers behaviour people would like. This stuff can then be ripped off by other people, and they can play around with it to make it look how they want it to look. I'm not possessive about this stuff. People will be actively encouraged to rip it off and use it for their own nefarious purposes.

All of the changes between pix are just done with CSS tweaks to the same markup. These will be in the finished theme, either selectable by use of the 2.0.x variant system, or just appearing automatically as screen size changes.

Screenies of current progress are below. Grab your rotten tomatoes and start throwing.

[Diego Andrés]

I like it, nice work

[ARG01]

Looking good. 

[Biology Forums]

Incredible work.

[margarett]

Very nice!

I'm also not very fond of flat... And is that responsive? Cool!

(Nice avatar, btw )

[Bloc]

Looks nice so far. I like the possibility to make the columns change places, makes for nice variations. For example making last post appear left-most.

[Antechinus]

And is that responsive?

Well, at the moment bits of it are responsive, and other bits aren't. The header is, post pages are, and other tweaks have been added for parts of profile and admin. However, I just threw the new board index coding into it and tweaked that for looks, to go with the feel the whole theme is developing, so haven't yet added the media queries for the new code.

I already had basic responsive CSS for the default (table-based) board index, but it's very limited as to what you can do with that.

Looks nice so far. I like the possibility to make the columns change places, makes for nice variations. For example making last post appear left-most.

Yeah it should be fun to play with. I haven't fully explored all the possible CSS options, and of course I also have the "unorthodox" usage of the variant system to call on (like I talked about in the PM's) if I want to take it that far. Not sure how far I'll push this yet.

I had the idea of the last post over at the left as a sort of "content first" thing. Once you know your way around a site, the boards often become less important than the topics, so in some ways making the post the primary thing on the index makes sense. It sort of turns the board index into a recent posts listing first, with the board listing being secondary.

Dunno if it will ever catch on, but I thought it was worth trying.

[kat]

Purty, tiz.

[Bloc]

Recent posts on top doesn't sound bad at all - that actually gave me some inspiration.

[Antechinus]

Oh cool. Wotcha gonna do then? Move that info centre section up? That's not a bad idea, come to think of it (which I didn't). I could see it working though.

Oh and I did have an idea about menus. Currently there's a thing for moving user menu items out of the site menu. It must be totally awesome, because Farcebook and Sh!tHub do it, and everyone is raving about it, so obviously it's the best idea ever.

[/cynical old bastard who has seen many fads come and go]

Anyway, assume doing this just via theme, without mods as such. If some people want to keep a more traditional layout, with avatar etc in the header, you can still do this quite easily.

I've linked the header avatar to profile anyway, so that makes it a profile button. Could easily add a droppy off it if I wanted to (dunno if I will). So all you need is a PM button there too, which can be done with the old PM notification/count text that SMF used to have there anyway.

Then all you have to do is add a notification pop-up to the admin and moderation buttons (which could be done in the template while still calling the current menu array from Subs) and use a bit of basic CSS to hide the profile and PM buttons in the main menu (just because this is "doing it by theme" without hacking Sources).

So if you do those all those simple tricks, you effectively have separation of user menu stuff and site menu stuff, in a more traditional layout that some people may prefer.

[Antechinus]

Ok, so tried out the recent posts idea, just for fun. Not bad. Kinda makes more sense there than down the bottom. Screeny attached.

Has a new toggle defined, so is collapsible just like the "News" section. Just copied the old recent posts stuff from info centre, then commented out the original. Needs a wrapper div added to keep a nice margin to the category below when the recent posts are collapsed.

Basic responsive CSS is sorted for it too (just drops board name column, then date column, as screen gets narrower). Is ok down to 320 wide.

Also threw in this tweak, since it was so easy: Easy mod idea (multi language support stuff)

No screeny for that, but it's basically the same code we used in 2.1 and Elk.

[Bloc]

Oh cool. Wotcha gonna do then? Move that info centre section up? That's not a bad idea, come to think of it (which I didn't). I could see it working though.

Oh and I did have an idea about menus. Currently there's a thing for moving user menu items out of the site menu. It must be totally awesome, because Farcebook and Sh!tHub do it, and everyone is raving about it, so obviously it's the best idea ever.

[/cynical old bastard who has seen many fads come and go]

Anyway, assume doing this just via theme, without mods as such. If some people want to keep a more traditional layout, with avatar etc in the header, you can still do this quite easily.

I've linked the header avatar to profile anyway, so that makes it a profile button. Could easily add a droppy off it if I wanted to (dunno if I will). So all you need is a PM button there too, which can be done with the old PM notification/count text that SMF used to have there anyway.

Then all you have to do is add a notification pop-up to the admin and moderation buttons (which could be done in the template while still calling the current menu array from Subs) and use a bit of basic CSS to hide the profile and PM buttons in the main menu (just because this is "doing it by theme" without hacking Sources).

So if you do those all those simple tricks, you effectively have separation of user menu stuff and site menu stuff, in a more traditional layout that some people may prefer.

I was thinking like you actually..recent posts on top. The idea could be to add attachments(or at least avatars which I do UrbanLife) for a semi-blog experience. But I see your works great, it feels natural to see it there.

he-ey..profile avatar with drop under is what I use lol Its exactly what I have done in UL, putting a user menu under the avatar, a small notification blob top right corner for unread messages, and also divided the man menu some more, for better space requirements.

Another thing..I have been wrestling with something: in the news section I have I used the upshrink feature to exchange CSS classes instead of just display:none. So it works fine, the two classes use transitions on the height to achieve a nice sliding effect. But heres the thing, that only works on a set height. I can't get it to work with auto-height.U know of other ways to make the transition work? It don't have to be the height, as long as its sliding up and down.

I thought margin and overflow:hidden perhaps..but haven't tried that yet, seeing as the height scenario is perfect so far...(other than having to have a fixed height on it, which in this case isn't so bad, but still..)

[Bloc]

Ok, so tried out the recent posts idea, just for fun. Not bad. Kinda makes more sense there than down the bottom. Screeny attached.

Has a new toggle defined, so is collapsible just like the "News" section. Just copied the old recent posts stuff from info centre, then commented out the original. Needs a wrapper div added to keep a nice margin to the category below when the recent posts are collapsed.

Basic responsive CSS is sorted for it too (just drops board name column, then date column, as screen gets narrower). Is ok down to 320 wide.

Also threw in this tweak, since it was so easy: Easy mod idea (multi language support stuff)

No screeny for that, but it's basically the same code we used in 2.1 and Elk.

Yep, using a CSS buton makes very much sense - no more gif'fy problems in other languages.

[Antechinus]

Dunno about the height transitions. Haven't played with those much. IIRC the only time I tried those was on a drop menu, which of course doesn't have a set height, so not much help for you there (no, they didn't work). Nice idea though.

And wotcha mean YOU did a profile droppy off the avatar? Who put profile droppies off avatars in 2.1 and Elk then? Well, ok, actually they came off the username just above the av, but it's all li's and anchors anyway so makes no diff (TBH I haven't looked closely at UL yet).

It makes sense off the avatar up top, if trying to separate user and site menus. TBH though I'm not keen on having the log out button in said droppy. I prefer that at the end of the main menu where it has always been. Saves looking for it when I've spent too long on a forum and need to get back to work in a hurry.

[Antechinus]

Hey that just gave me another idea. Even if using the basic js toggle for the collapse biz, it'd be easy to swap something other than the display attribute. The could save the need for excess wrapper divs, since you could just set the existing content div to your nominal margin height and zero opacity.

(of course, you couldn't then just define a new SM toggle, since that aint set up for fancy business)

[Bloc]

Agree, logout belongs at the end of main menu.

Yeah, I know its used in Elk D it just coincided with..err, well, probably a mix of influences then (*whistle*)

Actually, using height between 200px and 4px, which is what I use, works fine when also using a background image(not an image, it will shrink horribly so next better be just text I guess..though its not superimportant)..and some negative margins to hide the 4px too. But it should really be x in height, not just 200...still, with an theme option on the height its not so bad. Still researching on it.

Hey that just gave me another idea. Even if using the basic js toggle for the collapse biz, it'd be easy to swap something other than the display attribute. The could save the need for excess wrapper divs, since you could just set the existing content div to your nominal margin height and zero opacity.

(of course, you couldn't then just define a new SM toggle, since that aint set up for fancy business)

Yes. I had to write a modified js bit for exchanging CSS classes.

[Antechinus]

Yeah IIRC I nicked the profile droppy idea from Xenforo, after someone raved about that feature. Thievery FTW. If an idea is worth using, it's worth stealing.

I would have thought transitions would work with auto height, but they don't. However, a quick DuckDuck* gives you a solution.

http://css3.bradshawenterprises.com/animating_height/

"This is a really common thing to want to do, and when you know the trick it's really easy! The short version is, you can't animate from 0 to auto using transitions. You have to have a height at the end. However, all is not lost...

So, how did that work? We aren't animating height, we are animating max-height. By setting that to a large value, and setting our overflow to be hidden, we can do what we need."


*/me is not using Google any more.

You might also want to read this: http://stackoverflow.com/questions/3508605/css-transition-height-0-to-height-auto

Seems it can change transition speed.

[kat]

+1 for the duckduck!

[Antechinus]

Played with it some more. I have the index.template.php markup trimmed down to the minimum it needs to give the exact Curve look on the wrapper graphics, and without requiring main_block.png. At the moment it uses CSS3 gradients instead. This got rid of one div (class="frame") up in #header, and two divs inside #content section (another .frame, plus #main_content_section). This simplifies the CSS as well as the markup, which is all good.

This new configuration will handle banners of any size without them looking stupid over the background graphics. The second, inner, gradient around the user area, etc will now just move down the header to accommodate the banner above it.

The footer now doesn't include the lower graphics for the theme wrapper. Those graphics are just handled by #wrapper and #content_section. The footer is now independent, and has its own internal wrapper which also calls the forum width setting from admin. This means that by just tweaking CSS a bit, you can now get a full width footer bar in the modern style, for whatever content you like.

Just to prove it would work with the new markup, I also adapted the code from the full-width banner tutorial I wrote today and threw that in for a trial run. This could easily be included as another variant. The actual banner image is 1893px x 441px, and scales just fine on any res. Examples are given for 1280 and 320 wide screens.

The 320 shot also shows how the recent posts respond to that width, by dropping the less important columns. And yes, I know things are slightly misaligned on the small screen. I haven't tweaked the responsive CSS to match the new markup yet.

[kat]

What a clever boy you are!

[Bloc]

Thanks for the tip about max-height. Have implemented it and it works great! That means every upshrink I use can be a nice slide instead of the immediate jump.

[Antechinus]

Cool. Didn't know about it myself until you prompted me to look. Still learning new stuff, which is good.

I might play with it myself for some things. After looking around a bit, it seems doing animation effects with CSS3 is generally faster and lighter than doing them with jQuery or similar. So, even if using some javascript for touchscreen or a11y or whatever, having the eye candy side of it handled by CSS3 looks to be the best option.

[Bloc]

I am def. onboard with exchanging some of the js animation with CSS counterparts - adding plugins to JQuery/Mootools quickly adds up. Its easier to customize too, even remove alltogether.


Yeah, its working well indeed. If you need the modified code to exchange CSS classes instead of setting display: none/block, I added it below. You use the exact same setup as for smc_Toggle..but call urb_Toggle instead. The js code you put in theme.js, and the CSS to the stylesheet.

the call then looks like:

Code Select Expand


// Create the news fader toggle.
var smfNewsFadeToggle = new urb_Toggle({
bToggleEnabled: true,
bCurrentlyCollapsed: ', empty($options['collapse_news_fader']) ? 'false' : 'true', ',
aSwappableContainers: [
\'news_container\'
],
aExtraClass: [
\'forumwidth\'
],
aSwapImages: [
{
sId: \'newsupshrink\',
srcExpanded: smf_images_url + \'/collapse.gif\',
altExpanded: ', JavaScriptEscape($txt['upshrink_description']), ',
srcCollapsed: smf_images_url + \'/expand.gif\',
altCollapsed: ', JavaScriptEscape($txt['upshrink_description']), '
}
],
oThemeOptions: {
bUseThemeSettings: ', $context['user']['is_guest'] ? 'false' : 'true', ',
sOptionName: \'collapse_news_fader\',
sSessionVar: ', JavaScriptEscape($context['session_var']), ',
sSessionId: ', JavaScriptEscape($context['session_id']), '
},
oCookieOptions: {
bUseCookie: ', $context['user']['is_guest'] ? 'true' : 'false', ',
sCookieName: \'newsupshrink\'
}
});

Notice there is a extra parameter called ExtraClass, thats where you out the extra CSS classes you want on the container, since the routine effectively just replace the class with urb_xxx, everything else there is eradicated. I could make the JS check and tack it on..but found this approach more safe.

The actual JS code:

Code Select Expand


// *** urb_Toggle class.
function urb_Toggle(oOptions)
{
this.opt = oOptions;
this.bCollapsed = false;
this.oCookie = null;
this.init();
}

urb_Toggle.prototype.init = function ()
{
// The master switch can disable this toggle fully.
if ('bToggleEnabled' in this.opt && !this.opt.bToggleEnabled)
return;

// If cookies are enabled and they were set, override the initial state.
if ('oCookieOptions' in this.opt && this.opt.oCookieOptions.bUseCookie)
{
// Initialize the cookie handler.
this.oCookie = new smc_Cookie({});

// Check if the cookie is set.
var cookieValue = this.oCookie.get(this.opt.oCookieOptions.sCookieName)
if (cookieValue != null)
this.opt.bCurrentlyCollapsed = cookieValue == '1';
}

// If the init state is set to be collapsed, collapse it.
if (this.opt.bCurrentlyCollapsed)
this.changeState(true, true);

// Initialize the images to be clickable.
if ('aSwapImages' in this.opt)
{
for (var i = 0, n = this.opt.aSwapImages.length; i < n; i++)
{
var oImage = document.getElementById(this.opt.aSwapImages[i].sId);
if (typeof(oImage) == 'object' && oImage != null)
{
// Display the image in case it was hidden.
if (oImage.style.display == 'none')
oImage.style.display = '';

oImage.instanceRef = this;
oImage.onclick = function () {
this.instanceRef.toggle();
this.blur();
}
oImage.style.cursor = 'pointer';

// Preload the collapsed image.
smc_preCacheImage(this.opt.aSwapImages[i].srcCollapsed);
}
}
}

}

// Collapse or expand the section.
urb_Toggle.prototype.changeState = function(bCollapse, bInit)
{
// Default bInit to false.
bInit = typeof(bInit) == 'undefined' ? false : true;

// Handle custom function hook before collapse.
if (!bInit && bCollapse && 'funcOnBeforeCollapse' in this.opt)
{
this.tmpMethod = this.opt.funcOnBeforeCollapse;
this.tmpMethod();
delete this.tmpMethod;
}

// Handle custom function hook before expand.
else if (!bInit && !bCollapse && 'funcOnBeforeExpand' in this.opt)
{
this.tmpMethod = this.opt.funcOnBeforeExpand;
this.tmpMethod();
delete this.tmpMethod;
}

// Loop through all the images that need to be toggled.
if ('aSwapImages' in this.opt)
{
for (var i = 0, n = this.opt.aSwapImages.length; i < n; i++)
{
var oImage = document.getElementById(this.opt.aSwapImages[i].sId);
if (typeof(oImage) == 'object' && oImage != null)
{
// Only (re)load the image if it's changed.
var sTargetSource = bCollapse ? this.opt.aSwapImages[i].srcCollapsed : this.opt.aSwapImages[i].srcExpanded;
if (oImage.src != sTargetSource)
oImage.src = sTargetSource;

oImage.alt = oImage.title = bCollapse ? this.opt.aSwapImages[i].altCollapsed : this.opt.aSwapImages[i].altExpanded;
}
}
}

if ('aSwappableContainers' in this.opt)
{
// Now go through all the sections to be collapsed.
for (var i = 0, n = this.opt.aSwappableContainers.length; i < n; i++)
{
if (this.opt.aSwappableContainers[i] == null)
continue;

var oContainer = document.getElementById(this.opt.aSwappableContainers[i]);
if (typeof(oContainer) == 'object' && oContainer != null)
oContainer.className = bCollapse ? 'urb_hide' : 'urb_show';

if (this.opt.aExtraClass != null)
oContainer.className +=  ' ' + this.opt.aExtraClass;
}
}

// Update the new state.
this.bCollapsed = bCollapse;

// Update the cookie, if desired.
if ('oCookieOptions' in this.opt && this.opt.oCookieOptions.bUseCookie)
this.oCookie.set(this.opt.oCookieOptions.sCookieName, this.bCollapsed ? '1' : '0');

if ('oThemeOptions' in this.opt && this.opt.oThemeOptions.bUseThemeSettings)
smf_setThemeOption(this.opt.oThemeOptions.sOptionName, this.bCollapsed ? '1' : '0', 'sThemeId' in this.opt.oThemeOptions ? this.opt.oThemeOptions.sThemeId : null, this.opt.oThemeOptions.sSessionId, this.opt.oThemeOptions.sSessionVar, 'sAdditionalVars' in this.opt.oThemeOptions ? this.opt.oThemeOptions.sAdditionalVars : null);
}

urb_Toggle.prototype.toggle = function()
{
// Change the state by reversing the current state.
this.changeState(!this.bCollapsed);
}


..and the CSS:

Code Select Expand


/* CSS collapsing  */
.urb_show, .urb_hide {
max-height: 200px;
-webkit-transition: all 400ms ease;
-moz-transition: all 400ms ease;
-ms-transition: all 400ms ease;
-o-transition: all 400ms ease;
transition: all 400ms ease;
overflow: hidden;
}
.urb_hide { max-height: 0px; }



[Antechinus]

Thanks for that.

Speaking of js and a11y (which I was ) after playing around with the CSS I got a really good no-js fallback for keyboard/tab activation of the drop menus. Looks exactly like normal hover activation, except that the drop menu's ul wrapper extends off the left side of the screen. Link styling and positioning isn't affected, and it all works normally when js is switched back on, or when using hover activation of the drops. It's currently set up with Superfish but should be adaptable for any js menu.

The trick is to get the positioning right on focus, without borking things on hover. I tried just using a z-index shift to keep lateral positioning constant, but that introduced other problems and didn't work well. So, I had to stick with using left positioning to hide the ul off hover, and a left margin on the anchor when focused (with js off). That then needed an extra declaration to cancel the left margin on the anchor when hovering over the li and the anchor was focused (otherwise anchor disappears off the right side of the screen when you click the link). Also, you need to declare left positioning and margins in pixels, not em, otherwise it will play havoc with your positioning (and your brain) if you are using different font sizes in different menu levels.

You can do this without having the ul wrapper visible at all (forgotten how I did that before) but I found the disembodied links appearing out of nowhere looked more disconcerting than the ul extending off the left of the screen. I think the latter is a better solution for all round user-friendliness.

Anyway CSS looks like this. I've used basically the same classes as I used for Elk's menu system, since they are clearly descriptive for people unfamiliar with drop menu coding.

Code Select Expand

/* Coding for the drop menus (main, admin, etc) */
/* -------------------------------------------- */
.dropmenu {
margin: 0;
padding: 0 6px;
}
#adm_submenus {
padding: 6px;
}
.dropmenu:after {
display: block;
clear: both;
content: "";
}

/* List element <li> declarations */
.listlevel1, .listlevel2, .listlevel3 {
position: relative;
list-style: none;
}
.listlevel1 {
margin: 0 2px 0 0;
padding: 0 0 4px 0;
float: left;
}

/* Visible link declarations */
.linklevel1, .linklevel2, .linklevel3 {
display: block;
padding: 0 10px;
font-size: 0.857em;
line-height: 2em;
}
.linklevel1 {
border: 1px solid transparent;
}
.linklevel2, .linklevel3 {
width: 17em;
line-height: 2em;
}
.linklevel2.subsections:after {
position: absolute;
right: 5px;
content: ">"
}

/* The drop menu backgrounds */
.menulevel2, .menulevel3 {
z-index: 99;
position: absolute;
top: 100%;
left: -3002px;
padding: 6px 0;
background: #000 url(../images/theme/menu_gfx.png) 0 -220px repeat-x;
border: solid 1px #4F4131;
border-radius: 4px;
box-shadow: 2px 3px 5px 1px #000;
}
#admin_menu .menulevel3 {
margin: -2em 0 0 15em;
}

/* The active button */
.active {
font-weight: bold;
}
.linklevel1.active,
/* The hover effects */
.linklevel1:hover, .linklevel1:focus, .listlevel1:hover>.linklevel1 {
background: #222;
color: #cfc2a8;
text-decoration: none;
border: 1px solid #333;
border-radius: 4px;
}
.linklevel1.active:hover, .linklevel1.active:focus {
background: #333;
color: #ffefcf;
border: 1px solid #645441;
}

/* The hover effects on level 2 and 3 */
.linklevel2:hover, .listlevel2:hover>.linklevel2, .linklevel3:hover {
background: #222 url(../images/theme/main_block.png) no-repeat -20px -280px;
color: #cfc2a8;
text-decoration: none;
}
.listlevel1:hover .menulevel2, .listlevel1.sfhover .menulevel2,
.listlevel2:hover .menulevel3, .listlevel2.sfhover .menulevel3 {
left: -2px;
}

/* The focus effects on level 2 and 3 */
.linklevel2:focus, .linklevel3:focus {
margin: 0 0 0 3000px;
background: #222 url(../images/theme/main_block.png) no-repeat -20px -280px;
color: #cfc2a8;
text-decoration: none;
}
.linklevel3:focus {
margin: 0 0 0 6000px;
}
.listlevel2:hover>.linklevel2:focus, .listlevel2.sfhover>.linklevel2:focus,
.listlevel3:hover>.linklevel3:focus, .listlevel3.sfhover>.linklevel3:focus {
margin: 0;
}

The important bits for the no-js keyboard stuff are the last three declarations. Screenies below.

ETA: Oh and the sidebar menu flyouts use the same general positioning as the drop menus, so this also works with the "advanced sidebar", without requiring any extra declarations for that.

[Antechinus]

Ok, so got sick of js for menus, since I have decent keyboard a11y without it. Tried that animating max-height trick. There's a catch with it: since it relies on overflow: hidden; it borks three level menus (the third level gets clipped at the boundary of the second level). Transitions don't work on the overflow property either.

I tried out various daft ideas, but it looks like there's no way around it without borking the keyboard a11y. So, that effectively rules out eye candy animations for three level menus with pure CSS3. To get eye candy animations and good keyboard a11y, you'll still need javascript. Two level menus are no problem though.

[Bloc]

Yes, I realized this too, when working with it. I think the menus can be semi-animated though, by using transitions on the opacity combined with some slight side-positioning on 3-level menus. This is a CSS trick on dropdowns I've used before, after finding it on the net.

I like the approach of using :link and :target, in fact I already use that, I found a project for having a CSS driven lightbox. You know, getting full-size attachments shown instantly. I think it works great there, although the images have to be loaded on pageload - but hidden in CSS. Still, by the time someone press it, it should have downloaded so the experience is immediate anyway.

The flyout menu is great! I want to use that too, on touch-device-only, instead of trying to squeeze in all the items there. Simplification is the key to a good mobile experience IMHO.

[Antechinus]

No can do opacity trix when wanting good keyboard a11y. It gets fiendishly complicated. If you hide the ul background by using opacity, you then have no way of getting visibility back on the ul content, because you can't track back up the tree when you get focus on one of the anchors. No can see nuffin forever.

Ok, so say you get cunning and declare everything as RGBA. You can then ensure you have visible links on focus, by changing the alpha value on the anchor colour and background, but you also have to take care of hover, so that means more alpha transitions there too. Also, when someone is using keyboard access they want things instantly, not with whoopsy Venetian blinds, so any transition on focus will conflict with your hover transition. Also, what happens off hover or off focus? Linkys disappear again. Yay!

There is probably a workaround if you try hard enough, and if your CSS doesn't preclude it by nature (ie: no images) but it'll only be a straight fade in. Can't do roll-ups.

[Bloc]

Heh, after re-reading your post about z-index trouble I realized I had a simialr problem using dropdowns on topics - when hovering over the avatar(really a menu item a bit below though) the menu actually would overlap the next post - if it was short enough. Of course i could make the dropdown have its item horizontal, but wanted that vertical look. 

I had to do some PHP things there - by adding inline z-index to each menu, and that each had exactly 1 more than the former... I know, its hack'ish as hell lol, but it works as long as no-one use 70-80++ posts per topic page..and who does that?  

No can do opacity trix when wanting good keyboard a11y. It gets fiendishly complicated. If you hide the ul background by using opacity, you then have no way of getting visibility back on the ul content, because you can't track back up the tree when you get focus on one of the anchors. No can see nuffin forever.

Ok, so say you get cunning and declare everything as RGBA. You can then ensure you have visible links on focus, by changing the alpha value on the anchor colour and background, but you also have to take care of hover, so that means more alpha transitions there too. Also, when someone is using keyboard access they want things instantly, not with whoopsy Venetian blinds, so any transition on focus will conflict with your hover transition. Also, what happens off hover or off focus? Linkys disappear again. Yay!

There is probably a workaround if you try hard enough, and if your CSS doesn't preclude it by nature (ie: no images) but it'll only be a straight fade in. Can't do roll-ups.

So using visibility: hidden is a no-no for a11y?
Thats what I am using though, from visibility: hidden and opacity:0 -> visibility: visible and opacity: 1 upon hovering. That gives a nice fade effect.

[Bloc]

Sorry, a little unclear on the z-index..what I meant was that I have a z-index on the avatars already(it has a online/offline icon tucked partly under it lol) - and the dropdown was inside that whole container, so it would NOT go over the next avatar. Which led to the z-index trouble.

[Antechinus]

Oh I can handle z-index easily enough. That's not the problem (although it can be a little tricky at times).

Actually, there is one way you could get away with opacity tricks: by not having any visible background on the ul or li, and having all visuals in the droppy handled by the anchors. That could work, because then you could animate opacity directly on the anchors.

Other than that, no. Visibility and opacity affect the parent and all children, as I'm sure you know. This is no worries if using hover activation because you can haul up the ul opacity via css by targeting downwards from the parent li, but it totally screws you if someone is using the keyboard (Tab key) to access the links, because you can only select down from the anchor, not back up the other way. This means no can see nuffin forever (I believe I did mention that ).

[Bloc]

Yeah, you did. A little slow here haha.

Ok, so I need to correct this in some way. Need to read more about keyboard access and a11y in general I guess.

[Antechinus]

Yeah I've given menus a bit of thought. Doesn't much matter for the average custom theme, as long as the site offers alternative themes, but I was going over things for default coding. Having figured some of it out (meaning figured some out and read other people's stuff too) I'm sorta reluctant to go back to less functional menus.

What I really want a menu to do is:

1/ display: none all submenu links by default - this means anyone using keyboard access (or a screen reader) can just skip along the top level links, without having to tab through every link in the system. Bear in mind that some people have to tab through things by very awkward methods.

2/ Obviously, they also have to be able to open any submenu by hitting "Enter", after which they can tab through the submenu.

3/ Also has to work via mouse. That can be either a/hover or b/click activation of the submenus.

4/ If using hover activation, really should have a mouseout delay of 500-700 ms for people who need it.

You can get 2, 3/a and 4 with just CSS, but you can't get 1. 1 needs js.

Then there's one of my pet hates when dealing with multi level hover menus in areas like admin. Sooner or later you will accidentally open two or more of the wrong menus (just because you weren't paying attention to exactly where your cursor was) which means you then have a clusterf@ck, and have to wait until the mouseout delay expires before it will clear itself up.

No good saying you can just cut the mouseout delay to some insignificant value, because that will make the system almost unusable for a surprising number of people. It has to stay in the 500-700 ms range.

The only way you can close such a clusterf@ck quickly is if you have javascript, with click-anywhere-to-close functionality. So put that together with 1/ from the first list, and you're getting a good argument for some use of js, IMO. Also, because of said clusterf@cks, I have come to prefer click activation of submenus. They always open exactly when I want them to, and never when I don't want them to. Mouseout delay is effectively infinite too, making them easy to use for anyone with bad tracking skills.

Then there's the famous "mobile first" mindset us enlightened beings are supposed to have these days. That means at least half of your target audience will be on some sort of touchscreen anyway, so hover activation makes no sense for them either.

Put that lot together and I think that if only providing one menu system, it should use some javascript and it should use click activation of submenus. I've tried using pure CSS menus umpteen different ways, but it always falls short in one way or another, and I can't see any way around that.

[Bloc]

I see your point, but it just feels wrong to impair the users that do have normal needs and use hover menus without problems...I feel I need to work towards catering for both/all, else it won't matter. The equivalent of mobile-first I guess, where mobile-first often means just use the same for desktop users too. True, a lot of people need help..and touch devices really come into play all on its own..but theres still a great portion that do not. Or use both. I know I need the pages to easily scale without looking funny lol, and maybe my hands will shake soon too..but right now I don't. How to adress all scenarios is important.

So I am very reluctant to impose a click-to-drop on whats IMO is a better experience by hovering. But of course, for the same reason not offering ONLY that either.  I have no definitive answers now, and maybe JS is the only way to make sure all works correctly..but I will try to minimize the use of JS, if CSS can do the same job..

[Bloc]

You know, maybe instead of just offering a one-size-fits-all, one could easily make 2 or 3 different scenarios - th markup would not have to be different(or of it did, using PHP to separate)and let the user decide? If my hands are shaking I press the <relevant-icon-symbol-here>(preferably big enough to hit lol) and off you go. But if I don't need it, press the defautl one..or something like that.

It might be too hard to get to nirvana by only a single staircase.

[Antechinus]

Oh sure, I was saying if providing one menu, click activation with javascript makes the most sense. If you want to provide multiple options you can do that too. However, even though my tracking and reactions are still pretty good, and I can use the default 2.0.x system without significant problems, I have still come to prefer well-behaved click menus over trying to make hover menus behave properly. I actually like them better, so I don't regard them as impairing the experience of normal people at all. Quite the opposite in fact. Frankly I think the people who complain about them are just having a knee jerk reaction and haven't tried using them for long, if at all. This means I have little motivation for coding multiple menu systems.

However, if you wanted to do that, the easiest way would be to provide an option to simply switch off the js and fall back to rocket fast and twitchy hover menus. The js menus should have full CSS fallback anyway, IMO, since I am also concerned about usability with js disabled.

[Bloc]

Thats ok, everyone is different lol. I prefer fast hovering, others prefer clicking to get to it. Having the difference though, between a needed feature and a preferred feature, could be solved by forcibly opting out when it is needed - and offering a user choice when it isn't.  I'll think I try work towards that.

[Antechinus]

Ok, well personally I've tried hover menus so many ways that I'm over them, and no longer regard them as interesting. I've evaluated them and, all things considered, bearing in mind that everything has its trade-offs, I'm of the opinion that hover drops are an inferior option. If I'm coding for my own enjoyment, I'll just code what I want to code. I'm putting so much thought into other aspects of this beast that I'm not inclined to waste time (from my perspective) in offering different menu systems for every possible preference. I'd rather just make sure that whatever I do provide works well. This beast is largely to give people ideas about CSS and markup anyway. So if there's something they don't like, they can code something dfferent.

[Bloc]

Noted. (and if you feel this particular sub-discussion is a bit off-topic, feel free to split it up.)

[Antechinus]

No need. It's all good. We're trying to get people thinking about theming stuff anyway. TBH I probably will provide a no-js option on the menu in some form, since it will have to have fallback to pure CSS for a11y, but I wont be inclined to spend a lot of time on it, and the "primary functionality" (IMO) will be the major consideration.

One thing I do like doing with CSS though, is setting a transition on the top level menu buttons. If they just have a basic hover declaration, they will flash whenever your cursor crosses over them, even if you don't want anything from the menu. I give them a very short transition, which stops them flashing when you don't want them, but is fast enough to "instantly" light up the hover styling if you are aiming the cursor at the button (basically, you have to decelerate your cursor, and in the time it takes you to do that the transition will have expired).

It's not needed on second or third levels, only on the first level. It only has to be very brief, but IMO it gives a much more polished feel. I found ease-in-out worked better than linear, because it gives just a little more time before the transition becomes visible, without increasing overall time.

Code Select Expand

.linklevel1.active,
/* The hover effects */
.linklevel1:hover, .linklevel1:focus, .listlevel1:hover>.linklevel1 {
background: #222;
color: #cfc2a8;
text-decoration: none;
border: 1px solid #333;
border-radius: 4px;
transition: 0.1s ease-in-out 0.05s;
}
.linklevel1.active:hover, .linklevel1.active:focus {
background: #333;
color: #ffefcf;
border: 1px solid #645441;
transition: 0.1s ease-in-out 0.05s;
}

[Antechinus]

Hey while we're on about menus and eye candy stuff, there are some things I've tried with the max-height transition roll-up thing (dunno if you've tried them yet).

I tried it with visible overflow on the ul, and with a similar transition on the anchor heights (set for focus and hover). That works for multi-level menus, if you're only concerned with hover activation, and assuming you have no borders, paddings or margins on your li's. The whole thing rolls out very nicely like that.

It's a bit funny with keyboard activation, because each disembodied anchor rolls down out of nowhere, which looks rather odd. Still, if you just want it for a specifically hover-activated option, it's fine.

ETA: Ha! Should have thought of this before too. Ok, say you (meaning you, not necessarily me ) want your nifty hover droppies, but you want to provide decent a11y for people with poor tracking skillz (like us old sods in a couple more decades ) so you're going to give said people a nice, long mouseout delay.

This is going to be very annoying at times (ergo my earlier comments about clusterf@cks). So, all you have to do is include a very small js routine to allow instant closing of the submenus if you click outside them.

This is now not a "pure CSS menu", but TBH purist approaches are somewhat like religious fundamentalism, which isn't really my cup of tea. Javascript was invented to control behaviour, and if sanely employed is very good for that purpose. So, we should use it.

[Antechinus]

Been playing with it some more (not the drop menus, other stuff). If this separation of user stuff and site stuff is the go, which seems to make a certain amount of sense, then I reckon something like this is pretty good for layout.

Obviously the "Personal messages" text is linked to PM's. The new PM's notification is wrapped in the same link. Avatar is already linked to profile, so no need for the old "My Messages" and "Profile" buttons in the main menu (I've just hidden those with CSS for now).

Since the moderation notifications and maintenance mode warning are really "site stuff" I figured give them their own buttons, styled like the menu buttons, and shove them down where site stuff belongs. Moderation reports are still linked to the usual pages. Maintenance mode warning is now linked to admin server settings page for convenience.

Oh and funnily enough, the Tips and Tricks stuff I did for full-width banners still mostly works if you disable the banner (forum name just needed a slight left padding tweak). Having the SMF logo and upshrink absolute positioned is fine with or without a full-width banner, which is kinda handy.

[Bloc]

It does look more collected this way, more consistent with styling of the links. There are a lot of ways one can improve those links.

One thing that really puzzled me with SMF 2.0 is why the top links for admin dropmenu never was properly linked? I guess it was something to do with keeping sections "pure"..but IMHO it would be so easy to just assign whatever subsection comes first in that link. Sure, it will double up that link..but the upside is that keyboard access will at least go to the correct section. (which is what I aim for now atm, since subsections links are present on any main section's page.) And not stop dead since the top menu links are not actually linked. I did that for my theme now by a simple PHP code to get that first subsection:

Code Select Expand


$firstlink = array_shift(array_keys($section['areas']));


It might been fixed in SMF 2.1, not checked.

[Antechinus]

Yeah a lot of people grumbled about the dead top level links. Sinan actually wrote a mod for it. That's something else I'll be throwing in GenericMenu.

ETA: Just had a look, and can't find the mod, so maybe he just gave me the code when I grumbled about it.

[Antechinus]

Hey I found an old topic about it, which IIRC is the code we ended up throwing into 2.1 (Mantis seems to think so too).

http://www.simplemachines.org/community/index.php?topic=439046.msg3094573#msg3094573

[Bloc]

Yes, good to have in Sources no doubt ..but I'm making it work in a theme for  SMF2.0


Another thing: I know I have been ranting about themeing in SMF 2.0 for a long time..but its just so much thats should change IMO...so much it seems easier to just throw it out and rewrite everything, which I have done a few times(well, started on) and currently is doing. Sure, it takes more time but its also rewarding in the sense you do have control over the little irritating things currently in SMF 2.0. And yes, I do know you added a lot of that code, Antech I am not blaming anyone, its my personal opinion and I can't expect anyone to follow it blindly..but its absolutely necessary for me to get anywhere with what I like to create.

So I am glad we can meet halfways haha, exchange knowledge and perhaps spur other themers(and admins for that matter) to try new things. Doesn't have to be very big things, just...different stuff.


This topic led me to create another, more "normal" theme concept(or subtheme as it were), which does have recent posts on top and will *perhaps* have clickable menus instead of hover. I made it such, like you did, by adding a visible "button" next to the menu item, to signal that THIS is clickable menu, not just a hover one. At least thats the idea.. I'll post in another topic about this when its more fleshed out. So you see, its already useful
 

[Antechinus]

Yup, but it is legal to make themes dependent on a mod, as long as you warn people on the downloads page (theme guidelines say so, I checked ) but yeah I get where you're coming from. TBH I would very much like to make mine demand that mod I made for an updated browser array, just as one example.

And I totally agree that 2.0.x markup and CSS is horrible. Even some of the bits I did are horrible. I love ripping it to pieces and throwing heaps out too. 1.1.x was even worse (some weird bloke must have written code for that one).

And after figuring out how to clear up unwanted hover menus instantly (which I really should have thought of before) I reckon I could probably live with them now. They do still need some js though. Pure CSS still wont quite cut it, IMO (and apart from anything else, is useless for IE < 10 since they wont do transitions at all).

But yeah, it's fun kicking ideas around. I just had a rather good one myself, which I'll also have to flesh out some more before it gets shown here. That will happen after I get the current thing sorted.

[Antechinus]

Hey here's a funny story for you. I was working on that updated "2.0.x default" markup and CSS and, as you do when playing with CSS, decided to "try a thing or two just for fun". You can probably see where this is heading already.

So, as you do, I started out by commenting out the "default" CSS in a few places and adding the trial stuff. Some of it was useful for default tips and tricks (for instance, turning the old site slogan into part of a full-width linked banner using absolute positioning) but it sort of, umm, evolved. More like mutated. Like one of them things you see creeping out of laboratories in bad movies. Commented code and rough additions everywhere. At the moment the CSS is sorta like Zen Garden meets Zombie Apocalypse.

End result is that I have a totally awesome* new theme roughed out, but unfortunately it was my one working copy of the "let's stick with default", so I now have to make another copy and reverse engineer "default" back out of it.

(It wont be too bad, and it has given me a different perspective on the "default" markup, which is useful).


*Well, I think so anyway. YMMV.

[Bloc]

Pictures please

[Antechinus]

ROFL. It's still WIP. Working on it now over Sunday morning coffee. Just give me a while to sort out some of the detailing.

[Antechinus]

Ok, have managed to get some more done to it. Still needs more detailing, of course, but the concept is viable, coding is functional, and it's generally coming together really nicely. Will post comprehensive preview shots tomorrow night my time (roughly 30-36 hours from now).

Mini preview of the banner:



No prizes for guessing the name of the thing.

ETA: Oh and it turns out I was smart enough to save a copy of the "default" PoD before I went crazy with CSS, so that's good too. Means I can still get the basic Curve and Co back very easily. No reverse engineering required.

* Antechinus breathes sigh of relief. Backups FTW.