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.
| 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. |
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.
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.
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.
- since you can redefine macros in skins, I can (finally!) modify Wireless to remove some blocks of code entirely, instead of just hiding them.
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 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.
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.
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);
});
}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.
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)
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.
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.
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.