Client-side cropped-, adaptive- and also fluid images for Responsive Layouts

Client-side cropped- and also fluid images

Client-side cropped- and also fluid images

We decided in the past to add a image cropping feature (CPW since 4.1.6, April 13th 2016, as option and TACBPW since 1.0.1, as default), to set your image dimensions in pixel for the feature image or called thumbnail. We called it “CSS cropping for thumbnails“.

This CSS cropping gives your image the possibility to set dimension options for width and height. Our decision till now is to perform this cropping with CSS. CSS is fast and the website admin can use, but it’s not a have to. And our feature don’t neet to generate new images or actually a change for image sizes in the WordPress settings.

We talk much about the feature and implement it to other widgets like Same Category Posts.

We started to solve the max-width problem for our client-side cropped images

Solve "max-width" issue for client-side cropped images with Javascript

Solve “max-width” issue for client-side cropped images with Javascript

The problem we had with our cropped images is we can’t use the CSS property max-width, because the cropping is also made with CSS. No CSS rule solve both features correctly at the same time and we set a fixed width and height. For Responsive Layouts this is very bad to have only one image size and the image can’t be resized, e.g. for many different mobile devices and screen sizes.

For the 4.7 we tried a CSS solution again to solve the aim to have fluid images with CSS attribute max-width. It’s Mark again who mentioned to try it with Javascript. And now it’ll be available with the 4.7 (4.7 beta 1).

The Javascript code works only once at page load or on page resize. Last one is in the normal website usage not performed. The Javascript code is also performance optimized and curse a very less millisecond delay while page load.

Demo page: demo.tiptoppress.com

Advantages with client-side responsive images:

  • No additional (server-side) libraries required.
  • No cookies required.
  • No extra server configuration needed.
  • Does not attempt to perform any client OS detection.
  • Server image storage doesn’t change.
  • Fast server response any time.
  • No image quality loss.
  • No side effects with frequent use on several pages.

Other image features for Responsive Layouts are planed

We’re happy we found a solution and we hope we don’t get problems and can solve the requested Responsive Layout support. What we also want is use the CSS attribute “width” like percentage unit (100%). And either for one dimension and the other as pixels or for both, no size restriction is given and the image fill all the available space. We planed it also for the 4.8 – be patient if all works right.


Related posts:

New in 4.7: Default thumbnail

Thumbnail are great for the look of the page, but the problem with them is that they require some extra effort when editing the content, an effort for which you might not have time when you rush to publish something, or you just forget.

This kind of situation could have been handled in 3 different ways before 4,7

  • Do nothing and just don’t display a thumbnail. If the thumbnail setting produce a small thumbnail, it might be ok, but when the thumbnail is big and dominant, an item without it will ruin the balance of the design and might be harder to spot.
  • Just don’t display posts without a thumbnail. This keeps the visual balance but it means that the post is going to be more hidden than other posts.
  • Use a plugin that lets you specify a fallback thumbnail.

In 4.7 we are going to add an additional option, to set a fallback thumbnail for a specific widget. This will let you keep the visual balance without having to install additional plugins, and even have different fallbacks in different widgets.

default-thumbnail

And something that might have looked like

Customize test 4.6 – Just another WordPress site(2)

easily transformed to (notice the first item)

Customize test 4.6 – Just another WordPress site(3)

This feature will go into the 4.7 version of both the “free” and “pro” plugins due to be released right after WordPress version 4.7 will have its first RC release which is scheduled right now to november the 15th.

You can try the feature by downloading and installing the beta from https://github.com/tiptoppress/category-posts-widget/releases/tag/4.7.beta1, and report bugs or just get an impression of what is planned from our bug repository at https://github.com/tiptoppress/category-posts-widget/issues

Version 4.1.8 of the Category Posts Widget plugin released

PatchesThis mostly a bug fix release with few additional enhancements

Bugs fixed:

  • Some php warnings are logged when a widget is added
  • Division by zero error when thumbnails are configured to be bigger then the actual image sizes
  • Improved compatibility with jetpack when using the html excerpt option

Enhancements:

  • It is possible to select more HTML tags to be “used” as part of the HTML excerpt option
  • Introduce an option for a blur effect when hovering over a thumbnail

Unless there is some unexpected bug this is going to be the last release for the 4.1.x line, and we will switch to working on a 4.6 line (the logic behind this number) with the intention of releasing it to the wordpress.org plugin repository when WordPress version 4.6 will hit RC1 (get out of beta) which is expected to happen around the 20th of july. We still haven’t finalized what we want, and think we can achieve, in that time frame but first priority will go to writing unit tests for the plugin and some refactoring of the code in order to make it more testable.

Once we decide what we are going to have in 4.6, we will announce here. If you have an idea or request, the comment form is the best place to express them 😉