Wedge

rev 1956 -- woohoo, CSS love!
(3 files, 5kb)

+ Messages are now shown in a flexbox that, err... Well, you'll see by yourself. You probably won't notice if you don't read the actual CSS. I'm so happy with that. Took me the entire week to get it right. Non-supporting browsers will still get the CSS table version, or the HTML table one for IE 6-7. (sections.css)

! Fixed broken rounded corners on context menus. What..?! And the fix barely makes sense either... (index.css)

* Simplified CSS for mini-menu arrows. Arrows' horizontal positions should now be the same in either direction. Hey, it's my first use of the calc() keyword... Funny! There's a fallback, too. (index.css)

! A relatively recent update had .bbc_pre set to inline-block, and I forgot to document that in the changelog. Well, it turns out that it broke flex boxes, so I'm reverting this... And perhaps I'll find the reason why I changed it. ;) (index.css)

* Replaced brackets around page number with CSS-generated ones. Just as a prologue to whatever Pete wants to replace it with later... ;) (index.css)

* Moved two action icons to where their brothers were. This is the reason I implemented '@if member' in Wess, not that you would care, but it saves quite a few bytes. (index.member.css, sections.css)

- Removed right margin in .inner class... This dated back to the original Weaving commit (two years ago!), and I have no idea whether it was supposed to be 'cool' or just fixed something that no longer happens. (sections.css)

- Removed mini-menu overflow rules. I remember I had to keep them at some point, but was unable to reproduce an error when removing them this time. (sections.css)

And... Fixed! (Again.)

So... After I confirmed that the original 'bug' was in all 3 implementations (tested in Chrome 27 (sic), Firefox 21 and Opera 12.14), and that min-width only 'fixed' it in Chrome, I started looking elsewhere...
Turns out that Firefox and Opera not only need the min-width hack, but they also need the contents to be devoid of any inline blocks.
And it just turns out that Wedge's implementation of .bbc_pre is an inline block.
Turning it back into a regular block makes it behave correctly in all three browsers. (Removing min-height breaks it again, so I had to leave it in.)

Now, the only issue is to determine whether it's thinkable to get rid of all inline-blocks that might overflow the post box...?
It may be 'only' due to some inline-block + nowrap combination, mind you. I haven't seen any issues with other inline blocks in the post area. (Buttons, etc.)

Still... Is it 'ready for prime time'..? I don't know. I'll test with my gallery previews, too.

Nope, gallery items don't get cut off when overflowing, but apparently it's also the case in the regular CSS table style, so... I may have been wrong about that one. Same for videos... :-/
I don't know if it's best to cut them off on the side or have them overflow. I mean, it's less elegant, but it's probably more elegant than a scrollbar... I don't know.

Yes! Yes!!!! YES!!!!!!! YEEEEEEEEEEEES!!!!!!!!!!!
Fixed!! At last!

Okay, ready guys...?

.postarea
   min-width: 0

That's all it took...

Thanks to this solution posted at http://stackoverflow.com/questions/12022288/how-to-keep-a-flex-item-from-overflowing-due-to-its-text?rq=1
-- of course, finding it took me days... The closest I got before, was a tip to use 'width: 0', but it wouldn't work.
So, that's basically a hack... For a bug.

That's for the good news.

Now, the bad news: I've tested in Firefox, and the bug is just the same... Even worse, the horizontal scrollbar for the code block shows up, but it's showing like 99% of the very long line, and the code block is overflowing across the entire sidebar and even after... Now that's completely silly...

I'm not exactly back to square one, but it's not really encouraging... We're talking about a feature that's in Candidate Recommendation status, i.e. it's fully standardized, the algorithm is out, and... It's not working well.

Of course, when it comes to posting demos of the feature, I don't know if you ever looked, but authors usually just put a short place-holder like "Hello, world" in the box... This isn't exactly going to help spot any problems, like here... ::)

So... I've already spent two days on this. After implementing support for flex in Wedge, I was going to commit this, but stopped at the last minute.
I wanted it to be a surprise, but it just can't. I can't commit until it's fixed. And I can't seem to fix it... So I might as well ask for opinions.

My idea was to reset the message layout to what we had in SMF 1.1, i.e. a 100% table-like layout. In CSS, display:table works quite well, but it doesn't support rowspan and colspan. This 'oversight' was fixed by the W3C in the form of flexbox, where you can precisely force an element to take all of the available height.

All right.

So, I set display:flex on the post wrapper. This works just fine.
Then I set display:flex on the postarea class, with a width set to 100% (otherwise the child divs don't fill the postarea width, whatver!) Again, works normally... Then I'll set flex:1 on the .post class, meaning it gets priority on whatever fills the space.
As a result, the first post in the screenshot shows that the action bar is at the BOTTOM of the post, with extra space in between. This is what I wanted. I was so happy when I got to that point...

Except that right before committing, I noticed a problem with some posts. See second post in screenshot...

So, what is it due to..? Very simple. Just do "code { display: none }" or equivalent, and it starts working again.
To be clear: the post with the code block acts like if postarea was 'wrapped' on line two (flex-direction: column on the post wrapper), then it gets reset to the desired position (on the right of the poster area), but it keeps the same dimensions.
This is 'fixed' by forcing .post width to 70%, but the first post will then show a postarea that's 70% of the expected width... i.e. whatever I do, the body that contains the code block, will always be ~30% wider than the body with regular text.

I've always hated code blocks and their silly devilish implementation (WTF really?! Just look at the bbc PHP for it...), but this is not just that... Any item that would usually get overflow:hidden like a gallery preview, will now overflow:visible out of the post div, and extend their post width just the same, so that postheader overflows as well.

This is with Chrome... Even if it works in Opera 12 and Firefox 21 (haven't tested), there's no point in keeping that tech around if it's going to fuck up like this on a whim. I mean, it's actually worse than using floats at this point...

Who got this wonderful idea, already, that only tabular content should use table tags..?!

So many points here, I'm just going to focus on your last post on threaded stuff, otherwise I'll go crazy. (I'm already upset by a feature I was going to commit a few minutes ago, until I realize it was fundamentally broken because I wanted it to be as flexible as possible and it adds more complexity... -_-)

From the contents of your post, I gather you didn't know that vB 3.x did threading. Right..? Well, I thought I'd argued that threaded mode was 'not the black sheep' because vB had it in and it was still very popular... However, I didn't know that the feature had been removed in later versions. Perhaps it was, simply... Badly implemented..? Anyway, another thing I know is that I've rarely seen a vB forum use the feature by default. There's a per-user trigger for it, but I'd rather we do either one or the other (per-board), to avoid issues when attempting to read a flattened version of a threaded topic.

Threaded is useful mainly for one thing: makes it VERY easy to split a growing sub-conversation into its own topic. You don't NEED to select posts manually anymore. Which means it encourages mods to do just that.

It's also hard to follow if not done correctly... e.g. the iMDb forums always had a bit of an odd threaded layout. When you go to the next page, you can't see the parent for the first new post. This can be fixed implicitly by using infinite scrolling, which I'll try to implement soonish.

Finally, regarding multi-quote...
A few days ago, I was considering something silly, but also worthy of looking into.
Let's say I'm in a long post, and I want to immediately answer a portion of it... I would quote the post, and remove what's irrelevant. Another solution is what they do at opera.com -- you actually select the portion you want to reply to, and click Quote. It'll copy only that part in the textarea. Nice one. And finally, my idea: you select that portion, and immediately a "reply" or "quote" button comes up NEXT to your mouse cursor, i.e. floating in the page, and you can click it, and then a small textarea opens up RIGHT below the quoted portion, and you can reply to it... Then you can quote another portion of the same message and reply to it, but I don't know if we should "wait" for the page to be left before our sent content is actually posted (together), or if all portions should be sent separately and then automatically merged if they're detected to be from the same message (i.e. a simple post auto-merge...). I just don't know.
Another issue is with touch devices: selecting isn't easy on them. I was thinking something along the lines of just touching the paragraph, and then it would show a Quote button (if not touching something clikable..), which if pressed, would retrieve the entire paragraph. Not pretty, but... (could also be applied to desktop version if nothing is selected by the time mouseUp is triggered.)

Oh, and of course the usual issue of finding new unread posts in a threaded topic... Which can either be done through a flattened view (meh), or just a flattened view of the new posts only, or collapsing all read posts and just showing, in context, the unread ones. (That would make the most sense to me. I don't know if any implementation has ever done that.)

Okay, time for bed... :-/

rev 1954
(15 files, 6kb)

* Reviewed all {string:}'s in the source code (by this point, you already know I'm a bit crazy), and turned all relevant ones to literals. Also more naoisms not worthy of any mention. (ManageBoards.php, ManageErrors.php, ManageMaintenance.php, ManagePaid.php, Aeva-Gallery2.php, Aeva-ModCP.php, ManageMedia.php, Subs-Media.php, Memberlist.php, Reminder.php, Subs-Members.php, Subs-Post.php, Subs-PrettyUrls.php, Themes.php, UnreadReplies.php)

I think that what Pete forgot to tell you, is that (1) we never distributed the import tool to begin with, because (2) right now it's an *alpha*, not beta, and that as such, there's little to no chance we'll accept to see it run live on another website than this one.

Really -- keeping Wedge up to date here already takes me a lot of time -- and I'm one of the developers! Back in the day, when I was just an SMF user, I left most of my forums at version 1.x because the 2.0 converter wouldn't work on them or I'd simply made too many custom edits to make it easily upgradable. I think that when it goes public, Wedge will have gone through more internal changes that make it harder to keep up.
Of course, the goal in Wedge is to avoid all file edits. I've written a complicated system to ensure that users can easily mod the CSS, some HTML, etc, without any file changes. But there are casual users who'll follow the Wedge releases and not do any custom edits (ideal situation for us), and hardcore users who'll do what they want.
We don't want casual users for alpha testing. Maybe for beta testing.
We don't want hardcore users to run a live forum, precisely because of the live edits they'll end up doing, and thus the increasing difficulty of updating to the latest and greatest versions.

All in all... I don't want you to think you can suddenly switch to Wedge overnight.
No, you can't. I'm sorry about that. I know that I wanted us to go public back in 2011 already... We aren't paid for the job, it's a full-time one, and we can't really see an end to it all. Every year we're postponing to the next. I'm confident we can release a final in 2013, but certainly not before another six months.