[whatwg] Two more elements
levikcom at gmail.com
Mon Jun 28 19:30:22 PDT 2004
To your first point, I would say that it is completely unnecessary.
flexible solution implemented in HTML will likely not be less verbose
(especially if you want to accomodate weird rules like a triangle of
As far as the second point, I have suggested earlier today that tree
type selects be implemented by nesting OPTGROUP elements within each
other. By augmenting the current spec a little, we could say that in
SELECTS with MULTIPLE property enabled, OPTGROUPS will be rendered as
collapsible tree branches - this has the advantage of still showing
all the options normally in legacy browsers - gracefully degrading the
On Mon, 28 Jun 2004 22:09:14 -0400, Robert J. Accettura
<robert at accettura.com> wrote:
> Sorry for the lag on this one, but life has kept me busy....
> There are two things I would like in forms. I think others would agree,
> since both concepts have been used quite a bit, and are increasing,
> though are commonly done in JS, or Flash due to HTML limitations. These
> aren't implementations, or specs by any means, but written in hopes
> someone sees the void that exists, and can build on this:
> The first is the ability to move options between lists...
> <select multiple name="lista" attach="listb">
> <option value="1">A</option>
> <option value="2">B</option>
> <option value="3">C</option>
> <option value="4">D</option>
> <option value="5">E</option>
> <input type="selectMove" value="A to B" />
> <input type="selectMove" value="B to A" />
> <select multiple name="listb" attach="lista">
> Would be great IMHO. It's very useful. The alternative to some JS
> right now is to reload the page for each item selected. Very ugly with
> all that reloading.
> The option is important for grouping data. Ideally you can move between
> more than just 2 lists. Perhaps a 3 way triangle.
> The second thing on my X-Mas wish list is a simple tree. The ability to
> apply styles would be nice too (though not portrayed here). Perhaps it
> could be rendered by platform (so for Mac OS X, it takes that long
> length wise feature I love so much).
> <select name=foo class="bar">
> <option value="folder1" type=root view=maximized>My Stuff</option>
> <option value="folder1a" type=directory view=maximized>My Documents</option>
> <option value="folder1a1" type=directory view=maximized>Work</option>
> <option value="folder1a1a" type=object view=maximized>Revenue Plan</option>
> <option value="folder1a1b" type=object view=maximized>Our Enron
> <option value="folder1a2" type=directory view=maximized>Fun</option>
> <option value="folder1a2a" type=object view=maximized>My Pong
> <option value="folder1a3" type=directory view=maximized>Revenge</option>
> <option value="folder1a3a" type=object view=maximized>How to be a
> <option value="folder1b4" type=directory view=maximized>My Music</option>
> <option value="folder1b4a" type=object view=maximized>BeGee's Sing like
> <option value="folder1c" type=directory view=maximized>My Pr0n</option>
> <option value="folder1c1" type=directory view=minimized
> <option value="folder1c2" type=directory view=minimized>People</option>
> HTML lacks a nice way to show structure. That's a selling point of XUL
> as a web app. There's no good way to show large sums of data other than
> a table (which obviously isn't as good as a tree in some cases).
> Yea, these are really ideas, not really any implementation in this
> email. I'll leave that for now to the pro's. My goal here is just to
> get people thinking about these two missing holes in what is otherwise a
> pretty cool spec. These are two concepts I feel are pretty
> under-represented in HTML, but pretty well represented on the OS level.
> Sorry this is all so rough.
> Robert J. Accettura
> robert at accettura.com
> smime.p7s - 3K
More information about the whatwg