Wedge

Just wanted to say... I'm going to remove support for flex altogether. While it won't come as a surprise to you guys considering all the trouble I had with it, today I decided to search google for 'nested flexbox', which is what I'm doing in Wedge, and guess what..? The results tend to say that flexboxes are BUGGY when nested inside of each other. NO KIDDING...
Considering that browsers are "not ready" for that, then I see no reason to waste my time on it.

I quickly looked into the grid module as a replacement, as it offers full rowspan/colspan support and thus does exactly what I want, but it's only fully supported in IE10. I've read, here and there, that Chrome 27 "will" support it. However, Canary is currently at version 28, and there's still no such thing as proper support for "-webkit-grid-columns" or whatever... Also, Firefox has some -moz-grid properties, but they're for use in XUL only, so it doesn't apply to Wedge itself.

At this point, I'll just stick to the display:table layout, and after that, there are really only three solutions...
- Leave it be.
- Implement <table> tags, because I can. Not exactly responsive, though... But I can always replace the table tags with regular divs with macros for Wireless, or whatever. Wedge is powerful.
- Restore the quick JS function I wrote to harmonize cell sizes. This is the 'best' solution, but unfortunately, because it needs to load images and have 'definitive' sizes for cells before I start this, I can't run it at .ready() time, and thus have to rely on .load(), hence a very, VERY visible jump in cell size at page load time.

I don't know if it's worth doing a poll for this..? I suspect that I'm the only one who cares about cell size harmonization, or close to... (Then again, my tendency to work for days on a single minor feature no one cares about is also what gave birth to some excellent modules, such as Wess and, well, Wedge's skeleton and mini-skeleton systems...)

Fixed.
That's the thing when I have tons of files under work locally... Sometimes, I get mixed up when uploading the 'clean' revisions.
Hopefully this won't break another thing, ahah..!

Impossible... The earlier avatar code was based on SMF's, while my system class rewrite merged together $user_info['avatar'] and $context['user']['avatar'], into what is now we::$user['avatar']... However, when I did the merging, I didn't think of rewriting the lines that said !empty(we::$user['avatar']) -- because $context['user']['avatar'] COULD be entirely empty, but $user_info['avatar'] never was, so the line wouldn't work... At all! All I did to fix it, was to check for ['avatar']['image'] being empty, instead.

Anything's allowed.

Posting to ask if you can post, however, is dumb, and thus frowned upon.

At one point, I thought it depended on what board you'd post to, but in the end it didn't seem to have an influence either...
Really, the only way to reproduce for me, is to post a message, then immediately quick edit it, submit, and go back to the homepage. Then there's a chance that I'll get a 'new' icon on that topic, although not systematically.

Well, we're an SMF fork...

However, it's not completely identical -- AFAIK, SMF has a X icon you can click to remove the box... Wedge replaces that with a (still clickable) CSS-animated loading icon.You mean, like when you click an image preview in the media area............? :whistle:

I actually like both ways of doing it... I never tried implementing the media area version site wide, though, but I guess I could...

It's a chrome bug only. It started with version 25 in chrome beta. They even recognized it on their blog. So far they have yet to fix it. Can't do much on my own.
And yes this sucks... use Recent Posts to see a version that seems to remain consistent over time.