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
Is your feature request related to a problem and/or adding functionality? Please describe.
ImageMapster does not currently provide a way to automatically "resize" an image to its container (responsive image). There are a number of requests for this feature worded in various ways so consolidating here to capture and plan.
Currently, IM explicitly defines width/height for its wrapper div along with all image/canvas/etc. elements. The key portion of this that prohibits current support of responsive behavior is the fixed width/height vs. 100%;auto, etc. I believe the reason it was done this way is a couple-fold: 1) The canvas is not visual but must match the dimensions of the image itself (to make areas highlight/select/click where expected); and 2) Likely some legacy browser reasons.
Upon reviewing the code, addressing all of the required portions of this would require a breaking change and a major version release. Since the next major version is not yet planned timeline wise, I believe it makes sense to provide some basic functionality to IM to at least partially support responsive images.
Describe the solution you'd like
The proposal for next minor release is:
Add a feature flag enableAutoResizeSupport - If !== true, IM will be 100% backwards compatible. If === true, IM will no longer apply width/height to its wrapper which will allow it to resize the wrapper based on the wrappers content width. Changing the value of enableAutoResizeSupport at runtime will require a unbind and re-init (e.g. $img.mapster('unbind').mapster(options).
Add the following configuration options that are only applicable when enableAutoResizeSupport === true. All of these options will take effect immediately when applied via set_options:
autoResize - If true, automatically re-size images to size of wrapper. If false, auto-resize is disabled.
autoResizeDelay - When resize event is triggered on window, the amount of time to delay resizing the images (default 0).
autoResizeDuration - Corresponds to resize API duration parameter which indicates the amount of time for the resize animation (default 0 - no animation)
onAutoResize - Corresponds to resize API callback parameter
Describe alternatives you've considered
The only viable workarounds is to invoke resize API using an event listener outside of IM similar to this jsFiddle.
Additional context
In the next major release, the concept of "resizing" vs. "responsive images" should be re-visited and possibly separated to allow the browser itself to handle the "resize" of the image displayed and IM only respond to resize by "autoScaling" and adjusting canvas sizes, etc. At the very least, the feature flag enabledAutoResizeSupport can be eliminated and the implementation that it triggers in 1.5.0+ become the standard behavior as there is no reason to explicitly define width/height on the wrapper element itself.
Is your feature request related to a problem and/or adding functionality? Please describe.
ImageMapster does not currently provide a way to automatically "resize" an image to its container (responsive image). There are a number of requests for this feature worded in various ways so consolidating here to capture and plan.
Currently, IM explicitly defines width/height for its wrapper div along with all image/canvas/etc. elements. The key portion of this that prohibits current support of responsive behavior is the fixed width/height vs. 100%;auto, etc. I believe the reason it was done this way is a couple-fold: 1) The canvas is not visual but must match the dimensions of the image itself (to make areas highlight/select/click where expected); and 2) Likely some legacy browser reasons.
Upon reviewing the code, addressing all of the required portions of this would require a breaking change and a major version release. Since the next major version is not yet planned timeline wise, I believe it makes sense to provide some basic functionality to IM to at least partially support responsive images.
Describe the solution you'd like
The proposal for next minor release is:
enableAutoResizeSupport
- If!== true
, IM will be 100% backwards compatible. If=== true
, IM will no longer apply width/height to its wrapper which will allow it to resize the wrapper based on the wrappers content width. Changing the value ofenableAutoResizeSupport
at runtime will require aunbind
and re-init (e.g.$img.mapster('unbind').mapster(options)
.enableAutoResizeSupport === true
. All of these options will take effect immediately when applied viaset_options
:autoResize
- Iftrue
, automatically re-size images to size of wrapper. Iffalse
, auto-resize is disabled.autoResizeDelay
- Whenresize
event is triggered onwindow
, the amount of time to delay resizing the images (default 0).autoResizeDuration
- Corresponds toresize
APIduration
parameter which indicates the amount of time for the resize animation (default 0 - no animation)onAutoResize
- Corresponds toresize
APIcallback
parameterDescribe alternatives you've considered
The only viable workarounds is to invoke
resize
API using an event listener outside of IM similar to this jsFiddle.Additional context
In the next major release, the concept of "resizing" vs. "responsive images" should be re-visited and possibly separated to allow the browser itself to handle the "resize" of the image displayed and IM only respond to resize by "autoScaling" and adjusting canvas sizes, etc. At the very least, the feature flag
enabledAutoResizeSupport
can be eliminated and the implementation that it triggers in 1.5.0+ become the standard behavior as there is no reason to explicitly define width/height on the wrapper element itself.Related Issues: #123, #209, #229, #271
The text was updated successfully, but these errors were encountered: