This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
It makes the most sense to tie this to CSS3's resize property. This was suggested by Alfonso MartÃnez de Lizarrondo: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-August/032938.html
Somebody recently suggested it for mozilla too. It might not make a lot of sense for <body> for example, but I don't see why it would be a bad idea for regular contenteditable elements! Note that this basically means specifying resize:both in the properties for contenteditable element.
Just to be clear, the suggestion was to standardize resizability of things like <img>, not of the editable region itself. Apparently some browsers allow resizing them, but this should be standardized, and authors should be allowed to control it. For instance, forums often allow insertion of custom images and also of stock smilies, and they might want to allow the user to resize custom images but not smilies. A rule like [contenteditable] img:not(.smilie) { resize: both } seems like the best way to handle this -- the editing spec just needs to define the behavior in detail. I'll just copy the full mailing-list exchange here for the record (the part that relates to this): Alfonso: """ One basic example is resizing. Currently Webkit browsers doesn't allow the user to resize a picture, table,.. that it's placed in the contents. Some people might not want that behavior at all, others might prefer to enable it only for tables but not images, and I think that instead of putting that burden on the javascript editor, it should be the browser the one that takes care of that with a basic command to turn it on/off and then firing the needed events when something like a resize starts or ends like IE does. """ http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-August/032938.html Me: """ Might the CSS resize property be the best way to do this? http://www.w3.org/TR/2004/CR-css3-ui-20040511/#resize Then authors could do img { resize: both } or similar. This is much more flexible than a global on-off switch, because you could allow the user to resize some things but not others. For instance, a forum that allows users to insert custom images and also smilies might want them to be able to resize the custom images but not the smilies, and it could do that with an appropriate CSS selector. I'd have to update the spec to say that if the user resizes editable things, the browser needs to actually change the DOM to add height/width attributes or properties. """ http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-August/032940.html Alfonso: """ Yes, that sounds fine; we just have to be sure that everyone agrees that such CSS property also applies while editing a document (and maybe say that by default it should be enabled for both images and tables in editable elements) Also, maybe the behavior of the browser should be slightly different while editing. I think that the resize property might have been thought for textareas so the user can adjust the size (and ignore designers that don't use the pages that they create) and so they aren't really worried about the exact size, but while editing a content it's nice to see the resized dimensions like done in Firefox. And of course, resizing a picture by the corner should respect the width/height ratio, not like IE does. """ http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-August/032941.html
Oh, OK. The first thing that comes to my mind about this is whether this is the right thing to do with regard to the CSS overflow property. The CSS spec says that the resize property only applies to elements which have a computed value for the CSS property other than visible. This means that by default, for example, an img element will not show a resizer when you set resizer:both on it. Another concern that I have is the resizing UI. The resizer that most UAs use for the CSS property is a window resizer object. But wouldn't you agree that the resizer control that Gecko implements is a better UI for this?
Okay, so when the user resizes something, CSS3 UI says that a special extra step is added to width/height calculations, but Gecko/WebKit seem to actually just add inline style. That's what we need for this to be usable for editing, since it needs to persist if the editing host is saved. Most of this section needs to be rewritten to reflect how browsers behave, actually: http://www.w3.org/TR/css3-ui/#resize It should be changed to say that 1) resize applies even to elements with overflow: visible. 2) UI should vary based on the type of element. 3) When the user resizes the element, the UA has to add inline width/height styles to the DOM, with no special width/height handling beyond that. Then all we need is img:read-write { resize: both } in UA stylesheets. How does that sound to you?
(In reply to comment #4) > 3) When the user resizes the element, the UA has to add inline width/height > styles to the DOM, with no special width/height handling beyond that. I don't think this would actually be the right thing to do for non-editable contexts, don't you agree? Other than that, your suggestions seem fine to me.
(In reply to comment #5) > I don't think this would actually be the right thing to do for non-editable > contexts, don't you agree? Maybe not, but it's what Gecko and WebKit both do. Try making a <textarea> in http://software.hixie.ch/utilities/js/live-dom-viewer/, resize it, and hit "refresh" in the DOM View. Do you think this should change?
(In reply to comment #6) > (In reply to comment #5) > > I don't think this would actually be the right thing to do for non-editable > > contexts, don't you agree? > > Maybe not, but it's what Gecko and WebKit both do. Try making a <textarea> in > http://software.hixie.ch/utilities/js/live-dom-viewer/, resize it, and hit > "refresh" in the DOM View. Do you think this should change? Originally I though so, but I thought a bit more about this. The problem with not doing that is that the page, if it wants to determine why an element has the computed width/height that it does, it would be really confusing... So I guess I'll retract my comment! :-)
I started a www-style thread: http://lists.w3.org/Archives/Public/www-style/2011Aug/0565.html