Wedge

rev 1962 -- can_flex, E_STRICT, Firefox OS basic support.
(7 files, 9kb)

! Wess can't actually hold a list of browser UAs in a variable and allow you to do a test on it. It's a technical limitation. I could overcome it, but I don't see many situations where it would be helpful other than testing for a particular feature repeatedly, so I decided to implement constants to do just that. 'can_flex' is the one you want for the latest flex box model support, it replaces '$supports_flex' and that's all I have to say... Also, this has the advantage of allowing you to just do '!can_flex', without bothering about brackets. I also added support for the older flex models, which I'm not using. Currently, these constants are case-sensitive, in order to save time. I don't know what's best. It's something I'm saying a lot, these days... (Class-CSS.php, common.css, sections.css)

* Since E_STRICT is a PHP 5 constant, it no longer needs to be tested against... There's another one in Errors.php but I'm not committing this one for now because I'm working on the cleanest solution for it. Basically, SMF/Wedge skips all strict errors unless a hidden setting is enabled. Also, the end of the function is quite folkloric, dare I say hilarious, at least it made me laugh, so it shall be deleted entirely. (Elk, if you're listening....) (index.php, SSI.php)

! Fixed strict error: wetem static method calls. I don't know why I insisted on extending wetem from weSkeleton, it really wasn't needed. (Class-Skeleton.php)

! Fixed strict error: weSkeleton->render_recursive() doesn't accept non-variables as parameters. I benchmarked against the alternative (removing the pass-by-ref), and performance was similar, but often a tad faster in pass-by-ref mode, so I left it that way and just assigned variables. Anyone interested in doing more benchmarks in a different environment..? I can't wait to find a reason to get rid of all my unused references. Finally, weSkeleton is back to being a final class... If you have any reason for it to be extendable, just discuss it with me! (Class-Skeleton.php)

+ Added support for Firefox OS. Tested with both the G2B Desktop Client and the simulator bundled as a Firefox add-on. The former won't work because currently it provides the host OS in its user agent, instead of their own. The latter will work fine, though, it uses the official UA. (Class-System.php)

Yup, it's a well-known article...
Fact is, even though the old Firefox bug mentioned is similar to mine, it really was only in the old flexbox specification, and they simply dropped the bug (didn't fix it) because they've rewritten the entire thing for the new flexbox specification anyway, the one I'm using in Wedge...

Okay, so it's not fixed, but at least I know why...

The reason is the internals of my @if implementation... It's a bit complicated, but it was pretty much mandatory for me because I wanted to be able to use variables in mixins, and it didn't work otherwise. The specifics are that @if calls are parsed twice. The first pass is for browser tests (@if chrome[20-], opera...), while the second (which occurs later in the CSS compilation process), is for variable tests (@if $bg_color == #fff). I didn't take into account the possibility of using a variable to store indirect helpers.

So, what I did is 'simply' add a test in the variable parser, to ensure that it held at least one "$" in the string. If it doesn't, return false. And this magically fixes everything... Then again, it doesn't actually fixes much, because at THAT point, I remembered there's no $ in the string anyway. They're all transformed, i.e. the second @if pass actually tests for "@if #fff == #fff" of "@if #000 != #fff"...
This means that I could fix this all by searching for one of the comparison operators, i.e. "==", "!=", "<" and ">", which (thankfully?), aren't supported in browser tests (it supports "!", "&"/"&&", bracket grouping and "," which is an equivalent for "or").
But it also means that if someone looks at my CSS, finds "@if !($supports_flex)" and decides that it's in their right to use @if !($my_random_variable), they'll start bugging me because it doesn't work, and they won't understand why they should be doing "@if $my_random_variable == 0" or something...

I'm afraid my "system" is a bit too smart for its own good.
Perhaps I should be using another variable declaration scheme to clearly differentiate between browser variables and generic variables.
That, or I should simply give up on storing a browser list in $supports_flex, and instead add a constant (like 'member' and 'guest') to the browser test suite, that tests for flexbox support. i.e., "@if supports_flex"...

Something like a list of browser features that can't be detected through CSS and can be useful to regular themers.
can_flex = chrome[20-], ...
can_table = !ie[-7]
Things like that...

What do you think, guys...? And if you think it's the best compromise, can we settle on a constant structure (can_, supports_, browser_, browser_can...? Lowercase? Uppercase?), and a list of features that we should allow testing against..?
I'm a little lost, myself.

Okay, spotted where the problem is... It's in how I parse Wess. It's not due to the CSS itself.
I'm going to work on fixing the bug right now.

Does this bug also happen in SMF..?

What's happening is that the redirection is incorrectly handled. I'll look into simplifying it.

Fixed ;)

Can't believe you reported it a year ago... ;(

Fixed.

And I dropped my s3 on concrete while testing. YAY.

Screen gets new big scratch in the middle. All four corners are fucked up.
I miss good old cheap phones that you could drop every day.