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..?!
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..?!