contractor web site

I believe you're using too many line breaks and divs where other HTML elements are better suited to mark up you pages.

"navShell" could have been a list, for example.

I think more work needs to be done here.

Good luck!

Arielle

Your validation errors are because of the unescaped ampersand here:

Log In

and there's no alt attribute for homeIntro.jpg.

But like Arielle says, too many <br>s and non-breaking spaces used when you should be using CSS instead to create spacing.

All of the line breaks and spaces are created from PHP scripts. Also, many of these tags have been added by the CMS where I need to keep things as simple as possible for the users. But, nonetheless, point taken.

Why would a list be preferable to styled anchor tags for the navigation? I can't see any advantage and it seems like a touch more overhead. What's the rationale?

You can still style the anchors but what you have is a list of anchors so the correct semantic choice is an unordered list. Look at any major site on the internet that doesn't use tables for layout and you'll find ALL their navigation marked up as lists. Using lists also provides added benefits to people using assistive technologies: they can choose to just skip over lists when they want to skip navigation to get to content; they can't do that with anchors the way you've presented them.

How have you managed to be on this forum this long and not pick up on the fact that using lists of navigation is the correct way to do things?

As far as the CMS outputting line breaks goes, what's wrong with telling the CMS to output the content into the correct semantic containers like paragraphs or list items?

Well, simply because I haven't yet seen a truly functional explanation of why it's better. Semantics is something of a subjective reason, to be honest. Another way to put it is that I have a series of anchors, so in that semantic sense a list isn't necessarily the "best" option.

Functionally, I can use less coding using anchor tags wrapped in a container div than I would having a list of anchors. This set up works precisely how I want it to, what functional reason is there to make it more complicated? I'm not being facetious, that's a valid question. Yes, I've heard that lists are better for navigation but never a *why* as to why they are better....other than semantics, of course.

While not an expert on assistive technologies, it's my understanding that alternate browsers are (generally) capable of reading content and filtering out other elements such as lists as well as anchors. How does this way make it any more difficult for those visitors?

In the case of "navShell", you'll be using as much code:

• Something

As to the CMS's output, you can always tell it make paragraphs out of new line characters. The way I do it is to wrap the content first in

$myContent = "

".$output."

" ;

in Php, then in the proper place

echo preg_replace("/\n/", "

\n\n

", $myContent) ;

...or something to that effect.

Doing this sort of thing will enable you to better control your styling. Think about it, rendering x amount of breaks when you can just style paragraphs in a given div with bottom padding whose value fits your liking.

While I realize this is really picking nits, I have to disagree. There is more code with a list, even if it's only an extra tag per line, and it's a bit more cumbersome.

Compared to



• Something




Also, I disagree that the CSS is more appropriate. By simply styling the anchors I am adding styles to what is already there. By turning a list into a series of navigation links, I have to re-write the styles and positioning properties already existing in the <ul> and <li> elements. The CSS (to me, at least) is far more straightforward to do it with the simpler elements of <div> and <a>.

Again, I am seriously curious why the list has been held up as the "proper" way to create navigation. I have read many times on this forum that is *is* better, but I have yet to see a rationale behind it other than semantics which should be a secondary concern to functionality.

Also, a semantic argument could also be made for using the <div>/<a> structure as they are being used for their primary purpose- <div>s to separate content into disparate elements and <a>s to create navigation.

^Following this train of thought, why not just use tables then and style rows or columns as necessary? Better yet, why not just use an image map for the entire navigation section to totally remove the need for styling?

...I am, of course, being sarcastic.

Cheers!

Arielle

Sarcastic, yes, but you actually are making the same point I am. There are very significant functional advantages to using table-less design. There are some very concrete arguments to made against tables for non-tabular data. Now that I've started this conversation, I've looked and looked and I can't find a single *objective* reason why to use a list instead of a method similar to mine for navigation. I would really like to hear one and am open minded on it, but I've not heard anything yet.

And what do those arguments say?

I think the context of functionality you are proposing is very simplistic. When you say "a functional web page", do you only mean something that can be displayed in a browser? But what sort of web browser are we talking about?

Is Lynx, which will not give any hinting to a div grouping of anchors, not considered a web browser? What about a JAWS-aided Internet Explorer or ORCA-supported Firefox, which gives a user the advantage of listing anchors (among other things) grouped as either ordered or unordered lists? What about mobile devices like my outdated mobile phone that don't render CSS at all?

As it is, sure the website in question is functional. But I used only Firefox to view it the first time. Would it have the same functionality if I opened it up with my Nokia 7260? In Lynx, the multiple <br>s that you used didn't do much good separating your paragraphs, and your navigation links didn't have any hinting from bullets and additional separation from the rest of the content.

But that's just it. If you really believe that functionality only goes as far, just use an image map. It'll save you a lot of trouble styling things.

Cheers!

Arielle

.. but I could be wrong.

Objectively navigation generally consists of a list of various links. For lists the list elements UL, OL, DL are in actual fact provided by html for the purpose of marking up lists. Is that not an objective fact? So why wouldn't you put a list in the structure explicitly provide by the language for marking up lists?

If your navigation is not in fact a list of links then mark it up appropriately for what it actually is. But if it is a list of links then you use lists. Just as you use P for paragraphs, you use UL, OL, or DL for lists. What could be more objective than that?

Oh, and it makes your code far less complicated and much easier to understand, but I suppose that is not an "objective" fact.

It also avoids the use of specifically presentational tags like BR, which is one of the main aims of modern html, the separation of presentational concerns from semantic concerns.

But really - the language provides a structure for lists, you have a list, what else would you use?

I must side with velo, although I do use lists for my navigation.

For validation purposes the only requirement is that the anchors are contained by a block level element, which velo has met with the div (or could have been a p). Semantically it could be construed as a list of links - but it's not a set-in-stone requirement. In regards to accessibility, I believe Lorraine (a highly regarded accessibility expert and past member of CSSCreator) stated (in her own words) that a screen reader has no problems reading a series of links without the list markup.

An obvious benefit to using the list is the extra hooks it provides for styling purposes. Velo has stated that he has accomplished all the styling he needs with the anchor elements alone. One thing I will disagree with is the use break tags for presentation. It could and should be done with CSS - margin, padding, positioning, etc.

I believe some people are taking lists too far. One could theoretically bloat a page with lists thusly: the head and body are an ordered list; the headings and subheadings are an outline defined by a list; while sections are lists of paragraphs comprised of lists of sentences which, in turn are made of a list of words - oh, and those words? yup, a list of letters.

the break was an oversight on my part, I intended to remove them before posting the site as I have the anchor tags set to block display with a top margin, I didn't need them. Removed.

As I understand it the primary requirement is for clear separation between the links. This maybe more of a problem in visual browsers than for things like screen readers. The problem with using links with nothing or only spaces between them is when they are displayed unstyled, it is no longer easy to discern where the clickable region of one link ends and the next one begins.

Take a look at your page with CSS disabled(*). The links at the top are now a mess. The links at the bottom are fine.

(*) Generally a well constructed page will still look good - presenting its content clearly and understandably - when its displayed unstyled. Its a good check to use.

Screenreaders can also choose to simply skip over an entire list marked up as a list if they are navigating a page by links. If the links aren't marked up in a list, a screenreader user would have to tab through every one which could become especially tedious for a large group of links. Either that or that they'd have to switch to navigating by headings to jump over such a group.

But guess what? This site doens't have any heading tags in it either.

I'm currently viewing your careers page

http://caprice.websitewelcome.com/~gmca/?content=careers

on my vodafone V550 with awesome Vodafone Live-ness.

Your main links are the first ting I see, there are no gaps between them, I see

About UsHistoryServices
PortfolioCoverageHome
CareersLog In
Careers
G. M. Crisalli & Associates . . . .

all in the same font, same size, no line breaks.

Further down, the sub-heading "Construction Estimator" is indented and has a black square bullet which makes it stand out a little bit.

Your links at the bottom look much better, they're separated with the pipe and are spaced out better.