On Sat, 28 Jan 2006 22:54:07 -, Andreas Boehmer [Addictive Media]
[EMAIL PROTECTED] wrote:
trthFruits/th...
trthspanFruits /spanApple/th...
trthspanFruits /spanOrange/th...
trthspanFruits /spanLemon/th...
The problem with this solution is that it allows for only two levels of
On 1/29/06, Rene Saarsoo [EMAIL PROTECTED] wrote:
There is one usability problem still: the contents of th elements
are centered by default in most browsers, making the table look like
this:
1 Fruits Add Edit Delete
1.1 Apple Add Edit Delete
On Sun, 29 Jan 2006 11:04:07 -, Joshua Street [EMAIL PROTECTED]
wrote:
Not very comprehensible... The solution would be to use td instead:
That's what we have stylesheets for. It's trivial to change the text
alignment of TH elements :-) TH strikes me as being semantically more
sound,
: tabular data with sublevels
Andreas Boehmer [Addictive Media] wrote:
Bert Doorn wrote:
[ select category ] [ add ] [ edit ] [ delete ]
You can have option groups in the select. Example:
form action=whatever
select name=product
option value=Select Product/option
optgroup
Stephen Stagg wrote:
OR. cut a few semantics corners and make all visitors happy by using a
standard nested list approach with [add][edit][delete] as text links
after: Even Lynx users will see this:
Also worth considering as an alternative: break it down into a two-step
process. Show the
Patrick H. Lauke wrote:
Also worth considering as an alternative: break it down into
a two-step
process. Show the nested list, with the items as links. Clicking the
link takes you to the specific page about that item, with options to
add/edit/delete.
Do both: single link for
Well... I agree, that the proposed markup-structure would be
semantically most correct:
ol
liItem 1
ul
liAdd/li
liEdit/li
liDelete/li
/ul
ol
liItem 1.1
ul
liAdd/li
liEdit/li
liDelete/li
/ul
/li
/ol
Rene Saarsoo wrote:
Well... I agree, that the proposed markup-structure would be
semantically most correct:
...
But can you imagine working with that sort of list in a browser
where stylesheets aren't available? For example in Lynx it would
look something like the following:
...
Whats so
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Rene Saarsoo
Sent: Sunday, 29 January 2006 2:35 AM
To: wsg@webstandardsgroup.org
Subject: Re: [WSG] The dilemma: tabular data with sublevels
Whats so wrong with using good-old table... (skipped
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Bert Doorn
Sent: Sunday, 29 January 2006 1:42 AM
To: wsg@webstandardsgroup.org
Subject: Re: [WSG] The dilemma: tabular data with sublevels
Rene Saarsoo wrote:
Well... I agree, that the proposed
On 29/01/2006, at 8:57 AM, Andreas Boehmer [Addictive Media] wrote:
[Add] [Edit] [Delete] Folder 1
[Add] [Edit] [Delete]SubFolder 1
[Add] [Edit] [Delete]SubFolder 2
[Add] [Edit] [Delete]SubSubFolder 1
[Add] [Edit] [Delete]SubSubFolder 2
[Add] [Edit] [Delete]
Andreas Boehmer [Addictive Media] wrote:
Bert Doorn wrote:
[ select category ] [ add ] [ edit ] [ delete ]
You can have option groups in the select. Example:
form action=whatever
select name=product
option value=Select Product/option
optgroup label=Fruits
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Lachlan Hunt
Sent: Sunday, 29 January 2006 10:16 AM
To: wsg@webstandardsgroup.org
Subject: Re: [WSG] The dilemma: tabular data with sublevels
Andreas Boehmer [Addictive Media] wrote:
Bert Doorn
: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Lachlan Hunt
Sent: Sunday, 29 January 2006 10:16 AM
To: wsg@webstandardsgroup.org
Subject: Re: [WSG] The dilemma: tabular data with sublevels
Andreas Boehmer [Addictive Media] wrote:
Bert Doorn wrote:
[ select category
Joshua Street wrote:
The other thing (this list is definitely the wrong place for me to say
this) is if this is for a content management system or the like, where
the client's browsing capabilities are a well known quantity,
What? How can you possibly assume that any user of a CMS will not
Heh, as I said, wrong place to say this.
I meant if the app were being developed for a specific client with
specific (known) requirements/user environment. Obviously there's the
hypothetical what if they hire someone who uses these technologies in
the future who ends up needing to use the CMS,
Andreas Boehmer [Addictive Media] wrote:
Although it's currently impossible with a normal select list,
you can instead use radio buttons or checkboxes within nested lists.
/
Just fill that out with all the necessary attributes and
values, then add some submit buttons for add, edit and delete.
/
At 11:11 PM 1/26/2006, Geoff Pack wrote:
How about this:
style type=text/cssli span {float:right; margin-right:30%;}/style
ul
lispan[ Add | Edit | Delete ] /spanItem 1
I believe the challenge arises when you consider Add/Edit/Delete as a
series of links or buttons and deserving of a
I am tearing my hair out over the decision on how to best format following
data:
We start with a list of items and subitems:
Item 1
- SubItem 1.1
- SubItem 1.1.1
- SubItem 1.1.2
- Subitem 1.2
Item 2
- SubItem 2.1
...
Sounds very much like a collection of LIs, right? Well, the
At 04:46 PM 1/26/2006, Andreas Boehmer [Addictive Media] wrote:
[Add] [Edit] [Delete] Item 1
[Add] [Edit] [Delete] - SubItem 1.1
[Add] [Edit] [Delete] - SubItem 1.1.1
[Add] [Edit] [Delete] - SubItem 1.1.2
[Add] [Edit] [Delete] - SubItem 1.2
...
Andreas,
I could argue either list
You're saying that Add is a definition of Item 1
dtItem 1/dt
dda href=?add=123Add/a/dd
dda href=?edit=123Edit/a/dd
**
The discussion list for http://webstandardsgroup.org/
See
Hmm I'd strongly contest a definition list. Maybe nested UL's would be
better... but Item 1 cannot be sensibly/reasonably _defined_ as Add,
or Edit, or Delete.
On 1/27/06, Paul Novitski [EMAIL PROTECTED] wrote:
Andreas,
I could argue either list or table, but I'd be inclined to make it a
The problem with putting the links into a nested UL is that the list
wouldn't make sense anymore in the end. We would have the subitems in nested
ULs as well as the links. Links and subitems cannot be treated semantically
the same:
li
Item 1
ul
liAdd/li
liEdit/li
At 05:39 PM 1/26/2006, Paul Bennett wrote:
You're saying that Add is a definition of Item 1
dtItem 1/dt
dda href=?add=123Add/a/dd
dda href=?edit=123Edit/a/dd
At 05:44 PM 1/26/2006, Joshua Street wrote:
Hmm I'd strongly contest a definition list. Maybe nested UL's
So is the alternative unstructured content?
liItem 1
a href=#Add/a
a href=#Edit/a
a href=#Delete/a
/li
Maybe a combination of nested ordered and unordered lists would be more
suitable.
ol
liItem 1
ul
liAdd/li
liEdit/li
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Scott Swabey
Sent: Friday, 27 January 2006 2:29 PM
To: wsg@webstandardsgroup.org
Subject: RE: [WSG] The dilemma: tabular data with sublevels
So is the alternative unstructured content
[Addictive Media]
[mailto:[EMAIL PROTECTED]
Sent: Friday, 27 January 2006 11:46 AM
To: wsg@webstandardsgroup.org
Subject: [WSG] The dilemma: tabular data with sublevels
I am tearing my hair out over the decision on how to best format
following
data:
We start with a list of items and subitems:
Item 1
2006 11:46 AM
To: wsg@webstandardsgroup.org
Subject: [WSG] The dilemma: tabular data with sublevels
I am tearing my hair out over the decision on how to best
format following
data:
We start with a list of items and subitems:
Item 1
- SubItem 1.1
- SubItem 1.1.1
- SubItem
28 matches
Mail list logo