Wedge
Public area => The Pub => Features => Topic started by: Nao on April 27th, 2011, 04:20 PM
-
You know, I'm actually very tempted to ditch *themes* altogether...
I pretty much have the same view(http://www.simplemachines.org/community/index.php?topic=427679.0) as Bloc on this matter. But I'm not the only one making decisions here, of course, and it's not a shared vision. I'm fine with it as long as I don't have to test my styling feature in other themes :niark:
At any rate, I would like to remove the "per theme" aspect of user settings, yes. Although I didn't know Bloc introduced special settings in his custom themes. Maybe this has a use in the end, then...?
-
I have no idea. I'm really unsure what to do with theme settings. I'd tend to ditch everything and just assume that if someone uses a custom theme, they'll rarely change it, and so there's no reason to have different values for something. When it comes to board-specific themes, let's be realistic here: the news fader never shows up anywhere else than on the homepage anyway. So it's no big deal...
Then again, do we ditch the theme system at all?
I'd like to have opinions from everyone...
I don't really see a 'bad' point, in that it's really about turning themes into stylings. i.e. I could add the ability for stylings to specify new template files. Of course it makes for a strange mix of CSS, JS, XML and PHP in the same folder, but (1) there's nothing preventing the themer to put most of their non-CSS files into another folder as long as they're properly linked, (2) I think most themes don't have a lot of extra files anyway.
-
Personally, I moved away from themes on my board more because of differences between 2.0 revisions than mods. Most themes seem to be dependent on the RC code and the theme authors tend to not revisit them between versions, waiting for "2.0 to go final". Bloc's themes have been the notable exceptions, but even so, the only theme-related gripes I experience these days are from users on mobile devices.
It would be nice to see a more modular approach, specifically consistency with board features tied to permissions. For example, I modified the templates to only render the who's online option if the user has the permission 'who_view'.
-
Split topic into its own... Calling for advice.
-
First of all hello to everyone,
Nao as we can see in SMF itself most themes are curve based with some variation in images, so why not create a default theme using as less images as possible and then creating a section in admin panel where the admin can make the color variations by just putting color hex codes.
So it will provide a nice platform to admins to play with there themes and modify there forum looks as they want in very easy manner.
Just a suggestion :).
-
Well right now it's very easy to change using an add-type styling. Hello.
-
Well right now it's very easy to change using an add-type styling.
-
Yeah, I'll agree with that, it's very, very easy to make colour variations - even I can manage it without too much hassle, which says something.
Though we're planning on making it so that editing a theme affects mods less and vice versa.
-
I'm not much of a fan of noob-friendly CSS editing, personally. Tempted to get rid of that editor in the admin area. As for allowing people to set default colors for a styling, hmm... I guess it's doable, but only through using CSS variables. It can be done, but really, I imagine it would complicate things for Wedge at compilation time. Maybe by allowing to override only the actual CSS variables in the code...
-
The problem with making noob-friendly editing tools is that invariably it hampers those already familiar/the pro folks. I don't use the theme editing tools in SMF because they're the very worst kind: no good for noobs because they're too complex, and no good for competent folks because it's too basic.
I would actually rip it out because it doesn't add anything. One fact I would note: the only reason that there's a tool generating theme modules for 1.1.x that are colour variations is because a certain someone originally wrote one for their hosting platform, and no-one's done it for 2.0 to make the main block image because people will rather use Photoshop etc. to do it... no-one makes tools for that particular job because it's not in anyone's interest to do so.
-
Though we're planning on making it so that editing a theme affects mods less and vice versa.
I'm not much of a fan of noob-friendly CSS editing, personally. Tempted to get rid of that editor in the admin area. As for allowing people to set default colors for a styling, hmm... I guess it's doable, but only through using CSS variables. It can be done, but really, I imagine it would complicate things for Wedge at compilation time. Maybe by allowing to override only the actual CSS variables in the code...
You can create a script which can refresh the css cache if the user has made changes in css through admin panel.
One more suggestion if you people think of going with the above suggestion that do create backup css files so that even if one wants to have the old styling back he can simply get it back from backup css file.
Edit - Just saw Arantor's reply
Arantor why don't you make a css code highlighter in admin panel itself so that it will be much easier to read the css code.
-
You can create a script which can refresh the css cache if the user has made changes in css through admin panel.
-
It's a LOT more complex than that. There are no normal CSS files in Wedge, they are all Sass type files now, so you'd have to edit them, recache them then re-serve them.
-
Heh, well suffice to say that it takes some of the elegance of Python source and applies that to CSS, such that things are much more visually distinct and approachable at a glance than CSS normally is.
But of course since none of the browsers support it, it has to be processed first.
-
Hmm yeah I could still see myself doing something like this...
- Retrieve all variables from the wecss files,
- Retrieve a $modSettings['css_vars'] variable that contains potential replacements for them,
- Do the replacement before passing the css vars.
And in the admin area -- retrieve variables from the wecss files, list them ("$main_font", etc.), and offer to overwrite them. If one of them is detected to be a color variable ("rgba(0,0,0, .5)", etc.), we could also offer a color wheel to pick a new one.
@Joker> Actually it's only Sass-style by inspiration. I read about Sass in .net Magazine last January, loved how their idea was going further than my original plans for a css preparser, which encouraged me to do a PHP version of it. In the end it hasn't got half of the Sass features, and it's certainly not as elegant, but it's much, much faster, and at least you don't have to remember 50 different functions eheh. Plus, my implementation has some cool extra features that no other css preparsers have. (Notably the 'final' keyword which is important for object oriented programming. You'll see when I publish the feature list.)
Here's a sample from my index.css code:
section.block extends .wrc
overflow: hidden
header extends .wehead
font-weight: 700
padding: 3px 12px
border-radius: 8px 8px 0 0
margin: -0.9em -1.2em 1em
footer extends .wefoot
padding: 3px 12px
border-radius: 0 0 8px 8px
margin: .5em -1.2em -0.9em
dl.settings
margin, padding: 0
Fun, eh? :)
-
Heh, well suffice to say that it takes some of the elegance of Python source and applies that to CSS, such that things are much more visually distinct and approachable at a glance than CSS normally is.
But of course since none of the browsers support it, it has to be processed first.
Sass seems to be quite a fun thing from what I've read over here(http://sass-lang.com/).And in the admin area -- retrieve variables from the wecss files, list them ("$main_font", etc.), and offer to overwrite them. If one of them is detected to be a color variable ("rgba(0,0,0, .5)", etc.), we could also offer a color wheel to pick a new one.
@Joker> Actually it's only Sass-style by inspiration. I read about Sass in .net Magazine last January, loved how their idea was going further than my original plans for a css preparser, which encouraged me to do a PHP version of it. In the end it hasn't got half of the Sass features, and it's certainly not as elegant, but it's much, much faster, and at least you don't have to remember 50 different functions eheh. Plus, my implementation has some cool extra features that no other css preparsers have. (Notably the 'final' keyword which is important for object oriented programming. You'll see when I publish the feature list.)
Here's a sample from my index.css code:
section.block extends .wrc
overflow: hidden
header extends .wehead
font-weight: 700
padding: 3px 12px
border-radius: 8px 8px 0 0
margin: -0.9em -1.2em 1em
footer extends .wefoot
padding: 3px 12px
border-radius: 0 0 8px 8px
margin: .5em -1.2em -0.9em
dl.settings
margin, padding: 0
Fun, eh? :)
-
The pre parser is basically just some code to handle the funky style listed above, and output real CSS for browsers.
-
And minimize it ;)
-
And that's going to be crossbrowser?
-
The resultant CSS is...
-
Yes... Multiple versions of the file are generated in the cache -- depending on whether you're logged in or not, whether you're using the default language or another, and what browser you're using. Wedge automatically adds the relevant prefixes to any CSS3 that I use in the file. That is, box-shadow, border-radius, box-sizing, transition and background-image: linear-gradient(). (Although the last one is not in use for now because I'm using a custom function I made to get IE compatibility, but I added it for potential use by other themers.)
PS: back to the original question maybe..?
-
It's all relevant, actually.
The whole nature of the caching and processing means that theme editing from inside the box, as it were, is far less realistic, but making it vastly easier for admins to tweak the colour scheme of their forum. And since it's done as a styling rather than a theme, it really is ditching the bulk of what themes were conventionally used for.
This is not to say that we're ditching the theme capability, but to focus intent where it's needed: for themes that are simple recolouring/CSS tweaks derivatives of an existing theme, they shouldn't be made into new themes fully, but made into stylings that can inherit from the parent - which takes care of all the issues about mods on custom themes when the themes are basically the same.
The system does make it easier for themers to do slightly more interesting CSS too - but when custom templates are the only way to go, there's no barrier there at present that isn't in SMF in some fashion, but the barrier is lower: instead of having to craft some random mashup of tags that varies between RCs, there is a standard meta tag to use instead, that's under the theme's control, not mod control.
-
Meta tags? You mean the block system?
Although your post is interesting, it comes after a... peculiar hour of complicated Whoing, so I feel like you're an alien talking to me... :lol:
Does this mean it'll make more sense for us to ditch /Themes/*/ and just move everything to a root and then extend stylings with the ability to refine some templates?
We could do the structure this way:
/theme/
/theme/styles/
/theme/styles/css/
/theme/styles/js/
/theme/styles/img/
/theme/styles/tem/
/theme/styles/Other_Styling/
/theme/styles/Other_Styling/css
/theme/styles/Other_Styling/Sub_Styling/
/theme/styles/Other_Styling/Sub_Styling/img/
js, css, img and tem (and maybe "data" -- or maybe even JUST "data") could be 5 'reserved names' for folders (it could just as well be "js, css, images and templates" of course.)
Wedge would simply go through the folder list and discard these names when trying to find other stylings. It would make it easier to offer some clean code for themers, I don't know.
And themers wouldn't HAVE to use these folders to put their data into... It would just be the list of folders where they can safely put their stuff into without disrupting the nested styling system.
Time for bed...
-
Yes, I meant the block system, though really, it IS a meta tag, since <we:*> is a tag that will become other tags.
Like an alien? SILENCE, DOCTOR, SILENCE WILL FALL.Does this mean it'll make more sense for us to ditch /Themes/*/ and just move everything to a root and then extend stylings with the ability to refine some templates?
We have a top level Sources folder for all the fun sources stuff. We also have a top level Themes folder which contains a whole bunch of stuff, including languages.
Now, there is a wisdom to that top level Themes folder - you have the default theme and each theme that's added to it is added in parallel, making up anything it doesn't have in resources by substituting the default theme's.
If we remove that Themes folder, we essentially risk damaging that association. Thing is, true parallel themes can do things that styling cannot.
Yes, styling can change any CSS right now, and can change certain block elements in the HTML of templates. For stylings to replace themes, two things would have to happen.
Firstly, we'd need to give stylings the ability to modify any template's markup. To me, this seems the wrong way to go; a styling should be a *style*, rather than a complete layout specification. To me, then, I see stylings as making the theme variants system what it always wanted to be: a clear, easily accessible manner for a theme to provide multiple colour variations, or small style variations under a single 'theme' banner. This it can do, and do extremely well, and I see no reason to graft on the ability to hit up markup more generically when really if the markup is that far different, it should be a different physical theme with its own templates (and using the default templates where necessary)
Secondly, languages. If you have a theme that's doing really, really funky things the odds are it's going to bringing its own settings and with that its own language strings. Right now, SMF can deal with this (and even do it properly now, as far as I know!)
More importantly, languages already inherits the template loader subsystem, so it can load theme specific strings then load the default ones.
IOW, I'm not 100% sure we need to change anything, unless we replicate most of the functionality that's already present.
-
Yes, I meant the block system, though really, it IS a meta tag, since <we:*> is a tag that will become other tags.
Like an alien? SILENCE, DOCTOR, SILENCE WILL FALL.
Does this mean it'll make more sense for us to ditch /Themes/*/ and just move everything to a root and then extend stylings with the ability to refine some templates?
Let's see...
We have a top level Sources folder for all the fun sources stuff. We also have a top level Themes folder which contains a whole bunch of stuff, including languages.
If we remove that Themes folder, we essentially risk damaging that association. Thing is, true parallel themes can do things that styling cannot.
Firstly, we'd need to give stylings the ability to modify any template's markup. To me, this seems the wrong way to go; a styling should be a *style*, rather than a complete layout specification. To me, then, I see stylings as making the theme variants system what it always wanted to be: a clear, easily accessible manner for a theme to provide multiple colour variations, or small style variations under a single 'theme' banner.
This it can do, and do extremely well, and I see no reason to graft on the ability to hit up markup more generically when really if the markup is that far different, it should be a different physical theme with its own templates (and using the default templates where necessary)
I've actually never tested installing an extra theme in Wedge. I'm sure it wouldn't be pretty...Secondly, languages. If you have a theme that's doing really, really funky things the odds are it's going to bringing its own settings and with that its own language strings. Right now, SMF can deal with this (and even do it properly now, as far as I know!)
IOW, I'm not 100% sure we need to change anything, unless we replicate most of the functionality that's already present.
-
Actually, that's one concept I've never seen in designs. I'm not the best designer, but I like the way you're putting it...
I imagine that with CSS3 & HTML5, less images will be required... and icons must be in .png :P
-
I don't see what they can do that stylings could not do *eventually*.
Yeah... You're right in the sense that it's accessible. But from the moment I added more options (override JS, blocks...), it became less accessible. People have to rely on Warm/settings.xml as their documentation on stylings.
We can move the language folder to the root, and then potentially allow themers to specify more language files inside settings.xml...? (Which would then be stored in /data/ or something.)
The idea is just to avoid parallel theme folders when they could benefit from a nested structure. I know that themes in SMF *are* inheriting missing templates from the default folder, but it doesn't do it for CSS files afaik.
This is naturally less of an issue for us because that option was removed.
-
From a user standpoint I never use the default theme as the forum's default theme. I know squat about making variations from CSS (i know squat about CSS period :P), so I'm usually on the look out for a theme that appeals to me in design and colour scheme. Whichever way you guys decide to go, ass long as I can find a theme to my liking and install it somehow (fairly easily) I'm happy :)
-
Couldn't find the topic so...
I thought this sounds related:
http://xenforo.com/community/threads/smilies-as-css-sprites.20121/
-
(Yes it's related, thanks! Always interesting to look into the competition's new stuff. I don't look into it myself. I lack time.)
They totally missed the point. (+1 for execution though.)
Smileys are often animated GIFs and can't be put into CSS sprites.
The only solution in this case is base64-encoding them.
I should think/hope Wedge is the first system to offer this :eheh: