So... Regarding @if statements.
Right now, if you didn't follow, there are two things you can do with them:
- Test for a variable's value.
@if $my_variable <= 7
do_this
@else
do that
@endif
- Test for a browser. (It's also more flexible, can be done anywhere.)
@if ie[7-8], opera
do this
@endif
Meaning "If browser is Opera or IE7 or IE8". The syntax is the same as in CSS file suffixes, e.g. "index.ie[7-8],opera.css" in the case above.
So... As usual when I'm a bit lost when resuming work on Wedge, I'm working on 'easy' stuff that I'm very familiar with, currently being the Wedge logo (yes, I've got something else in the works...) and this particular area of Wess.
These are the three additions I made to user agent tests, and I need some suggestions to help with them.
1/ Negative statements, i.e. @if (!ie[7-]) means "If browser is not IE 7 or above". (Parenthesis can be ommitted, of course.)
2/ OS, i.e. @if (win[6.1-]) meaning "if user is running Windows 7 or later".
3/ Logical AND, i.e. @if (opera, chrome && !android), meaning "if browser is Opera, or it's Chrome but not running in Android".
Pretty nice uh...?
Okay, the OS thing is due to two things.
- I've always been bugged by the fact that Wess stores some browsers per OS, like the fact that Safari Mobile's version number is actually the iOS version number because iOS doesn't allow for a different browser engine than Safari Mobile and thus any browser is locked to the OS version.
- There are some cases where a browser will behave differently in two different OSes, usually due to bugs. I like having the ability to specify browser and OS versions.
Okay, so here are my problems...
0/ First of all, with number zero... I know, 'semantics'... As if it's not 'right' to do browser sniffing. But until we're in a perfect universe where all browsers are perfectly compatible and follow standards etc etc, it's going to be a non-issue to me. People who are against browser sniffing and who say that to others have absolutely no idea how much time they're going to take away from them. IE6 being an obvious example... Wess makes it easy to add quick hacks to IE without hurting other browsers. Screw semantics here, they're just a twisted invention.
1/ I don't know what OS versions I should store... Windows is a given, iOS too (see above), Android as well. But what about the rest...? Are there any OSes, mobile or not, that are famous for requiring tweaks to one or more browsers running in them...? Because if I'm only storing Windows, iOS and Android, at least I don't have to create separate CSS files for each obscure OS like Bada or SunOS or whatever.
2/ Linux: should I store this..? If yes, a generic 'linux' entry? And what about the version number? Maybe no OS version at all, given the mess that it is? And I don't think Linux kernel versions have any influence over the browsers...
3/ Is it any actually necessary to store the OS version in the filename every time...? I was thinking of something a bit complex but that could save some space on the hard drive... Let's say we have a @if (win/windows) test in a file. Wess analyzes this, determines whether we're running Windows, and if yes, it tells the cache manager that we have a special behavior for 'windows'. Thus, the cache manager adds a 'windows-6.1' (or whatever version) keyword to the current file. Otherwise, no special keyword. At cache load time, Wess tries to load the 'windows-6.1' version. If it doesn't exist, it tries to load a version without the 'windows-6.1' keyword. Main problems is, I can already smell a really complex implementation (even if I'm up to it, it might be a failure in terms of performance or comprehensiveness in the end...)
4/ Or we could just store the 'main' version numbers, such as Windows shouldn't bother with anything below XP (5), then store only Vista versions (6) for anything above it because I'm not sure 7 or 8 have any significant differences in how they render stuff. Well, I'm mostly thinking of Vista adding things like Segoe UI Light and C fonts by default, or having support (IIRC) for Direct2D rendering in IE9, thus making it a no-brainer to use the ClearType-enabled fonts by default in a skin when instead it's probably wiser to just ommit them from the font stack in XP.
See what I mean...?
I'm just trying to make things 'right' and avoid having more cache files than necessary...
Re: negative statements, it was an annoying implementation, but it seems to be working. It adds quite a lot of lines though... AND statements were easier to add. And funnier, because I'm doing recursive calls for the AND lists. As I said -- fun. Not sure it's going to be liked widely, though... ;)
