Dreamweaver question

[hotnuts21]

I have a friend who is building a site in dreamweaver, he has about 8 categorys in the nav and each category has about 6 sub categories.

He wasnt sure how to implement the nav in the best way, so I suggested using an expanding nav, when someone clicks a category link, the box opens up with more links underneath it.

However we couldnt find how to do this in dreamweaver, using templates is it possible? The site has to be managed by someone using contribute and we dont want to use anything like javascript or DHTML.

Thanks

[Redhat_PHP]

what scripting language does his web server support? PHP?

[hotnuts21]

Yeah it supports the majority of scripting languages and I did think of using a simple php script to do it for him

However the management of the site is going to be passed over to someone else, who is going to use most likely Contribute or dreamweaver to manage it. This means that if they wanted to add a new link it would mean they had to know what to add.

Or the site would start becoming a full blown CMS which then starts getting out of hand!!

[pissant]

is there any reason why you don't want to use js?
If you use unobtrusive dhtml then all that you would need in the html would be simple nested lists with some ID tags hung on them.
Then in the JS add some listeners for those IDs...
also in the js you could set it up so that the menus contract on load (depending upon cookies) hence making the menus appear opened if someone browses the site with js disabled.

You can also do something very similar with css, but the amount of control decreases when you have to support legacy browsers... You can have very effective menus even using IE, but if you want to have expanding contracting ones then ie doesn't support enough css.

[hotnuts21]

They dont want to use JS, because the site they are building has to be cross compliant with a lot of browsers and users, and a lot of people will have the JS turned off. Therefore the open nav, will take up about 3 screens of navigation which wil look awfull.

I think they will probably be forced down the PHP route.

[asp_funda]

But a good approach will be to use JavaScript only. If you are using DreamweaverMX(any) then there's an option of pop-up menu in the behaviours section. Just select a link & open behaviours panel in the Windows Menu. Click on the (+) sign & select the show pop-up menu.
I haven't checked it for cross-browser compatibility but you can handle that in PHP.
The pop-up menu behaviour uses layers. So you can check if the browser is IE then you can use the <DIV> tag or else use a <LAYER> tag.

Also there are quite a few cross-browser DHTML menus available at http://www.dynamicdrive.com.
If what you say is true(lots of categories with sub-categories) then I don't know how you are going to manage without using JavaScript.

[pissant]

But a good approach will be to use JavaScript only. If you are using DreamweaverMX(any) then there's an option of pop-up menu in the behaviours section. Just select a link & open behaviours panel in the Windows Menu. Click on the (+) sign & select the show pop-up menu.
I haven't checked it for cross-browser compatibility but you can handle that in PHP.
The pop-up menu behaviour uses layers. So you can check if the browser is IE then you can use the <DIV> tag or else use a <LAYER> tag.

Also there are quite a few cross-browser DHTML menus available at http://www.dynamicdrive.com.
If what you say is true(lots of categories with sub-categories) then I don't know how you are going to manage without using JavaScript.

Gotta say you should definately avoid the kind of code forking you are mentioning here...
Apart from being a nightmare to code, try explaining to the users that they have to add new content twice, once for a layer and once for a div.
If one uses good standard js/dhtml one can code for everybody and leave a good experience for those with browsers which do not understand js. The old days of testing for browsers and serving up nine different code forks should be over, but some people still think this is the only way to go. This type of thing is not only not necessary but harmful, in fact probbaly why so many people are wary of JS.

The original poster mentioned that a problem with using a js solution which defaults (in case of no js) to all menus open would lead to too many options available at the top level... one way around this would be to use CSS to close up all but the menu on the current page, (you could also set the css to act like the js menu but only in modern browsers like mozilla, opera, and safari) giving your users more options than just the top level links, but not all at once...

[asp_funda]

Gotta say you should definately avoid the kind of code forking you are mentioning here...
Apart from being a nightmare to code, try explaining to the users that they have to add new content twice, once for a layer and once for a div.
If one uses good standard js/dhtml one can code for everybody and leave a good experience for those with browsers which do not understand js. The old days of testing for browsers and serving up nine different code forks should be over, but some people still think this is the only way to go. This type of thing is not only not necessary but harmful, in fact probbaly why so many people are wary of JS.

I think that there's a mis-understanding. No good DHTML or JavaScript can force a browser to accept what the browser doesn't. I just said that you can write your code like:-

Following is the ASP/VBScript code. You can change it to your language
accordingly.

<%
If (strBrowser = "IE") Then
Response.Write("<DIV id='myMenu'>")
ElseIf (strBrowser = "NN") Then
Response.Write("<LAYER id='myMenu'>")
End If
%>
---- your menu contents here -----
<%
If (strBrowser = "IE") Then
Response.Write("</DIV>")
ElseIf (strBrowser = "NN") Then
Response.Write("</LAYER>")
End If
%>

This doesn't mean that you have to enter your menu contents twice. I am not that dumb, you know!!.
And besides every cross-browser DHTML Menu does that. The only difference is that it checks for the browser at client-side & you are gonna check the browser at server-side.

[pissant]

I think that there's a mis-understanding. No good DHTML or JavaScript can force a browser to accept what the browser doesn't. I just said that you can write your code like:-

Following is the ASP/VBScript code. You can change it to your language
accordingly.

 <%
 If (strBrowser = "IE") Then
 Response.Write("<DIV id='myMenu'>")
 ElseIf (strBrowser = "NN") Then
 Response.Write("<LAYER id='myMenu'>")
 End If
 %>
 ---- your menu contents here -----
 <%
 If (strBrowser = "IE") Then
 Response.Write("</DIV>")
 ElseIf (strBrowser = "NN") Then
 Response.Write("</LAYER>")
 End If
 %>

This doesn't mean that you have to enter your menu contents twice. I am not that dumb, you know!!.
And besides every cross-browser DHTML Menu does that. The only difference is that it checks for the browser at client-side & you are gonna check the browser at server-side.

so with your above code what happens if the user comes to the page with netscape6+, mozilla, safari, camino, opera, or any of the other browsers which support js/ecma262 script but will choke on you code forking?
Personally if I have to test for compatability I prefer to test for the browsers ability eg

if document.getElementByID do x
if document.all do y
if document.layers do z

The above obviously isn't real code but you get the idea, test for what the browser understands not what it is called.
Maybe it is just me but as well as separating precentation from content (something which your above example manages not to do) I also believe in separating behaviour from content. This allows greater ability for the CM to add new content without worring about breaking the scripts.

Of course if one does still have to support legacy browsers like NN4.x then one will still need some event handlers in the document. However in combination with CSS much is possible without having to resort to locking out ANY users. This includes users of lynx to PDA and telephone users.

It is of course just my opinion but I personally think anyone still writing browser detect scripts which look for particular browser name is being irresponsible or unprofessional.

[asp_funda]

so with your above code what happens if the user comes to the page with netscape6+, mozilla, safari, camino, opera, or any of the other browsers which support js/ecma262 script but will choke on you code forking?

Nothing, its gonna work fine. Only IE takes on Layers as <DIV>. Netscape & all other browsers such as Mozilla, Opera, etc take it as <LAYER>. And by the way, I don't think that Netscape6+ isn't part of the netscape family!! What works in NN4 or 5 will definitely work in NN6+ unless Netscape decides to bring out drastic changes & declaring that it will stop supporting things that were supported in previous versions.

Personally if I have to test for compatability I prefer to test for the browsers ability eg

if document.getElementByID do x
if document.all do y
if document.layers do z

The above obviously isn't real code but you get the idea, test for what the browser understands not what it is called.
Maybe it is just me but as well as separating precentation from content (something which your above example manages not to do) I also believe in separating behaviour from content. This allows greater ability for the CM to add new content without worring about breaking the scripts.

There are several ways to work out a thing, not just one.

It is of course just my opinion but I personally think anyone still writing browser detect scripts which look for particular browser name is being irresponsible or unprofessional.

Pretty strong words. Using browser detection isn't unprofessional, just some smart thinking by not relying on just one thing. If a thing's old, it doesn't mean that it cannot be used effectively again and being a professional(if you are one), you should know that.

[pissant]

Nothing, its gonna work fine. Only IE takes on Layers as <DIV>. Netscape & all other browsers such as Mozilla, Opera, etc take it as <LAYER>. And by the way, I don't think that Netscape6+ isn't part of the netscape family!! What works in NN4 or 5 will definitely work in NN6+ unless Netscape decides to bring out drastic changes & declaring that it will stop supporting things that were supported in previous versions.

Your name asp_funda leads me to believe that perhaps asp is your core skill. So it is up to you whether or not you believe me but <layer> was a proprietry Netscape term, and was only supported by netscape browsers. It is also no longer supported by netscape browsers (as of nn6, and there is no nn5). They now support the w3c DOM, as does almost every browser released since early 2000 (almost 4 years ago).

There are several ways to work out a thing, not just one.

There certainly are, I am just a little concerned that what you were proposing to the original poster of this thread would lock some users out. In your original code snippet you had a code fork if a browser was IE and another if the browser was NN. I didn't like this because it left all the other browsers out in the cold. Also your use of layers would have left more modern versions of netscape browsers out in the cold.

Pretty strong words. Using browser detection isn't unprofessional, just some smart thinking by not relying on just one thing. If a thing's old, it doesn't mean that it cannot be used effectively again and being a professional(if you are one), you should know that.

your opinion versus my opinion...
I did of course say that browser detection using names and types of browsers, checking for capabilities is a much better way to work.
above you said that nothing would happen, and your script would work fine for users of other browsers, please explain to me how that could happen, as unless I am missing something a mozilla user (for example) would go to your page, the script would say is it IE? no. Is it NN? no. Then it would stop, do nothing and the mozilla user would be locked out.

Maybe I'm missing something, but sometimes when old practices no longer fit the way things are done now, or the current climate, they have to be set aside and new better practices adopted.

Personally I am sick of going to webpages and finding out that some fool has written a browser sniffer which locks my browser out despite the fact my browser can actually run the scripts, it just doesn't have the correct name. Perhaps your detects ARE good and work, but I do not see why looking for the name of a browser rather than testing what it understands could be better.

[asp_funda]

Your name asp_funda leads me to believe that perhaps asp is your core skill. So it is up to you whether or not you believe me but <layer> was a proprietry Netscape term, and was only supported by netscape browsers. It is also no longer supported by netscape browsers (as of nn6, and there is no nn5). They now support the w3c DOM, as does almost every browser released since early 2000 (almost 4 years ago).

Yeah, you are right on that one, asp being my core skill. Ok, I didn't know that, <layer> tag not being supported by nn6, I am an IE user most of the time & for quite some time now(about 2-3 years), I've been doing server-side stuff in ASP & JSP, so I am a bit outdated in client-side scripting(you've just proved that).
But as I suggested above, if the menu is made with DreamWeaverMX or FireworksMX, it works fine in both IE & NN without any modifications to the code as I suggested or for that matter you suggested. There are also many cross-browser menu scripts available at http://www.dynamicdrive.com. I am attaching 6sample scripts of drop-down menus from DHTML Central at http://www.dhtmlcentral.com. All of them(except 6th one) works fine with both IE5+ & NN6+(I have tested on these only).
Also as asked by hotnuts21 above, I said that DHTML would be their best choice & I still say it, unless you or anyone can tell me how that nav bar can be implemented without causing any pain to the common visitor to the website.