-
I'm no designer, and I generally leave theme design to others, but this one I thought I'd start trying to do something interesting. It's a WIP, dubbed Wintage. Might be familiar to some of you :whistle:
-
Might be familiar, yes :P Core wasn't that bad of a theme, although it looked better in SMF1 than 2, dunno why.
Evening jab: gonna make Wabylon and Wassic, too? lol
-
reminds me on C... :whistle: but I'd definitely prefer your version, is looking way more modern and cleaner ... Nice work :cool:
-
Lol. After all this time, it'll be fun to try and run Wedge with such a skin. Is it inherited or main?
We should try finding existing W words before relying on new terms but it's not important.
Maybe I should give guests the ability to change skins too. Via a URL var I guess?
-
Are you guys going to release .png files anytime, so we can have a fiddle with skin colours?
:angel:
-
CSS only. No pngs for colors. Wedge is magic ;)
-
Shoot!
Where did I put that "CSS Guide For Learners"
-
Color changes can sometimes be done with a single variable change.
$main_bg = hue(rgb(235,235,255), 20%)
to...
$main_bg = #fcfafc
Save and upload.
Totally different results :)
You can set $main_bg in custom.css too, this ensures Wedge updates don't erase it.
Has other vars like $window_bg2 etc.
-
Thanks Nao,
Sounds straightforward enough :^^;:
-
Nice, Arantor! :D I have always liked Core a lot but I like this version better :)
-
It's inherited from the current default skin ;)
-
Good!
-
And there's no images either, it's all CSS gradients (not even inheriting the normal gradient classes)
It is experimental, though, so it's ugly coding for now, but I did manage at one point to do a "#id reset extends something" which I thought was pretty neat :D
But it is also interesting to note where there is styling stuff hardcoded - the gap between the catbg and the titlebg bars in the screenshot is not controlled by the theme - but by a hardcoded div in the template. Same for the misaligned div in the thoughts area of the sidebar (where it's hard up against the left side)
Interestingly, it's not possible to truly replicate SMF's Core layout without changing templates, because there's no way I could find to wrap both the upper sections (the blue gradient area, the title area) with the navigation menu inside a single element, to get a border around both at once, because they're contained in two separate divs and the only parent is #wedge which contains the entire page.
As it turns out, I'm not that fussed personally, because I think the style I have there works better. Though I do want to see if I can't recreate something akin to SMF's Core menu tab thing, since I quite liked that. We'll see, busy seeing how badly the world looks on an iPod touch right now.
-
It is experimental, though, so it's ugly coding for now, but I did manage at one point to do a "#id reset extends something" which I thought was pretty neat :D
But it is also interesting to note where there is styling stuff hardcoded - the gap between the catbg and the titlebg bars in the screenshot is not controlled by the theme - but by a hardcoded div in the template.
You can rewrite title headers with a mixin, although I think they really need some kind of rewrite... (Perhaps just removing the default ones from the index template, because it's really not the same format as in skin files.)Interestingly, it's not possible to truly replicate SMF's Core layout without changing templates, because there's no way I could find to wrap both the upper sections (the blue gradient area, the title area) with the navigation menu inside a single element, to get a border around both at once, because they're contained in two separate divs and the only parent is #wedge which contains the entire page.
Just that sometimes it's not worth it.
Posted: February 24th, 2012, 03:59 PM
Speaking about the skin system...
I was thinking about something a bit funny and idiotic. And very certainly too late in the process.
Having all template blocks behave as if they had no indenting at all, and then indenting them when outputting them, by using the number of tabs by which the block name is indented in the skeleton.
The code is already ready for that, since there's an 'indent' param in skeletons, I just thought it'd be neat to do it automatically based on the skeleton...
Of course, the only (and major!) issue is that it would require going through all existing templates and removing their base indenting.
-
Really...? Is that something in Wedge you mean? Where?
For the thoughts, I believe it's index.template.php, but there's a div explicitly setting sizes there too.Everything is doable in CSS...
<div id="wedge".
<div id="somestuff">
</div>
<div id="someotherstuff">
</div>
... more markup
</div>
Now put a single border around those items, with a 1px padding between the border and the content, and leave the content such that you can still put borders on the content that butt up against the 1px padding+border (e.g. the someotherstuff div has a gradient but a 1px darker border on it)
i.e. replicating the Core layout.Speaking about the skin system...
I was thinking about something a bit funny and idiotic. And very certainly too late in the process.
-
Okay, I hope you won't mind too much but I've fixed some things that needed fixing in the skeletons, so it's possible that you'll need to fix them too in Wintage... At worst, you'll just need to copy some of the stuff from the Wine/skin.xml file.
For the info centre, InfoCenter.template.php. Under the <we:title> is a div with an explicit 8px height.
Even if Wedge is miles ahead of SMF when it comes to theming, templating and CSS, it still inherits a few of its oversized CSS so sometimes I'm just too lazy to look into what's breaking padding etc... :-/Now put a single border around those items, with a 1px padding between the border and the content, and leave the content such that you can still put borders on the content that butt up against the 1px padding+border (e.g. the someotherstuff div has a gradient but a 1px darker border on it)
i.e. replicating the Core layout.
The first Noisen theme (back when it was running SMF 1.1) was based on Babylon. I still like it a lot.Certainly late, but interesting idea. Personally, though, I'd rather strip the indentation instead of outputting it - simply because it should save a bit of bandwidth, no?
Although yeah, it's really indenazi territory at this stage... ;)
-
Okay, I hope you won't mind too much but I've fixed some things that needed fixing in the skeletons, so it's possible that you'll need to fix them too in Wintage... At worst, you'll just need to copy some of the stuff from the Wine/skin.xml file.
Though looking at the latest rev, seems that it might have been more than just me that was intrigued by it.Ah, yes... I think I added that one as a quick hack to make it 'work' because the padding wasn't very good for this particular occurrence.
But technically speaking, it might also break other design possibilities. (For instance, breaking up a large div into several horizontal divs certainly makes it impossible to put a gradient on the first div and expect it to continue flawlessly in the following ones. Unless you set the parent div's position to relative and the children to absolute, and set a large height for the first child... Uh.)
The first Noisen theme (back when it was running SMF 1.1) was based on Babylon. I still like it a lot.
Well, it certainly would be feasable... Could even have an admin setting to determine whether you want 'correct' indenting (i.e. based on skeleton tabs), or bandwidth/CPU-saving indenting (i.e. nothing done), or bandwidth-saving indenting (i.e. removing all indents at run time, including the hard-coded ones.)
The other thing is, does it make a difference in gzip size? I know that sometimes you can end up saving far less than you thought by not removing things like spaces.
-
Okay...
- A concept for you to play with: dynamic replacement of HTML code. In skin.xml:
<replace for="ie6,ie7">
<from><aside id="sidebar"></from>
<to><table id="sidebar" class="top"><td></to>
</replace>
It's just an example, because it'd be impossible to find the closing div, and thus to do a full replacement -- I think. Unless we do some recursive regex matching... I dunno. Without it, that would allow adding extra divs, but only if you could also match the next div opener to add a closer before it.
- removing tabs on a typical page will save about 100 bytes after gzipping. It's not something to be ignored, but it's not that much compared to a typical (small) page size of 5KB gzipped. About 2% worth...
-
I LIKE IT! That said, I see your point about finding the end div, and I don't think there's a good way to solve that at all, sadly.
-
<from><div I'd="sidebar">{match}</div></from>
If match is met in the request, and is followed by a closer, turn it into a regex with recursively. Can be done. Just doesn't feel very natural.
<to><i >{match}</i></to>
I hate the iPod when it comes to typing HTML in...
-
Yeah I see what you mean about not feeling natural.
-
So... I've been thinking about it a bit more... Couldn't find a perfect solution. Right now the best realistic code I have is this:
<replace>
<from-start><aside id="sidebar"></from-start>
<from-end></aside></from-end>
<to-start><div id="sidebar"></to-start>
<to-end></div></to-end>
</replace>
If <from> is used, a simple replace is done. Otherwise, Wedge would build a recursive regex out of <from-end>, or it would simply step through the code until it meets an unmatched closer, which has my preference these days (it's probably not faster, but at least it's not subject to any security problems.)
Maybe use from-opener and to-closer etc instead of start and end, although it'd imply we only support one tag in these, when there could be more. Or perhaps it could be made simpler for skinners...
<replacenode>
<from><aside id="sidebar"></from>
<to><div id="sidebar"></to>
</replacenode>
Replacing a "node" would look into the HTML in 'from', extract the tag name, and look for the closer. Then it would replace the opener normally, and would replace the closer with the tag extracted from the 'to' entry.
That one, obviously, would require having only one tag.
Finally, there's also the possibility of giving freedom to skinners, but they'd also need to learn regex...
<replace>
<from-regex><aside id="sidebar">(.*?)</aside></from-regex>
<to><div id="sidebar">$1</div></to>
</replace>
Would obviously require that skinners know how to encode the request for preg_replace. *And* know how to do a recursive regex... (I suppose I could provide one for inspiration. But it would still require work on their side...)
Posted: February 25th, 2012, 12:38 AM
BTW, I also have in my to-do-list a @replace command for WeCSS... Although it's a bit on the backburner for now, because I'm not sure where best to implement -- in the same way as my @remove code, possibly, although it might be smarter to do it either before the parsing, or after the processing.
-
I like the idea of the regex but I suspect it's going to be a bit much for themers. Heck, regex is beyond most mod authors too.
Regarding @replace, what are the benefits and problems with doing it before parsing and what are the benefits/problems to doing it after?
-
Dragging this back on topic a bit, I did some more work on fixing the styling up. Notably, I've altered the menu to be reminiscent of Core's menu - but not that similar.
The board index still needs work as does post display, but the message index looks good :)
-
Cool! :D
-
And remember, this is *purely* done using the theme system - there are no new templates involved.
-
I like the idea of the regex but I suspect it's going to be a bit much for themers. Heck, regex is beyond most mod authors too.
If I provide an example for a simple div replacement, then it should be alright. Maybe I could even document it in comments, or something. Coming up with a recursive regex is hard. Adapting it to other tag types is easy.Regarding @replace, what are the benefits and problems with doing it before parsing and what are the benefits/problems to doing it after?
Pre-parsing, I don't know. The main issue with doing it at the same time as @remove is that it does add a bit more processing time compared to pre or post parsing. That's really the only thing... I'd like to move @remove to pre-processing, but technically it's not doable, because if you remove an entry and its selector only had that entry, you end up with an empty selector entry which usually means parsing problems in WeCSS...
Posted: February 25th, 2012, 05:52 PM
In the end I went for the pre-parsing way. Works perfectly, and its only costs a preg_match_all. (I could make it a bit faster though, by preventing @remove from having tabs or spaces before it.)
-
Hmm, I probably should pick up on this again now that one of the things which bugged me has been fixed in the base theme ;)
-
What was it?
Btw I should add support for @remove specificity, ie being able to add a selector filter right after the keyword... That'd be good. And maybe even a wildcard like "background: *" so that any changes to the parent won't affect this...
Oh, and about the iPod preventing me from typing: seems to fix itself once it first saves that empty draft. But I don't know if drafts are the cause. The same issue happens when I get asked for my admin password...
-
I actually mentioned it in a thread somewhere: I wanted to be able to put a border around just the categories themselves, not around the entire table, but that wasn't possible with Curve style markup. But in the last few weeks I rewrote the board list markup so that it generated separate tables for each category, with their own thead and tbody rather than having category headers, board contents and the divider all being separate tbody elements.
Btw I should add support for @remove specificity, ie being able to add a selector filter right after the keyword... That'd be good. And maybe even a wildcard like "background: *" so that any changes to the parent won't affect this...
Oh, and about the iPod preventing me from typing: seems to fix itself once it first saves that empty draft. But I don't know if drafts are the cause. The same issue happens when I get asked for my admin password...
I probably should use my own iPod a lot more for testing but right now it's waiting to be packed up with the rest of my stuff.