Wedge

rev 1648
(5 files, 4kb)

+ Added an internal rgb2hex function in WeCSS. It makes it easier to return a #rgb value for CSS while compressing it if possible (#fc9 instead of #ffcc99). (Class-CSS.php)

! It is with great sadness that I'm hereby forced to allow selectors to start with a digit, while it conflicts with the basics of CSS. It's not my fault that they allow these for @-keyframes declarations. (Class-CSS.php)

+ Added support for the 'fr' value (fraction) in the math() function. I doubt anyone will ever need to use math(2fr * 3fr), but whatever! (Class-CSS.php)

! Partially reverted rev 1143's IE9 fixes for gradients. While it did fix gradients, it also completely deleted rgba() declarations from IE9 files. The new fix should be the best of both worlds... (Class-CSS.php)

* Renamed signature_minposts language string to signature_needs_posts, to avoid conflicts in the admin search. (Profile-Modify.php, Profile.language.php)

! Fixed title icon alignment in Recent page. (Recent.template.php)

You mean, per-board templating...? i.e. load the list of boards, then for each board, determine type, and load the correspond template block. Render. Rinse and repeat.
Yup...As you may remember, I rewrote the templating system for Wedge last year or so. What Wedge supports now is a skeleton where you determine a list of blocks to load from the available templates. You can load multiple templates (as long as you use different function names of course), so it's very easy to have a MessageIndex.template.php file with a function template_type_blog() and a function template_type_board(), which is pretty much how we do it already...
We have yet to delve[1] further into it, it's pretty much done for per-page templating, but it's very much doable for per-board (or per-topic) templating as well... Which, of course, we'll eventually do.

1.	Always thought it was spelled 'dwelve'...

Err... Yes?

Should be good now...

I'd really appreciate being given a clear test case for this... ;)

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... ;)

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.