Wedge

Public area => The Pub => Features => Topic started by: Nao on July 24th, 2013, 11:07 AM

Title: Soft merging of posts
Post by: Nao on July 24th, 2013, 11:07 AM
Better temperatures here today, so I figured I could get more work done on Wedge...

In terms of innovations, I'm not particularly fond of trying to figure out new ones, but I have to say it feels good to do things that I haven't seen done elsewhere, and I'm trying not to get stopped by 'reality', and do things my own way.

So, one of the things that have always bothered me, is merging of double-posts. It's a feature I've loved since day one (as you may remember from my stint on the 'Merge double posts' mod on sm.org, and generally adding the same feature in here by default), but that was in contradiction with another feature I wanted in: threaded view.

The trouble with threadles

Threaded view, as controversial it is, as 'outdated' it might be to some (and I'm not saying it isn't), implies that if you answer every single post in a thread, you'll end up with a lot of double posts, but if you start merging them, you'll end up with a long post that loses its association to the thread parents, and that is, if you'll forgive me, absolutely FUCKED UP.

I started considering doing a 'soft' merging of these posts, i.e.: the posts are not physically merged in the database, and instead they're only merged in the template if there are two or more posts by a same user in the same level.

Skeletons in the closet

Here's where it gets complicated. Ever since I introduced mini-skeletons for topic posts, it became harder to do anything like rendering only parts of a post. I made a modification to the skeleton class, where you could specifically ask it to render just a single layer from a skeleton, and I still have that code around (uncommitted), but it was getting too complex, even for me, and I wrote the whole damn thing... Essentially, it's too fragile.

I'm still considering doing it this way, though, because it's so 'clean'. But the code changes, alas, wouldn't be... So, this morning, I figured I'd try doing it with my favorite little hobby...

Ne vous déplaise, en dansant la Javanaise... ♫

And it worked. I wrote 10 lines of JavaScript, about 370 unminified bytes, and it does exactly what I wanted.
Actually, I even tested it on wedge.org, so you can get a feel of it...

http://wedge.org/pub/feats/6108/new-revs/2160/

As you can see, all of the double posts are now merged into one, and they all retain their respective action bars. Really, it's just all about removing the duplicate signature and user box areas.

It takes one to know one.

There are a few caveats to this technique, and I'm weary of committing my code, so here's the list of problems, and possible fixes, and I'd really, REALLY appreciate if you guys could share your feelings about this implementation, and whether it's worth it.

- Since it executes at render time, you can for a very short time see the unmodified posts. I've fixed this by putting the code into the script.js file, instead of topic.js, as it executes earlier, but it's not exactly a noticeable improvement, so I'll probably end up putting it back into topic.js later, and anyway, if you don't actually refresh the page, it's unlikely you'll notice the difference when simply browsing through pages, which is what you'll be doing most of the time, anyway.

- This doesn't fix postbg/postbg2 alternance. Well, I'll fix that one next... But, more importantly, because it's JS, it means that if you do alternances differently (or not at all) in your version, it'll be broken by my upcoming fix.

- Anchor links are broken. e.g., if you're in a soft-merged post, and you click the subject, you'll end up on the same page, but at the top, because it won't find the message ID, which was suppressed by JS. A possible fix would be to just move the message ID to the postheader for the corresponding soft-merged post, but it'll also break any code that accesses .root and then gets the message ID through this. Very, very bad idea either way... I need to fix this one, ASAP.

- I haven't tested all action menu options, maybe some will be broken, potentially by the change just above this one.

So... Thoughts, please..? Or just Likes :P
Title: Re: Soft merging of posts
Post by: Aaron on July 24th, 2013, 12:27 PM
Love the idea! I have to wonder, though, why tackle this with JavaScript at all? It seems like something that can easily be handled in the topic template instead — which also makes solving the issues you list much easier.
Title: Re: Soft merging of posts
Post by: Nao on July 24th, 2013, 12:38 PM
Quote from Aaron on July 24th, 2013, 12:27 PM
Love the idea! I have to wonder, though, why tackle this with JavaScript at all? It seems like something that can easily be handled in the topic template instead — which also makes solving the issues you list much easier.
As I explained in 'Skeleton in the closet', Wedge's mini-skeleton system, while VERY flexible, is built for show its skeletons one by one... Obviously. As in Wedge, a message has its own skeleton[1], it would force me to 'disrupt' the skeleton rendering flow in the middle, which is both going to make the process slower, and in total contradiction with the philosophy of the very system I built... :-/ (which is, basically: give as much flexibility to third-party devs, but within the bounds of a normal flow.)

Oh, which makes me think, I forgot to mention one of the issues:

- If you build a theme that doesn't use the same structure for the message mini-skeleton, at all, then you're screwed... Maybe I'd have to add an optional global var, declared in index.template.php, saying "dont_soft_merge", or something... Then it'd be okay. Except if a plugin starts moving layers around, of course... But then it never ends, eh..? And it can always add the variable manually, too.

Regarding doing it all in PHP, I think that it's still doable, but perhaps instead at ob_sessrewrite time, and it wouldn't be very easy to manipulate the DOM at this point, so... I'm not thrilled with the idea.
Any ideas are welcome, of course.
 1. If you're not aware of what a mini-skeleton is, I'll advise you to REALLY, really read about them. There's a topic about them. I'll try to document them properly in the future, but it's something I spent weeks on, so I kinda assume that anyone interested in Wedge, had already read it by that point... ;) But I'm not sure whether you'd rather follow Wedge or ElkArte these days, so I'm going to assume you left the project months ago and only came back today to check it out, or something.
Title: Re: Soft merging of posts
Post by: Arantor on July 24th, 2013, 05:47 PM
When I first saw it in one of the other topics, I was like... is that a bug? It's neat, and yes, threaded does pretty much demand not physically merging. (Though I still don't see how we fix the various UX issues with threaded even if the technical implementation isn't a killer. Show me a site that actually does it well... Reddit doesn't count because it looks and acts like a mess, sorry.)

I like what you've done, once I realised it was supposed to be like that ;) Doing it at JS time is an interesting solution and does generally make it cleaner on all levels (knowing the skeleton stuff etc.) though I can argue there is a usability issue if you have a run of posts from one person, e.g. like in New Revs, and the user info is way way way back up... though that's largely true for all long posts anyway.

And yes, tampering with it at the skeleton level would be incredibly messy, though I daresay it would be possible. I would expect it to become very convoluted if so done, and it's already got a little bit of a barrier to entry for modders (though once they get round the idea of skeletons and miniskeletons, which they'll have to for pretty much any plugin, it's not so much a big dea), so making it more complex is not a good idea.

I do wonder what will happen if themes (which modify templates, rather than skins which just modify CSS) come along and change that up. Perhaps the variable is a good idea so that a theme can indicate it as such.
Title: Re: Soft merging of posts
Post by: Nao on July 24th, 2013, 06:50 PM
Quote from Arantor on July 24th, 2013, 05:47 PM
When I first saw it in one of the other topics, I was like... is that a bug? It's neat, and yes, threaded does pretty much demand not physically merging. (Though I still don't see how we fix the various UX issues with threaded even if the technical implementation isn't a killer. Show me a site that actually does it well... Reddit doesn't count because it looks and acts like a mess, sorry.)
It's not that I absolutely WANT to make a threaded view absolutely... It's that I believe it might be helpful to some people, and it's not that hard to implement. I'm more curious about whether I should add a 'limit' to the threading level, e.g. stackoverflow has a limit of one level of replies after a comment, which makes a lot of sense, if you'll allow me. (The guy even documented this conscious choice on his blog, and I agree with it... Though I think it shouldn't be hardcoded, really.)
Quote
I like what you've done, once I realised it was supposed to be like that ;) Doing it at JS time is an interesting solution and does generally make it cleaner on all levels (knowing the skeleton stuff etc.) though I can argue there is a usability issue if you have a run of posts from one person, e.g. like in New Revs, and the user info is way way way back up... though that's largely true for all long posts anyway.
Yeah... There are always going to be a few usability issues, but this one could be solved in a bold way, by making the user info box fixed when you're scrolling... A bit like the sidebar contents, but in real time. Of course, this creates an issue in that we then need to have a .scroll() event, and calculate our page position, and the position of all user boxes on each scroll, which is, err... Probably a bit costly, I guess..?
Quote
And yes, tampering with it at the skeleton level would be incredibly messy, though I daresay it would be possible.
I said it-- it's possible. It's just plain ugly.
I've been trying to find a non-ugly solution, but it always involves manipulating the DOM after the render phase, and... It's something I'm not too keen trying to do, eh.
Quote
I would expect it to become very convoluted if so done, and it's already got a little bit of a barrier to entry for modders (though once they get round the idea of skeletons and miniskeletons, which they'll have to for pretty much any plugin, it's not so much a big dea),
I'm expecting 99% of all mini-skeleton uses will be in the main codebase, anyway... Plugins and themes, lemme guess... Will simply expand upon the existing ones, eh.
Quote
so making it more complex is not a good idea.
So, no need to commit my 'render only this layer' portion of the skeleton code, I suppose..?
Quote
I do wonder what will happen if themes (which modify templates, rather than skins which just modify CSS) come along and change that up. Perhaps the variable is a good idea so that a theme can indicate it as such.
That's the idea.

Oh, I implemented the postbg toggler, and it creates yet another problem, ah ah... If you infinite-scroll the page, nothing says the new page will start with the same, alternate postbg. Also, obviously, soft merging doesn't happen. I'll have to put this all into a new function, and call it at infinite time, like I do for breakLinks, IIRC...
Title: Re: Soft merging of posts
Post by: Arantor on July 25th, 2013, 07:17 AM
The thing about Stack Overflow and similar Q&A is that most people still manage to screw it up and post new messages rather than replying to things as they wanted to do, and the whole system gets screwed up as a result.

I'd be inclined not to have 'render just this layer' thing if possible... no need to get *too* complex with it. There is a level of functionality we need, and pretty much we have that. Anything else we'll add when we need it.

As for the alternation fixing, the solution to that would be to call the next page of results as not already-prerendered and then add it at post time, e.g. bring it from the server in JSON or a similar wrapper and have the wrapper be expanded to include classes in the client.
Title: Re: Soft merging of posts
Post by: Nao on July 25th, 2013, 11:08 PM
Quote from Arantor on July 25th, 2013, 07:17 AM
The thing about Stack Overflow and similar Q&A is that most people still manage to screw it up and post new messages rather than replying to things as they wanted to do, and the whole system gets screwed up as a result.
Never underestimate the average user's ability to screw up a perfectly logical interface ;)
Quote
I'd be inclined not to have 'render just this layer' thing if possible... no need to get *too* complex with it. There is a level of functionality we need, and pretty much we have that. Anything else we'll add when we need it.
I think that since it's basically a free addition (only adds a few instructions, once per skeleton rendition), it could be used for other things, for instance, creating a 'fake' mini-skeleton with multiple layers that follow each other, and then you simply call the layer to be rendered, multiple times, or just once. It could, err... "make sense", I guess.
Quote
As for the alternation fixing, the solution to that would be to call the next page of results as not already-prerendered and then add it at post time, e.g. bring it from the server in JSON or a similar wrapper and have the wrapper be expanded to include classes in the client.
Nah, because it wouldn't be possible to merge the posts with the previous page's.

Anyway, I've done it... Quite simply, I changed the infinite scroller to call a soft merge on all posts (including the old ones), every time a new series of posts is added. I simply had to add a .not() filter to ensure that sub-posts (inside a soft-merged post) weren't touched by the thing, because then it would return a user ID of 0 for these... (OTOH, I could simply tell Wedge to 'skip' an item if it has no user ID, but whatever, I think the filter will be faster, so let's do that...)

TL:DR, infinite scrolling + soft-merging is working now.
Title: Re: Soft merging of posts
Post by: Arantor on July 26th, 2013, 05:14 AM
That's precisely my point. SO has a simple enough interface and yet it's screwed up, especially by theoretically technically minded users. Now multiply that by the lowest common denominator of forum posters and boom. Even FB gets badly messed up by it with its very limited notions of it.

It's not so much the whole thing of being free vs not free, it's a user (mod author) usability issue. The more things people can do, the more complex troubleshooting becomes - bear in mind we will not only be supporting the core code but also supporting plugin authors trying to do things too.
Title: Re: Soft merging of posts
Post by: Auk on July 26th, 2013, 09:13 AM
I thought this feature got added a long time ago. I noticed it while reading the commits to this project.

With that said, I like where this is going. At least the threaded view of things, even though it might break the traditional forum topic appearance. A reply to a reply should appear as a new message. A threaded reply to a reply would kinda get funny to those not used to viewing threaded discussions. I've seen on some websites. Just doesn't appear too elegant.

I like how youtube does it. You can see all the messages,  and a reply to a reply are clasped, but you can still see their messages as a New message being replied to another commenter.
Title: Re: Soft merging of posts
Post by: Nao on July 26th, 2013, 08:05 PM
@Auk> I *especially* don't like YT's implementation of it... ;) Too confusing.
Quote from Arantor on July 26th, 2013, 05:14 AM
It's not so much the whole thing of being free vs not free, it's a user (mod author) usability issue. The more things people can do, the more complex troubleshooting becomes - bear in mind we will not only be supporting the core code but also supporting plugin authors trying to do things too.
Re: threading, I think that people are 'aware' of how it works, if anything billions of blogs (more or less........ ::)) are using Disqus for comments, for instance.

Anyway, I just discovered another issue... Argh.
"new" anchors don't get taken into account. So, I changed the HTML to output these into the postheader, and it would work, only... It seems that because the anchor is being moved by JS, Chrome no longer gives a damn about it, and it just won't lead me to any post, and as I said: argh... :-/

Well, I guess I'll have to take into account the possibility of doing it in ob_sessrewrite, right..?
Title: Re: Soft merging of posts
Post by: Nao on July 26th, 2013, 11:05 PM
I've reverted my anchor changes, so the 'new' links should be working again. (Except when the latest unread post is a double-post, like this one.)

I'm working, in parallel, on a PHP-only implementation of my JavaScript code.
I've decided that it should be much, much faster to do the changes on the buffer, if I use macros inside the msg skeleton, so this is exactly what I'm doing, and it has two advantages:
- easy to find individual messages, and thus merge them, if possible;
- since you can redefine macros in skins, I can (finally!) modify Wireless to remove some blocks of code entirely, instead of just hiding them. It's not a guarantee though, but at least I should be able to move all of the "if (MOBILE)" code away from PHP, and to macros, e.g. you can conditionally define a macro to be empty on 'mobile', or even more selectively, e.g. 'android[-3.9], ios[-5.2]', etc...

Isn't that exciting...? ;)
(What do you mean, "no it'll be even more complicated"..?!)

Still, I'm torn between keeping the macro definitions as they are, in index.template.php, or moving them all to skin.xml, just like I got rid of the skeleton definition in index to move it to skeleton.xml, but the latter case was done because it wasn't any different in terms of performance, while it'll be a bit slower in the case of a skin.xml macro definition.

I'll look into that tomorrow, I guess...
Title: Re: Soft merging of posts
Post by: Nao on July 27th, 2013, 02:26 PM
Quote
- since you can redefine macros in skins, I can (finally!) modify Wireless to remove some blocks of code entirely, instead of just hiding them.
Hmm, actually I just realized that I already went through this... Dunno why I forgot it, but it seemed like it was only recently, that Pete complained about Wireless still holding the HTML for most things, or something..?
There are multiple ways to remove code for a skin:
- hardcode the change into the template file (meaning it's not up to the skin, of course...)
- hardcode it into skeleton.xml (IIRC it supports either MOBILE_SKIN (i.e. the skin has a 'mobile' flag), or a browser string),
- hardcode it into the macros, like I'm doing now.
Quote
Still, I'm torn between keeping the macro definitions as they are, in index.template.php, or moving them all to skin.xml, just like I got rid of the skeleton definition in index to move it to skeleton.xml, but the latter case was done because it wasn't any different in terms of performance, while it'll be a bit slower in the case of a skin.xml macro definition.
I'll be going to the xml route, because I made some tests, and even with 60 custom macros, it takes no more than half a millisecond to parse them all, so it should be all right, no..? (Even if it isn't, I could just as well cache these for the next X minutes, etc.)
Title: Re: Soft merging of posts
Post by: Arantor on July 28th, 2013, 03:05 AM
I really need to study the code to get a feel for this myself but from a plugin point of view, provided that adding new items to the userbox is just a case of using the existing skeleton and that adding stuff like menu buttons can still be done with the menu arrays (though, frankly, I'd kind of like internal helper functions because it's... complicated), it's probably all good.
Title: Re: Soft merging of posts
Post by: live627 on July 28th, 2013, 03:40 AM
Quote from Arantor on July 28th, 2013, 03:05 AM
I really need to study the code to get a feel for this myself but from a plugin point of view, provided that adding new items to the userbox is just a case of using the existing skeleton and that adding stuff like menu buttons can still be done with the menu arrays (though, frankly, I'd kind of like internal helper functions because it's... complicated), it's probably all good.
it won''t work, because the call to the skeleton is in the template, and isn't grabbable through a hook.
Title: Re: Soft merging of posts
Post by: Nao on July 29th, 2013, 08:07 PM
So... Took me longer than expected, but I did manage to rewrite Subs-Template to handle soft-merging of posts at the PHP level (ob_sessrewrite), and it works. You can check out the HTML source code, it's all done directly now.

Few caveats:
- #new still doesn't work for me, even though at this point it SHOULD... Maybe it's a browser bug..? :unsure:
- Parsing time takes about 10 milliseconds when there are many posts to merge. It's... quite a lot more than I expected. I dunno. It's still very good, and it saves bandwidth, after all...

Thoughts, anyone?
Title: Re: Soft merging of posts
Post by: Nao on July 29th, 2013, 08:10 PM
Okay, looks like #new is fixed now, phew...

Oh, bugger, this is a 'opens up a new page' post... Was hoping to check the #new behavior when posting :lol:
It should work, though...
Title: Re: Soft merging of posts
Post by: live627 on July 29th, 2013, 11:41 PM
Confirmed working. Merged and non-merged.
Title: Re: Soft merging of posts
Post by: Nao on July 30th, 2013, 12:23 AM
Yup ;)

I was going to commit tonight, but I got busy with a few quick improvements, and it'll have to wait until tomorrow.
I'll also commit the JS version.
Title: Re: Soft merging of posts
Post by: Aaron on August 6th, 2013, 01:07 AM
Love the result so far... Had an idea: perhaps you could have the .poster box scroll with the posts? Especially useful when scrolling through topics with several long posts by the same user (e.g. the changelog topic).
Title: Re: Soft merging of posts
Post by: Nao on August 6th, 2013, 11:34 PM
I think I discussed that a few days ago, but had no feedback on it, so I didn't explore the idea further.

The #1 problem with this, is that it's dependent on the userbox being a vertical layout, which isn't the case in any mobile skin, for instance... :-/
'course, could do something to prevent that from happening in horizontal layouts, but... How do I make the difference..? Hmm...
Title: Re: Soft merging of posts
Post by: Aaron on August 7th, 2013, 08:42 PM
I'd assume it the scrolling to be tackled through JavaScript, so ... through a theme-specific piece of JavaScript that the vertical layout has, but the horizontal does not? I guess the horizontal could override the vertical one with a dummy if need be — not sure how Wedge tackles overriding internally, but I guess you've got that covered.
Title: Re: Soft merging of posts
Post by: Nao on August 9th, 2013, 04:24 PM
Quote from Aaron on August 7th, 2013, 08:42 PM
I'd assume it the scrolling to be tackled through JavaScript, so ... through a theme-specific piece of JavaScript that the vertical layout has, but the horizontal does not? I guess the horizontal could override the vertical one with a dummy if need be — not sure how Wedge tackles overriding internally, but I guess you've got that covered.
Yes, technically, I can add JavaScript to any specific skin, but I'm not fond of the idea.
I could simply add a variable, though, such as "post_layout_horizontal = true" or something, and test for (!window.post_layout_horizontal) to trigger the code, or even write a custom function for horizontal layouts, such as turning the userbox into a fixed div, but... I don't know, I'm not too fond of this idea...

My problem, right now, is that I'm starting to feel the HUGE weight of having an overpowered system like Wedge's skin + skeletons + Wess, and realizing you can't modify something without making sure it doesn't break anything else.

The simpler my underlying HTML/CSS/JS code is, the easier it is to add something onto it, but I don't like not giving people opportunities to make breaking changes to my layout, so... Well, it's hard to make decisions, at this point.

SMF has always had the problem, too, and that system is certainly less complex than Wedge, so...

PS: a good example is the 'upshrink' area... In Warm, it is hidden by default, so that you can't remove the header... But if you remove it while in Weaving, and then switch to Warm, err... Well, you don't get the header anymore, ah ah... How do I fix that, ehh??!!
Title: Re: Soft merging of posts
Post by: Nao on August 18th, 2013, 12:54 AM
So... I've had a quick stab at doing like Aaron suggested, and managed to get a 'working' thingy, but it's still a bit buggy.
Overall, I'm not happy with it.

I can get the userbox to move along with the window scroll, but it gets very complicated when I reach the end of the post, because it tends to increase the userbox size regardless, and thus increase the size of the post, and make it impossible to reach the next message, etc...
So, I added a few failsafes to ensure the userbox size never increases beyond the original height, but even then...

It becomes *jerky*. A bit jerky when I'm scrolling with the keyboard or mouse wheel (like, 1 out of 10 times, you can see the avatar scroll up, then suddenly be restored), and a LOT jerky with the mouse, especially when scrolling through with the mouse, i.e. smoothly: probably because there are too many event triggers, it not only shows the jump effect too much, but it also fails to correctly *scroll the screen* (even though I don't manipulate this!) when transitioning between posts.
Additionally, I think that this animation, while fun at the beginning, will probably get tiresome quickly enough, unless it's replaced with just the user name instead of the entire user box, I don't know, but in this case, it means I'll have to do a position:fixed item... Hmm, well at least it'll solve the jerkiness issue, I guess..?!

If you want to test, I'll paste the code for you. I'd really, REALLY appreciate any feedback.

Open scripts/topic.js
On line 45, add this (or just add it anywhere inside the $(window).load() event):

Code: [Select]
var poster_padding = parseInt($('.poster').first().css('padding-top'));
if (!isNaN(poster_padding))
{
$(window).scroll(function ()
{
var top = $(window).scrollTop(), $poster = null, poster_top, ex_poster_top, last = true;
$('.poster').each(function ()
{
if ($poster === null)
{
$poster = $(this);
poster_top = $poster.offset().top;
return;
}
ex_poster_top = poster_top;
poster_top = $(this).offset().top;
if (poster_top >= top)
return last = false;
$poster = $(this);
});
if (last)
{
var swap = ex_poster_top;
ex_poster_top = poster_top;
poster_top = swap + $poster.height();
}
$poster.css('padding-top', Math.min(Math.max(0, top - ex_poster_top) + poster_padding, poster_top - ex_poster_top - $poster.find('.column').height()));
$('.poster').not($post).css('padding-top', poster_padding);
});
}

I can probably upload it here too, but I'm wary of alienating users, ah ah...

:edit: Also, in Msg.template.php, find <div class="poster"> and immediately add <div class="column"> after it... Then find the </div> that matches it, and replace with two </div>.
Title: Re: Soft merging of posts
Post by: Aaron on August 18th, 2013, 01:24 PM
Hmm, would it be an idea to switch to 'position: fixed' when the scrollTop is within a given boundary? That way, the browser can handle the positioning directly in its render engine, so things should be much smoother.
Title: Re: Soft merging of posts
Post by: Nao on August 18th, 2013, 03:17 PM
Quote from Aaron on August 18th, 2013, 01:24 PM
Hmm, would it be an idea to switch to 'position: fixed' when the scrollTop is within a given boundary? That way, the browser can handle the positioning directly in its render engine, so things should be much smoother.
I dunno, it can probably be optimized later, but I managed to rewrite the thing with position: fixed, and it actually also fixes the problem I had with mouse scrolling, so it's all good.
It only gets a bit jerky when the userbox is is in process of being hidden from view (i.e. you're scrolling into the next post), because at this point, I have to reset the top position on every frame, obviously...

I think it's commit material at this point, but it's also very, very much something I think people will want to have a setting for, with said setting being OFF by default, dunno...
Title: Re: Soft merging of posts
Post by: Nao on August 18th, 2013, 03:28 PM
Just for fun...
I uploaded the code here.

It doesn't work as well as on my local site, though... Far from it!
I probably forgot to update something.
Posted: August 18th, 2013, 03:21 PM

Can't seem to find what causes this to happen, unfortunately.
Also, it's currently applied to mobile skins as well, which isn't the case locally -- because of my recent rewrite, which has yet to be applied here.
While I'm (in the long run) hoping to ready it for mobile skins as well, currently it's not possible, because I need to rewrite the mini-menu code to account for position: fixed parents, which isn't done right now.
Title: Re: Soft merging of posts
Post by: Aaron on August 18th, 2013, 04:20 PM
I'm loving it in the Weaving theme. Great work, even if you're not fully satisfied yet! :)
Title: Re: Soft merging of posts
Post by: Nao on August 18th, 2013, 04:58 PM
:)
Title: Re: Soft merging of posts
Post by: Arantor on August 18th, 2013, 05:19 PM
While I was replying to http://wedge.org/code/8240/login-info-local-storage/ I noticed this bug. Chrome 29.
Title: Re: Soft merging of posts
Post by: Nao on August 18th, 2013, 06:33 PM
Position fixed has its issues.
Generally, any changes to the page layout will break it.

That's why it's not possible to do this kind of trick on a site with a lot of js like here.
Same with infinite scrolling: always happy to have done it, always thinking it's not realistic to keep it in.
Title: Re: Soft merging of posts
Post by: Arantor on August 18th, 2013, 07:09 PM
Scrolling up and down this page I can see issues too... e.g. the userboxes from reply 26 and 27 sometimes overlap when scrolling.

It's always one of those things, we can make it crazy powerful but there are going to be issues with people wanting to customise it. Perhaps it would be better to keep it simple?
Title: Re: Soft merging of posts
Post by: Nao on August 18th, 2013, 07:31 PM
Yup, as I said, I don't have this locally, so I'm going to try and commit my Msg changes, get ready for that... :-/
Title: Re: Soft merging of posts
Post by: Nao on August 18th, 2013, 07:39 PM
I don't get it... I uploaded all of my WIP in here, and it still doesn't work, even though it's pretty much the same codebase...
Title: Re: Soft merging of posts
Post by: Nao on August 18th, 2013, 07:39 PM
Testing.



1




2





3





4





5.

Hmm, working fine on *this* page...
Title: Re: Soft merging of posts
Post by: Nao on August 18th, 2013, 08:05 PM
Okay... Most of the problems are due to user boxes being taken out of flow, without anything to replace 'em. If your signature is longer than your post, then it's dead, you'll get glitches.

I'm working on a fix, but it involves cloning, and I'm not fond of that...
Posted: August 18th, 2013, 07:56 PM

Made a workaround that avoids using clones, so it's faster.
Unfortunately, it also means the .poster area is now fixed in size, but I think it's acceptable as a trade-off, hmm...

Now, I only need to fix the last post.
Title: Re: Soft merging of posts
Post by: Nao on August 19th, 2013, 12:07 AM
Just for the record-- I've finally fixed all bugs, I think...

If you're seeing anything 'abnormal' with the user boxes, please post ASAP.
Also, I'd like to ask whether you'd all like to have this as optional rather than forced, and if yes, default or not..?

One of the issues, in terms of usability, is that having the user box always at the same place, you might think the post starts 'there' when you're right in the middle of it, but it probably simply means getting used to look for the 'Reply #' box to see the beginning of the post, I guess...
Title: Re: Soft merging of posts
Post by: Nao on August 19th, 2013, 12:58 AM
(No one around anymore..? :P)

A small bug... You need a post sent by a guest, or someone with no avatar and no user details.
Go to that post, so that the user name is position:fixed, and hover the name. The menu is shown above everything as expected, but below the user name of the next message. This shouldn't be happening, but stacking contexts are so fucking complicated when you start positioning stuff...

I'm guessing, the only fix for that is to have the menu HTML in a div outside of the main HTML page, and absolutely position it relative to the document itself, but the very reason why I avoided that, is because all hell breaks loose when you start modifying the username's position without hovering out of the menu.

I'm marking this as a cantfix for now, but all suggestions are welcome... Of course.
Title: Re: Soft merging of posts
Post by: Arantor on August 19th, 2013, 01:20 AM
Oh, I'm around but I was trying to figure out how to reply but since we're here... I love the idea. The implementation... not so much. But not for the obvious reason.

We still have the non-zebra striping issue (e.g. previous page, reply 20 has postbg, replies 21-22 are postbg2, reply 23 should logically be postbg but is postbg2, 24-25 are postbg, 26 is postbg as well)

I also don't see themers actually bothering to do anything creative with the templates when, to be blunt, this is going to make them fragile. This is the problem we're going to run into more and more; cool stuff gets implemented but it screws up on anything that isn't the exact structure we've set up.

Does it, for example, work in any other skin? (Haven't tested) And we only have a few skins here. What it will guarantee going forward is that virtually every skin just becomes a knock off of the defaults with slight colour variations because no-one will bother to customise them at all for fear of breaking anything.

Now, that's not unheard of - XenForo and IPB are largely in the same rut but they're not actually as deeply into it as we are, pretty much everything there is still customisable without too much pain but with us it's just going to get worse.

I don't know if that's a trade off you're willing to make, ultimately.

The only way it might work is if it's not really toggleable as such but that themes can override and disable it and just have it that way.


Thought: why are we doing the zebra striping in classes? Can't we just use :nth-child(odd) and :nth-child(even) to handle that? I can think of other places that would be nice (like the thoughts on the front page, it always feels weird when we do anything odd with it)

It also means that infinite scrolling never fights with these issues, and that my dream of AJAX quick reply never has to care either. And it's totally controlled by the style rather than wrangling with template code so the templates get smaller too! (since you don't need postbg, postbg2 alternation, you just declare postbg or even don't bother with that, and just control it straight from CSS)

In fact, the only modern browser that doesn't support it is IE 8 and we can just provide them a default for that without alternation which is fine by me.
Title: Re: Soft merging of posts
Post by: Auk on August 19th, 2013, 02:35 AM
Woah, sooo coooooool! :cool:

Weeee





EeeEEee




eEeeeeeeEeeeEeE





eeEeeeeEee




eeeEeeEeee!!! :D
Title: Re: Soft merging of posts
Post by: Aaron on August 20th, 2013, 03:51 PM
Quote from Arantor on August 19th, 2013, 01:20 AM
Thought: why are we doing the zebra striping in classes? Can't we just use :nth-child(odd) and :nth-child(even) to handle that? I can think of other places that would be nice (like the thoughts on the front page, it always feels weird when we do anything odd with it)
Yes, please. Saves a lot of headaches.
Title: Re: Soft merging of posts
Post by: Nao on August 20th, 2013, 04:26 PM
CSS-based zebra striping has actually been a high-level to-do in my list for a LONG while, and I really, really want to do it, but it also implies getting rid of windowbg everywhere, something I'm willing to do, but when...?

Well, OF COURSE now I want to do it as my next mission... :lol:

Anyway, Pete, I need to comment your post point by point, and I'll do it, but I just want to say, your post seems to question the need for soft-merging, rather than the more recent userbox changes..?
Title: Re: Soft merging of posts
Post by: Arantor on August 20th, 2013, 04:34 PM
You don't need to get rid of windowbg everywhere. One at a time - there's already postbg specifically for posts, target that first. Then one for the thoughts list, and so on and so on. Eventually yes, windowbg will go and that's a good thing. Ideally each major area should have its own set of classes so that it's easier to style at will - while it will take slightly more CSS, the per-page saving could be surprising - because you wouldn't necessarily need to leave in all the classes; I don't know what 'root' does but I see no reason why you couldn't flatten down 'root postbg(2)' to simply postbg, which would give you the same targeting in the JS as root did, whilst giving you all the styling options you needed. And then you save 5 or 6 bytes per post, every post. It will quickly make up for extra CSS.

I'm not questioning soft merging or the userbox changes per se, though they're both intertwined. Anything that makes it harder for themers to theme means we're just going to see what IPB and XenForo have for theming; which is to say we have much the same as SMF, only a bajillion times more entrenched.

There are precisely two XenForo sites I know of that don't look like XenForo. Every other installation just screams XenForo. Ditto for IPB. Anything that introduces behaviour that is dependent on rewriting layout markup is going to be fragile.
Title: Re: Soft merging of posts
Post by: Nao on August 21st, 2013, 05:55 PM
Quote from Arantor on August 19th, 2013, 01:20 AM
We still have the non-zebra striping issue (e.g. previous page, reply 20 has postbg, replies 21-22 are postbg2, reply 23 should logically be postbg but is postbg2, 24-25 are postbg, 26 is postbg as well)
Yeah, looks like I forgot about that uh..?
Interestingly, the JS prototype version I wrote accounted for that, although not in a obvious way.
Quote
I also don't see themers actually bothering to do anything creative with the templates when, to be blunt, this is going to make them fragile. This is the problem we're going to run into more and more; cool stuff gets implemented but it screws up on anything that isn't the exact structure we've set up.
I've tried really hard to make the process as solid as possible, although it always has limits...
It can be disabled by setting the <mobile> option to 1, although I'm considering adding a <softmerge> option, to make things clearer, I guess... (Or a <userbox-direction>horizontal</userbox-direction> setting, or something.)
Quote
Does it, for example, work in any other skin? (Haven't tested)
Yes, it works in all skins.
Right now, short of changing the template files or Msg skeleton or modifying userbox visibility, you can't 'break it', unless you really want to, I guess...
Quote
And we only have a few skins here. What it will guarantee going forward is that virtually every skin just becomes a knock off of the defaults with slight colour variations because no-one will bother to customise them at all for fear of breaking anything.
Worst that can happen, I guess, is skin authors will need to explicitly disable that feature, of course...
Adding new settings to a skin is really, really easy.
Quote
Now, that's not unheard of - XenForo and IPB are largely in the same rut but they're not actually as deeply into it as we are, pretty much everything there is still customisable without too much pain but with us it's just going to get worse.
The least IPB-ish IPB forum I've ever seen, has got to be this one...
http://forum.frandroid.com/
It's just using someone else's skin, though. But as flat designs go, it's an interesting one.
Quote
The only way it might work is if it's not really toggleable as such but that themes can override and disable it and just have it that way.
Yup, it can be done...
Quote
In fact, the only modern browser that doesn't support it is IE 8 and we can just provide them a default for that without alternation which is fine by me.
Quite honestly, we're far, far away from 2010 now. At the time, I still felt it was important to have some basic IE6 support. I haven't tested IE6 in weeks (months?), IE7 pretty much the same, IE8... Not in a while, but to me it's important to get this one right, but there's certainly one thing I'll never give a damn about: getting the colors to be the same... If it doesn't support :nth-child, it just won't do zebra striping, so... Who cares! ;)