Virtual selectors in WeCSS

Nao

  • Dadman with a boy
  • Posts: 16,079
Virtual selectors in WeCSS
« 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.

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Virtual selectors in WeCSS
« Reply #1, 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?
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,079
Re: Virtual selectors in WeCSS
« Reply #2, 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... ;)

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Virtual selectors in WeCSS
« Reply #3, 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

live627

  • Should five per cent appear too small / Be thankful I don't take it all / 'Cause I'm the taxman, yeah I'm the taxman
  • Posts: 1,670
A confident man keeps quiet.whereas a frightened man keeps talking, hiding his fear.

Nao

  • Dadman with a boy
  • Posts: 16,079
Re: Virtual selectors in WeCSS
« Reply #5, 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.
Re: Virtual selectors in WeCSS
« Reply #6, 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.)
Re: Virtual selectors in WeCSS
« Reply #7, 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. :(
Re: Virtual selectors in WeCSS
« Reply #8, on August 14th, 2012, 03:15 PM »Last edited on August 14th, 2012, 05:20 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.

nolsilang

  • Lurking <i class=
  • Posts: 106
Re: Virtual selectors in WeCSS
« Reply #9, on August 14th, 2012, 03:49 PM »Last edited on August 14th, 2012, 05:20 PM by Nao
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.

spoogs

  • Posts: 417
Re: Virtual selectors in WeCSS
« Reply #10, 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:
Stick a fork in it SMF

Nao

  • Dadman with a boy
  • Posts: 16,079
Re: Virtual selectors in WeCSS
« Reply #11, 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.)
Re: Virtual selectors in WeCSS
« Reply #12, 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?

nolsilang

  • Lurking <i class=
  • Posts: 106
Re: Virtual selectors in WeCSS
« Reply #13, 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.

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Virtual selectors in WeCSS
« Reply #14, 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.