Wedge

Re: output buffers, nothing really surprising... I'll admit I was stumped at first, but then I remembered; ob_sessrewrite is only called at the start of the templating session (long after most of the PHP has been executed), meaning that it shouldn't be called at all if you're doing exit(), rather than obExit().
So, technically, I guess I could do without the ob_end_clean() calls... What mattered to me was not saving the cost of gzipping a few bytes (it's probably nearly free), but of running ob_sessrewrite on them, which would be potentially most costly.

I've double-checked other areas in Wedge that call ob_end_clean(), and they don't seem to generate any errors, so I'm *guessing* this is due to some codepath executed when in Ajax mode. The only two places where I get a crash, are in notification unread count, and thought retrieval. The first one probably generated the bug I mentioned yesterday (that the unread count cache wasn't invalidated when the number was changed), while the second never happened to me in the course of my testings, because thoughts are only ajaxively retrieved when they're not pure text (e.g. have a HTML tag in their rendition.)

I'm not going to delve too deep into this; just going to say I'm sorry for wasting your time with this, and just delete the ob_end_clean line...

I'm just wondering if that call to clean_ouput() REALLY is that necessary... After all, all it does is reset the output buffers. But at this point in the code, we haven't even started dealing with them in a proper fashion -- ob_sessrewrite isn't added to the output buffer list yet. Heck, suddenly it strikes me... Maybe it's going to run ob_sessrewrite twice instead..??!!
Just let me check... Nope, nope, I was a bit confused.
- clean_output() changes the output buffer list from "default, gzip" to "default" then to "default, gzip, ob_sessrewrite".[nb]Which is a problem, technically... It assumes that gzip is the only extra handler at this point. It should be doing the while() call, and then the rest..? I think. Warrants looking into.
- obExit() adds ob_sesswrite then shows the skeleton, but obExit(false) simply goes through obExit but skips both $do_start and $do_finish code-blocks, effectively NOT adding ob_sessrewrite to the list...
- so, technically, I could get away with just calling clean_output() and not calling obExit(false), so that Wedge doesn't execute the side-functions like sending mail or tracking stats... I guess, it would make more sense.

Well, what a complicated mess. To my defense, when I wrote the return_* function, I mainly copied-pasted code from somewhere else in our codebase, then tested it, and as it worked... Didn't really bother to see the magic it did. (Or needed to do.)

Did you have a look at my magical one-line CSS code for the popup animation? ;)

As for your OP, I'm fine with the styling of everything. I can always tweak it a bit later if you want. I shall also have a look at the padding issue! Tomorrow, hopefully...

Wouldn't expect anyone to!

Just a few comments...

- Tablets use Weaving by default, anyway. If you end up being served Wireless on a tablet, please tell me the name of your tablet, and I'll fix it.
- While it's technically possible to have a regular Wireless and a bandwidth-conscious Wireless, it'd be a mess to implement. What Wireless does is test SKIN_MOBILE inside the Weaving templates (it's set to 1 in Wireless, and 0 in other skins), and redo the templates based on this -- such as, using only one column for some tables along with simple line breaks, instead of multiple columns, so that it renders more naturally in a horizontally-challenged device; so, yes, it removes some HTML here and there, but it doesn't remove any features. Doing that would beat its purpose, which is to make a responsive skin with the same amount of features as the others. In order to make an extra level of bandwidth consciousness, I'd have to add some new constant, like SKIN_MOBILE_DATA or SKIN_MOBILE_NOWIFI, and do even more tests in the template for this. It's doable, once again, but it just feels overcomplicated, and I don't really imagine other themers using that. Of course, considering that my plan is to entice people into doing skins rather than full-fledged themes, it might still be possible to do it.
- I can't determine your current bandwidth, except vaguely with JavaScript, meaning I can't redirect you to some skin or the other based on your bandwidth in a very predictable manner. This means that you'd have to manually select the bandwidth-optimized version, and it doesn't feel very natural. Wedge is cool in that it automatically presents you either the desktop, or the mobile version, for your comfort. (e.g. if you're a guest visiting a forum for the first time, you're more likely to stay on it if it's adapted to your current device.)

I just don't feel like removing so many stuff "by default" without requiring an extra effort from the user, and I don't see much of a point in trimming down our HTML when it's already much, MUCH lighter than any competitor's equivalent HTML.

The only thing I can realistically do, is ensure that mobile devices have a good-looking skin for them, and even that isn't always easy to do.

rev 2078
(2 files, 5kb)

+ Another one of my hobbies... I've had this running literally for weeks on my local install, with no discernable issues, so I'm assuming my regex and general code is flawless. Implemented :matches pseudo-selector in Wess, in a way that you don't have to do it yourself, instead it will group your elements as efficiently as it can (it's far from perfect, but really, it's better than nothing), and only on browsers that support it, meaning mostly Firefox and Chrome, as usual. This doesn't save a lot, I'm afraid... But still, it's something like 100 or 200 bytes on the main CSS file, gzipped, and it's basically free, except for the processing at cache time, so there you go. (Subs-Cache.php)

! Oops, committed some debug styles, it seems... (index.css)

@ And there we are, most of my code is now committed. There are still a few things here and there, but I've got only 12 outstanding files left to commit (mostly changes that will never make it because I'm not sure about them), which is very, very little by my standards. Yay, now I can have a look at my to-do list again, ah ah... It's never going to end, I think... ;)

Let's just imagine you're editing a thought, and then you realize you're better off WITHOUT the thought at all, as it makes you silly... Sometimes, your first reaction will be to just erase the thought and submit. Earlier, it wouldn't work. ;)

rev 2076 -- had these optimizations around for some time, figured it'd be okay to commit them...
(4 files +32 image manipulations, 58kb)

! New thoughts could be empty, which is wrong. This is due to the latest rewrites, in which I added the ability to delete one's existing thoughts by editing them to nothingness, rather than using the Delete button. (Ajax.php)

* Optimized some image file sizes. Some of them were integrated into the CSS files, saving close to 200 bytes. Others aren't integrated, but that shouldn't excuse some of the (sometimes already optimized) files from being 100 to 300 bytes larger than they could be. Also of note, warning_mute doesn't seem to be used anywhere, but I'm not removing it because it might be hidden in some variable like $context['warning_status'].gif or something. I'll leave it up to Pete. (16 files in the attic, 16 in /images, including board status icons, warning icons, and Wedge footer logos.)

* I'm not convinced that warning icons should be integrated into the CSS. The only 'visible' difference between integrated and non-integrated is the extra HTTP hit, and I'm not sure warnings are a feature that is supposed to seen on every page... Is it? So I'm adding the no-base64 keyword to them, but it can always be reverted. (index.member.css)

* Admin intro could use some extra margin, I think. (mana.css)

* Translation. Eh... Sounds like a cool new feature for Wedge... ;) (ManagePosts.french.php)