Home → How Do I... →

Better process for fluid images

• Edit

Justin McDowell

Jun 05, 2014 @ 09:30 PM

We're working on updating our CMS users to a new, responsive template. One of the three components of responsive web design is fluid images, which means images that don't have an explicit height or width set.

Currently, when a user inserts an image, Cascade automatically adds in an explicit height and width. The natural inclination is to simply delete the height and width, but this instead zeroes out the numbers, which makes the image effectively invisible. An image with a height and width of zero can’t be seen.

It turns out the process is to unlink the height and width first, THEN delete both numbers.

This is unacceptable. We have to train inexperienced users to go through this process every time they insert every single image. And good luck getting them all to remember or even care about responsive design. As long as it works on their display, they're satisfied and do not put a single shred of mental energy toward what other users might be experiencing.

Is there a simpler process to make images fluid, instead of unlinking, deleting height, and deleting width? Or better yet, is there a setting to make Cascade stop auto-populating height and width by default? This way we can use our users’ laziness to our benefit!

1. 1 Posted by Wing Ming Chan on Jun 06, 2014 @ 12:22 PM

   

   Hi Justin,

   I don't know anything about settings in Cascade to stop auto-populating height and width. But to remove all the height and width attributes, will you consider using a template format written in XSLT? When you attach a format to a template, it will be applied to the entire rendered page at the last stage of rendering. Here you can process the img elements and remove all the height and width attributes, without altering anything in the source. Users can still be inserting images in the usual way, and pages will still contain these attributes. But the rendered versions will be free of them.

   Wing

   • Edit

2. 2 Posted by Ryan Griffith on Jun 06, 2014 @ 02:15 PM

   

   Hi Justin,

   Currently, when a user inserts an image, Cascade automatically adds in an explicit height and width. The natural inclination is to simply delete the height and width, but this instead zeroes out the numbers, which makes the image effectively invisible. An image with a height and width of zero can’t be seen.

   Your description sounds like a similar discussion I had with another client regarding the TinyMCE media plugin. What I found was the media plugin was written to only handle pixel dimensions; otherwise, the dimension would be set to 0 by the plugin.

   I am curious if this is a similar issue in which the TinyMCE image plugin does not properly handle percentages, nor does it properly handle clearing out the dimensions all-together. My apologies for the inconvenience this may be causing you and your users, unfortunately this is an issue with the TinyMCE plugin and not something specific to Cascade Server.

   A few options I can think of:

   • When adding/editing the image, disable the Maintain Aspect Ratio option for the dimensions. This will allow you to clear out both the height and width fields without the opposite field being calculated to 0. After submitting, the attributes won't be added at all.
   • Adjust your CSS to target these images and overwrite the inline dimensions. This would probably require adding !important to ensure the styling takes priority.
   • As Wing mentioned, use a Page, Template, or Configuration Set level XLST Format which targets your images and either removes the dimension attributes all-together, or replaces the width and height with something else. If you went this direction, this will affect all <img> tags on the page, so I would suggest adding some sort of way to exclude images, perhaps with a specific class name. I have attached a sample XSLT Format that may be able to get you started.

   Please let me know if you have any questions.

   Thanks!

   • remove-img-dimensions.xsl 919 Bytes
   • Edit

3. Ryan Griffith closed this discussion on Jun 19, 2014 @ 01:37 PM.