Navigation revisited and freeing your thinking

Revisiting Navigation

Last month I set out my view of using <nav> and <ul>s for navigation purposes. This was as a reaction to feelings in the php development community against changing the default behaviour of <ul>s using css.

The message that came across clearly after the fact was: the objection was not to the use of <ul>s as parent elements for a list of links. The problem comes with the styling:
/*css seen as a problem */
ul {text-align:center;list-style-type:none;}
a{display:block;padding:2px 5px;}

The problem is that default behaviour for all <ul>s is changed so <ul>s elsewhere in the page will be styled like this.

/*css seen as a reasonable solution */
nav ul{text-align:center;list-style-type:none;}
nav li {float:left;}
nav a{display:block;padding:2px 5px;}

Just the behaviour for children of the <nav> element is changed leaving other <ul>s to be styled differently (or defaultly).

This is a really subtle distinction and I don’t mind admitting it took me a while to sus out. The argument isn’t against using <ul>s in navigation but advises us to do so in a careful and considered way.

Not using <ul>s closes the door to such enhancements as submenus and accordian style menu layout. This shows up my intial example last month, at best, as being oversimplistic and a bit naive.

Jumping to Conclusions

It’s not the first time in my life I’ve jumped to a conclusion. Another I’ve revisited recently can be succinctly summed up in a sentence from PHP in Action:

Alternatively, we could achieve the same effect with Javascript, but it’s better to avoid Javascript if we can, since some users disable it in their browsers.

Reading this recently initially reinforced my long held belief that Javascript is Bad because some users disable it.

The desired effect mentioned in the quote from PHP in Action is getting submit buttons to generate individual commands where there are multiple submit buttons in a form. The authors go on to suggest solutions in javascript which work where there is already javascript present in the form so they aren’t really saying Javascript is Bad so Don’t Ever Use It.

I first hit the ‘Javascript is Bad’ assumption in accessibility and coding circles in about 2003 when the numbers of users with disabled javascript were about 20% (based on visitors to W3C at the time). As a result of taking it for granted I spent six years not bothering to learn much javascript because it’s Bad.

What a waste!

The Real Lesson

I am quickly working to fill this ridiculous hole in my knowledge, with the understanding that javascript should be used with care, for tasks where it is the best fit and always ensuring that all the functionality of the site is still there if a user should have javascript turned off or uses a screenreader.

The lessons here are ones I’ve taken a while to learn and they are relevant to coding and most things in life, I hope this blog post helps others learn them quicker:

  • Conclusions drawn, even by the ‘wise men’ in a community should never be taken on their own, as gospel.
  • Always check the date of a resource if you can.
  • Do your own tests.
  • Join in discussions and check your view against that of others.
  • Go back and review your own conclusions after time, has anything changed? new techniques or technology been released? did you jump the gun?
  • Never be afraid to admit you would change your mind (even if it’s only to yourself).
  • Never be afraid to try something new.

Is there anything you don’t agree with? have I missed something? what assumptions have you challenged recently (your own or from others)?

html markup for navigation

There’s been a lot of griping today about the use of an unordered list for a navigation menu (from @calevans among others). Although it is a generally accepted practice with the argument that a navigation menu is an unordered list of links, it’s not too difficult to find an alternative that is just as efficient is it? What’s the most basic code we could use as an alternative?

In html5 you could use the following: –

<a title="First link additional text" href="#">Link 1</a>
<a title="Second link additional text" href="#">Link 2</a>
<a title="Third link additional text" href="#">Link 3</a>

with css to sort out positioning and look.

For some specific layouts you may want to specify a :first-child pseudo class or a class="last" on a link.

For HTML4 strict just substitute a <div class="menu"> for <nav>.

So, not as complicated as I once thought!

Displaying html code listings your blog

I’ve long admired technical bloggers who spout seemingly reams of code listings to illustrate and support their blog articles, whatever the subject.

My recent forays into testing html5 and reporting the findings has lead me to want to produce my own listings. Really simple I thought, just dump the plain text from the source between two <code> tags and hey presto, one listing. Um… No, not quite that simple. It works fine for css – it’s considered plain text unless found in the <head> of a document between <style> tags. Html, however, is more tricky as the browser wants to render it <code> tags or no <code> tags.

Veteran code geeks may laugh and point at my obvious stupidity but I can honestly say it was only after several frustrating minutes of forum searches that the doh! moment struck and I remembered html entities.

So for anyone else out there bashing their head on this seemingly simple conundrum here’s the solution:

  1. type or paste your html code into your favourite blog software between <code> tags
  2. change every & to &amp;
  3. then change every < to &lt;

If you fancy showing the line numbers as well you can always mark up each line as a line item <li> within an ordered list <ol>.

Simple – now I know that is…

… happy code listing!

Fixing footer styling

Happily I appear to have fixed the issue with footer styling as detailed in my last post. Oh to have such an easy answer to all my problems!

The addition of
to the css told the browser (in this case firefox 3.0.6) what sort of element <footer> is and therefore how it should be dealt with.
Result – display as originally expected:

screen shot of firefox 3.0.6
screen shot of firefox 3.0.6

Big thanks to Bruce and David for pointing out this simple but effective solution.

Do not adjust your set it’s just HTML5

I’m lazy by nature and the less I have to type to get something working the better. This is what attracted me to HTML in the first place: meaningful tags reducing the need for div-itis. Adoption by the browser manufacturers seems to continue at their own pace (whatever that really means) and in the mean time something I expected to look like this:

screen shot of firefox 3.0.6
screen shot of firefox 3.0.6

well lets just say, it just didn’t. Not good…

Continue reading Do not adjust your set it’s just HTML5