[whatwg] Element borders as resizable handles
This may just be another one of my crazy ideas, but web applications are increasingly using resizable elements such as resizable windows, resizable form columns, image croppers and so forth. Currently this requires injecting one or more handles into the element you wish to resize and absolutely positioning them on the edges of your element and continuously resizing the handles with javascript. If you are doing an 8-direction resize you will have to inject 8 different handles into your element. It might be nice if the element borders could be used by the javascript libraries as handles, which I imagine would require that the borders be able to be accessed via the DOM somehow. I don't know if there would be a solution for getting this to work with corners, but at least four directions would be easier to resize. I think this could probably even work with tables where borders are collapsed since both the elements sharing the collapsed border are simultaneously being resized in relation to each other. Also, you might be able to specifically refer to the right-border of such and such td, and so regardless of whether or not it is collapsed it would still be the border referred to by the drag event. Again, I realize this may not be feasible, but thought I would throw the idea out there. 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. Cheers, Greg
Re: [whatwg] Element borders as resizable handles
On Sun, 20 Apr 2008 08:40:20 +0200, Greg Houston [EMAIL PROTECTED] wrote: Again, I realize this may not be feasible, but thought I would throw the idea out there. Is this what you're looking for: http://www.w3.org/TR/2004/CR-css3-ui-20040511/#resize ? 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 ? -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Element borders as resizable handles
Greg Houston wrote: 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; 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? I suspect that this request would be better sent to the W3C CSS Working Group, anyway.
Re: [whatwg] Element borders as resizable handles
Hi Anne, Thanks. I need to read through the various CSS3 specs. On Sun, Apr 20, 2008 at 4:21 AM, Anne van Kesteren [EMAIL PROTECTED] 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
Re: [whatwg] Element borders as resizable handles
On Sun, 20 Apr 2008 14:58:35 +0200, Greg Houston [EMAIL PROTECTED] wrote: 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. If you want full control you probably have to implement it yourself. 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. You can probably style them using XBL in due course. They are similar to form controls as far as I can tell. 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)? I'm not sure what you mean here. 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. Oh, you want 'box-sizing': http://www.w3.org/TR/2004/CR-css3-ui-20040511/#box-sizing (This property has several UA implementations already. Some with a prefix only, admittedly.) -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Element borders as resizable handles
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. You can probably style them using XBL in due course. They are similar to form controls as far as I can tell. Thanks. I only had some vague notions about XBL, that it was a proprietary Gecko language for skinning the Firefox browser. I wasn't aware it was being developed now as a web standard and that it would give you control over UI elements inside the webpages themselves. 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)? I'm not sure what you mean here. Dragging an element requires a handle to drag that element by, something to mousedown on and move. In the simplest case, lets say I have a red rectangle, 100x100px. By default the handle for dragging the red rectangle may be the entire red rectangle. So mousedown anywhere on the red rectangle and drag and the rectangle moves. In my experience, maybe 50% of the time this is fine. Generally things are a little more involved. Take an OS window for instance. OS windows are draggable, but the entire windows are not handles for the drag. You have to drag windows on your desktop around by mousing down on the titlebar. In this case the titlebar is the drag handle for the window. Generally the drag handle is a child element of the element being dragged, though this is not always true. The element you pull on when resizing another element is a handle. The knob on the scrollbar is a handle. They all have similar functionality, mousedown on an element and the movement of the mouse then changes a property of another element. With drag you are changing the position. With resize you are changing the size, and actually, with more advanced resizing you are simultaneously changing the size and the position, consider resizing in the west, north-west, and north directions. If you have an absolutely positioned div and resize it in the north direction, the top position is decreased by exactly the amount the size is increased. In this way the bottom of the div remains stationary. Oh, you want 'box-sizing': http://www.w3.org/TR/2004/CR-css3-ui-20040511/#box-sizing Yes, the border-box property in particular. Thanks. The ability to evenly horizontally split two divs looks promising. I hope that works vertically as well. Intricate fluid layouts that break a page up into panels that fill the available space both horizontally and vertically is currently a nightmare without using frames or tables. It gets even more complicated if the panels are resizable. My request for canvas strokeAlign is still on the table. It does not necessarily need a response, just keep it in mind. ctx.strokeAlign = center // this is the current default. ctx.strokeAlign = inside ctx.strokeAlign = outside Like in Adobe Illustrator, inside and outside would only work on closed paths. Cheers, Greg
