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

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:03:39 UTC