You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Support for the <picture> element is now in place across all the browsers we intend to support for CotnentTools 2 (sorry no IE11 support). Image support (especially responsive images) in ContentTools has previously been very limited with just the <img> tag being available. We've typically worked around these limitations by using a combination of image fixtures and ContentFlow to provide different upload options at different browser widths but it's far from ideal.
Supporting the <picture> element would allow ContentTools to provide a modern approach for inserting imagery into pages with the option to add multiple versions (crops, formats, qualities, etc.) of the picture for different media queries.
As part of this update we will look to change the current approach of using a division to represent images within the page when editing, this approach was used at the time to allow before and after elements to be used within the editable image element, but whilst it works and was a simple solution at the time for presenting additional image information (e.g size) it causes lots of problems for developers and designers integrating ContentTools within their content.
I'd love to hear from people how we might best approach a UI to allow users to support generating multiple versions of an image to meet different media queries. We'd ideally need to support for:
Manually control, allowing a user to configure a versions of an image for multiple predefined media queries (media queries would be predefined by the developer/design team to meet the requirements of the content).
Automatic generation, a way to plugin image creation tools like cloudinary or H51 to automatically generate URLs/images for media queries the user does not manually configure (can see this being the most common scenario for a lot of our clients).
Safe fall backs for when an image on it's own will do. There's plenty of times when I've found simply setting the max-width of the image to 100% is all I've needed. It's not a good solution clearly, but it should be possible to take this approach, if only to help with the transition over from ContentTools 1.x to 2.
The text was updated successfully, but these errors were encountered:
Support for the
<picture>
element is now in place across all the browsers we intend to support for CotnentTools 2 (sorry no IE11 support). Image support (especially responsive images) in ContentTools has previously been very limited with just the<img>
tag being available. We've typically worked around these limitations by using a combination of image fixtures and ContentFlow to provide different upload options at different browser widths but it's far from ideal.Supporting the
<picture>
element would allow ContentTools to provide a modern approach for inserting imagery into pages with the option to add multiple versions (crops, formats, qualities, etc.) of the picture for different media queries.As part of this update we will look to change the current approach of using a division to represent images within the page when editing, this approach was used at the time to allow before and after elements to be used within the editable image element, but whilst it works and was a simple solution at the time for presenting additional image information (e.g size) it causes lots of problems for developers and designers integrating ContentTools within their content.
I'd love to hear from people how we might best approach a UI to allow users to support generating multiple versions of an image to meet different media queries. We'd ideally need to support for:
The text was updated successfully, but these errors were encountered: