« Standardization of UI elements
Ditching themes? (+ CSS preparsing)
Public & Private Groups? »

Joker™

  • Posts: 6
Re: Ditching themes?
« Reply #15, on April 30th, 2011, 07:39 PM »
Quote from Arantor on April 30th, 2011, 05:33 PM
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.
Not read python ever but one of my friend is a big fan of it.

Sass seems to be quite a fun thing from what I've read over here.
Quote from Nao/Gilles on April 30th, 2011, 06:43 PM
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.
You can use a nice JS color picker to offer colors.
Quote
@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.)
Will wait to see your feature list. css preparser, can you explain a bit that what exactly is that?
Quote
Here's a sample from my index.css code:

Code: [Select]
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? :)
Lol that seems to be a great thing which will surely remove a lot of hassles.

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Ditching themes?
« Reply #16, on April 30th, 2011, 08:42 PM »
The pre parser is basically just some code to handle the funky style listed above, and output real CSS for browsers.
When we unite against a common enemy that attacks our ethos, it nurtures group solidarity. Trolls are sensational, yes, but we keep everyone honest. | Game Memorial

Nao

  • Dadman with a boy
  • Posts: 16,080

DoctorMalboro

  • I like rounded borders.
  • Posts: 316
Re: Ditching themes?
« Reply #18, on May 1st, 2011, 12:36 AM »
And that's going to be crossbrowser?

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278

Nao

  • Dadman with a boy
  • Posts: 16,080
Re: Ditching themes?
« Reply #20, on May 1st, 2011, 01:28 AM »
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..?

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Ditching themes? (+ CSS preparsing)
« Reply #21, on May 1st, 2011, 01:33 AM »
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.

Nao

  • Dadman with a boy
  • Posts: 16,080
Re: Ditching themes? (+ CSS preparsing)
« Reply #22, on May 1st, 2011, 02:04 AM »
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...

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Ditching themes? (+ CSS preparsing)
« Reply #23, on May 1st, 2011, 03:54 AM »
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.
Quote
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?
Hrm. This is a complex issue. 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.

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.

Nao

  • Dadman with a boy
  • Posts: 16,080
Re: Ditching themes? (+ CSS preparsing)
« Reply #24, on May 1st, 2011, 08:18 AM »
Quote from Arantor on May 1st, 2011, 03:54 AM
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.
I met one tonight as well, but he said EAT YOUR GREENS instead. (So I ate him.)
Quote
Quote
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?
Hrm. This is a complex issue.
It doesn't look complex at all to me....?
Quote
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.
Yeah I forgot about these... We also have a fonts folder which could very easily be moved to the root (I don't see the point in having that in a theme folder.)
Quote
If we remove that Themes folder, we essentially risk damaging that association. Thing is, true parallel themes can do things that styling cannot.
I don't see what they can do that stylings could not do *eventually*.
Quote
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.
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.
Quote
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)
Because it becomes complicated when it comes to determine where you put your CSS... "Shall I put it into my theme folder or the default one as a styling...?"
I've actually never tested installing an extra theme in Wedge. I'm sure it wouldn't be pretty...
Quote
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!)
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.)
Quote
IOW, I'm not 100% sure we need to change anything, unless we replicate most of the functionality that's already present.
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.

DoctorMalboro

  • I like rounded borders.
  • Posts: 316
Re: Ditching themes? (+ CSS preparsing)
« Reply #25, on May 1st, 2011, 03:29 PM »
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

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Ditching themes? (+ CSS preparsing)
« Reply #26, on May 1st, 2011, 03:59 PM »
Quote
I don't see what they can do that stylings could not do *eventually*.
It depends whether stylings are intended to be style variations or potentially complete replacement themes. If the former, parallel themes will still be required where major template changes are. If the latter, we need to devise a way that a styling can replace individual templates.
Quote
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.
Documentation, we can write that. Tutorials too. What we can't change, though, is how it's viewed by the user if that makes sense. Folks coming from SMF will understand how SMF does themes, and stylings are a different mindset entirely - and the very name implies a variant rather than something totally different.
Quote
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.)
That would certainly solve my concern.
Quote
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.
Yes, it does. If you use loadTemplate() to load a CSS file, it attempts to load it from the theme first before loading it from the default theme as I discovered a couple of weeks back where Bloc had put the old SD CSS file in his premium custom themes.

This is naturally less of an issue for us because that option was removed.

spoogs

  • Posts: 417
Re: Ditching themes? (+ CSS preparsing)
« Reply #27, on May 1st, 2011, 04:28 PM »
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 :)
Stick a fork in it SMF

Dismal Shadow

  • Madman in a Box
  • Me: Who is Arantor? Cleverbot: It stands for time and relative dimensions in space.
  • Posts: 1,185
“I will stand on my ground as an atheist until your god shows up...If my irreligious bothers you much, and if you think everything I do is heresy to your god I don't care. Heresy is for those who believe, I don't. So, it isn't heresy at all!


   Jack in, Wedge,
   EXECUTE!

Nao

  • Dadman with a boy
  • Posts: 16,080
Re: Ditching themes? (+ CSS preparsing)
« Reply #29, on September 21st, 2011, 07:06 AM »
(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:
« Standardization of UI elements
Public & Private Groups? »