Re: [WSG] The dilemma: tabular data with sublevels
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 hierarchy (parents:children = fruit:apples). But the application we are building is more like a file/folder structure in Windows Explorer - it can have an endless number of levels. Every folder can have a subfolder. So you need more levels... What if you just use some simple numbering: trthspan1 /spanFruits/th... trthspan1.1 /spanApple/th... trthspan1.1.1 /spanRed apple/th... trthspan1.1.2 /spanGreen apple/th... trthspan1.1.2.1 /spanExtra green apple/th... trthspan1.1.2.2 /spanMedium green apple/th... trthspan1.2 /spanOrange/th... trthspan1.3 /spanLemon/th... This should make the hierarchy pretty clean to both screenreader and text-browser users. 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 1.1.1 Red apple Add Edit Delete 1.1.2 Green apple Add Edit Delete 1.1.2.1 Extra green apple Add Edit Delete 1.1.2.2 Medium green apple Add Edit Delete 1.2 Orange Add Edit Delete 1.3 Lemon Add Edit Delete Not very comprehensible... The solution would be to use td instead: 1 Fruits Add Edit Delete 1.1 Apple Add Edit Delete 1.1.1 Red appleAdd Edit Delete 1.1.2 Green apple Add Edit Delete 1.1.2.1 Extra green apple Add Edit Delete 1.1.2.2 Medium green apple Add Edit Delete 1.2 Orange Add Edit Delete 1.3 Lemon Add Edit Delete Maybe it makes the table a bit harder to understand for screenreader users, but it surely adds clarity to all the other users. Hopefully it doesn't make me look like someone who is very into table-based solutions :) Rene Saarsoo ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] The dilemma: tabular data with sublevels
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 1.1.1 Red apple Add Edit Delete 1.1.2 Green apple Add Edit Delete 1.1.2.1 Extra green apple Add Edit Delete 1.1.2.2 Medium green apple Add Edit Delete 1.2 Orange Add Edit Delete 1.3 Lemon Add Edit Delete Not very comprehensible... The solution would be to use td instead: 1 Fruits Add Edit Delete 1.1 Apple Add Edit Delete 1.1.1 Red appleAdd Edit Delete 1.1.2 Green apple Add Edit Delete 1.1.2.1 Extra green apple Add Edit Delete 1.1.2.2 Medium green apple Add Edit Delete 1.2 Orange Add Edit Delete 1.3 Lemon Add Edit Delete Maybe it makes the table a bit harder to understand for screenreader users, but it surely adds clarity to all the other users. 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, particularly if you give them ID's and set the headers attribute in your corresponding TD cells accordingly. Josh ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] The dilemma: tabular data with sublevels
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, particularly if you give them ID's and set the headers attribute in your corresponding TD cells accordingly. The whole point was to make it more usable in browsers with no CSS support. But you can also give ID-s to TD elements and reference those with headers attribute: tr td id=header-1span1 /spanFruits/td td headers=header-1Add/td td headers=header-1Delete/td td headers=header-1Edit/td /tr Actually, according to HTML 4.01 secification, using TD for headers is quite OK (http://www.w3.org/TR/html4/struct/tables.html#h-11.2.6): TH is for headers, TD for data, but for cells acting as both use TD Rene ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] The dilemma: tabular data with sublevels
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: liItemX a href=[add]/anbsp;a/a ulliItem X.Y a href=[add]/anbsp;a/a/li ... ... liItem X.Z.D.E.E.Pa href=[add]/anbsp;a/a/li /ul On 28 Jan 2006, at 23:25, Andreas Boehmer [Addictive Media] wrote: -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 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 optionApple/option optionOrange/option optionLemon/option /optgroup ... /form The problem is that we are not only allowing to add/edit/delete one level of the hierarchy, but all of them. Imagine it more to be like this: [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]SubFolder 3 [Add] [Edit] [Delete] Folder 2 Although it's currently impossible with a normal select list, you can instead use radio buttons or checkboxes within nested lists. ol lilabelinput type=radio Fruits/label ol lilabelinput type=radio Appleslabel lilabelinput type=radio Orangeslabel lilabelinput type=radio Lemonlabel /li li.../li /ol Just fill that out with all the necessary attributes and values, then add some submit buttons for add, edit and delete. I have considered this possibility, but to be honest I find it not as user-friendly as the other solution. In particular if the list of items is very long, users will have to tick the radio button and then scroll to the end of the page (or the beginning) to find the button. So I am facing the question: make it user-friendly for the larger audience or make it user-friendly for users of browsers that cannot display style sheets. I am tending towards the first. ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help ** ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] The dilemma: tabular data with sublevels
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 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. P -- Patrick H. Lauke __ re·dux (adj.): brought back; returned. used postpositively [latin : re-, re- + dux, leader; see duke.] www.splintered.co.uk | www.photographia.co.uk http://redux.deviantart.com __ Web Standards Project (WaSP) Accessibility Task Force http://webstandards.org/ __ ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
RE: [WSG] The dilemma: tabular data with sublevels
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 accessibility and old browsers, some DOM scripting to add all the links for the rest. e.g. http://www.dhillon-pack.net/editMenuList.htm cheers, Geoff ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] The dilemma: tabular data with sublevels
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 /li /ol 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: 1. Fruits + Add + Edit + Delete 1. Apple o Add o Edit o Delete 2. Orange o Add o Edit o Delete 3. Lemon o Add o Edit o Delete 2. Vegetables + Add + Edit + Delete 1. Carrot o Add o Edit o Delete If this web page is meant to be used mainly for adding, editing and deleting, then it's one quite uncomfortable user experience at least. (There are 6 items in the list above - imagine 60!!!) Whats so wrong with using good-old table... (skipped summary attribute and possibly more, that should be added): table trthFruits/th tdAdd/td tdEdit/td tdDelete/td/tr trthApple/th tdAdd/td tdEdit/td tdDelete/td/tr trthOrange/th tdAdd/td tdEdit/td tdDelete/td/tr trthLemon/th tdAdd/td tdEdit/td tdDelete/td/tr trthVegetables/th tdAdd/td tdEdit/td tdDelete/td/tr trthCarrot/th tdAdd/td tdEdit/td tdDelete/td/tr /table Well you need to maintain the hierarchy... so... what if you just add some extra hierarchical information: trthFruits/th... trthspanFruits /spanApple/th... trthspanFruits /spanOrange/th... trthspanFruits /spanLemon/th... The result in Lynx would: FruitsAdd Edit Delete Fruits AppleAdd Edit Delete Fruits Orange Add Edit Delete Fruits LemonAdd Edit Delete Vegetables Add Edit Delete Vegetables Carrot Add Edit Delete Well.. at least what I think. Rene Saarsoo ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] The dilemma: tabular data with sublevels
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 wrong with using good-old table... (skipped summary attribute and possibly more, that should be added): If it gets that complicated I'd rethink the setup. For instance, rather than having all those links, lists, tables etc I'd use a simple form with select and 3 submit buttons. [ 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 optionApple/option optionOrange/option optionLemon/option /optgroup optgroup label=Vegetables optionCarrot/option optionCabbage/option optionBeans/option /optgroup /select input type=submit value=Add/ input type=submit value=Edit/ input type=submit value=Delete/ /form But perhaps I misunderstand the function of the page in question. Regards -- Bert Doorn, Better Web Design http://www.betterwebdesign.com.au/ Fast-loading, user-friendly websites ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
RE: [WSG] The dilemma: tabular data with sublevels
-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 summary attribute and possibly more, that should be added): table trthFruits/th tdAdd/td tdEdit/td tdDelete/td/tr trthApple/th tdAdd/td tdEdit/td tdDelete/td/tr trthOrange/th tdAdd/td tdEdit/td tdDelete/td/tr trthLemon/th tdAdd/td tdEdit/td tdDelete/td/tr trthVegetables/th tdAdd/td tdEdit/td tdDelete/td/tr trthCarrot/th tdAdd/td tdEdit/td tdDelete/td/tr /table Well you need to maintain the hierarchy... so... what if you just add some extra hierarchical information: trthFruits/th... trthspanFruits /spanApple/th... trthspanFruits /spanOrange/th... trthspanFruits /spanLemon/th... The result in Lynx would: FruitsAdd Edit Delete Fruits AppleAdd Edit Delete Fruits Orange Add Edit Delete Fruits LemonAdd Edit Delete Vegetables Add Edit Delete Vegetables Carrot Add Edit Delete The problem with this solution is that it allows for only two levels of hierarchy (parents:children = fruit:apples). But the application we are building is more like a file/folder structure in Windows Explorer - it can have an endless number of levels. Every folder can have a subfolder. ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
RE: [WSG] The dilemma: tabular data with sublevels
-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 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 wrong with using good-old table... (skipped summary attribute and possibly more, that should be added): If it gets that complicated I'd rethink the setup. For instance, rather than having all those links, lists, tables etc I'd use a simple form with select and 3 submit buttons. [ 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 optionApple/option optionOrange/option optionLemon/option /optgroup optgroup label=Vegetables optionCarrot/option optionCabbage/option optionBeans/option /optgroup /select input type=submit value=Add/ input type=submit value=Edit/ input type=submit value=Delete/ /form The problem is that we are not only allowing to add/edit/delete one level of the hierarchy, but all of them. Imagine it more to be like this: [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]SubFolder 3 [Add] [Edit] [Delete] Folder 2 This kind of interface is impossible to recreate with a simple select box. ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] The dilemma: tabular data with sublevels
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]SubFolder 3 [Add] [Edit] [Delete] Folder 2 The other option, from an interface point of view rather than standards/semantics, is selection: [ ] Folder 1 [ ]SubFolder 1 [ ]SubFolder 2 [ ]SubSubFolder 1 [ ]SubSubFolder 2 [ ]SubFolder 3 [ ] Folder 2 [Add] [Edit] [Delete] The main 'hard choice' with that layout is 'radio button' or 'checkbox'? Just an option :) HIH Lea -- Lea de Groot Elysian Systems Brisbane, Australia ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] The dilemma: 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 label=Fruits optionApple/option optionOrange/option optionLemon/option /optgroup ... /form The problem is that we are not only allowing to add/edit/delete one level of the hierarchy, but all of them. Imagine it more to be like this: [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]SubFolder 3 [Add] [Edit] [Delete] Folder 2 Although it's currently impossible with a normal select list, you can instead use radio buttons or checkboxes within nested lists. ol lilabelinput type=radio Fruits/label ol lilabelinput type=radio Appleslabel lilabelinput type=radio Orangeslabel lilabelinput type=radio Lemonlabel /li li.../li /ol Just fill that out with all the necessary attributes and values, then add some submit buttons for add, edit and delete. -- Lachlan Hunt http://lachy.id.au/ ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
RE: [WSG] The dilemma: tabular data with sublevels
-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 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 optionApple/option optionOrange/option optionLemon/option /optgroup ... /form The problem is that we are not only allowing to add/edit/delete one level of the hierarchy, but all of them. Imagine it more to be like this: [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]SubFolder 3 [Add] [Edit] [Delete] Folder 2 Although it's currently impossible with a normal select list, you can instead use radio buttons or checkboxes within nested lists. ol lilabelinput type=radio Fruits/label ol lilabelinput type=radio Appleslabel lilabelinput type=radio Orangeslabel lilabelinput type=radio Lemonlabel /li li.../li /ol Just fill that out with all the necessary attributes and values, then add some submit buttons for add, edit and delete. I have considered this possibility, but to be honest I find it not as user-friendly as the other solution. In particular if the list of items is very long, users will have to tick the radio button and then scroll to the end of the page (or the beginning) to find the button. So I am facing the question: make it user-friendly for the larger audience or make it user-friendly for users of browsers that cannot display style sheets. I am tending towards the first. ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] The dilemma: tabular data with sublevels
Select with Optgroups? Tables with (assuming two levels), a structure like this: tr th id=fruit colspan=2Fruit/thtdAdd/td tdEdit/td tdDelete/td /tr tr td/tdth headers=fruitApple/thtdAdd/td tdEdit/td tdDelete/td /tr etc? 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, perhaps it would make sense just to cater for that in whatever way works best for them, and not worry too much about broader Accessibility. For example, it's unlikely a client would be using Lynx to update their website. If the audience is known here, usability should (IMO) win over absolutely universal accessibility -- only for back-end systems, though. Josh On 1/29/06, Andreas Boehmer [Addictive Media] [EMAIL PROTECTED] wrote: -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 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 optionApple/option optionOrange/option optionLemon/option /optgroup ... /form The problem is that we are not only allowing to add/edit/delete one level of the hierarchy, but all of them. Imagine it more to be like this: [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]SubFolder 3 [Add] [Edit] [Delete] Folder 2 Although it's currently impossible with a normal select list, you can instead use radio buttons or checkboxes within nested lists. ol lilabelinput type=radio Fruits/label ol lilabelinput type=radio Appleslabel lilabelinput type=radio Orangeslabel lilabelinput type=radio Lemonlabel /li li.../li /ol Just fill that out with all the necessary attributes and values, then add some submit buttons for add, edit and delete. I have considered this possibility, but to be honest I find it not as user-friendly as the other solution. In particular if the list of items is very long, users will have to tick the radio button and then scroll to the end of the page (or the beginning) to find the button. So I am facing the question: make it user-friendly for the larger audience or make it user-friendly for users of browsers that cannot display style sheets. I am tending towards the first. ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] The dilemma: tabular data with sublevels
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 have accessibility requirements? Is there some restriction on the web that I don't know about in which users of Lynx, JAWS or other assistive technology can't publish on the web, and therefore have no use for a CMS? -- Lachlan Hunt http://lachy.id.au/ ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] The dilemma: tabular data with sublevels
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, but that may not be a concern depending on the business and anticipated life cycle of the product. I did most emphatically NOT suggest this as a blanket approach, and never would. It was practical advice that may or may not have been useful depending on circumstances best evaluated by Andreas, nothing more. On 1/29/06, Lachlan Hunt [EMAIL PROTECTED] wrote: 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 have accessibility requirements? Is there some restriction on the web that I don't know about in which users of Lynx, JAWS or other assistive technology can't publish on the web, and therefore have no use for a CMS? -- Lachlan Hunt http://lachy.id.au/ ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] The dilemma: tabular data with sublevels
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. / I have considered this possibility, but to be honest I find it not as user-friendly as the other solution. In particular if the list of items is very long, users will have to tick the radio button and then scroll to the end of the page (or the beginning) to find the button. Precisely the kind of problematic UI design that AJAX addresses -- click/check a button and it's done, no [submit] necessary. :-) -- Hassan Schroeder - [EMAIL PROTECTED] Webtuitive Design === (+1) 408-938-0567 === http://webtuitive.com dream. code. ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
RE: [WSG] The dilemma: tabular data with sublevels
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 structure to contain
them. If you mark it up like this:
a href=#Add/a | a href=#Edit/a | a href=#Delete/a
...then the presentational relationship of the three is determined by
the HTML markup and difficult or impossible to modify with CSS.
For that reason it makes sense to wholly contain them so they can be
visually presented in a variety of ways merely by tweaking the stylesheet:
taga href=#Add/a/tag
taga href=#Edit/a/tag
taga href=#Delete/a/tag
If the tag that contains them is simply a span or p, it's a kind of
tag soup: enough markup to be able to apply styles, but with no
internal structural meaning.
Hence the attempt to find a coherent structure such as a list that
makes sense in context. Personally I think Scott's suggestion of an
OL nest for the fundamental list and child ULs for the buttons is the
best that's been offered so far.
Paul
**
The discussion list for http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list getting help
**
[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 1.1.2 - Subitem 1.2 Item 2 - SubItem 2.1 ... Sounds very much like a collection of LIs, right? Well, the problem is that for each Item and SubItem we will have links that allow the user to edit them: [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 ... Now to me that looks like a table with column headings Add, Edit, Delete, Item Name. But if I do that I will loose the logic of the lists, which really should remain. Hmmm. I really cannot come up with a sensible solutions for this, that does not involve a ridiculous amount of tags. Any suggestions? Thanks! ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] The dilemma: tabular data with sublevels
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 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 dtItem 1/dt dda href=?add=123Add/a/dd dda href=?edit=123Edit/a/dd dda href=?delete=123Delete/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. Paul ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
RE: [WSG] The dilemma: tabular data with sublevels
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 http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] The dilemma: tabular data with sublevels
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 dtItem 1/dt dda href=?add=123Add/a/dd dda href=?edit=123Edit/a/dd dda href=?delete=123Delete/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. Paul ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
RE: [WSG] The dilemma: tabular data with sublevels
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 liDelete/li /ul ul liSubItem 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 itemAdd/item itemEdit/item itemDelete/item /XYZ ul liSubItem 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 dtItem 1/dt dda href=?add=123Add/a/dd dda href=?edit=123Edit/a/dd dda href=?delete=123Delete/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 **
RE: [WSG] The dilemma: tabular data with sublevels
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 would be better... but Item 1 cannot be sensibly/reasonably _defined_ as Add, or Edit, or Delete. You're doubtless correct... but... to be picky, the HTML 4.01 spec says that dd is a description: Definition lists vary only slightly from other types of lists in that list items consist of two parts: a term and a description. http://www.w3.org/TR/html4/struct/lists.html#h-10.3 Can an action verb that applies to an object be considered to be part of a description of that object? Hmm, I suppose it is a stretch. So is the alternative unstructured content? liItem 1 a href=#Add/a a href=#Edit/a a href=#Delete/a /li *Sigh* Paul ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
RE: [WSG] The dilemma: tabular data with sublevels
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 liDelete/li /ul ol liItem 1.1 ul liAdd/li liEdit/li liDelete/li /ul /li /ol /li /ol Whereby you have an ordered list of items, and each item can have a related unordered list of actions, an ordered lists or sub-items, each of which can in turn have it's own related unordered list of actions and ordered list of sub-items. Regards Scott Swabey Design Development Director Lafinboy Productions www.lafinboy.com ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
RE: [WSG] The dilemma: tabular data with sublevels
-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? 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 liDelete/li /ul ol liItem 1.1 ul liAdd/li liEdit/li liDelete/li /ul /li /ol /li /ol Whereby you have an ordered list of items, and each item can have a related unordered list of actions, an ordered lists or sub-items, each of which can in turn have it's own related unordered list of actions and ordered list of sub-items. Yes, I have got the feeling this is the best solution. I already tried this one, but did it other way around (ordered list for te links). But having a look at your solution I prefer to give the Items and Subitems the ordered list and the links the unordered list. Thanks for all the comments, guys! ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
RE: [WSG] The dilemma: tabular data with sublevels
Could you do something like ul liItem 1 div class=editfunctions[Add] [Edit] [Delete]/div/li ul liSubitem 1.1 div class=editfunctions[Add] [Edit] [Delete]/div/li ... /ul ... /ul and use css positioning to move the div to the left of the list? -Original Message- From: Andreas Boehmer [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 - 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 problem is that for each Item and SubItem we will have links that allow the user to edit them: [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 ... Now to me that looks like a table with column headings Add, Edit, Delete, Item Name. But if I do that I will loose the logic of the lists, which really should remain. Hmmm. I really cannot come up with a sensible solutions for this, that does not involve a ridiculous amount of tags. Any suggestions? Thanks! ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help ** ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
RE: [WSG] The dilemma: tabular data with sublevels
How about this:
style type=text/cssli span {float:right; margin-right:30%;}/style
ul
lispan[ Add | Edit | Delete ] /spanItem 1
ul
lispan[ Add | Edit | Delete ] /spanSubItem 1.1
ul
lispan[ Add | Edit | Delete ] /spanSubItem 1.1.1/li
lispan[ Add | Edit | Delete ] /spanSubItem 1.1.2/li
/ul
/li
lispan[ Add | Edit | Delete ] /spanSubItem 1.2/li
/ul
/li
lispan[ Add | Edit | Delete ] /spanItem 2
ul
lispan[ Add | Edit | Delete ] /spanSubItem 2.1/li
/ul
/li
/ul
You could even do a little DOM scripting to add the edit menu dynamically when
an item is clicked.
cheers,
Geoff
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Andreas Boehmer
[Addictive Media]
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
- 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
problem is that
for each Item and SubItem we will have links that allow the
user to edit
them:
[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
...
Now to me that looks like a table with column headings Add, Edit,
Delete, Item Name. But if I do that I will loose the
logic of the lists,
which really should remain.
Hmmm. I really cannot come up with a sensible
solutions for this,
that does not involve a ridiculous amount of tags.
Any suggestions?
Thanks!
**
The discussion list for http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list getting help
**
**
The discussion list for http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list getting help
**
