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.
sorry, couldn't resist... :P
Gave those up years ago. I value my lungs. :D
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.
I broke my mouse while hitting that like button :D
lol
Sorry ant, but Spuds won it xD
Probably depends on your definition of "much of a delay". Personally I've always detested highslide and never understood why some people liked it.
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.
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.
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.
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.
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.
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:
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> - <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:
/* 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:
.attachment_block.zomfg_highslidez {
position: fixed;
z-index: 99;
left: 0;
right: 0;
etc, whatever...
}
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.
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.
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.
Well if by "really made the page layout jump about" you mean the expansion pushed the adjacent blocks to another line then sure, that's what expand in place will do. That doesn't bother me personally*, as long as nothing else happens. Everything else on the page should behave nicely. If it doesn't, something is wrong (which will be fixable anyway).
*I like the image to expand within post width, so I can see it without disrupting anything else. Admittedly this is just personal preference though.
I'm not a fan of highslide, but I never liked the old expand in place either to which I tend to prefer the highslide.
Ok, well I suppose it might be worth asking what we think would be perfect, because if we can think of it we can probably code it. :)
An highslide, with some kind of "normal" speed, configurable by admin (so that if you want it to be faster you can make it faster, or slower), with some mopped up markup as antechinus suggested. That, would do.
Sorry, but I'm failing at understanding what you mean by "slow".
Here it loads the overlay in the blink of an eye (without any effect of sort), and then the image is loaded at the speed of the itnernet connection.
What's so slow about that?
Why not use Lightbox? I have implemented that in SMF (modified by me) and that looks very good. Also you can show more images in One topic as a Gallery..
Look at http://smf21devel.portamx.com/index.php?topic=4.0
I do think that if you are going to use a highslide type of display, it should have the ability to scroll through all images in that post. Having to jump in and out of black pages/normal pages for every image in one post would be really annoying.
Blow 'em up image displays look very cool on a desktop. On the flip side, I find they're often horribly broken on mobiles. This is a huge concern as better than 75% of my traffic is from mobile users. Proper mobile rendering is key!
There are Addons for ElkArte that provide for all the full set of zoom effects, gallery navigation, overlay etc features (for example there is a FancyBox addon).
When I added this to the core, the intention was to be light weight and provide an way to turn it off so an addon writer
(and end user) could select their lightbox addon of choice. This was simply an improved version of what we had, It should work for mobile but I have not checked everything. The lightbox itself is responsive to screen size changes.
Anyway I think I'm going to be removing this from B2 and leave the old chunk in place.
Sibling rivalry is out. Enter dev rivalry!
Well .. I have modified the Lightbox2, so he can load in the header and the image is zomed centered. Also this works very well on Mobile devices, bacause the small images for prev/next image is shown allways on mobile, not on mouseover.
My version works very well with all mobile devices and with all browsers .. also in IE ;-) and this is very small while jquery is exists.
Take a look at our test side ...
LOL .. I'd just like it to be a bit better (tad faster, navigation, validate mobile) based on the feedback.
Perhaps what
@Feline states is a better path, Lightbox2 is pretty lightweight and MIT. I'm not sure what modifications were made / needed with her version.
Just defer the loading if you put it in the header, so that you won't have to wait for that to load up to see the actual page (=faster).
Perhaps you should look at the code and then provide a "fix" (=more useful) ;)
if you load lightbox2 defered this gives problems with IE and Edge. So I load it in the Header an react on document.ready ...
This really should not use any kind of js, at least not as animation engine... :) I have used CSS only popup-to-full-width in some themes and never looked back. The speed, the simplicity and adapting to all resolutions is just too nice lol. One click to send it back and you are done.
I did look to see if a easy next/prev buttons could be added, also through CSS..just to be a bit more user-friendly, but haven't explored that further. Also, an option to just show it in 100% no matter what(with scrollbars) over the entire page could be useful, especially if you want to see details - sometimes a fit-to-screen-width will be too small for that.
The icon at the top right corner.
Duh :) I saw it, but never tried it.