The future of SMF themes - free or paid?

[JBlaze]

Curve sucks. It's sooooooooooooo 2006. ಠ_ಠ

[bloc]

Yeah, Blaze..but its what we got. Besides, forum software have always lagged behind everyone else, so we're right on schedule

Antech, why the header doesn't allow bigger logos is not a fauly of my Curve design, but rather of the implementation of it into CSS/HTML. Splitting up the top header and middle in exact parts - without allowing the "inner" gradient to be pushed down - was not made by me, nor did I ever approve of it. Eren did those and it was decided to keep it. But you are 100% right thats its a major fault..I am surprised why it hasn't been adressed though. Is using one single image for the header/frame graphics that important? Use 2, at least, or even smaller sprties which are repeated for the middle parts: a better solution and will solve the elasticity problem of the header. Nuff said.

[JBlaze]

* JBlaze patiently awaits HTML5/CSS3 themes for SMF

[Antechinus]

Yeah, Blaze..but its what we got. Besides, forum software have always lagged behind everyone else, so we're right on schedule

Antech, why the header doesn't allow bigger logos is not a fauly of my Curve design, but rather of the implementation of it into CSS/HTML. Splitting up the top header and middle in exact parts - without allowing the "inner" gradient to be pushed down - was not made by me, nor did I ever approve of it. Eren did those and it was decided to keep it. But you are 100% right thats its a major fault..I am surprised why it hasn't been adressed though. Is using one single image for the header/frame graphics that important? Use 2, at least, or even smaller sprties which are repeated for the middle parts: a better solution and will solve the elasticity problem of the header. Nuff said.

Ah, ok. That was before my time and I assumed it was the way you had designed the theme, since you didn't grumble about it when we were setting up the code for the sprites. I suppose I could write a mod to split the header. That wouldn't be at all difficult. Markup and css changes would be minimal and I can't see it breaking any other mods. I'll take a look at it tonight.

[bloc]

Oh, I gave that particular grumbling up a long time ago lol. TBH , I only just sniffed at using no tables back when that was made, and I was very unsure on how to proceed + Eren was the expert on CSS so.. . Today its another matter, I've gone the long way and slowly learned more and more about what works and what doesn't in using CSS in SMF templates. Still no expert though lol.

But to elaborate further on what I said about simplifying the CSS: I have been wondering what the purpose was of making so many specific classes? A small example: there are 2 windowbg classes, good, and one .post class for text. Then you can change the line-height in those and it will work everywhere, right? Except it won't because there are at least 2 more for posts, in PM section and in recent topics screen. And thats just one example, the admin screens have even more such one-time only classes.

No wonder the index.css is so big.

The normal Curve index.css is 3620 lines long. In comparison my current index.css in bwTheme is 512 lines long. Ok, so I also use a self-made CSS grid system which reduce the need for styles that build columns and I thrown out all the header code in favor of CSS3 for headers..but I'll argue that default can be that slim, thus any other theme will have no problem adapting and expanding on it. Just because there are so few styles.

[Antechinus]

Ok, sounds good. But........................................what I am finding, just from doing a bit of playing around with my variants (IOW, before I even start going mental on full-on custom theming) is that I am wanting specificity that isn't there in some places. I'm also finding that where specificity is available in the markup, it is arranged in such a fashion that it gets overridden by generic classes in some places.

Obviously, none of this is optimal and there is room for improvement. So if we can strip down the default css, while still allowing experienced themers to hit any damned thing they want any way they want, then this would be the best of both worlds and we'd have a lot of happy people methinks.

Just in general terms, it sems to me that the best way of achieving this is to use generic classes all over the place for simplicity of default css, but with all higher level elements having specific ID's, combined with low level elements having either ID's or extra classes after the generic ones. The latter may or may not get called in the default css, but would be available for themers who want them.

This is, of course, basically what we were trying to do in 2.0. But, having started to do a bit more custom stuff now that the mindless debugging crap is out of the way, I'm finding there are bits we could have done better. Figures.