Jeffing 233 posts sucks.
-
@Tsaukpaetra said in Jeffing 233 posts sucks.:
Right, which (at the time) was perfectly cromulent (and, indeed, the only way, because there was no /post/ route to identify a particular post)
It was not cromulent, because even if the re-arranging thing wasn't added yet, mods could move or delete posts and break all the links. And it wasn't the only way, either: they were writing the code, and they could've written the /post/ route at any point where it seemed obviously necessary to do so, which indeed it should've been.
-
@El_Heffe said in Jeffing 233 posts sucks.:
What about notifications? When I click on the link it doesn't always take me to my post that was mentioned or upvoted. Sometimes it's only off by a couple of posts, sometimes it drops me into No-Mans-Land where there is no post of mine in site.
Most likely the link's correct but it's just taking you to the complete wrong place in the thread because images and oneboxes take up space and cause jellypotato.
-
@anotherusername said in Jeffing 233 posts sucks.:
@El_Heffe said in Jeffing 233 posts sucks.:
What about notifications? When I click on the link it doesn't always take me to my post that was mentioned or upvoted. Sometimes it's only off by a couple of posts, sometimes it drops me into No-Mans-Land where there is no post of mine in site.
Most likely the link's correct but it's just taking you to the complete wrong place in the thread because images and oneboxes take up space and cause jellypotato.
Wow if #only #there #was #something #one #could #put #in #an #URL #to #target #a #specific #element #in #a #page #to #scroll #into #view #on #load
SINGLE PAGE APP!
-
@Lorne-Kates said in Jeffing 233 posts sucks.:
Because "select post_id as RepliesToThisPost FROM posts WHERE toPid = @thisPostPID" is super difficult and a completely unknown and untested database retrieval theory.
it is in NoSQL
-
@El_Heffe said in Jeffing 233 posts sucks.:
What about notifications? When I click on the link it doesn't always take me to my post that was mentioned or upvoted. Sometimes it's only off by a couple of posts, sometimes it drops me into No-Mans-Land where there is no post of mine in site.
That's usually because there was a oneboxed thing somewhere above your post but in the same chunk, and we still don't try to figure out what the sizes of those things are despite this being very relevant. The current code seems to assume that oneboxes are one text-line high, with hilarious results when the dynamic updating to actually load the onebox occurs.
Is this the problem in all cases? No idea, but it's what's happened in all the situations I've checked with my posts…
-
@Lorne-Kates The problem is that the content above the anchor point is growing (immediately) after the anchor target is reached. If only there was some way to specify the
height
of a<div>
…
-
@El_Heffe said in Jeffing 233 posts sucks.:
When I click on the link it doesn't always take me to my post that was mentioned or upvoted. Sometimes it's only off by a couple of posts, sometimes it drops me into No-Mans-Land where there is no post of mine in site.
IME that's usually due to things like tweets which change size after they're rendered, which cause some jellypotato.
-
@boomzilla If only there was some way to render the page BEFORE the browser finished navigation... oh well, such mystery technology might never exist
-
@Yamikuronue To be fair, this is the same problem browsers used to have with loading images on static sites in the past. Opera was the first browser I know of that didn't jump around wildly when loading an image-heavy website on a slow connection.
As for dynamic context such as oneboxen... Other than pre-calculating that shit using PhantomJS on each load I don't really see a solution. Images are doable, stuff like YouTube embed should be as well, but given that the content of a onebox could change...
Of course, there's always rendering everything serverside. Which... It could work, I guess? Never tested how that would combine with infiniscroll though.
-
@Onyx said in Jeffing 233 posts sucks.:
given that the content of a onebox could change
Could, but usually won't, and the dimensions particularly usually won't change.
-
@Onyx said in Jeffing 233 posts sucks.:
@Yamikuronue To be fair, this is the same problem browsers used to have with loading images on static sites in the past. Opera was the first browser I know of that didn't jump around wildly when loading an image-heavy website on a slow connection.
As for dynamic context such as oneboxen... Other than pre-calculating that shit using PhantomJS on each load I don't really see a solution. Images are doable, stuff like YouTube embed should be as well, but given that the content of a onebox could change...
Of course, there's always rendering everything serverside. Which... It could work, I guess? Never tested how that would combine with infiniscroll though.
serverside cacheing? render it on client side and send back to the server for everyone else to use in future?
I see a million pixel post in our future
-
@DogsB said in Jeffing 233 posts sucks.:
render it on client side and send back to the server for everyone else to use in future?
No need, you could use PhantomJS.
But.
That still doesn't account for zooming, missing fonts on the client causing slightly different rendering, etc, etc, etc.
Delivering full HTML and letting browser just inject that is probably the safest, but then you lose some of the efficiency of client-side rendering (bandwidth-wise).
-
@Onyx said in Jeffing 233 posts sucks.:
That still doesn't account for zooming, missing fonts on the client causing slightly different rendering, etc, etc, etc.
Getting it 90% will do well enough, especially since the one thing that you actually need is the size of the embedded content. Once you've got that, you can tell the page what size it actually needs to be (so letting you get the positioning right) and the rest can be done with client-side handling.
Don't need to get a perfect solution. Just need one that isn't utter
-
@dkf Oh, it's certainly doable within some limitations. I'm just saying there's no silver bullet.
Also, with infiniscroll involved you still need to work with batches. I did a test once to see if it would be possible to get the height of entire thread so the scrollbar doesn't do the jellypotato dance all the time. I made a set of random lipsum posts in a simple layout and tested the calculations.
Basically, with my very simple, text-only test the calculation was off by 1px per paragraph (yes, it was paragraphs, not entire posts) when compared to Chrome, and off by 2-3px per paragraph when compared to Firefox (didn't test IE since, well, Linux machine).
So yeah, it's workable for relatively small chunks, but it would get messed up on large threads. I think I should be able to write a plugin to do that actually, just need to figure out how to add new post metadata to
webscaleMongoDB.
-
@Onyx said in Jeffing 233 posts sucks.:
this is the same problem browsers used to have with loading images on static sites in the past.
If only there was a way to specify image sizes for the browser.
-
-
@Yamikuronue again, that only works if you send the entire DOM, not just JSON, otherwise you have to load it in some way to get the size (be it in DOM or into an object).
In the latter case you have to calculate the size at least once and then send the calculated values if you have any kind of scaling rules. Implementation of the calculation left as an exercise to the reader.
If you're arguing that clientside rendering should be completely removed, well, that's a different argument altogether.
-
@blakeyrat said in Jeffing 233 posts sucks.:
Do you want to be murdered?
Not particularly, but I'm open to suggestions.
-
@Onyx I think the problem is simply that we're using the World's Shittiest Onebox Plugin.
And I think we should turn it the fuck off. Because it doesn't work. This is only one of the many dozen ways it's broken and wrong.
-
@Lorne-Kates said in Jeffing 233 posts sucks.:
@anotherusername said in Jeffing 233 posts sucks.:
@El_Heffe said in Jeffing 233 posts sucks.:
What about notifications? When I click on the link it doesn't always take me to my post that was mentioned or upvoted. Sometimes it's only off by a couple of posts, sometimes it drops me into No-Mans-Land where there is no post of mine in site.
Most likely the link's correct but it's just taking you to the complete wrong place in the thread because images and oneboxes take up space and cause jellypotato.
Wow if #only #there #was #something #one #could #put #in #an #URL #to #target #a #specific #element #in #a #page #to #scroll #into #view #on #load
Oh, there is. It's just that all the crap like images and oneboxes don't load until later, because they're all delayed to load so that they don't take up memory. Or something. I think it's supposed to be "more efficient". Nevermind the fact that it's only loading 20 posts at a time, and if 20 posts worth of images and oneboxes is enough to kill a browser it's probably indicative that there's something seriously wrong. (I mean really... load the posts. The whole posts. And when they've been read, unload everything heavy and replace it with an empty div of the same size -- though it'd be nice if they could not replace currently playing videos. Re-load them if the user scrolls back up. That's hard?)
@Onyx said in Jeffing 233 posts sucks.:
problem browsers used to have
Right. It's a solved problem, and NodeBB manages to re-break it.
@Onyx said in Jeffing 233 posts sucks.:
Delivering full HTML and letting browser just inject that is probably the safest, but then you lose some of the efficiency of client-side rendering (bandwidth-wise).
I'm pretty sure if you just pushed everything into the DOM and then told the browser to go to the
<a>
nchor, it'd actually get it right. Instead of trying to use JS to "intelligently" load things only when they scroll into view. Even if links worked correctly, more often than not when a post has a big image or a few it pushes the top of the post off the screen as they load and then I have to scroll back up to find it.
-
@anotherusername said in Jeffing 233 posts sucks.:
I'm pretty sure if you just pushed everything into the DOM and then told the browser to go to the nchor, it'd actually get it right. Instead of trying to use JS to "intelligently" load things only when they scroll into view.
You still have to wait for the image to load. When you're getting the full page on a "real" load the browser can first grab all the HTML and CSS, parse the DOM and request images which it needs. It can then just grab the metadata from the stream before the image actually loaded, recalculate the size given any already loaded CSS and preallocate the space. That's what I gather is happening at least.
With async loads there's no such mechanism, AFAIK. You need the entire image loaded into memory before you can read the dimension info from the headers.
Note that I didn't mess with this stuff for about 3 years now (I've got no need for arbitrarily sized images in my projects), so if there's a way to do this better, hey, I'm all ears.
EDIT: @ben_lubar, we broke your sanitizer!
-
@Onyx said in Jeffing 233 posts sucks.:
EDIT: @ben_lubar, we broke your sanitizer!
I don't think so, looks like a bug in the composer to me. @anotherusername put backquotes around his "<a>", but they got removed when you quoted the post.
-
@NedFodder said in Jeffing 233 posts sucks.:
I don't think so, looks like a bug in the composer to me. @anotherusername put backquotes around his "<a>", but they got removed when you quoted the post.
Correct, the "reply" button doesn't escape
<
and>
properly when it quotes highlighted text. It's looking at text content, not HTML, so it should escape them.
-
@anotherusername said in Jeffing 233 posts sucks.:
@NedFodder said in Jeffing 233 posts sucks.:
I don't think so, looks like a bug in the composer to me. @anotherusername put backquotes around his "<a>", but they got removed when you quoted the post.
Correct, the "reply" button doesn't escape
<
and>
properly when it quotes highlighted text. It's looking at text content, not HTML, so it should escape them.Ooh, you're right, BenL's sanitizer should escape them. I tested this on my personal instance (the top is a quote, the bottom is a reply with selected text).
BenL's sanitizer:
The default Markdown plugin sanitizer:
-
@NedFodder the problem still isn't sanitizing or not, the problem is that it's quoting it wrong. Probably in both cases. It's quoting
<a>nchor
instead of<a>nchor
. That creates an unbalanced tag, and the difference you're observing there is that @ben_lubar's sanitizer will automatically close unbalanced tags, while the default apparently just escapes them to plain text.