Dreamweaver CC Named Anchor Tag Missing?

[Moonie]

Insert > Named Anchor

This command has been removed. Does it exist elswhere, or does one have to hand code the HTML in DWCC?

[Jon Fritz]

An anchor to bring you to the very top of a page is redundant code bloat (albeit a very small amount). To link to the top of a page from within the page, you simply use # as the link.

I'm not sure what you are saying about not being able to bring the viewer to the exact location of the anchor. I've never seen them not bring you to their exact location, except in situations where the page was too short to scroll far enough to put the anchor at the top of the browser viewport.

You can still use named anchors. They weren't completely deprecated and will still validate, though they will show as "Obsolete" under HTML5 (completely valid in html 4.0 tranitional). If you create a Snippet in DW with a blank named anchor, you can use that as your "anchor button". DW still puts in the little anchor icon in CC.

[hen3ry]

Jon Fritz II:  Thanks for your response.

In my context:  An anchor to the very top of a page is quite OK in my opinion, as I view the majority of my pages as continually evolving-- what's at the top today might move down the page tomorrow, as new material is added.  The tiny bit of extra code will then be functional. 

(I get the idea that I'm in a minority:  it seems many web folks --maybe most-- have a different workflow, more like "once a page is published, it's done".)

You cite exactly the case I worry about:  when the page is too short to scroll enough.   That happens relatively rarely in my site, but I consider it unforgiveable to lead a visitor via a link to a page where he/she has to search around for the linked-to item -- even if that page is "short".  (If I had a magic wand --sufficient tech knowledge-- and it could be done simply, I'd implement a unique marker to indicate the exact material to which the link is intended to bring the visitor.  It would live only for a short time, maybe only until the first user click on the target page. ) 

I'm thoroughly convinced:  I'm moving on to link-to-ID exclusively; I won't use the old named anchor again.  

Pilot error:  reviewing, my quick test case in DW CC earlier today was flawed.  Looking at it again, yeah, I see the little anchor-on-shield.  Which I won't be seeing in any new work I do.

There's no equivalent for link-to-ID, right?

[paladyn]

"You cite exactly the case I worry about:  when the page is too short to scroll enough.   That happens relatively rarely in my site, but I consider it unforgiveable to lead a visitor via a link to a page where he/she has to search around for the linked-to item -- even if that page is "short".  (If I had a magic wand --sufficient tech knowledge-- and it could be done simply, I'd implement a unique marker to indicate the exact material to which the link is intended to bring the visitor.  It would live only for a short time, maybe only until the first user click on the target page. ) "

You could do this, with advanced planning (and a good deal of back revision of existing pages to bring them up to snuff)..You would need to have (or develop) a consistent naming strategy for assigning ids, but since the action all takes place client-side, then you could use javascript/jQuery query string encoding and parsing, When linking to the target page for the "glossary" item, you would encode the link with a querystring parameter identifying the element on the page to target (the "named anchor"). The target page, when it opens, would parse the query string, if it exists, then use document.getElementById() to find the element, and manipulate the DOM to change some characteristic (font-weight, color, prefix/postfix asterisks, ???) to make obvious the passage intended.

Yes, it would take a little time in development, but once you have the encoding and parsing code worked out it becomes boilerplate, requring only a change of id from instance to instance of the encoding script (the target pages just use whatever comes in in the query string). If you use any kind of templating technology (DWTs, includes, whatever) you could implement it sitewide in the target pages fairly easily.

So, no, it's not a quick fix solution. But, can it be done? Sure. Are you willing to undertake it? Only you can say. If so, google "javascript/jquery query string parsing." You'll find tons of info, and it's not really that hard for the average literate adult to implement. Have fun... 

[hen3ry]

paladyn:

Thanks VERY much for your on-target, comprehensive response.   You gave me just the right information for me to see the complexity of the job.  And a very relevant search string.

Yeah, I'm fairly sure I could do it.  But the issue comes up  rarely on my site, so the amount of work to implement seems a bit extravagant, and I'd rather put the energy into conten .   As for the exceptions, e.g. "short" glossary pages... maybe I could handle these by inserting a nice-looking   photo or graphic to pad out the page.  Crude,  almost certainly irrevevant, but possibly effective.

Thanks!