Very nice plugin!

Further notes on this. It looks like the enqueueing of scripts is using ‘picturefill’ as a handle. This was causing a conflict. Maybe this plugin should be using ‘picturefill-wp’ ?

I have also discovered that it does not preserve the float on a left-aligned image. This has caused me to turn off the plugin. It would be nice to see this fixed.

Here is an example from the editor of an image that is left floated but losing its float with this plugin enabled –

<div><img alt=”Shanna” class=”alignleft size-full wp-image-126″ height=”300″ src=”https://wildmice.ca/wp-content/uploads/2014/01/shanna-2010-06.jpg&#8221; width=”240″ /></div>

Thanks very much for your feedback Wildmice.

I debated with myself over the issue of the default breakpoints. To try to allow for all use cases, I included a filter hook to customize the image breakpoints as desired. The picturefill_wp_media_query_breakpoint filter.

For the kind of seamless responsiveness you describe, you may want to try something like the following:

In functions.php

function theme_breakpoint($breakpoint, $image_size, $width, $image_attributes, $image_attachment_data, $image_sizes){
  // First we find the position of the current image size in the list of images
  $image_size_index = array_search($image_size, $image_sizes);
  // Next we set the index for the next image size down
  if('@2x' === substr($image_size, -3)){
    $new_index = $image_size_index - 3;
  }else{
    $new_index = $image_size_index - 2;
  }
  // Lastly, we set the breakpoint to the width of the next smaller image size. If the image is already our smallest, we set the breakpoint to 1.
  if(0 <= $new_index){
    $new_breakpoint = $image_attachment_data[$image_sizes[$new_index]][1];
  }else{
    $new_breakpoint = 1;
  }
  return $new_breakpoint;
}
add_filter('picturefill_wp_media_query_breakpoint', 'theme_breakpoint', 10, 6);

With regard to the script handle suggestion, do you mean that you had already enqueued the picturefill.js script in your theme, and this is conflicting with the plugin? Changing the script handle may be an appropriate idea, since I do make a few small changes to Scott Jehl’s original script. Although I would be hesitant to make any changes that might have backward compatibility issues. For the time being, I am going to wait and consider the issue. Since several major browsers have announced support for the picture element to be rolled out this year, there will likely be big changes to picturefill.js as it moves towards becoming an actual polyfill. I will probably wait on making any feature changes for this plugin until the road ahead for the picture element becomes more clear.

With regard to the image floats, I am having trouble duplicating the issue you describe. One of the changes I made to the picturefill.js script involves looping through all of an image’s attributes to ensure that classes, styles, data attribute etc., are included in the output image. It is very slightly slower than the original picturefill.js, but the hope was to avoid situations like you describe. If you are willing, please include the output html for the picturefill syntax (everything inside and including the <span data-picturefill> element), as well as the actual output image html from the web inspector. This may help me narrow down where the problem is occurring.

Thanks again for your feedback. I hope we can figure out the source of this issue.

Thanks for a quick followup!

Since posting that i decided to use your version of picturefill.js to get width and height on the output – to satisfy Google Page Speed Insights, etc.

I also renamed the handle in my own source from ‘picturefill’ to picturefill-js’ and that made it work, but it strikes me that you should perhaps not duplicate the name that would logically be used for this.

The breakpoint is a small issue and i will look at your hook.

Now, the floated image problem. Here is the output that was generated from the HTML that i posted above.

<div><span data-picture data-alt=”Shanna” data-class=”alignleft size-full wp-image-126″>
<span data-src=”https://wildmice.ca/wp-content/uploads/2014/01/shanna-2010-06.jpg”></span&gt;
<span data-src=”https://wildmice.ca/wp-content/uploads/2014/01/shanna-2010-06-150×150.jpg&#8221; data-width=”150″ data-height=”150″ data-media=”(min-width: 1px)” class=”picturefill-wp-source thumbnail”></span>
<span data-src=”https://wildmice.ca/wp-content/uploads/2014/01/shanna-2010-06.jpg&#8221; data-width=”150″ data-height=”150″ data-media=”(min-width: 1px) and (-webkit-min-device-pixel-ratio: 1.5),(min-resolution: 144dpi),(min-resolution: 1.5dppx)” class=”picturefill-wp-source retina thumbnail”></span>
<span data-src=”https://wildmice.ca/wp-content/uploads/2014/01/shanna-2010-06.jpg&#8221; data-width=”240″ data-height=”300″ data-media=”(min-width: 260px)” class=”picturefill-wp-source full”></span>
<noscript><img alt=”Shanna” class=”alignleft size-full wp-image-126″ height=”300″ src=”https://wildmice.ca/wp-content/uploads/2014/01/shanna-2010-06.jpg&#8221; width=”240″ /></noscript>
</span>

However, you probably won’t need this, because after i replaced the original picturefill.js with your version it seems to be working. This seems a bit odd, since they are still different files and both being loaded, but the important point is that i seem to have stumbled into a solution.

The page concerned is this one – https://wildmice.ca/en/about/shanna/

Thanks for your response. If i discover that it’s really not working i will follow up, but it looks like using the same version of the script fixed it. I also made the spans for Scott’s version conform to yours, and maybe this was part of why it began working. I don’t know, but can do some tests for you if it matters.

— shanna

Hi Kyle – I found the problem. The picturefill.js script is not being enqueued.

It was working because i was already loading the script. When i tracked this down i discovered that it was being registered but not enqueued, so i just added the enqueue and it works.

Here is the change i made to class-picturefill-wp.php after line 56 –

// Filter and action methods
public function register_picturefill_scripts(){
wp_register_script(‘picturefill’, PICTUREFILL_WP_URL . ‘js/libs/picturefill.min.js’, array(), PICTUREFILL_WP_VERSION, true);
wp_enqueue_script(‘picturefill’);
}

As i mentioned earlier, i switched to using your version of picturefill.js on my own responsive images and everything seemed fine (except the enqueue problem mentioned above).

However, i was doing some speed tests tonight and discovered that your version of the script does not work for IE11, iPad or iPhone. When i switched back to Scott’s original version they all started working again.

Meanwhile on a recent version of Firefox it worked just fine with either version of picturefill.js.

Thanks very much for reporting back with your findings. It makes sense that two versions of picturefill on the same page would conflict with each other. The second one loaded should actually overwrite the first. Scott Jehl’s original script is meant to mimic the proposed picture element syntax more strictly. Meaning that classes, ids, and other attributes stay in the outer span, and are not transposed down to the output image. I would be willing to bet that this is where the css float issue was coming from. Since renaming the scripts, now they are loading in a different order and now mine is overwriting Scott’s, meaning all of the classes and whatnot are being transposed down to the output image.

With regard to the picturefill script not being enqueued. On line 72 of the class-picturefill-wp.php file, the script is only enqueued after we check if there are images in the html being filtered. You are correct however, that the script will not be enqueued if the picturefill syntax is added manually. This was an oversight on my part and I will be sure to keep it in mind as I look at reworking the plugin to keep up with the picture element as it is being implemented in browsers this year.

I am very sorry to hear that there are issues with IE11, and the iPhone/iPad browsers. Unfortunately, I don’t have access to testing environments for any of those at the moment, but I will see if I can commandeer some friend’s devices this weekend. In the meantime, I will do some research to see if I can figure out what might be tripping up those browsers.

Thanks again very much for the feedback.

While i like your plugin a lot, there seem to be a few issues that would need resolving before i could use it.

The clash of scripts can be sorted out i think by my simply using yours for both purposes, however yours currently does not seem to work in a few browsers.

Since i am already using picturefill.js myself for masthead image, slideshows, lightboxes, and features images, this only leaves full-width images in the editable areas. It seems that your plugin does not really know what to do when an image is left or right floated and not the full width.

The other observation i have is that i am using a 2 column theme, and you are measuring the viewport rather than the column width. I understand that you really could not do otherwise, but it makes the resizing not very effective in this scenario.

I really wonder how a picture tag is going to deal with all of these things. Sounds like they’ll have fun figuring it all out.

To report back, I have unfortunately not been able to reproduce the browser issues that you describe. I did coincidentally catch a bug in IE7 and below, but while that could pop up as trouble in IE’s compatibility mode, it wouldn’t account for anything happening on IE11 or an idevice. I will push an update with the IE7 bug and the script enqueuing issue you uncovered in the near future, but hopefully after a have figured out what is going on with this issue.

You’ve hit on one of the limitations of media queries for responsiveness, which is that they are relative to the window width, rather than a parent element. This makes it difficult to set bulletproof defaults, but hopefully the picturefill_wp_media_query_breakpoint filter from my first response will also serve well here. A site builder could use the filter to manually set the break points for each of their image sizes.

function theme_manual_breakpoint($breakpoint, $image_size, $width, $image_attributes, $image_attachment_data, $image_sizes){
  switch($image_size){
    case 'full':
      return 800;
      break;
    case 'large':
      return 600;
      break;
    case 'medium':
      return 400;
      break;
    case 'thumbnail':
      return 1;
      break;
  }
}
add_filter('picturefill_wp_media_query_breakpoint', 'theme_manual_breakpoints', 10, 6);

or something like that.

I apologize for not being able to duplicate the error that you are seeing with regard to browser compatibility or CSS floats. I certainly don’t expect you to run around trying to snoop out bugs, so do not feel obligated to continue the thread if you have decided to move on.

If you are interested in pursuing this further, I would want to try to get more details about the circumstances under which these errors occur. Are there any circumstances where the plugin works as expected? On a twenty* theme without any other plugins perhaps? This would give us a starting point to try to figure out which plugins or theme components are causing conflicts. We would want to start from a working system and then add plugins and theme components until it breaks, hopefully giving us some idea where the trouble spots are.

Again, I’ll keep poking around at this to try to duplicate the issue, but don’t feel obligated if you have decided not to use the plugin.

Thanks very much.

Thanks Kyle. Let me try then to summarize what i encountered.

Everything was fine in Firefox (a fairly recent version), and it was only when i did speed tests of the site on webpagetest.org and https://mobitest.akamai.com/ that i realized no images were showing in IE11 or iPad/iPhone. IE11 on my computer was not showing them either. However they were showing on gtmetrix.com (where you cannot specify the browser, so who knows).

When this was happening i was using your version of picturefill.js for my own picturefill use too. Earlier i had used the original one, and having two different versions made my images disappear when your plugin did it’s substitution. I fixed that with your ignore attribute. I then switched to using your version for everything in order to get width and height. Then everything seemed fine, but later i noticed that it was only good in Firefox. Hope you can make sense of this.

The only thing unusual i am doing is using picturefill myself in addition to your plugin (so two separate copies of your picturefill.js) – and i think this is very likely where the problem lies – so not likely a concern for most people.

I certainly appreciate the limitations of using picturefill in a multi-column page. As you say, viewport is not what’s relevant in that case, but it’s all we have. I ended up setting up a configuration array for different page layouts, from which i select the breakpoints dynamically.

My use was limited to things outside the editable area – masthead, sliders, lightboxes, feature images. Your plugin deals with content in the editable area – the part that i did not have a solution for.

Unfortunately i am in the middle of something for a few days so cannot recreate this right now for you to test – but i could do that later if you still need me to.

Shanna

Just to help organize my own thoughts, I’m going to try to list out and reiterate the issues in the thread.

1. Unexpected breakpoints — This issue can be addressed with the picturefill_wp_media_query_breakpoint filter. See post 5345758
2. Float problems — Scott Jehl’s picturefill syntax expects classes and other attributes to be applied to the outer picture span, not to the image tag. CSS styles are often not prepared for this and need to be adapted. The Picturefill.WP syntax transposes attributes back down to the image so that CSS does not need to be adapted, but it requires a slightly different syntax. data-{attribute}="value" in the picture span will be transposed to {attribute}="value" in the output img element. Obviously, this adapted syntax does require the Picturefill.WP version of the picturefill.js script.
3. Browser compatibility — Browser compatibility issues are almost certainly JavaScript issues. An issue with IE7 and earlier was identified in post 5364090, but I have been unable to duplicate any of the issues described in IE11 or iDevices.
4. Script does not enqueue for manual syntax — The script automatically enqueues when images are present in the post but requires manual enqueuing for manual syntax. It isn’t any trouble to automatically enqueue when the picturefill syntax is present, so that will be changed with the next release.
5. Multi-column breakpoints — Unfortunately, there isn’t an easy solution for breakpoints and multi-column layouts. However, if the layouts and image sizes are consistent, breakpoints can be set manually. Example in post 5364090.

Unless I’m missing something, all of the issues have been addressed, apart from the browser compatibility issues that, unfortunately, I have not been able to duplicate. Without duplication, I can only guess at what might be happening, and my best guess so far is that there is a conflict with some custom JavaScript on the page.

I apologize that I haven’t been able to be more helpful :-/

@kylereicks ~ Thanks for going through that. I will watch for the next version.

I don’t think it’s reasonable for anyone to expect that this plugin will do its magic on a multi-column page, because everything is based on viewport breakpoints, not the width of the column. To make this work for multi-column you would need to set breakpoints manually for the specific page template layout. I know this is very picky because i am already doing it with the original picturefill.js. But since the plugin will accept manual breakpoint settings (as you say) then that becomes a task for the user, if it’s important enough to tweak like that. This is certainly my case and may be for others.

Using this plugin on floated images may be challenging because, as any WP theme developer may tell you, getting floated images to work well responsively with captions can be very picky. I would shy away from messing with that once you i it working in CSS. But, as you say, it can be done.

The manual enqueuing is something i did not realize was involved and may actually account for why i was not seeing anything in certain situations. How this could be browser dependent though i cannot imagine. I will have to check again with this in mind.

I have also been following Scott’s original Picturefill.js suggestion that the script can be run at the end of the page just in case it does not get run before that – but it does not seem to make any difference.

So i still don’t have much that’s solid about it not working in IE11 and (some) mobile browsers. I will let you know if i discover any clues other than the obvious (i.e. no images show).

Thanks for your patience and persistence on this. It’s still a cool plugin ??

– shanna