Skip to main content
Topic: Highslide-style attachment thumbnail expansion in 1.1 (Read 8453 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Highslide-style attachment thumbnail expansion in 1.1

Just noticed that there's an easy way to get around how annoyingly slow this function is. Simply ignore it, and use right click > open in new tab instead.

Seriously, is there any way of speeding up the expansion of thumbnails? Highslide stuff has always been so slow you could that you could make coffee, order dinner, and have a bonk while waiting for the image to arrive.
Master of Expletives: Now with improved family f@&king friendliness! :D

Sources code: making easy front end changes difficult since 1873. :P

Re: Highslide-style attachment thumbnail expansion in 1.1

Reply #1

Quotehave a bong
sorry, couldn't resist... :P
LiveGallery - Simple gallery addon for ElkArte

Re: Highslide-style attachment thumbnail expansion in 1.1

Reply #2

Gave those up years ago. I value my lungs. :D
Master of Expletives: Now with improved family f@&king friendliness! :D

Sources code: making easy front end changes difficult since 1873. :P

Re: Highslide-style attachment thumbnail expansion in 1.1

Reply #3

I honestly don't see much of a delay :/

If you stop skimming of your neighbors wifi you would have more bandwidth.. ah but then you would not have much money left to fill your bong, have to use parrot poo :P

Really all the function does is fetch the image by href and then place in in the DOM.  Its only different than the old "expand thumbnail" in that it creates its own div to load vs loading inside the existing thumbnail div / container.  

The only speed difference that I can see would be in the DOM manipulation to add those div's etc.  The function is not even 100 lines of code with comments, and most of that are the mouse / key events.  If we think that maybe adding the divs to the dom is slow, then we could always add the placeholder the markup.

Re: Highslide-style attachment thumbnail expansion in 1.1

Reply #4

I broke my mouse while hitting that like button :D
LiveGallery - Simple gallery addon for ElkArte

Re: Highslide-style attachment thumbnail expansion in 1.1

Reply #5

lol
Bugs creator.
Features destroyer.
Template killer.

Re: Highslide-style attachment thumbnail expansion in 1.1

Reply #6

Sorry ant, but Spuds won it xD
~ SimplePortal Support Team ~

Re: Highslide-style attachment thumbnail expansion in 1.1

Reply #7

Quote from: Spuds – I honestly don't see much of a delay :/
Probably depends on your definition of "much of a delay". Personally I've always detested highslide and never understood why some people liked it.

QuoteReally all the function does is fetch the image by href and then place in in the DOM.  Its only different than the old "expand thumbnail" in that it creates its own div to load vs loading inside the existing thumbnail div / container. 

The only speed difference that I can see would be in the DOM manipulation to add those div's etc.  The function is not even 100 lines of code with comments, and most of that are the mouse / key events.  If we think that maybe adding the divs to the dom is slow, then we could always add the placeholder the markup.
Why load new divs? Why not just change the CSS on the existing container? All you'd need to do is append a class on click.
Master of Expletives: Now with improved family f@&king friendliness! :D

Sources code: making easy front end changes difficult since 1873. :P

Re: Highslide-style attachment thumbnail expansion in 1.1

Reply #8

QuoteWhy load new divs? Why not just change the CSS on the existing container? All you'd need to do is append a class on click.
In 1.1 the attachment markup changed a bit ... so it may not be right  O:-)

In 1.0 the attachment thumbs were pretty misbehaved, they went out of "grid" very easily due to size or type variations, and got extra ugly when you would expand and shrink..

In 1.1 moar markup was added so they behave better, but they seem to be trapped in the container div ... meaning changing the width/height of the thumbnail  will not allow them to expand past the parent container. 

No matter what image you expand, it uses the same named div, so really it should be no drama to add a empty div to the page to load the image into.  I don't know if adding that is slow, or is page size dependent slow, actually if you notice a slower response on the first image vs the second that would answer that question as it reuses the div it adds.

Re: Highslide-style attachment thumbnail expansion in 1.1

Reply #9

Quote from: Spuds –
QuoteWhy load new divs? Why not just change the CSS on the existing container? All you'd need to do is append a class on click.
In 1.1 the attachment markup changed a bit ... so it may not be right  O:-)

In 1.0 the attachment thumbs were pretty misbehaved, they went out of "grid" very easily due to size or type variations, and got extra ugly when you would expand and shrink..
Yeah but that's easy to sort. I've had it working before. Was going to take a look at the 1.0 default soon anyway, since I saw the problem.

QuoteIn 1.1 moar markup was added so they behave better, but they seem to be trapped in the container div ... meaning changing the width/height of the thumbnail  will not allow them to expand past the parent container.
Lemme guess: you set a width on the container, yes? :D Would have to look up the code I had working before, but I'm 99% sure it didn't do that. It just used inline-bock on the containers with the width set on the contents (image). That way it all goes to the right block width by default, and when you clickety teh thumbnails the container div gets biggerer to fit around the image.

It should only need minimal markup too. Anyway will take another look at it and see what I can come up with.

Master of Expletives: Now with improved family f@&king friendliness! :D

Sources code: making easy front end changes difficult since 1873. :P

Re: Highslide-style attachment thumbnail expansion in 1.1

Reply #10

Sounds good! ... If the markup can change I can simply the light box and maybe make it a tad bit faster, at least as fast as the old expand I would think.

Re: Highslide-style attachment thumbnail expansion in 1.1

Reply #11

Found the old solution. This is heavily mutated 2.0.x so would need Elkification, but that shouldn't be a big deal. Will look into that sometime this week. Anywayz, markup as it stands is just this:

Code: [Select]
				echo '
<div class="attachment_block">';

if ($attachment['is_image'])
{
if ($attachment['thumbnail']['has_thumb'])
echo '
<a href="', $attachment['href'], ';image" id="link_', $attachment['id'], '" onclick="', $attachment['thumbnail']['javascript'], '"><img src="', $attachment['thumbnail']['href'], '" alt="" id="thumb_', $attachment['id'], '" class="attachment_image" /></a>';
else
echo '
<img src="' . $attachment['href'] . ';image" alt="" class="attachment_image" width="' . $attachment['width'] . '" height="' . $attachment['height'] . '"/>';
}

echo '
<a href="' . $attachment['href'] . '" class="attachment_name">' . $attachment['name'] . '</a>
<span class="attachment_details">', $attachment['size'], ($attachment['is_image'] ? ', ' . $attachment['real_width'] . 'x' . $attachment['real_height'] . ' - ' . $txt['attach_viewed'] : ' - ' . $txt['attach_downloaded']) . ' ' . $attachment['downloads'] . ' ' . $txt['attach_times'] . '</span>';

if (!$attachment['is_approved'] && $context['can_approve'])
echo '
<a href="', $scripturl, '?action=attachapprove;sa=approve;aid=', $attachment['id'], ';', $context['session_var'], '=', $context['session_id'], '" class="approval">', $txt['approve'], '</a>&nbsp;-&nbsp;<a href="', $scripturl, '?action=attachapprove;sa=reject;aid=', $attachment['id'], ';', $context['session_var'], '=', $context['session_id'], '" class="deletion">', $txt['delete'], '</a>';
echo '
</div>';
So that's pretty much bare bones markup. One container div per attachment, then just the required anchor or two (depending on thumbnail or not), the image, and span for the details (size, downloads, etc).

The CSS looks like this:

Code: [Select]
/* Important stuff. */
.attachment_block {
display: inline-block;
max-width: 99%;
min-width: 21em;
margin: 0 3px;
vertical-align: bottom;
text-align: center;
overflow: hidden;
}
/* Just eye candy. */
.attachment_image {
margin: 25px 0 0 0;
}
.attachment_name, .attachment_details {
/* Important stuff. */
display: block;
/* Just eye candy. */
background: #1a1a1a;
border: solid 1px #333;
background: #0f0f0f;
color: #888;
border-bottom: 1px solid #222;
}
/* Just eye candy. */
.attachment_name {
margin: 5px 0 0 0;
border-bottom: none;
}
/* Important stuff. */
.attachment_name:before {
display: block;
clear: both;
content: "";
}
/* Just eye candy. */
.attachment_details {
border-top: none;
border-radius: 0 0 8px 8px;
}

/* Important stuff. */
/* Auto scaling of images in posts, sigs, attachments, etc. */
/* @todo - Cross check where this is defined earlier */
.inner .bbc_img, .signature  .bbc_img, .attachment_image {
height: auto;
width: auto;
max-width: 100%;
max-height: 800px;
}
So it does have a max and min width set on the container div, but no width as such. This is what allows it to expand when the thumbnail is clicked. When the thumbnail is displayed, the blocks just collapse to min-width. When you click the image, the container div can expand to a maximum of 99% of post div width (this setup always scales the expanded image to fit available post width, which is what most people probably want most of the time). The image inside the container is set to max-width of 100% of the container, so it never overflows. This works because the inline styles set by the PHP only set image width and height, which get overridden by the maximums set in the CSS. Is all quite nifty if I do say so myself. :)

You could easily set this up to do a highslide type of display, simply by appending an extra class (like zomfg_highslidez) and having CSS do something like:

Code: [Select]
.attachment_block.zomfg_highslidez {
position: fixed;
z-index: 99;
left: 0;
right: 0;
etc, whatever...
}

Master of Expletives: Now with improved family f@&king friendliness! :D

Sources code: making easy front end changes difficult since 1873. :P

Re: Highslide-style attachment thumbnail expansion in 1.1

Reply #12

tracked as a feature request to return to the old inline expand vs lightbox, I think thats the basic summary.

Looks like the 1.1 markup has an overall attachments div, with attachment_thumb div's inside so there may be an opportunity to drop a div as well.
Last Edit: June 12, 2016, 07:20:37 am by Spuds

Re: Highslide-style attachment thumbnail expansion in 1.1

Reply #13

Well I can put up with the lightbox thing if it's fast. If most people want a lightbox then give them a lightbox. If I want something different I'll just code it different. You know what I'm like. I have a total disrespect for default code. Even if I wrote it myself. :D

Anyway the point here is that debugging the 1.0 version should be easy enough, either in the default theme or in custom themes.

And it's not just an extra div in 1.0. There's a pile of horrible br's as well. Now admittedly any themer worth their salt can recode the template to get rid of those if they want different presentation, but that shouldn't be necessary. If you check the CSS in my example I've used things like display: block; on a span and whatever else to get line breaks without br's in the markup. The advantage of this is that it can be changed with a basic CSS tweak.
Master of Expletives: Now with improved family f@&king friendliness! :D

Sources code: making easy front end changes difficult since 1873. :P

Re: Highslide-style attachment thumbnail expansion in 1.1

Reply #14

I should also track this for 1.0.8 (should it happen) ... This way we can fix the 1.0 branch which as you noted is a mess and whats worse about that mess is that it really does not work very well in more than a few cases.

1.1 things were changed around a bit to make it behave and been generally responsive, but then you need the lightbox to escape the div but this would fix that as well ... the expand in place effect of the old JS really made the page layout jump about which was not the greatest either.