W3C home > Mailing lists > Public > whatwg@whatwg.org > June 2004

[whatwg] Two more elements

From: Robert J. Accettura <robert@accettura.com>
Date: Mon, 28 Jun 2004 22:09:14 -0400
Message-ID: <40E0CF4A.8030405@accettura.com>
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>
</select>

<input type="selectMove" value="A to B" />
<input type="selectMove" value="B to A" />

<select multiple name="listb" attach="lista">
</select>

This is done all the time with javascript, why not just standardize it.  
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 
Scandle</option>
<option value="folder1a2" type=directory  view=maximized>Fun</option>
<option value="folder1a2a" type=object  view=maximized>My Pong 
Scores</option>
<option value="folder1a3" type=directory  view=maximized>Revenge</option>
<option value="folder1a3a" type=object  view=maximized>How to be a 
Jerk</option>
<option value="folder1b4" type=directory  view=maximized>My Music</option>
<option value="folder1b4a" type=object  view=maximized>BeGee's Sing like 
women</option>
<option value="folder1c" type=directory view=maximized>My Pr0n</option>
<option value="folder1c1" type=directory view=minimized 
class="monkeypr0n">Monkies</option>
<option value="folder1c2" type=directory view=minimized>People</option>
</select>

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3182 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20040628/b42bf58d/attachment.bin>
Received on Monday, 28 June 2004 19:09:14 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:58:34 UTC