Lists with <br>s

[Stomme poes]

I'm probably going to just be stubborn with this and keep going my way, but who knows? I'd like to run this by folks here first:

I have a page with a list of real estate companies.

With the contact page of the company who owns the website, I ended up using a list for the contact info-- not sure it was the best choice but it ended up looking like this:

	  <h1>Contact</h1>
          <p class="contact">Voor meer informatie, neem contact op met:</p>
 	  <ul id="contactlijst">
	    <li>Company name<br />
		Street 10<br />
		#### XX City</li>
	    <li>Postbus ###<br />
	        #### XX City<br />
		Nederland<br />
	        Tel : #########<br />
	        Fax: #########3<br />
		<a href="#">mailto:blah</a></li>
	    <li>Handelsregister nr: #######<br />
		Fortis Bank Nederland: ########<br />
		Iban: NL32 FTSB ########<br />
		BIC: ########</li>
	   </ul>

The original design (done with divs and <BR> all over the place) needed to be kept. So, there's a chunk for regular address, space, chunk for mailing address, space, chunk for important numbers. So, it looked like an address made up of a list of three parts. I'm uneasy with the br's but their placement is due to postal convention mostly, which is I think part of the content. Surely the above information would make a bit less sense if it was all in one long line (though you could figure it out).
I didn't make every line a list item because an address itself isn't really a list. Each item isn't actually independent, just on a new line. So, kinda feeling my way here. Someone would have done good to invent a tag called "address" but for postal addresses, not "Site Written By Joe" (which I don't even consider an address, but should be called <author> or something).

So going on the assumption that I was ok there, I went ahead and ran into a list of companies and their addresses. Again, I considered the group of real estate companies to be a list, but their individual postal address lines aren't independent enough to be list items.

          <div id="makelaar">
	    <ul>
              <li><h2>Company Name</h2>
	        <a href=website address"><img src="banner.gif" width="234" height="60" alt="[Company name and motto]" /></a> 
      	        Street 14-C<br />
      	        P.O. box ####<br />
      	        #### XX City<br /> 
      	        Tel: 0031 (0)#########<br />
      	        Fax: 0031 (0)#########<br /> 
      	        <a href="website again">website</a> 
      	        <a href="mailto:blah">info@blah</a>
	      </li>
	      <li><h2>Company Name</h2>
      	          Bleh Bleh<br /> 
      	          Lot 16 street B<br /> 
      		  City<br /> 
      	          ####-### Portugal<br /> 
      		  Tel: 00351 #########<br /> 
      		  Tel: 00351 #########<br /> 
      		  <a href="webaddress</a> 
      		  <a href="mailto:blah">info@blah</a> 
	      </li>
	      <li><h2>Company Name</h2> 
      		  Street 15<br />
		  #### XX City<br /> 
		  Tel: 0031 (0)########<br /> 
	    	  fax: 0031 (0)########<br /> 
      	 	  <a href="website/">website</a> 
		  <a href="mailto:blah">info@blah</a> 
	      </li>
etc...
</ul>
</div>

I'm not sure about making the company name a header... it's a name, which is a title, which is often a header.

Other ways I've thought of doing it is just divboxes stacked on top of each other, without a list... I've thought of just wrapping every line in something like a p even though they aren't paragraphs, but the newline of the content is preserved. Speaking of preserved, I've even thought of the pre tag.

Comments? Is there a better way I can do this? I'm also still figuring out what I'm doing with the banners-- some companies have a banner which on the old site was displayed to the right of the company name, though more companies than not have no banner.

Also, while I have no br's after the website link, thinking I could make those anchors display: block, that means I'm saying content-wise they do not need to be on new lines. And I'm not sure if they do or not. Usually on addresses, business cards and the like, each web address is on a new line. Not sure if this is old enough to be considered a "typographic convention" or not. If it is, I'd add <br /> after the website link as well.

[corbyboy]

Sorry if I missed something, but what actually is the problem? Are you just looking for a way to get rid or <br>s in a list? Does it render OK?

[fattyjules]

Don't forget you can embed lists within lists;

<ul>

<li>
    <h2>Company Name</h2>
    <ul>
    <li><a href="#"><img src="banner.gif" width="234" height="60" alt="[Company name and motto]" /></a></li>
    <li>Street 14-C</li>
    <li>P.O. box ####</li>
    <li>#### XX City</li>
    <li>Tel: 0031 (0)#########</li>
    <li>Fax: 0031 (0)#########</li>
    <li><a href="website again">website</a></li>
    <li><a href="mailto:blah">info@blah</a></li>
    </ul>
</li>

<li>
    <h2>Company Name</h2>
    <ul>
    <li>Bleh Bleh</li>
    <li>Lot 16 street B</li>
    <li>City</li>
    <li>####-### Portugal</li>
    <li>Tel: 00351 #########</li>
    <li>Tel: 00351 #########</li>
    <li><a href="webaddress"></a></li> 
    <li><a href="mailto:blah">info@blah</a> </li>
    </ul>
</li>

</ul>

[Stomme poes]

Sorry if I missed something, but what actually is the problem? Are you just looking for a way to get rid or <br>s in a list? Does it render OK?

I haven't even CSS'd it yet, but it will render fine and it is valid. It's more the semantics of it-- am I really stretching the use of BR too far? There are CSS ways I could remove the brs (well, I'd have to either use Pre or wrap every line in some other element like a span or a p); mostly I'm wondering if I'm doing the right thing.

I did consider a list in a list, and it would naturally make new lines for me just by li's being blocks... I didn't use it because I don't see parts of an address or contact info as a list. I'll think about it more.

[chris cressman]

The most semantically rich way to mark up contact information is hCard:

microformats.org/wiki/hcard

The markup is easy to learn, but if you're in a hurry, you can use the hCard Creator:

microformats.org/code/hcard/creator

[Erik J]

It's more the semantics of it-- am I really stretching the use of BR too far?

I don't think you do. In addresses and say... poetry, you may have to use them to get it right as it is meant to be without the css.

[felgall]

Breaking up address lines is one of the few legitimate semantic uses for the <br> tag. The line breaks at those spots are actually a recognised part of the address and so should be coded as <br>.

[Stomme poes]

ok thanks, that's kinda what I wanted to hear (that they were ok and semantic, or that they weren't). I knew about poetry and so, but while I've been abusing the <address> tag earlier but also with brs:
<address>
street #<br />
postcode city<br />
country
</address>
I was already doing abuse so a few br's there didn't bother me (and yes Santa I want a postal-address tag for Christmas pls, not an <author> tag).


--offtopic--

The most semantically rich way to mark up contact information is hCard:

microformats.org/wiki/hcard

The markup is easy to learn, but if you're in a hurry, you can use the hCard Creator:

microformats.org/code/hcard/creator

Dude, I'd love to use microformats, however they do NOT fit our website or the subject--- I'll have to wait until someone makes a "real estate" version of them.

Currently, for instance, on our second home rentals site (another, related site), there are calendars showing when a house is available and in what price range depending on season. While looking at microformats I did find calendar stuff and dates, however "event" was required. There are no events on our calendars.

This is fine for bloggitty blog-blog-bloggers who have a specific event they use their calendars for, this completely doesn't fit what OUR calendars do (same would go for how long a buy-house has been on the market).

Nor do we really want these addresses to somehow more easily get added to someone's PDA or whatever (one benefit of microformats). Hell, the people who supply the addresses can't even keep the language consistent-- one company uses their local language names for the streets, the postcode-order of the Netherlands (postcode in two pieces, then city), and the English name of the country. Another lists an address in Florida but uses the Dutch order (so, I'm sure postal workers in the US could eventually figure it out but why make it harder for them? Just another excuse for all that lost mail).
I was gonna wrap spans around each line just to set a lang attribute, and then I said, screw it. There's like a hundred addresses on that page... I'll lump those folks in with people who try to sell "plam pilets" on e-bay...

Plus I'd have to convince the guy who uses the template to add all that stuff in dynamically (I only (re)write the static HTML part).

I'll just keep waiting for mf's to come out of the friendster-blogo-sphere and enter the corporate world of real websites, and then we'll see : )

[chris cressman]

@Stomme poes

I thought my post was on topic. I used to use <br>s to mark up addresses, but I've recently switched to Microformats, which I think are a better solution. I've just started using hCard and hCalendar to mark up people, organizations, and events in my documents. I've got a site going live in December or January that makes extensive use of them. It's not corporate (it's a nonprofit community group), but it's also not a hip blog or anything like that. I'll try to remember to send you the link. Microformats have worked great for me, and I just wanted to share the love

[Stomme poes]

Oh, I wasn't trying to say you were off-topic, but wanted my comments to be known as straying away from, specifically, br's. : )

I used to use <br>s to mark up addresses, but I've recently switched to Microformats, which I think are a better solution.

Am I confused? I thought microformats was metadata in the HTML tag (like where we normally stick attributes) which has machine-readable versions of the content inside the tag, so a... whatever, PDA, can grab the "tuesday, 12pm BBW @ mom's" and stick it into a calendar program on someone's Mac or whatever, without needing to try to read the human-typed "tuesday...etc".

But you are using them to physically style the text?? Yesh, pls post a link. I've read on microformats (and a bit on RFDa) but they had requirements that really fit more teh bloggities than, for instance, real estate (which is what I had in mind when I was first looking at microformats... another type of site I build is insurance). It would seem to me that in general, both need their own meta-jargon rather than basic tags.

[chris cressman]

Microformats are essentially some class names that you add to your HTML to add more semantics. There is no "person's name", "street address", or "phone number" elements in HTML, so the hCard microformat uses class names to represent those things on the page. Microformats are an effort to get everyone to agree on these class names so that we're essentially adding new elements to HTML. There are already applications in the wild that recognize these class names. For example, I believe all three major search engines do, so when you mark up a name and address with hCard, the search engine actually knows its a person and place. In the future, this will help when people search a map or do some other sort of location-based search, since it makes it easier for search engines (and other apps) to find and recognize contact info.

The best example of an hCard I have online so far is the right column of my home page at chriscressman.com. There are lots of examples on the microformats wiki though.

At first, you may not like the look of all the extra divs and spans, but each one is actually adding semantic data to your page, so they are not extraneous. Also, depending on your use, you may be able to replace the divs and spans with existing HTML elements, and apply the class names to those elements instead.

John Allsopp has a great book on microformats (published by Friends of Ed), and O'Reilly is selling a short PDF from Brian Suda that explains them better than most of the online tutorials. However, there are many automated tools that will generate hCards and hCalendars for you as well.

Hope that helps.

Chris

[Homie_187]

What about a definition list?

<dl>
<dt>Company Name</dt>
<dd>Address line 1</dd>
<dd>Address line 2</dd>
<dd>Phone</dd>
<dd>url</dd>
<dd>email</dd>
 
...
 
</dl>

[Stomme poes]

Homie:
I could have done that with a nested list, as someone suggested above:

<ul id="main">
  <li><h2>company name</h2>
    <ul>
      <li>one address chunk</li>
      <li>address line 1</li>
      <li>address line 2</li>
      <li>City etc</li>
    </ul>
  </li>
  <li><h2>Company name</h2>
    <ul>
      <li>another address chunk</li>
      <li>address line 1</li>
      <li>address line 2</li>
      <li>City etc</li>
    </ul>
  </li>
etc...

However, the reason I didn't do this was because an address itself isn't really a list-- it's a sequence of lines, but none of them really stand alone as list items.

Definition list would actually be worse, because while I do abuse them to hold things other than just dictionary terms and definitions, I do still hold to the rule that you have key-value pairs, like in a hash.

So I would want a dt for each dd.

[felgall]

Each line in an address contains a different type of information and so they are definitely NOT a list.

Unless you are going to use microformats the <br> is probably the most semantically correct way using just HTML at least for those line breaks that actually are required in all addresses such as the one after the name and the one before the city/suburb.

[Stomme poes]

Yeah, that page got done as soon as I'd gotten an answer from you guys. It's over with : )
The current list. I don't have any plans to change it now.

Thanks Steven.

[Ed Seedhouse]

Each line in an address contains a different type of information and so they are definitely NOT a list.

Each line is an element of an address so they form a list of address elements. Since the order matters it would be an ordered list, I should think.

Or so it seems to me.

[felgall]

Each line is an element of an address so they form a list of address elements. Since the order matters it would be an ordered list, I should think.

Or so it seems to me.

And each paragraph in an article is an element of that article and so they form a list of article elemebts. Since the order matters they would then by your logic be best entered as an ordered list as well presumably with one paragraph within each <li> tag.

[Erik J]

Off Topic:

The current list. I don't have any plans to change it now.

The #makelaar ul is hiding the last item behind the navigation. Maybe needs a bottom padding?

[AutisticCuckoo]

It seems that a lot of people have difficulties with the difference between a sequence and a list.

If it would look wrong presented with list markers (bullet points or numbering), then it's not a list. In many cases we may prefer to display a list without markers (e.g., in a navigation menu), but only if it would still make sense using an unstyled list. A definition list should make sense with a ':' or '=' between the term and the definition.

I don't think either of those scenarios would make sense for a postal address.

[Ed Seedhouse]

And each paragraph in an article is an element of that article and so they form a list of article elemebts. Since the order matters they would then by your logic be best entered as an ordered list as well presumably with one paragraph within each <li> tag.

If you are storing addresses in a database you would store each element as a separate column in a table, not as one single column. The various elements have an implied order of specific to general. A list of addresses would be best displayed as a table, in my opinion, but a single address should be a list.

An address is not a paragraph. Parargraphs have little implied structure, but addresses thoughout the world do have a structure and the structure is how you recognize it as an address. "Canada, Victoria B.C., Glentana Road" is wrong. "Glentana Rd., Victoria, B.C. Canada" is right. They teach you how to do it the right way in school, or they did when I went to school in the middle ages. Heaven knows what they teach these days.

The structure is how you recognize something as an address, so in my opinion it should be marked up as a list. As the structure is specific to general an order is implied so I think it should be marked up as an ordered list. CSS would be used to hide the numbers, of course. For semantic purposes it should probably be classed as "address".

It would be better still, in my opinion, if a proper html element existed for it, but you have to draw the line somewhere and you can't provide a semantic element for everything.

As addresses may also be displayed on a singal line it is obvious, or so is seems to me, that a BR is in no way implied in the structure, and so should not be used.

[Ed Seedhouse]

If it would look wrong presented with list markers (bullet points or numbering), then it's not a list.

If so then we should not mark up menus as a list, which is generally accepted now as the right way to do things. Authors generally remove the bullets, presumably because the bullets look "wrong" in a menu.

What matters is not how it looks, anyway. The default style is irrelevant to the semantic meaning. Just as a menu is a list of links, an address is a list of geographical elements, usually ordered specific to general.

It may be written in a single line or in several lines so BR is not implied in that structure. The closest element we have for that is OL, so that is what we should use, probably with the class "address". If we all did addresses that way it would make them much easier to extract that information from html documents.

[felgall]

There is no reason why a menu can't be marked up as a list since the menu entries will work fine displayed on the page as a straightforward list with bullets. Each entry is a separate item and the bullets help to separate one item from the next making it more accessible.

The same is not true for an address.

[Ed Seedhouse]

There is no reason why a menu can't be marked up as a list since the menu entries will work fine displayed on the page as a straightforward list with bullets. Each entry is a separate item and the bullets help to separate one item from the next making it more accessible.

Well, I am certainly not the Voice of God or anything like it, but it seems a rather fine distinction to me. We mark up a menu as a list because that's what it is and because html provides semantic structures for lists. It seems to me that an address is a separate semantic element and deserves a markup method that reflects it's structure. It also seems to me that it is actually a list of elements with an implied order.

I don't see that the default display in browsers has anything to do with it's semantic structure. Addresses may certainly be displayed on a single line and often are, so use of BR seems to be unjustified to me.

No doubt HTML doesn't have a perfectly satisfactory semantic structure for them, but the ordered list seems closest to the nature of an address and I don't see why one shouldn't use such a structure. On the other hand a series of text lines separated by BR seems to miss the structure entirely.

Once we've settled this, we can move on to angels dancing on pinheads...

[felgall]

If you are worried about the structure of an address beyond its being a series of lines separated by line breaks then you should be using the appropriate microformat to mark up the address so as to properly capture what is what within the address in the most accepted way.

[AutisticCuckoo]

If so then we should not mark up menus as a list, which is generally accepted now as the right way to do things. Authors generally remove the bullets, presumably because the bullets look "wrong" in a menu.

I disagree. A menu presented as a bulleted list makes sense. The reason we remove the bullet points with CSS is not that they look wrong, but that we can convey the concept of a list in another way (e.g., with 'tabs' or 'buttons') that better fits into the page layout.