Re: [css-ui] Definition and scope of 'resize' property

Top-posting:


It'd be nice if resize worked with min-width and min-height. I recently did the textarea+background-image trick, to give the user an opportunity to resize an image. Resize does not allow them to resize smaller than the initial width/height, and so I have to set the initial width/height to a small value (like 200px).





On Aug 19, 2011, at 11:02 AM, Aryeh Gregor <ayg@aryeh.name> wrote:

> Context: http://www.w3.org/Bugs/Public/show_bug.cgi?id=13795
> 
> For rich-text editing (contenteditable), it's logical and expected
> that users are allowed to resize images and similar things.  The
> author might want to control which things exactly the user can resize,
> for various reasons.  For instance, in a web forum, it's common to
> allow users to insert both custom images and stock smilies.  The user
> should be able to resize the custom images, but not the smilies.  The
> logical way to allow this flexibility would be to support the resize
> property here, and have rules like img:read-write { resize: both } in
> the default stylesheet.
> 
> I discussed this with Ehsan Akhgari of Mozilla in the bug I linked to.
> When I researched how browsers behave as it stands, I found that the
> spec doesn't match them.  The spec says "When an element is resized by
> the user, the user agent keeps track of a resize factor (which is
> initially 1.0) for the width and height, which it then applies to the
> computed width and height as part of determining the used width and
> height."  However, if you try creating a <textarea> in Gecko or WebKit
> and resizing it, you'll see that it just adds style="width: XXXpx;
> height: YYYpx" to the DOM.  This is perhaps a bit ugly, but it's
> vastly simpler than changing how CSS height/width calculation works
> for this one special case.  If browsers aren't willing to change to
> what the spec says, the spec should change to mandate what browsers
> do.
> 
> This behavior (adding inline style attributes) is also essential for
> contenteditable.  The most common use-case for contenteditable is that
> the user types in some rich text, it's submitted to the server, and
> then it's republished as a regular HTML document (blog post, forum
> post, e-mail, etc.).  The only thing that's submitted to the server is
> the DOM, so any information like a resize factor that's not in the DOM
> is lost.  So whatever the resize mechanism is for images and such in
> contenteditable, it has to use DOM attributes.  Happily, browsers
> already do this for the CSS resize property, and this just needs to be
> specced.
> 
> Ehsan also pointed out that resize currently only applies to elements
> with overflow other than visible, because it's concepted specifically
> as a window resize mechanism that goes in the same place as
> scrollbars.  This restriction should be removed, so that it applies to
> all elements.  Also, the spec should note that UAs should expose
> different UI for different types of resizable content.  Gecko has good
> UI for image resizing in contenteditable (which it allows on all
> images AFAICT).
> 
> So basically, my current thoughts are that we should have the following changes:
> 
> 1) The idea of a resize factor should be removed in favor of saying
> that the UA has to add inline style rules.  I don't think this is a
> layering violation, since CSS acknowledges the concept of a DOM and
> inline style rules.  If a host language doesn't support inline style
> rules, behavior can be left undefined, or we can say there's no
> effect, or whatever.  It's a little scary to have user actions messing
> with the DOM, but I don't see any good alternative offhand even for
> the non-editable case.
> 
> 2) The restriction on resize not applying to overflow: visible should be lifted.
> 
> 3) The wording about UI should be adjusted a little, and an example
> with an <img> should be added.
> 
> Of course, CSS is not my forte, so maybe I'm missing something here.  Thoughts?
>

Received on Friday, 19 August 2011 18:10:25 UTC