Forum    Search    FAQ

Board index » Sluggy Related Forums » Sluggy Related Chat




Post new topic  Reply to topic  [ 232 posts ] 
 
Author Message
 Post Posted: Tue Jun 19, 2018 7:36 pm 
User avatar
Offline
Joined: Tue Dec 13, 2016 12:19 am
Posts: 100
Captain_20plus wrote:
Does this test link to that strip fix the issue for you?


Yes and no. I just clicked that link ten times, and here's where it took me:

  1. Strip for October 24th
  2. Strip for October 24th
  3. Strip for October 24th
  4. Strip for October 23rd
  5. Strip for October 19th
  6. Strip for October 24th
  7. Strip for October 24th
  8. Strip for October 23rd
  9. Strip for October 23rd
  10. Strip for October 23rd

I guess 1 out of 10 is…better than nothing? ¯\_(ツ)_/¯

Incidentally, I'm noticing the exact same fragment identifier rewriting behavior as swmartian in the browser's address bar.

Update: I just found another link to reproduce this issue: it should take me to the strip for June 2nd, 2011, but instead it takes me to the strip for May 19th or June 1st, depending on how many times I click it (or manually paste the URL into the address bar).

Top 
   
 Post Posted: Sat Jun 23, 2018 3:34 pm 
User avatar
Offline
Joined: Thu Aug 17, 2017 1:14 pm
Posts: 38
kansaichris wrote:
Incidentally, I'm noticing the exact same fragment identifier rewriting behavior as swmartian in the browser's address bar.

I wanted to confirm and explain the address bar behavior you're seeing. You might notice as you scroll through the archives that the url will change to reflect the current strip you're looking at. This is to facilitate being able to just copy the url from your address bar and link someone to the strip you're looking at. (I'm sure we've all tried to link someone to what we're looking at on a dynamic webpage and had it fail.)

So this is somewhat intentional and in this instance is just a side effect of the bad landing behavior. The url updating process is kicking in on the strip you land on, because it doesn't know the different between scrolling there on purpose and having been dragged there by a hash url.

Of course, we're still looking into the underlying issue, with some disappointment that testing for the possible fix is not panning out.

Top 
   
 Post Posted: Sun Jun 24, 2018 2:57 am 
User avatar
Offline
Joined: Tue Dec 13, 2016 12:19 am
Posts: 100
You know, I actually never noticed that the URL automatically changes as I scroll through the archives, but—now that you mention it—it totally does! Your explanation makes perfect sense and definitely fits with the behavior I'm seeing.

Just out of curiosity, did you ever end up trying to set the size of each <img> tag rather than relying on the browser to accurately calculate it on its own, or would that be technically infeasible to accomplish at this point?

Top 
   
 Post Posted: Sun Jun 24, 2018 1:56 pm 
User avatar
Offline
Joined: Thu Aug 17, 2017 1:14 pm
Posts: 38
kansaichris wrote:
Just out of curiosity, did you ever end up trying to set the size of each <img> tag rather than relying on the browser to accurately calculate it on its own, or would that be technically infeasible to accomplish at this point?

Unfortunately there are technical reasons not to do that. I'll explain below, but first, are you noticing any reflow as the page loads? Elements that grow in height as images load? I suspect the problem might be something else, given that you were actually landing on later strips with your 10 try test.

Geeky details, for anyone interested:

Setting explicit height and width attributes on the image tag would break responsive css. The comic images would fall off the right of the screen on mobile screens.

What this last test attempted is commonly known as the padding-bottom hack, where the image is put in a container with a height of 0 and a padding-bottom of the height to width ratio, so it always reserves an appropriate height relative to the width.

This is all under the assumption that the problem is related to DOM reflow, where the height of the page changes as elements are loaded, thus pushing the correct comic down immediately after landing on it. The original solution to reflow (which is working well enough that we can't reproduce the issue) is embedding a transparent png as a data URI (base 64 encoded string of the image data) directly in the image tag as the html is generated, which is then replaced with the real comic image as the strip scrolls into view. Data URI images should reserve their height right away, as they don't wait for a second request to load an image file and determine its dimensions.

Top 
   
 Post Posted: Mon Jun 25, 2018 3:48 am 
User avatar
Offline
Joined: Tue Dec 13, 2016 12:19 am
Posts: 100
I love geeky details. :) Thanks for sharing!

Captain_20plus wrote:
are you noticing any reflow as the page loads? Elements that grow in height as images load? I suspect the problem might be something else, given that you were actually landing on later strips with your 10 try test.


Though there seems to be an almost imperceptible "jump" just after the page starts to load (i.e. at the same time that the date in the address bar changes), I don't see any reflow issues when I then try to rapidly scroll down the page. In other words, it would appear that both the data URI images and the padding-bottom hack are working as intended. I was thinking about using something like the <picture> element with the <srcset> and <sizes> attributes to set the image size according to responsive breakpoints, but your solution looks like it may be a bit more elegant. :)

In that case, I wonder if the issue has to do with a rounding error in how some JavaScript function—or even the browser itself—is calculating the scroll position on extremely long pages?

Top 
   
 Post Posted: Mon Aug 13, 2018 12:43 pm 
User avatar
Offline
Joined: Sun Nov 13, 2005 1:59 pm
Posts: 1648
Location: In "Still" waters...
Today's comic (8-13-15) is not visible in the archives (and thus not in the transcription site, either).

I have a screenshot if necessary - but I'm too busy to find out where to post it so I can link to it. But let me know if you need it.

Also, you might want to tell Pete to remove the message from Leah above the comic. I'm not sure if anyone's aware that there is a new comic -- including Zil (i.e., no reaction thread for today)!! :-)

Top 
   
 Post Posted: Tue Aug 14, 2018 1:31 pm 
User avatar
Offline
Joined: Sun Nov 13, 2005 1:59 pm
Posts: 1648
Location: In "Still" waters...
Everything all fixed now - apparently part of a larger issue. So never mind!

Thanks

Top 
   
Display posts from previous:  Sort by  
 
Post new topic  Reply to topic  [ 232 posts ] 

Board index » Sluggy Related Forums » Sluggy Related Chat


Who is online

Users browsing this forum: No registered users and 1 guest

 
 

 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to: