Wedge

Public area => The Pub => Features => Topic started by: Nao on July 25th, 2012, 05:22 PM

Title: Virtual selectors in WeCSS
Post by: Nao on July 25th, 2012, 05:22 PM
So, I was considering a new feature that I'll add to WeCSS, and need to get some thoughts on it first...

Let's consider this new keyword, 'virtual' (always in line with the C++/Delphi naming scheme.)

.inline-block virtual
   display: inline-block
   blablabla...

Now, the idea is that if a selector is found that has the virtual keyword, at the end of the pre-processing stage, Wedge will run a check for the selector, and delete it from all selector combinations (i.e. .inline-block, .windowbg, .windowbg2 will just become .windowbg, .windowbg2).

Additionally, if it's found to be alone (i.e. no other selectors extend it), it will simply delete it. Thus allowing me to create a 'virtual.css' or 'common.css' file with all of the nice little helpers like this one, and add it silently at the beginning of all files, which in turns allows us to use "extends .inline-block" everywhere, including external CSS files not related to the main file.

I think it's a pretty good idea, but this is where it gets tricky: there are a few rare situations where "inline-block" is used as a proper class in the HTML -- notably in the admin homepage, where it's also associated with admin_menu (making it easy to remove it... Just extend it!), the profile template (can add a custom class to that one), and the plugin manager (same here, will need an extra class.)

So, I'm wondering what's best?
1/ just forget about that keyword, and keep allowing the HTML to use virtual selectors.
2/ use it, but don't delete the selector afterwards... (which makes it pretty much useless, ah ah :))
3/ use it, and always delete the selector, and force the HTML to inherit from the selectors instead of using them.
Title: Re: Virtual selectors in WeCSS
Post by: Arantor on July 26th, 2012, 05:16 AM
I like the idea of being able to allow extensions etc. to be able to extend the base classes, something I'm sure I had trouble with at some point.

I don't really think 2 is an option, but what's the downsides of 1 and 3 vs their specific benefits?
Title: Re: Virtual selectors in WeCSS
Post by: Nao on July 26th, 2012, 12:55 PM
The downsides of 1 are that:
- plugin authors may be at a loss when they attempt to inherit from .inline-block in their custom CSS when 'it works perfectly when editing index.css'...
- philosophical conflict. See below.

The downsides of 3 are that:
- we have to ensure we don't use abstract (or virtual, what would be best?) selectors in the HTML, and we need to convert existing uses to classes (which isn't that bothersome.)
- if we use a 'large' mixin or extend in the common.css file (for example by including a base64-encoded image in the class), you have to keep in mind that both the final gzipped 'index.css' and 'my-plugin.css' files will include the image, which is a total, complete and absolute waste of space, and something kind of scary in the end.

And, on a higher level, it's basically a fight to the death between the SASS philosophy (mixins and extends for the win, every HTML div has its own custom class) and Nicole Sullivan's OOCSS methodology (https://github.com/stubbornella/oocss/wiki/), where every class is an 'object' with a single role and you need to accumulate classes on your divs to give them the shape/role you want.

I'm of the opinion that both philosophies have their pros and cons, and can actually be adopted either way. I like them both.
However, because WeCSS went into the direction of class extensions, it's hard to justify not keeping to that method through the end.

As such, I'd recommend going with virtual keywords and using a common.css file for inline blocks, windowbg and any other elements that may regularly be inherited by others.

Now, there remains the case of windowbg (and probably other classes), where most of our templates specifically indicate they want windowbg as their base on this or that div, and then add other styles to it. This, in essence, is OOCSS and while it's still compatible with WeCSS, it feels 'wrong' to have it.

I guess that, before asking about virtual selectors, I should have asked to discuss the conflicting philosophies of CSS objects, and whether or not we should bother about them... ;)
Title: Re: Virtual selectors in WeCSS
Post by: Arantor on July 27th, 2012, 12:34 AM
I think the downsides to 1) make it enough reason I don't like it, I can fully see that being a problem otherwise.

For 3), call it virtual, it's not abstract by definition. As far as large mixins go, as long as we don't ourselves use anything too massive I don't really see a problem. I don't see us including base64 stuff in the main file - and we're not responsible for keeping themers super-efficient. (As it is, WeCSS deals with things a lot better than SMF anyway)

I agree that both methodologies[1] have their pros and cons but since WeCSS is - sensibly - on the class extension side, you're right in that it should use it to the end.

windowbg is a special case because it has no right home, it's not quite either mixin/extends nor OOCSS because it's both stylistic and semantic. It's like we need to split it up into its roles and have windowbg simply extend that.
 1. I kept wanting to write mythologies
Title: Re: Virtual selectors in WeCSS
Post by: live627 on July 27th, 2012, 02:00 AM
How big a mixin?
Title: Re: Virtual selectors in WeCSS
Post by: Nao on July 27th, 2012, 12:22 PM
Quote from Arantor on July 27th, 2012, 12:34 AM
For 3), call it virtual, it's not abstract by definition. As far as large mixins go, as long as we don't ourselves use anything too massive I don't really see a problem. I don't see us including base64 stuff in the main file - and we're not responsible for keeping themers super-efficient. (As it is, WeCSS deals with things a lot better than SMF anyway)
base64 is usually for icons, so it's unlikely they'll be used in virtual selectors, but it's very possible to include a gradient 8-bit PNG for IE6 compatibility (or whatever), and use that in .windowbg for instance...
However, because .windowbg is usually used directly into the HTML markup (because of historical SMF guidelines), it's one of the few 'exceptions' to the class extension rules. (Along with .smalltext etc.)
This is the kind of class that won't find itself moved to the common.css file ;)
Quote
windowbg is a special case because it has no right home, it's not quite either mixin/extends nor OOCSS because it's both stylistic and semantic. It's like we need to split it up into its roles and have windowbg simply extend that.
Hmmm...
Yeah, it could be a possibility, too.

Just like I made my own postbg and postbg2 for posts, where SMF only uses windowbg and windowbg2.
Title: Re: Virtual selectors in WeCSS
Post by: Nao on August 6th, 2012, 05:16 PM
So, I resumed work on Wedge today... (Hectic weekend IRL.)
I decided I'd start by finishing my virtual implementation. "Oh, that should be easy enough..."
Yeah, sure.

Well, it's not. It's 'only' an additional 25-30 lines but it's full of bugs that I've been working on for a few hours now...

Innovation always comes with a price :lol: (And limitations, I'm afraid.)
Title: Re: Virtual selectors in WeCSS
Post by: Nao on August 11th, 2012, 11:06 PM
I'm not in the best of moods regarding my current work on Wedge... (And it's not helped by a certain basketball match playing right now on my TV... :P)
Implementing virtuals is proving to be the biggest hurdle ever for WeCSS. And that's really odd, because after my initial failure, I settled for a VERY simple version of it: dealing with them just like with any selector, and removing them from selector lists after inheritance is calculated.
Well, all hell broke loose after that.
- If I move one of the virtuals to a certain position, everything compiles correctly. If I move it just two lines below it (even though those lines have nothing to do with it), that virtual will still work, but some other inherited selectors will suddenly disappear from the list. I've spent hours and hours on this, but I just couldn't understand why. For instance, .top_likes simply goes away from the final file. If you'll look at the CSS for it, .top_likes is inherited from stuff that has nothing to do with my short list of virtuals (inline-block, wehead, wefoot...)
- If I remove the virtual keyword from the entire file, I suddenly find myself with a completely failed compiled file: only rules are printed in it, not selectors! I'm sure this one is easier to fix, but still, I'm baffled...

See, that's exactly what Pete has been going through these days -- the feeling that you simply can't code anything worthwhile these days. It's easy to fall into that trap... It's even more annoying when it's code that you wrote long ago and that has always worked flawlessly, despite its extreme complexity. :(
Title: Re: Virtual selectors in WeCSS
Post by: Nao on August 14th, 2012, 03:15 PM
So... Fixed.

The problem wasn't with the virtuals themselves -- I realized that when I did tests on the current SVN and saw the same thing happened. Turned out my implementation was fine.
What wasn't fine, though, was the sorting function for $bases... Instead of returning a negative, zero or positive value, it returned only zero or 1 (a boolean). Considering that PHP has an "undefined" behavior when it receives 0, it's not a surprise that it didn't work perfectly. But even that wasn't the main issue -- the main issue was that I needed to sort (by length) not only the inherited elements, but also the elements that will inherit something... For that reason, in some situations we had a ".div .subdiv" element that was inherited from something, and ".div" from something else, and it would first stumble upon ".div", inherit it, and skip to the next element... Or something like that. Quite honestly, I didn't spend too much trying to figure it out, I just did the fixing, tested it, "seems to work", and I'm happy. I spent the better part of the week on that crap... -_-
Even got badly sick last night, probably due to the stress. Ended up going to bed before 9pm. Which is, like, the beginning of my work day sometimes... :^^;:

Anyway, it's all good now... Phew.
Now I've just got to fix alerts.. And confirms... And more CSS... And other things... All that without any feedback as usual... :P

I guess I'll just commit everything in one go -- because it's going to be one hell of a large commit. I don't even know whether it's worth documenting my commits... I think I'm the only one who cares about what I fix and stuff.

:edit: 9pm, not 9am... Changed that.
Title: Re: Virtual selectors in WeCSS
Post by: nolsilang on August 14th, 2012, 03:49 PM
Quote from Nao on August 14th, 2012, 03:15 PM
Even got badly sick last night, probably due to the stress. Ended up going to bed before 9pm. Which is, like, the beginning of my work day sometimes... :^^;:
Please just take it easy :unsure:
Quote from Nao on August 14th, 2012, 03:15 PM
Anyway, it's all good now... Phew.
Now I've just got to fix alerts.. And confirms... And more CSS... And other things... All that without any feedback as usual... :P

I guess I'll just commit everything in one go -- because it's going to be one hell of a large commit. I don't even know whether it's worth documenting my commits... I think I'm the only one who cares about what I fix and stuff.
I do read your documentation/changelog, and I love to read it :)
About feedback.. I don't really understand the technicality of it, that's why I just left it to others that more capable than me.

Cheers.
Title: Re: Virtual selectors in WeCSS
Post by: spoogs on August 14th, 2012, 05:04 PM
Quote from 0x on August 14th, 2012, 03:49 PM
I do read your documentation/changelog, and I love to read it :)
About feedback.. I don't really understand the technicality of it, that's why I just left it to others that more capable than me.

Cheers.
I resemble this comment as well. I try my best to read everything but I can't say much on the more technical things. many topics that I read the point I would raise is usually already brought up and replied to by the time i get to it.

Alls I can say is keep up the great work :cool:
Title: Re: Virtual selectors in WeCSS
Post by: Nao on August 15th, 2012, 02:54 PM
That's the thing, many say they read the changelog, but rarely if ever comment on it... :whistle:
I'm human. I like feedback -- whether positive or not!

So, I only have one bug left in virtuals -- I used a virtual on a certain tag, and it canceled it and all its children altogether. Hmm... (I'm so tired, I'll probably just leave it without a virtual keyword for now.)
Title: Re: Virtual selectors in WeCSS
Post by: Nao on August 15th, 2012, 03:54 PM
So, "while I was at it" (a dreadful thing for me to say usually...), I rewrote the suffix system (again!) to allow for CSS files to be applied depending on the browser version.

Up until now, you could have index.ie6,ie7.css or index.ie6,firefox.css, but not, for instance, index.ie6,firefox14.css -- which was due to the fact that IE sucks so much, it's often a good thing to have custom CSS files for IE6 etc...

From now on, the first file will have to be written this way: index.ie=6,ie=7.css or index.ie-8.css, meaning "IE is version 6 or 7" for the former, and "IE is less than version 8" (minus sign) for the latter. Which allows us to also have "index.ie=6,firefox=14.css", obviously.
If you want to provide support for a later version, which is less likely but whatever, you can do "index.opera+12.css" (ie Opera 12 and later.)
One of the drawbacks is that for now you can only provide a major version number, i.e. not "opera+12.5"... Which upsets me a bit because Opera usually adds their developer-centric features in .5 versions, while .0 versions are more user-centric.

Also, I wanted to use '>' and '<' keywords in this, but unfortunately they're not allowed by the filesystem it appears. ARGH. So I'm using '-' and '+' instead. '+' is alright, but '-' bothers me because people may want to add CSS suffixes like 'my-suffix'... Well, I guess I'll have to ensure these are accepted if what follows the '-' isn't a number.

So... Given the pros and cons of this new system, I just have one question to ask you guys:

Do you think it's good idea or I should just forget it?
Title: Re: Virtual selectors in WeCSS
Post by: nolsilang on August 15th, 2012, 04:48 PM
Quote from Nao on August 15th, 2012, 02:54 PM
That's the thing, many say they read the changelog, but rarely if ever comment on it... :whistle:
I'm human. I like feedback -- whether positive or not!
Quote from Nao on August 15th, 2012, 03:54 PM
Do you think it's good idea or I should just forget it?
I want to give feedback... but if I don't understand it like above, I don't know what I'm should be talking about.

Cheers.
Title: Re: Virtual selectors in WeCSS
Post by: Arantor on August 15th, 2012, 06:21 PM
I think the pros are probably worth the apparently few cons - but maybe I'm missing something. It's been a very long couple of days for me.
Title: Re: Virtual selectors in WeCSS
Post by: spoogs on August 15th, 2012, 06:54 PM
Quote from 0x on August 15th, 2012, 04:48 PM
I want to give feedback... but if I don't understand it like above, I don't know what I'm should be talking about.
Dammit stop speaking for me LOL.

I've read this entire topic and really just rely on the input from those who get the ins an outs of what's being put forth. Honestly the most get out of it is that change are being made to enhance browser compatibility.... all in all I suppose thats a good thing but I have no idea how it all plays out in practice.
Title: Re: Virtual selectors in WeCSS
Post by: Arantor on August 15th, 2012, 07:11 PM
It's more that the underlying system makes it easier to use the newer CSS goodies, and to make life easier in general for themers to do something interesting.
Title: Re: Virtual selectors in WeCSS
Post by: Nao on August 15th, 2012, 09:58 PM
An alternative to that syntax could be...

index.ie[8].css
index.ie[6-9].css
index.ie[-7].css (i.e. 6 & 7)
index.ie[7-].css (i.e. 7 and above)
index.ie[6,7],firefox[1-3].css

Or () or {} instead of []... I don't know. What do you think?
Posted: August 15th, 2012, 09:56 PM
Quote from Arantor on August 15th, 2012, 06:21 PM
I think the pros are probably worth the apparently few cons - but maybe I'm missing something. It's been a very long couple of days for me.
So... What happened? I did notice you weren't there ;)
Title: Re: Virtual selectors in WeCSS
Post by: Arantor on August 15th, 2012, 10:00 PM
I like that syntax structure, and I'd keep the square brackets to be honest.
Quote
So... What happened? I did notice you weren't there
My grandfather is in hospital with a stroke, I spent the last day or so with my grandmother who requires 24-hour care, and then arrange transfer to a care home.
Title: Re: Virtual selectors in WeCSS
Post by: Nao on August 16th, 2012, 12:06 AM
Quote from Arantor on August 15th, 2012, 10:00 PM
I like that syntax structure, and I'd keep the square brackets to be honest.
Okay, done that way...
Added a new function in Load.php, hasBrowser(), that takes a string or array of strings as a parameter, and tries to match the current browser version against it. I'm using it in the macro builder (both the XML and index template versions), in the skin settings' <for=""> param, and obviously when looking through css filenames.
It's not gonna make WeCSS any faster -- but at the very least, it's even more flexible now.

And while testing it, I realized something annoying.
Long ago, Wedge used to compile files in that order: index.css, sections.css, index.ie7.css. Now, mainly for clarity reasons I believe, I'm compiling them in that order: index.css, index.ie[7].css, sections.css. As a result, any custom IE7 changes to section items (like for instance, topic page handling...) are canceled out by the sections.css file that follows. Eh. So that explains why topic pages broke long ago...
One solution is to just move all of my custom things to sections.ie[7].css etc. Or merge index.css and sections.css once and for all. Or rewrite the code to ensure that custom files are executed at the end -- but I don't believe it's for the best.

Quite annoying really... I'm pretty impressed at the number of bugs that I keep adding to the templating system!
Quote
My grandfather is in hospital with a stroke, I spent the last day or so with my grandmother who requires 24-hour care, and then arrange transfer to a care home.
Oh... Sorry about that. So it's the followup to recent weeks then..? :(
Title: Re: Virtual selectors in WeCSS
Post by: Arantor on August 16th, 2012, 01:06 AM
Quote
Quite annoying really... I'm pretty impressed at the number of bugs that I keep adding to the templating system!
That is, unfortunately, that nature of the beast.
Quote
Oh... Sorry about that. So it's the followup to recent weeks then..?
Yup.
Title: Re: Virtual selectors in WeCSS
Post by: spoogs on August 16th, 2012, 02:45 AM
Quote from Arantor on August 15th, 2012, 10:00 PM
My grandfather is in hospital with a stroke, I spent the last day or so with my grandmother who requires 24-hour care, and then arrange transfer to a care home.
Sorry to hear that man, seems you just can't catch a break eh :sob:
Title: Re: Virtual selectors in WeCSS
Post by: Nao on August 16th, 2012, 07:49 AM
So... I've decided to (at least temporarily) add YET another prefix type to the main list... So, right now, we have in this order of 'execution':

common.css (virtuals and anything that needs to be in all files including non-index)
index.css (main index file obviously...)
sections.css (per-area styles, although it's always included as well)
hacks.css (browser hacks, RTL hacks)
custom.css (this is the one you can include at will.)

The order in which they're included once you're in a sub-skin may not be intuitive. I'm taking the absolute extreme example of Warm, which is a sub-sub-skin. Here it is:

Code: [Select]
[0] => skins/common.css <--- okay...
 [1] => skins/index.css <--- still fine...
 [2] => skins/index.member.css <--- this one has the CSS that only shows up to members anyway
 [3] => skins/Wine/index.css <-- this is what Wine needs to modify in Weaving
 [4] => skins/Wine/index.member.css <-- and a hack for the original index.member.css
 [5] => skins/Wine/Warm/index.css <-- and now, what Warm needs to modify in Wine...
 [6] => skins/sections.css <-- and now for the per-area CSS...
 [7] => skins/Wine/sections.css <-- and what Wine needs to change to it.
 [8] => skins/hacks.ie[6].css <-- CSS hacks for IE6 to work
 [9] => skins/Wine/hacks.ie[6].css <-- CSS hacks for IE6 to work with Wine
[10] => skins/Wine/Warm/hacks.ie[-9].css <-- CSS hacks for IE 6,7,8 and 9 to work with Warm
     => skins/custom.css <-- Gone, see below.
[11] => skins/Wine/custom.replace.css <-- my own personal custom CSS for Wine (which is empty).
        Because it has the 'replace' keyword, the skins/custom.css file is removed from the list.

As you can see, there's at least one big problem: sub-skins execute their index.css file earlier than their parent's sections.css file. This can lead to huge bugs when it comes to CSS selector precedence.
One solution is to rename Wine/index.css to Wine/hacks.css -- and do the same for other index-type files in all sub-skins.
The main inconvenience is that it doesn't scream "I'm a skin definition!", but "I'm a hack!"... (Even though, that's technically what it is since it isn't a replace-type skin... You're trading off "code beauty" for ease of update.)
Or I could simply include files the way they used to be -- folder by folder, i.e. everything from Weaving first, then all of Wine second, etc... I don't like that, there's *PROBABLY* a reason why I did that -- and the original order was screaming for hacks to be included in different positions. (custom.css?)

Another solution is to just drop 'sections.css' (25KB) and merge it with 'index.css' (35KB), like in SMF. Remains to be seen whether it's nice to have everything in a single large file than in two relatively manageable files...
Or, I could do an exception to my system and just merge sections.css to index.css at sort time, but honestly I don't know how to do that... (it's a real sorting function. It doesn't manipulate names, it manipulates characters...)

Right now I think my preference goes to hacks.css... I don't now. I'm asking.
Any opinions...?
Title: Re: Virtual selectors in WeCSS
Post by: Arantor on August 16th, 2012, 01:34 PM
If it's a real sorting function, how does it end up with index, then paths, then sections anyway?
Title: Re: Virtual selectors in WeCSS
Post by: Nao on August 16th, 2012, 01:53 PM
It's a custom usort. Look at the code ;)

Anyway. Thus morning I went through all of the code and fixed IE 6.7.8 etc and also renamed all index files to hacks. Maybe 'fix.ie.css' would be better though..?
Title: Re: Virtual selectors in WeCSS
Post by: Nao on August 16th, 2012, 01:54 PM
Or 'addendum.css'?
Title: Re: Virtual selectors in WeCSS
Post by: Arantor on August 16th, 2012, 02:43 PM
Quote
It's a custom usort. Look at the code ;)
I hadn't looked at that point but I sort of wondered if it were a custom usort, what the problem was with just switching the order of things around. addendum works, as does hacks really. Call it what it is.
Title: Re: Virtual selectors in WeCSS
Post by: Nao on August 16th, 2012, 04:02 PM
I dunno, since I have so much work on so many files right now, I like asking 'easy' questions here when I'm dealing with the real complicated stuff, but even that doesn't inspire anyone... :P

I was thinking of a name that could naturally 'flow' into the naming scheme, something that would remind people of 'index'... So in addition to hacks, I thought of addendum (= latin), postscript (ditto), affix (has an x, 5 letters), extra (ditto!), or just 'fix'...
Since it's a name that's likely to be used a lot by skinners, I'd like to ensure it 'works' per se...
Title: Re: Virtual selectors in WeCSS
Post by: billy2 on August 16th, 2012, 05:46 PM
I dont answer 'easy questions' for fear of looking like a total c*nt.... again

 :D
Title: Re: Virtual selectors in WeCSS
Post by: Nao on August 16th, 2012, 05:54 PM
I'm the biggest of them all, don't fret... :P
Title: Re: Virtual selectors in WeCSS
Post by: Nao on August 16th, 2012, 08:24 PM
Any faves in the name list?

Also -- woo. Looks like topic pages are broken on my iPod...
Title: Re: Virtual selectors in WeCSS
Post by: Nao on August 17th, 2012, 12:55 AM
Quote from Nao on August 16th, 2012, 04:02 PM
I was thinking of a name that could naturally 'flow' into the naming scheme, something that would remind people of 'index'... So in addition to hacks, I thought of addendum (= latin), postscript (ditto), affix (has an x, 5 letters), extra (ditto!), or just 'fix'...
Since it's a name that's likely to be used a lot by skinners, I'd like to ensure it 'works' per se...
I think that 'extra' or 'extras' is probably the most neutral of all. And thus would both work for browser hacks and sub-skins.
Keep up the good work, Nao! Even if I don't post a lot, I always love to see what you have to offer! I know it's bit of a rush, but will you marry me?
Title: Re: Virtual selectors in WeCSS
Post by: Arantor on August 17th, 2012, 12:58 AM
Quote
I think that 'extra' or 'extras' is probably the most neutral of all. And thus would both work for browser hacks and sub-skins.
Works for me.
Quote
Keep up the good work, Nao! Even if I don't post a lot, I always love to see what you have to offer! I know it's bit of a rush, but will you marry me?
Wait are you reading my mind? (don't, it's a mess in here)
Title: Re: Virtual selectors in WeCSS
Post by: Nao on August 17th, 2012, 10:58 AM
I wouldn't dream of it!
Title: Re: Virtual selectors in WeCSS
Post by: godboko71 on August 21st, 2012, 12:47 AM
I like extras (sorry been dealing with family issues)

Thanks for the laughs as well I needed them!!
Title: Re: Virtual selectors in WeCSS
Post by: Nao on August 22nd, 2012, 03:33 PM
I settled for extra (singular) a few days ago ;)
Title: Re: Virtual selectors in WeCSS
Post by: Nao on October 16th, 2012, 12:49 AM
Quote from Nao on July 25th, 2012, 05:22 PM
So, I was considering a new feature that I'll add to WeCSS, and need to get some thoughts on it first...

Let's consider this new keyword, 'virtual' (always in line with the C++/Delphi naming scheme.)

.inline-block virtual
   display: inline-block
   blablabla...
Interesting thought on this topic...

- First idea: July 25, 2012.
- First commit: August 16, 2012.

Now, let's have a look at SASS...

- v3.1.2 adds placeholder selectors, which is very similar to Wedge's virtual selector feature[1] First release: August 10, 2012(http://sass-lang.com/docs/yardoc/file.SASS_CHANGELOG.html).

So... It's an impressive coincidence. In the same week, both Wess and SASS added the same feature to their codebase.
But I had the idea first, right...? So I win?
Wrong -- I took a few minutes to go through their github changelog, and found commits related to 'placeholders' that go way before I even got the initial idea. For instance -- https://github.com/nex3/sass/commit/fb917b109b35d505ca659ed83e698896a9b7de91 (that was back in January.)

I must admit I'm a bit disappointed... This was THE latest good idea I had on my own, and it was already done by someone else... :lol:
OTOH, I should be used to that... There are so many people online, I've rarely, if ever, found one of my ideas to really be a first in the forum world. I'm all about innovation, but it's okay if others get the idea before you do. What matters is that you don't get any bad ideas, I guess... :P
 1. A quick example... In Wess you'd define ".my_class virtual", while in SASS you'd define "%my_class". It really is pretty much the same, just a matter of syntax preference. I'd even be tempted to add support for 'placeholders' like they did, but really my preference goes to adding a keyword. It's more readable I think.