General theme stuff (markup n shiz)

General theme stuff (markup n shiz) Started by Antechinus · December 05, 2012, 05:58:23 pm · Read 12971 times 0 Members and 1 Guest are viewing this topic. previous topic - next topic

General theme stuff (markup n shiz)

December 05, 2012, 05:58:23 pm

K, since we presumably aren't quite so worried about backwards compatability with SMF 2.0.x themes now, I suggest we should do the job properly.

Note that this is not necessarily going to be fatal for backwards compat anyway, because a lot of custom themers are lazy and just append their custom css to the end of a copy of the default index.css. Anyone who does that might have to add a few more classes to their custom stuff, but that's not a huge deal.

I seriously think we should go for tableless markup for the board index, message index, unread posts and new replies pages. The presentation of the data in those areas is not tabular, so having them marked up as tables is a misuse of the tags. Doing them tableless is better for semantics, as well as offering better flexibilty for small screens and general customisation. If done properly it should also be a little better for people on screen readers.

I can rewrite those pages as lists very easily. Cross-browser stability and RTL support are no problem. Markup can be very simple, and the majority of the CSS can be shared by all of those pages.

I'd also do Display.template.php as a list instead of a stack of divs. It is, after all, a list of posts.

Note that I would not use an ordered list for these pages (I vaguely remember this being suggested somewhere). Although they are ordered in a sense, IMO it wouldn't work in terms of tags. The problem is how they are ordered. You have the OP on the first page of a thread, but it's then followed by Reply #1. That's the second element if you use an ordered list. Then if you have say 25 posts per page, the first item on Page 2 will be Reply #25, but it will be the first item in the ordered list for that page.

IOW, it only makes sense to use an ordered list if you only consider the order of items on each page, and completely disregard the order of items within the topic as a whole. This bugs me and I don't think it's the way to go. I'd use ul for the lot.

Re: General theme stuff (markup n shiz)

Reply #1 – December 05, 2012, 07:02:45 pm

Agreed on using unordered list - but will it be able to embrace other tags then? Strike that, just checked , it can.

There is really not a lot of places a table tag is appropriate, but things like stats might use it in a better way. Sorting tables for example, is a underused feature that could explored when you really use tabular data the way its meant to be: as a spreadsheet..

Index.css is still one heck of stylesheet though. If you are planning a minimizing feature for it, it might be worthwile chopping that up into at least one "SMF" css with all the classes SMF needs + one for all the specific default theme things, and finally: one themers most likely will use. All of them combined of course at compression time. It will only be themers and admins that use this feature, so it could safely take its time by being started manually - doing it dynamically I have no love for, that would be wasting server cycles.

Re: General theme stuff (markup n shiz)

Reply #2 – December 05, 2012, 07:11:18 pm

Well I have been thinking about the size of index.css since I started playing with my 1.1.x theme the other day. That theme has had a pretty comprehensive re-write of ten templates to semantic markup, and it still only has around half the number of lines of CSS that 2.0.x default has.

IOW, I think we should consider putting the css on a serious diet. I'm not sure that realistically we will be be to make the index.css much smaller than 2.0.x default by the time we include everything, but I'm pretty sure it doesn't need to be larger if it's done right. I'd like to haul it back to around 3,500 lines without splitting it. If we can get it smaller than that, even better.

Re: General theme stuff (markup n shiz)

Reply #3 – December 07, 2012, 04:19:51 am

Agreed, and I actually starting the same "diet" for my own fork of SMF 2.0..I can't really say much right now since I just started, but I know from past experience that a a lot of id targeting will make it a lot bigger. So I think part of the solution is to either mash togehter lots of id's that share same style - or use a lot more classes.Which implies changing templates too.(which I am doing anyway, but it is a major job no doubt)

When you think of it, many sections share the same look, its just minor details that separate. Also, using some sort of grid styles can help with the layout targeting.(this I nagged about before lmao : ) so you need less id's to place items. Heck, even something like 960grid can help.

Re: General theme stuff (markup n shiz)

Reply #4 – December 07, 2012, 06:48:31 am

Well, I've been thinking of using a lot of id's purely as styling hooks that custom themers can use if they want to, but not relying on them for the default theme. I think that's the best way to build in flexibility without bloating the default css.

Also, I do not like presentational classes. They're generally considered to be bad practice these days anyway, so I'd strongly prefer to not see crap like class="smalltext" and class="windowbg" and class="windowbg smalltext padding" and all that nonsense.

As for sections sharing the same look, I've pushed that in the theme I've been playing with and I really like the results. Not only is it simple, but it looks coherent. News fader, board index, info centre, message index, unread pages, etc all share the same basic markup and most of them use the exact same sizes and spacing. This keeps the css simple for default, and by having id's built in on parent wrappers (id="boardindex", id="messageindex", etc) you are giving a lot of scope for future alterations.

The id's complicate the markup a bit, but not very much because they're only needed at a fairly high level so there aren't many of them. The lack of presentational classes does complicate the css slightly (you may have to string a few classes in a declaration), but not much if it's done sensibly, and it saves a lot of crap in the markup. That's more important IMO.

Re: General theme stuff (markup n shiz)

Reply #5 – December 07, 2012, 12:41:37 pm

Mmh, I am not sure I see the benefit in that logic tbh. Its not going to be easy to make new themes when everything is so meticulous built up. Using css classes makes perfect sense,not the least for building layout, where the designer can focus on making a new look - not spend time figuring out what id does what and how many ids they have to change to keep their new design consistent throughout the pages.

I am all for complexity and making the best of CSS - but my goal will rather be user-friendliness. Cuz I know so well that if its hard, people ain't going to change it.

And thus it will be a poor environment for design, which is important for me. So if its going that way in Dialogo, I fear our visions will too far apart...sorry lol.

Re: General theme stuff (markup n shiz)

Reply #6 – December 07, 2012, 02:52:18 pm

There's nothing meticulous about it, and it's very easy to make new themes on a base like that. In some ways it's easier than doing it the old way, because you don't have a lot of inline classes to fight against when you want to do something different.

Having presentational classes forced into the markup is a little (not quite) like having inline css. It throws something in there that you may not want, which you may then have to override via complex declarations and cascades. You might want the classes to apply somewhere but not somewhere else, and instead of just writing your css to suit you have to struggle against the markup. That's not good. It's irritating for advanced themers, and it's almost insoluble for non-advanced ones. Getting rid of presentational classes as much as possible makes things easier, not harder.

Here: http://www.w3.org/QA/Tips/goodclassnames

QuoteOften people use class names like bluetext, or redborder. A much better way to name your classes is with the role a certain HTML element of that class has.
Good names don't change

Think about why you want something to look a certain way, and not really about how it should look. Looks can always change, but the reasons for giving something a look stay the same.

Good names
warning, important, downloadableImage and submenu are all good names. They describe what a certain element represents, and they are not likely to change. A warning will always remain a warning, no matter how much the look of the page changes.

Bad names
border4px, lighttext and prettybackground are examples of bad names. You might fatten that border to a whopping 5 pixels, or the background may look pretty old after a while, and not pretty at all. An advantage of using CSS is that you won't have to change much in order to change the looks of your website. If you have to change all light text into dark text, and thus change all classes lighttext to darktext in all your HTML pages, you're likely to miss a few.

There are stacks of other articles about this sort of thing. Another one here: http://2002-2012.mattwilcox.net/archive/entry/id/1058/

QuoteClass names should never map directly to a CSS property, or a given visual effect you want to achieve (such as floating, or a border effect, or a background colour, etc.). It’s shockingly bad as an ideology because it encourages a direct mapping between class name and display action. A class name, like an ID, should be descriptive in a semantic sense. ie., it should describe something about the content of the tag to which it applies. “float” is not describing content. It is describing an action you want to perform. That is not abstraction. It is not useful.

Another here: http://css-tricks.com/semantic-class-names/

Quote<div class="largeText"></div>

Unsemantic. This is specifying. Why should the text be larger? To stand out from other smaller text? "standOut" or "callout_text" might be better here, as in the Theoretical Redesign Future™, you may wish to choose a different style to make that text stand out that has nothing to do with the size of the text, and you won't be stuck with an awkward class name.

Note that I am totally in favour of user-friendliness, which is why I want to do things this way. I've tried fighting against markup done the other way and it is not fun, IMHO.

My take on it is that if we want to encourage interesting custom theming, we have to build a base that is flexible enough to do just about anything. If we want to keep the default theme light and non-intimidating, we have to avoid using all of that flexibility in the default theme. It should be there in the background, but not relied upon by default. If it's done right, beginners and intermediate themers should still be able to create basic variants without much trouble, while more advanced themers should be able to do what they like without too much crud holding them back.

Re: General theme stuff (markup n shiz)

Reply #7 – December 09, 2012, 10:48:34 pm

This sums up my attitude pretty well: In Defense of Descendant Selectors and ID Elements

Yes, I know OOCSS is the current big thing. It's not the only good way of doing things though, especially if you are writing a gui from scratch and have control over the process.

Re: General theme stuff (markup n shiz)

Reply #8 – December 15, 2012, 04:05:54 pm

Hey brainwave!

A bloke asked something over at Dziner and it got me thinking. First he wanted to know about shortening extremely long topic titles in the recent posts lists in the info centre. Sorted that for him (we'll be using a different structure). Then he asked about the same for the linktree, so I sorted that. Then that got me thinking about people posting horrendously long raw url's in posts. So, I sorted that and have already implemented it on the site I run. Works a treat, and is stable as font size changes in browser settings.

Examples (using SMF 2.0.x classes):

Code: [Select]

.navigate_section ul li a
{
	white-space: pre;
	display: inline-block;
	max-width: 24em;
	text-overflow: ellipsis;
	overflow: hidden;
	vertical-align: bottom;
}

[/pre]

Code: [Select]

.inner a {
   display: inline-block;
   white-space: pre;
   overflow: hidden;
   text-overflow: ellipsis;
   max-width: 24em;
   vertical-align: bottom;
}

[/pre]

To save some CSS, this sort of declaration could amalgamated into one that covered several areas. I think it's a handy little addition. It's certainly less resource-heavy than alternatives like seeking out page title and doing a replacement.