SitePoint Sponsor

User Tag List

Results 1 to 23 of 23
  1. #1
    SitePoint Enthusiast DavidChildress's Avatar
    Join Date
    Jun 2009
    Posts
    39
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Wrapping form controls in <ol> ordered lists or <div> tags?

    Wrapping form controls in <ol>ordered lists or <div> tags.

    In "Learning Web Design" 3rd edition(2007), Jennifer Robbins states that current best practice[s are] to wrap form controls in lists...most commonly ordered lists since it makes it easier to format the form using style sheets later.

    I notice that Lloyd 2nd ed(2008)and Carey are using the <div> tag and Wendy Willard 3rd edition(2007) occasionally employs table tags <tr> &<td> and uses no wrapping at all in other cases.


    Any compelling reasons to choose one over the other or would exigent circumstances dictate one's choice?

  2. #2
    Programming Since 1978 silver trophybronze trophy felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, NSW, Australia
    Posts
    16,875
    Mentioned
    25 Post(s)
    Tagged
    1 Thread(s)
    Each person just has a different opinion as to the relationship between the form fields and therefore what the most appropriate semantic markup for a form would be.

    If you think it is tabular data then use a table.
    If you think it is a list then use a list.
    If you think it is neither then use div tags.
    Stephen J Chapman

    javascriptexample.net, Book Reviews, follow me on Twitter
    HTML Help, CSS Help, JavaScript Help, PHP/mySQL Help, blog
    <input name="html5" type="text" required pattern="^$">

  3. #3
    SitePoint Wizard silver trophybronze trophy
    Join Date
    Jul 2008
    Location
    New York, NY
    Posts
    1,432
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    @DavidChildress

    Stephen is right, everyone has their own opinions.

    I personally wouldn't use an ordered list.

    To add appropriate semantic richness, use an unordered list.

  4. #4
    SitePoint Author silver trophybronze trophy

    Join Date
    Nov 2004
    Location
    Ankh-Morpork
    Posts
    12,158
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Very, very few forms are semantically a list of form control. Ordered or unordered. It's a sequence, but that's not the same as a list.

    Here's a lithmus test for deciding whether or not to use a list to enclose form controls:

    Would the form look weird or incomprehensible unstyled, i.e., with numbers or bullet points before each label/input pair? If so, it's not a list.

    I use fieldsets to group related form controls, and usually just a <br> before the labels – no need for wrapping anything.
    Birnam wood is come to Dunsinane

  5. #5
    SitePoint Wizard silver trophybronze trophy
    Join Date
    Jul 2008
    Location
    New York, NY
    Posts
    1,432
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    A sequence is an ordered list, correct?

    I was thinking since there is a 'list' of form controls that could be in any order, that an unordered list would best be fit for the job.

    I am using the word list as a series of words in this case....

    If you say it's not a list, i'll take your word on this

  6. #6
    SitePoint Author silver trophybronze trophy

    Join Date
    Nov 2004
    Location
    Ankh-Morpork
    Posts
    12,158
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by cooper.semantics View Post
    A sequence is an ordered list, correct?
    No. A sequence is a number of things occurring one after the other, without necessarily being a list at all. A sentence is a sequence of words, but it's not a list of words.

    I once wrote an article about lists that attempts to explain the difference between lists and sequences. It might be helpful.
    Birnam wood is come to Dunsinane

  7. #7
    SitePoint Wizard Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,287
    Mentioned
    51 Post(s)
    Tagged
    2 Thread(s)
    Problem is, in Engrish (and other languages) we say "please fill in the following list of questions" and in many other places refer to questionaires and forms as lists.

    I figured a grocery list is a list and not a sequence because all the items are at the grocery store and involve tasks. But all the form controls also belong under some idea as well.

    There are lists I don't feel comfortable using bullets with, like breadcrumbs (which, I think are lists, because they're paths). *edit hmmm maybe a path isn't a list? I wouldn't add bullets to /etc/usr/bin/app... I wonder if the better test for me is, could it have a semi-colon pause at the end of it? A grocery list certainly can:
    coffee;
    tea;
    chocolate;

    a path can't though...

    and forms, yeah they could though it would look JSON-y : )
    name: (blank);
    address: (blank);
    postcode: (blank);

    and of course, after they get filled in, they get turned into definition lists:
    name=>Joe;
    address=>Hondenpoelaan 5;
    postcode=>1100 KK;


    Even so, I don't use lists in forms because that's sugar for novice CSSers I think. It's easier to style a list than loose form controls. I think people were able to convince themselves that a list made sense, and then could go along with style tutorials.

  8. #8
    SitePoint Enthusiast DavidChildress's Avatar
    Join Date
    Jun 2009
    Posts
    39
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Thank you all very much... I enjoy reading the posts in this forum and feel fortunate to have been directed here to this site by SitePoint authors, Ian Lloyd and Jason Beaird .


    From some of the threads/posts that I've seen here and some of the spirited, yet friendly debate I've observed among the peer-recognized SitePoint experts, I'm beginning to think that ONE appropriate job description of the "Web Designer/Developer" would be "problem solver".

    Again, thanks

  9. #9
    SitePoint Wizard silver trophybronze trophy
    Join Date
    Jul 2008
    Location
    New York, NY
    Posts
    1,432
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by AutisticCuckoo View Post
    No. A sequence is a number of things occurring one after the other, without necessarily being a list at all. A sentence is a sequence of words, but it's not a list of words.

    I once wrote an article about lists that attempts to explain the difference between lists and sequences. It might be helpful.
    Good read Tommy!

    Quote Originally Posted by Stomme poes View Post
    Even so, I don't use lists in forms because that's sugar for novice CSSers I think. It's easier to style a list than loose form controls. I think people were able to convince themselves that a list made sense, and then could go along with style tutorials.
    I'd think novices would rather use divs haha, since they use divs for everything else...

    I'd rather use a <br> inbetween form fields then wrapping divs in this sense...

    W3C it seems advocates p tags for wrapping form fields
    Last edited by cooper.semantics; Jul 23, 2009 at 13:45.

  10. #10
    I meant that to happen silver trophybronze trophy Raffles's Avatar
    Join Date
    Sep 2005
    Location
    Tanzania
    Posts
    4,662
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Does HTML5 have a <sequence> element? Even if it doesn't, you could create it with JavaScript and style it accordingly.

  11. #11
    SitePoint Author silver trophybronze trophy

    Join Date
    Nov 2004
    Location
    Ankh-Morpork
    Posts
    12,158
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Stomme poes View Post
    Problem is, in Engrish (and other languages) we say "please fill in the following list of questions" and in many other places refer to questionaires and forms as lists.
    Ah, but there's a difference between casual language and specific jargon. You can also refer to something as a 'form' even though it wouldn't be marked up with <form> in the HTML markup.

    A questionnaire may be a list of questions (but it doesn't have to be). If some questions refer to previous questions, it would make sense to have them numbered and since the order of the questions affect the meaning of the questionnaire as a whole, it's clearly an ordered list.

    Quote Originally Posted by Stomme poes View Post
    I figured a grocery list is a list and not a sequence because all the items are at the grocery store and involve tasks. But all the form controls also belong under some idea as well.
    A grocery list is an unordered list (it's also a sequence, since a list is a sub-class of sequences). Some forms can be correctly marked up as lists, but they are few and far between.

    Quote Originally Posted by Stomme poes View Post
    There are lists I don't feel comfortable using bullets with, like breadcrumbs (which, I think are lists, because they're paths).
    I mark up breadcrumbs as ordered lists. It is a list of structural levels (or pages visited) and the order affects the meaning as a whole. Thus it should be an <ol>. Think of it as, 'You are here: Top level; secondary level; tertiary level; ...'

    Quote Originally Posted by Stomme poes View Post
    *edit hmmm maybe a path isn't a list? I wouldn't add bullets to /etc/usr/bin/app...
    No, I wouldn't say a path is a list. It's a sequence of directory names separated by slashes (or backslashes in some inferior operating systems ). The default rendering of an unordered list would be to put one directory name per line with a bullet preceding it, and that's not a valid path. Therefore it's not a list.

    Quote Originally Posted by Stomme poes View Post
    and forms, yeah they could though it would look JSON-y : )
    name: (blank);
    address: (blank);
    postcode: (blank);
    No, you're thinking presentationally. Displaying these fields inline wouldn't affect the meaning of the form, although it might be detrimental to usability.

    name: (blank) - address: (blank) - postcode: (blank)

    Quote Originally Posted by Stomme poes View Post
    and of course, after they get filled in, they get turned into definition lists:
    name=>Joe;
    address=>Hondenpoelaan 5;
    postcode=>1100 KK;
    Or a single-row table, which is more likely, unless you only ever expect to have a single person fill in the form.
    Birnam wood is come to Dunsinane

  12. #12
    SitePoint Wizard Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,287
    Mentioned
    51 Post(s)
    Tagged
    2 Thread(s)
    Quote Originally Posted by cooper
    W3C it seems advocates p tags for wrapping form fields
    Yeah I noticed that, but I also remember that was written like 10 years ago or whatever, before the Web Standards Evangelical Movement decided on different elements for semantics : )

    Quote Originally Posted by Tommy
    I mark up breadcrumbs as ordered lists.
    Hm, I hadn't thought of that before, and it makes sense from a direction standpoint. But I've always seen breadcrumbs as paths, even if you can jump directly to any "level" in between. I mean, to me it was always
    home > animals > bears > polar, File > Edit > Preferences > Internets,
    which is the same to me as /home/poes/BureauBlad/muziek.

    Is a breadcrumb a path that, for the user, we're marking up as an ordered list? Or am I taking the name "breadcrumb" too far?

    ...or backslashes in some inferior operating systems
    Lawlz, ++

    name: (blank) - address: (blank) - postcode: (blank)
    Since I'm starting to see name-value pairs as hashes, and because hashes are a type of list, I'm probably seeing these more and more as special types of lists. Semantically, anyway. I still don't have to mark up my forms in lists, because of course the labels and inputs already have that relationship between each other.

    Or a single-row table, which is more likely, unless you only ever expect to have a single person fill in the form.
    Most forms who display results back to the single user are of course only filled in by a single user... but yes where you store everyone's filled-in forms would be, at the least, a database table : ) And yes if for whatever reason multiple users' responses were displayed, I'd prolly also use a table, since now we can have headers for the (now collection of) user names, and labels on the sides.

    No, wait, it's a list of hashes! A list of lists! Which flatten into a table! : )
    (been reading too much Llama)

  13. #13
    SitePoint Author silver trophybronze trophy

    Join Date
    Nov 2004
    Location
    Ankh-Morpork
    Posts
    12,158
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Stomme poes View Post
    But I've always seen breadcrumbs as paths, even if you can jump directly to any "level" in between.
    There are two kinds of breadcrumbs.

    One – the most common type, I think – simply shows the hierarchical structure of the site from the root to the current page. It's not really a path, since the components are usually document titles rather than subdirectory names (as in 'About Us' instead of 'about_us').

    The other is more deserving of the name breadcrumbs, because it shows exactly the path you took to get where you are. It's essentially a visual representation of your Back button history within the site.

    Either way, I think both models should be represented by an ordered list. They show a list of steps for getting to the current location.

    Quote Originally Posted by Stomme poes View Post
    Most forms who display results back to the single user are of course only filled in by a single user... but yes where you store everyone's filled-in forms would be, at the least, a database table : )
    Precisely. And that indicates that the information is, in fact, tabular. The circumstance that you only fill in one record at a time doesn't really change the underlying semantics.
    Birnam wood is come to Dunsinane

  14. #14
    SitePoint Wizard Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,287
    Mentioned
    51 Post(s)
    Tagged
    2 Thread(s)
    But is it a table with just one entry? (semantically, not databasey)

    once I asked my husband how you could have an emptyList(). he was like, easy, it's like an empty CD rack. And I was like, wait, doesn't the term "list" imply plural? Like, family and other words, if there's just one member the word doesn't quite work.

  15. #15
    SitePoint Author silver trophybronze trophy

    Join Date
    Nov 2004
    Location
    Ankh-Morpork
    Posts
    12,158
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Whether you show one record or many doesn't affect the semantics.

    And in (X)HTML you can't have an empty list. The DTDs require at least one list item in a list.
    Birnam wood is come to Dunsinane

  16. #16
    SitePoint Wizard silver trophybronze trophy
    Join Date
    Jul 2008
    Location
    New York, NY
    Posts
    1,432
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Stomme poes View Post
    Yeah I noticed that, but I also remember that was written like 10 years ago or whatever, before the Web Standards Evangelical Movement decided on different elements for semantics : )
    Yeah, the entire spec. is about 10 years old...

    Some people still wrap form fields with the p element.

  17. #17
    SitePoint Addict
    Join Date
    Apr 2001
    Location
    Devon, UK
    Posts
    333
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Crikey - this is a long discussion. Is my form a list? Is it structured? Is it unordered?

    IMHO, it doesn't matter. HTML doesn't provide any definitive semantic way of separating form labels/fields so use <div>, <li>, or <p> as you prefer. I'd just suggest you keep it consistent.

    <table> is out unless the fields are for a table of updatable data.

    I'm not sure about <br/> though. It offers less flexibility for CSS styling because a label/field cannot be treated as a block. That may not be important for semantics, but it will be when you style your page.

  18. #18
    SitePoint Author silver trophybronze trophy

    Join Date
    Nov 2004
    Location
    Ankh-Morpork
    Posts
    12,158
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by ceeb View Post
    IMHO, it doesn't matter. HTML doesn't provide any definitive semantic way of separating form labels/fields so use <div>, <li>, or <p> as you prefer. I'd just suggest you keep it consistent.
    Yes, it does matter. The purpose of HTML is to convey the structure and the semantics of a document. Stating that something is a list when it isn't, is just as bad as stating that something is a table when it isn't.

    HTML provides two mechanisms for associating a label and an input field: implicit/nesting (<label><input></label>) or explicit (<label for="x"></label> <input id="x">). And that association separates the label/input pair from all other label/input pairs.

    If you need to wrap them in a container for styling purposes, use a semantically appropriate one if one exists, or else a <div>.

    Quote Originally Posted by ceeb View Post
    I'm not sure about <br/> though. It offers less flexibility for CSS styling because a label/field cannot be treated as a block. That may not be important for semantics, but it will be when you style your page.
    As I said, if you need a wrapping container, then use one. If you don't, you can still use a wrapping container or you can use a <br>. It's a matter of choice (and a small amount of bloat).

    A simple 'two-column' form (labels on the left, inputs on the right) don't need such containers, but more complex ones may.

    Code HTML4Strict:
    <fieldset>
      <legend>Legend</legend>
     
      <label for="a">Label 1</label> <input type="text" id="a">
      <br><label for="b">Label 2</label> <input type="text" id="b">
      <br><label for="c">Label 3</label> <input type="text" id="c">
    </fieldset>
    Code CSS:
    fieldset {position:relative; padding-left:5em}
    label {position:absolute; left:0}
    Firefox has some bugs that makes it a little bit more complicated than that in real life, but that's an aside.

    If you have short input fields where you want the label above the field and several such pairs laid out horizontally, you can do it this way (although it can cause accessibility problems with Window-Eyes, iirc),
    Code HTML4Strict:
    <fieldset>
      <legend>Legend</legend>
     
      <label for="a">Label 1 <input type="text" id="a"></label>
      <label for="b">Label 2 <input type="text" id="b"></label>
      <label for="c">Label 3 <input type="text" id="c"></label>
    </fieldset>
    Code CSS:
    label {float:left; width:5em}
    label+label {margin-left:1em}
    label input[type="text"] {display:block; width:100&#37;}
    Birnam wood is come to Dunsinane

  19. #19
    SitePoint Addict
    Join Date
    Apr 2001
    Location
    Devon, UK
    Posts
    333
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by AutisticCuckoo View Post
    Yes, it does matter. The purpose of HTML is to convey the structure and the semantics of a document. Stating that something is a list when it isn't, is just as bad as stating that something is a table when it isn't.
    Some great information there, but I think it's possible to get a little over-analytical on the semantics side. A table of data must obviously use a table.

    A form consists of questions and answer boxes. Most forms could have numeric question prefixes or define a specific order - an ordered list certainly appears to be a valid choice. There are probably good arguments to support <dl> too - a form defines the 'terms' and the user supplies the 'definitions'.

    The form, fieldset, labels and input controls already provide a good semantic meaning for your document. However, HTML does not currently give us definitive semantic structures for separating label/input controls. Your recipe lists are great examples but, sometimes, the distinction between sequences, sets, lists (ordered or unordered) is not so clear cut and interpretations will differ.

  20. #20
    SitePoint Author silver trophybronze trophy

    Join Date
    Nov 2004
    Location
    Ankh-Morpork
    Posts
    12,158
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by ceeb View Post
    A form consists of questions and answer boxes.
    Some forms do. Probably most. But it's not a valid statement in the generic case. A form could consist of nothing but hidden fields plus a couple of submit buttons, for instance.

    Quote Originally Posted by ceeb View Post
    Most forms could have numeric question prefixes or define a specific order - an ordered list certainly appears to be a valid choice.
    I strongly disagree with you here. Not saying I'm right and you're wrong, though. Only that I disagree.

    I think very few types of forms could have numbered label/input pairs without making the user wonder, 'why are those fields numbered?'

    And just because you could prefix numbers to something doesn't mean it's an ordered list. An ordered list's meaning changes if the order of the list items is changed. It's not the same as 'sorted'.

    Consider a typical form with the following label/input pairs: name, address, postal code, city. I would find it very odd if those were prefixed by bullet points or numbers, which means it's unlikely to be a list. And it's most certainly not an ordered list, because it doesn't matter (semantically) in which order the fields appear, and it is of no consequence in what order the user fills in the information.

    (When presenting the collected information, the order may be very important, though. If it's printed as an address label, for instance, you'd want them printed in the order I enumerated them, or the postal services might find it difficult to deliver the product to the right recipient. That's because we don't prefix each field with a label then, but rely on a long-standing convention. And it's something entirely different than a form for filling in this information, anyway. )

    Quote Originally Posted by ceeb View Post
    There are probably good arguments to support <dl> too - a form defines the 'terms' and the user supplies the 'definitions'.
    I don't think so. The only reason people do such a thing, I believe, is to get some more elements to hang style rules on, without giving the impression of divitis.

    Quote Originally Posted by ceeb View Post
    However, HTML does not currently give us definitive semantic structures for separating label/input controls.
    It gives us two semantic structures for associating a label and an input field. Anything that isn't associated is separated.

    Quote Originally Posted by ceeb View Post
    Your recipe lists are great examples but, sometimes, the distinction between sequences, sets, lists (ordered or unordered) is not so clear cut and interpretations will differ.
    I agree that it's sometimes not completely obvious, and interpretations will certainly differ.

    I stand by my rule-of-thumb advice about bullet points, though. If bullet points before each alleged item doesn't make sense, then it's probably not a list. You can use that lithmus test regardless of whether you suspect it to be an ordered or unordered list. An ordered list can have bullet points instead of digits, although it's probably quite uncommon.

    And you shouldn't only think visually! Even if you really want to use a list and convince yourself that bullet points would be acceptable to, e.g., Lynx users, imagine how it would be read out by a screen reader. Would it sound confusing if each label was prefixed by the word 'Item:'? (Note that it doesn't matter whether existing screen readers actually say 'item' or something else.)

    Or imagine you're describing the form to someone over the phone. Would you say 'item' before reading out each label?
    Birnam wood is come to Dunsinane

  21. #21
    SitePoint Wizard Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,287
    Mentioned
    51 Post(s)
    Tagged
    2 Thread(s)
    (although it can cause accessibility problems with Window-Eyes, iirc),
    I wish I could find out, without buying the dang thing, if W-E7 has fixed this.
    And nobody seems to know the cause of the intermittant Mac problem with implicit label-inputs that Mike Cherim found. : (

    Because otherwise I rather like using the label itself as the block container and using some inline to wrap the label text for styling purposes. It's not any fewer elements than using a wrapping div (and I though that's what ceeb was talking about when s/he said "no sematic wrapper" available, unless you count a fieldset which shouldn't be around each label-input pair) though.

    There are probably good arguments to support <dl> too - a form defines the 'terms' and the user supplies the 'definitions'.
    Since the label and the input, when linked in one of the ways Tommy mentioned, have that same relationship (whether you're informed of the relationship or not as a user, lawlz) means the dt/dd around labels and inputs is kinda redundant. So I use them for presenting the information back to the user: using dt/dd to preserve the relationship when the information is coming back, and not in a form. Problem with dl's is, you can't have another thing inside wrapping each dt/dd pair, which for me, sucked initially. I've found other ways around that now.

  22. #22
    SitePoint Author silver trophybronze trophy

    Join Date
    Nov 2004
    Location
    Ankh-Morpork
    Posts
    12,158
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Stomme poes View Post
    Since the label and the input, when linked in one of the ways Tommy mentioned, have that same relationship (whether you're informed of the relationship or not as a user, lawlz) means the dt/dd around labels and inputs is kinda redundant.
    Whaddaya know ... I just thought of a use case where a definition list could have a theoretical quasi-semantic purpose in a form:
    Code HTML4Strict:
    <dl>
      <dt><label>Date</label></dt>
      <dd><input type="text" name="year" maxlength="4"></dd>
      <dd><input type="text" name="month" maxlength="2"></dd>
      <dd><input type="text" name="day" maxlength="2"></dd>
    </dl>
    That would sort out the problem of associating a single label with multiple input fields, except that assistive technologies probably wouldn't 'get it'.
    Birnam wood is come to Dunsinane

  23. #23
    SitePoint Wizard Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,287
    Mentioned
    51 Post(s)
    Tagged
    2 Thread(s)
    Hell, why not? They can see all the labels and inputs people stuff in p's, divs, and other lists... why not also in a dl? It seems so long as there is a form control, it doesn't matter what it's put inside of.

    That's such a good idea, I'm going to try it and test in JAWS. Yeah, not the only reader but the only one I have (that works, orca grumble grumble...) and, if the other two inputs seem to not be connected to anything, fallback is a title attribute. I use them now when I can't use a real label when I need it. Titles work great.
    Off Topic:


    but that'll have to be next week, I'll be computerless for a week while enjoying the Perl conference in Lisbon : )


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •