[whatwg] Element borders as resizable handles

[Greg Houston]

Hi Anne,

Thanks. I need to read through the various CSS3 specs.

On Sun, Apr 20, 2008 at 4:21 AM, Anne van Kesteren <annevk at opera.com> wrote:
>  Is this what you're looking for:
>
>   http://www.w3.org/TR/2004/CR-css3-ui-20040511/#resize

This fulfills the basic idea, though the spec seems to leave the
resize mechanism up to the imaginations of the UAs. All it says is
that the resize mechanism is not a scrollbar. Using the element
borders might be one option for a resize mechanism. I imagine the CSS3
authors may have felt it out of their scope to try to define a resize
mechanism since it is a UI element. Though my particular idea may or
may not be a good one, it does beg the question as to whether or not
there should be HTML elements that can be used for such things and
that developers can then style and customize themselves rather than
being stuck with the various UA implementations that may or may not
work well with specific web application designs. Also, due to the
vagueness of the specification the implementations could vary quite
wildy from one browser to another. Do the resize mechanisms go on the
inside of the element, on the outside, centered on the edge? What
shape are they, circles, squares, rectangles? Are they as tall or wide
as the element or are they just little icons centered on each edge and
at the corners? If the element that is being resized has rounded
corners does the UI still look good? Are they simple in design or are
they shaded and intricate? Are they visible at all, or does the cursor
merely change when the mouse is over them? As a designer and developer
these are things I would like to have some control over.

Take the scrollbar for instance, which I think poses much fewer design
possibilities than resize handles, on sites with a more refined design
they can tend to stand out like an eye sore. Where the designer has
chosen and matched each color, shape and pixel precisely, the designer
has no control over the scrollbar since it has no HTML elements.
Perhaps to keep the UI elements separate from the HTML yet have a
standard cross-browser method for constructing and styling them their
should be a UI specification. HTML, CSS, and CUI(Cascading User
Interfaces).

In the past UAs have had trouble with UI z-index, and actually in the
present as well. In Opera, if you absolutely position a div above
another div that has a scrollbar in it, you can click through the div
with a higher z-index and move the scrollbar in the div behind it. In
Mac Firefox, not only can you do the same thing, but the scrollbars
show through elements with a higher z-index. In Mac Firefox you can
set the visibility of a div with a scrollbar in it to hidden and the
scrollbar is still visible though the div is no longer displayed.
These sort of quirks may be partially due to the UI elements being
somewhat in their own little world. If developers had control over the
z-index of these elements issues like these would have been a lot
easier to create workarounds for. Then, once this is fixed in these
browsers, what if there are special cases where the developer actually
wants these elements to function in the ways that we now consider a
bug?

Regarding a couple of the new UI elements in HTML5, it is not clear to
me from the spec if the meter and progress elements are purely UA
designed elements or if the developer has control over their styling.
With the HTML5 drag and drop, can you specify a handle for the dragged
element(s) or are the dragged element(s) always their own handle(drag
mechanism)?

>
> > While on the topic of borders, it would also be nice if there was a
> > CSS property for their alignment, "outside" as is the current default,
> > and "inside". Pushing my luck, I would like to see the same options
> > for the strokes in the canvas element with the addition of "center"
> > which is the current default.
> >
> > CSS
> > border-align: inside;
> > border-align: outside;
> >
> > Canvas
> > ctx.strokeAlign = "center"
> > ctx.strokeAlign = "inside"
> > ctx.strokeAlign = "outside"
> >
> > Center, inside, and outside are the labels used for this in Adobe
> Illustrator.
> >
>
>  This seems partially off-topic for this list and I'm not sure what this
> means. Is this what you're looking for:
>
>   http://www.w3.org/TR/css3-background/#the-background-origin

No, though after looking at these links the non-canvas part does
indeed appear to be more in the realm of the CSS3 spec. Where HTML
ends and CSS begins can be a little fuzzy for me. Regardless, to
clarify, if you have a div that is 100x100 pixels and you add a 5px
border, you will now have an element with dimensions of 105x105px.
This is because the border is aligned to the outside of the element.
If you animate the size of the border the element will grow and shrink
in size. If the border were added on the inside the element will
remain 100x100px wide regardless of the border size, but the content
size would shrink and expand.

With canvas, the border/stroke is centered, so if you add a 5px stroke
to a shape it will appear to grow 2.5px. It would be nice to have a
little more control over how the stroke is drawn on shapes, either
adding the stroke to the outside of the shape, centered on the edge of
the shape, or on the inside. In Adobe Illustrator you have these
options on closed shapes. On lines that are not closed the stroke is
always centered.

On Sun, Apr 20, 2008 at 6:58 AM, Martin Atkins <mart at degeneration.co.uk> wrote:
> Greg Houston wrote:
> > CSS
> > border-align: inside;
> > border-align: outside;
> >
> >
>
>  I'm not sure what effect you're intending these values to have, but have
> you looked at the CSS "outline" property? Does that achieve what you are
> intending?

No, outlines do not take up space, so the content would not shift if
the outline was offset with a negative value, and from the spec it is
not clear if it accepts a negative value. Yes, this probably is a CSS3
issue though you removed the canvas part which is not.

Cheers,

Greg