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>
<li>Add</li>
<li>Edit</li>
<li>Delete</li>
</ul>
<ul>
<li>SubItem 1.1</li>
</ul>
</li>
The definition list manages to treat the links differently, but of course
they really are no definition. We need a whole new animal here, I think:
<li>
Item 1
<XYZ>
<item>Add</item>
<item>Edit</item>
<item>Delete</item>
</XYZ>
<ul>
<li>SubItem 1.1</li>
</ul>
</li>
What to use for XYZ, I guess is the question.
> [mailto:[EMAIL PROTECTED] On Behalf Of Joshua Street
> 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
> > list. I see the three editing functions being part of each
> list item:
> >
> > <ul>
> > <li>
> > <dl>
> > <dt>Item 1</dt>
> > <dd><a href="?add=123">Add</a></dd>
> > <dd><a href="?edit=123">Edit</a></dd>
> > <dd><a href="?delete=123">Delete</a></dd>
> > </dl>
> > </li>
> > ...
> > </ul>
> >
> > This might seem taggy, but doesn't take a whole lot more
> markup than a
> > table would. Nesting the ULs will also maintain the semantic
> > structure of the complex list.
> >
******************************************************
The discussion list for http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list & getting help
******************************************************
