1225773 - CSS resize property should work for image (<img>) that is not in contenteditable

Status: UNCONFIRMED

(Core :: Layout: Images, Video, and HTML Frames, defect)

Description

[Duan Yao]

Attachment: css-resize.htm

User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0
Build ID: 20151029151421

Steps to reproduce:

Set "resize: both" CSS property for an <img> that is not in a contenteditable context; try to resize the <img> by dragging mouse. The attachment is a test case.



Actual results:

Can't resize the <img>.


Expected results:

Be able to resize the <img>.

With Firefox one can resize <img> in contenteditable, why can't out of it? The spec (https://drafts.csswg.org/css-ui/#resize) doesn't say that CSS resize property has something to do with contenteditable.

Comment 1

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

https://drafts.csswg.org/css-ui/#resize says: 

  Applies to:    elements with overflow other than visible, and optionally replaced
                 elements representing images or videos, and iframes

and later says:

  The resize property applies to elements whose computed overflow value is something
  other than visible. UAs may also apply it, regardless of the value of the overflow
  property, to:

    Replaced elements representing images or videos, such as img, video, picture,
    svg, object, or canvas.

    The iframe element. 

  The effect of the resize property on generated content is undefined.
  Implementations should not apply the resize property to generated content.

Is this something other implementations do?  It feels to me like a somewhat unusual request.  (The resizing UI in contenteditable is designed for editing, which is a rather different case.)

Comment 2

[Duan Yao]

Contenteditable is not the only way to make an editor, and contenteditable=true is going to be deprecated (https://medium.com/content-uneditable/fixing-contenteditable-1a9a5073c35d#.rh2sxhgq5). I'm developing a HTML editor without contenteditable, because contenteditable is not quite extensible and is not consistent across browsers. So it is reasonable to allow all elements including replaced ones to be resized outside contenteditable.