Wedge

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.

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?
So... What happened? I did notice you weren't there ;)

I like that syntax structure, and I'd keep the square brackets to be honest.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.

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

That is, unfortunately, that nature of the beast.Yup.

Sorry to hear that man, seems you just can't catch a break eh :sob:

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

If it's a real sorting function, how does it end up with index, then paths, then sections anyway?

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.

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

I dont answer 'easy questions' for fear of looking like a total c*nt.... again

 :D

I'm the biggest of them all, don't fret... :P