Wedge

Or 'addendum.css'?

I was talking about "Wedge - New ways..."

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:


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...?

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!Oh... Sorry about that. So it's the followup to recent weeks then..? :(

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?

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.

Then we'll have to live with people who keep bugging us about upgrade paths...

Eh.

As if it's not already enough that I have to live with internal W3C wars that force me to rewrite WeCSS for days... -_-

God why did I start work on Wedge?! Why am I heading towards an OS license when we should really be selling it for a million dollars?!