How to Make a div a Clickable Link

Forum Moderators: not2easy

Message Too Old, No Replies

How to Make a div a Clickable Link

kenmorgan

3:13 pm on Jan 2, 2015 (gmt 0)

I found a Web site with instructions on how to do what I wrote in the "Subject" line:


<div class="feature">
 <a href="http://www.example.com"></a>
</div>

div.feature {
 position: relative;
}
 
div.feature a {
 position: absolute;
 width: 100%;
 height: 100%;
 top: 0;
 left: 0;
 text-decoration: none; /* No underlines on the link */
 z-index: 10; /* Places the link above everything else in the div */
 background-color: #FFF; /* Fix to make div clickable in IE */
 opacity: 0; /* Fix to make div clickable in IE */
 filter: alpha(opacity=1); /* Fix to make div clickable in IE */
}

My OS on my home computers is CentOS, and I run Apache locally to test my Web sites before uploading them to my VPS. When I used this code in my index.html file, it worked locally and brought up the external Web site when the div was clicked. When I uploaded index.html, the mouse pointer still worked, but when the div was clicked, absolutely nothing happened--the external Web site did not open.

Any ideas why the same code works locally but not on my VPS?

Thanks so much.

Ken

birdbrain

4:19 pm on Jan 2, 2015 (gmt 0)

Hi there kenmorgan,

try it like this...


<!DOCTYPE html>
<html lang="en">
<head>

<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">

<title>untitled document</title>

<style>
.feature {
    position:relative;
    padding:20px;
    border:1px solid #000;
   }
.feature a {
    position:absolute;
    display:block;
    width:100%;
    height:100%;
    top:0;
    left:0;
    z-index:1;
    text-decoration:none; 
    background-color:#fff;
    opacity:0;
    filter:alpha(opacity=0);
  }
</style>

</head>
<body>

<div class="feature">

<a href="http://www.example.com"></a>

<p>
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Donec 
ultricies sollicitudin nisi, ut molestie felis adipiscing sit 
amet. Sed auctor vehicula commodo. Nam a nibh neque, vitae 
faucibus felis. Vivamus at metus eget eros consequat fringilla. 
Quisque magna magna, laoreet eu tempus sit amet, fringilla at 
tellus. Praesent felis tortor, scelerisque vitae fringilla 
non, porttitor et lacus. Ut ut sapien nec quam tincidunt 
consectetur in nec lacus.
</p><p>
Phasellus porta, dui a elementum egestas, odio sapien rhoncus 
lorem, vitae bibendum erat sem eget sapien. Maecenas ut metus 
ac quam pellentesque lacinia quis sit amet augue. Fusce eu 
euismod urna. Nunc volutpat scelerisque tempus. Donec eget arcu 
et mauris scelerisque tristique. Donec fringilla mauris dolor, 
sit amet vulputate lacus. Nulla feugiat mattis nulla non 
tincidunt. Nam sit amet dolor eros, a viverra lacus. Nunc quis 
nisi eget neque tempus facilisis eu quis sapien.
</p>

</div>

</body>
</html>

birdbrain

kenmorgan

4:52 pm on Jan 2, 2015 (gmt 0)

Thanks for the reply!

I think I need to keep my DOCTYPE the way I have it to specify that the code needs to be parsed as XHTML 1.0 Strict:


<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
 "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">

My page does pass the W3 validator.

You suggested adding the meta tag "viewport." I was not familiar with that tag, but from a quick search it seems to be related to writing code that will work on mobile devices. I have never made any attempt to write for anything but a real computer. All my widths are specified in the HTML code in px without leaving it up to the browser.

Your suggestion about putting CSS padding and border specifications in the code for ".feature" was done in a style specification in the <div> tag itself.

You last suggestion was to remove the div in the CSS code, making if simply ".feature" instead of "div.feature". I tried that: it still doesn't work on my VPS.

I'm still open to suggestions! :)

birdbrain

5:42 pm on Jan 2, 2015 (gmt 0)

Hi there kenmorgan,

I do not have the foggiest idea what VPS is. :(

But I do know that the code works splendidly in this selection of browsers...
IE8 -> ->
Firefox 34.0.5
Chrome 39.0
Opera 12.17
Opera 26.0
Safari 5.1.7

birdbrain

kenmorgan

7:01 pm on Jan 2, 2015 (gmt 0)

I have an idea. But first, VPS stands for Virtual Private Server. When one looks for a company to host his Web site, most companies offer three options:

Shared hosting: when your Web site is just one of many on one server (the least expensive option)
VPS: where an underlying software divides the computer up into several "virtual" computers that act as separate computers. Thus you have root access to the OS (usually CentOS) on your virtual server
Dedicated server: you truly have one whole physical computer devoted to you! The cost is usually well over $100 dollars per month.

But now my (great?) idea: I've uploaded the index that is not working on the server; it is saved in public_html as indexNEW.html. Thus, it can be tested on the server without it being the real index.html of the Web site. It would be accessed using:


http://example.com/indexNEW.html

Ken

[edited by: not2easy at 8:19 pm (utc) on Jan 2, 2015]
[edit reason] Exemplified per TOS/ snipped review request [/edit]

kenmorgan

7:34 pm on Jan 2, 2015 (gmt 0)

I sort of expected that. So what could make it not work when I do the very same thing on Firefox on my home computer? I'm baffled. :(

birdbrain

7:45 pm on Jan 2, 2015 (gmt 0)

Hi there kenmorgan,

are you saying the code that I gave you does
not work in Firefox on your home computer?

birdbrain

mattur

7:59 pm on Jan 2, 2015 (gmt 0)

I think I need to keep my DOCTYPE the way I have it to specify that the code needs to be parsed as XHTML 1.0 Strict:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">

Note that unless you have specifically configured your web server to deliver your web pages as XML, browsers will be parsing your pages as HTML(5), not XHTML. The MIME type you server your pages with determines whether your pages are parsed as HTML or XHTML, the doctype has no effect on how the page is parsed.

The Doctype is just used to switch CSS layout modes:
[developer.mozilla.org...]

So you can prune all that down to:


<!DOCTYPE html>
<html lang="en">

and it will work exactly the same, as al that XHTML stuff is not actually doing anything anyway :)

Browsers have an XML parser and an HTML(5) parser. Unless a page is delivered with "application/xhtml+xml" MIME type, browsers always use the HTML parser - regardless of what the doctype says.

Browsers have supported wrapping block-level elements in a link for years (apart from one bug in FF which disappeared when they switched to a HTML5-based parser), and HTML5 makes this conformant. So you can just do:


<a href="http://www.example.com">
<p>
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Donec 
ultricies sollicitudin nisi, ut molestie felis adipiscing sit 
amet. Sed auctor vehicula commodo. Nam a nibh neque, vitae 
faucibus felis. Vivamus at metus eget eros consequat fringilla. 
Quisque magna magna, laoreet eu tempus sit amet, fringilla at 
tellus. Praesent felis tortor, scelerisque vitae fringilla 
non, porttitor et lacus. Ut ut sapien nec quam tincidunt 
consectetur in nec lacus.
</p><p>
Phasellus porta, dui a elementum egestas, odio sapien rhoncus 
lorem, vitae bibendum erat sem eget sapien. Maecenas ut metus 
ac quam pellentesque lacinia quis sit amet augue. Fusce eu 
euismod urna. Nunc volutpat scelerisque tempus. Donec eget arcu 
et mauris scelerisque tristique. Donec fringilla mauris dolor, 
sit amet vulputate lacus. Nulla feugiat mattis nulla non 
tincidunt. Nam sit amet dolor eros, a viverra lacus. Nunc quis 
nisi eget neque tempus facilisis eu quis sapien.
</p>
</a>

And/or put a class on the <a> and style it accordingly eg <a class="feature" href="...">. Which makes this a lot easier.

lucy24

8:05 pm on Jan 2, 2015 (gmt 0)

Backtracking to the original question:

How to Make a div a Clickable Link

One difference between HTML5 and HTML4 (and, presumably, XHTML-anything) is that <a> is no longer considered an inline element. You can have all the stuff you like inside an <a>, including a <div> with lots of <p> and so on. As a matter of fact you've been able to do this for ages: browsers* will happily follow a block-level link; the only difference is that outside of HTML5 it won't validate.

So there's no need to make the <div> itself clickable. Just wrap it in <a> tags.

* With the obvious exception of MSIE < some-number, but I don't know exactly what the number is.

kenmorgan

8:06 pm on Jan 2, 2015 (gmt 0)

Both your code and my code (the code on indexNEW.html that you accessed) work when I run it locally--where Apache is actually running on my home computer and I use Firefox to access this page (indexNEW.html) from the directory on my local disk drive. That local URL is:


http://localhost/BibleWebSite/indexNEW.html

This URL is not accessible to the outside world, only to my local network. But when I run the same indexNEW.html file from the copy on the public_html directory on my VPS--a publicly accessible Internet Web server--then it does not work. The URL for that copy is the one you used for the test:


http://example.com/indexNEW.html

That's the enigma.

[edited by: not2easy at 8:11 pm (utc) on Jan 2, 2015]
[edit reason] Exemplified domain per TOS [/edit]

kenmorgan

9:05 pm on Jan 2, 2015 (gmt 0)

To Lucy,

Thanks so much for your help. Here are a couple points/questions:

(1) I tried wrapping one of my three troublesome <div>'s in <a></a>. That DID work when running the page from my VPS.

(2) But my original code also DID work when running the page locally. That still bothers me: it's the same code on the same browser. Is there an explanation?

(3) I did know about the alternative of wrapping the <div> in <a></a>. However, before switching over to that to solve this problem--which could be humorously called doing what Darth Vader did (taking the quick and easy way, according to Yoda)--I'll mention why I did it the other way. On "Digital Sky Design," in an article called "How to make an entire div a link using CSS,"
Posted on May 17, 2013 by Chris Jumonville, he said the following:

While that does indeed work, it�s actually a hack. The reason for this is when you wrap a div with a link (like the code above) the markup will not validate as proper HTML since the syntax is incorrect.

This is from an author who seems also to have written articles on HTML5. However, I do grant that when I tried the wrapping method with mattur's recommended DOCTYPE, it DID pass the validator because it was treated as HTML5.

I would appreciate any comments you might have of this issue. My Web site in question here has over 1000 Web pages (my biggest), but it is only one of eight that I've created. I've always done everything so that it would validate as XHTML 1.0 Strict. Do you see a problem here? Is XHTML becoming passe?

(4) I was unaware that there was so "hard" a connection between XHTML and XML. I thought XML was simply another alternative to HTML5 and XHTML. Any clarification you could give would be most appreciated.

Thanks.

Ken

lucy24

9:09 pm on Jan 2, 2015 (gmt 0)

ken, the problem is that this thread will still be here tomorrow and next week and next year-- after the page has either been re-coded or no longer exists at all. Pasting-in specific lines of css and html is a solution for the ages.

But when I run the same indexNEW.html file from the copy on the public_html directory on my VPS--a publicly accessible Internet Web server--then it does not work.

Is this still true if you clear your browser cache or, better, use an entirely different browser? Test in some browser that you normally don't use at all-- yes, even if the reason you don't normally use it is that you hate it ;)

In some cases, live site vs. localhost differences are due to different Apache and/or php versions (or IIS equivalent). But html and css should be completely independent of the server, so the only possible difference is local caching.

I've always done everything so that it would validate as XHTML 1.0 Strict. Do you see a problem here? Is XHTML becoming passe?

I'm the wrong person to ask, because I've never used anything but HTML except in a few ebooks that were supposed to support XML entities (but actually didn't, because browsers aren't there yet, so it was all hypothetical). I tend to associate XHTML with wysiwyg editors and cms.

Almost everything that validates in XHTML will also validate in HTML. (The opposite isn't true.) The main difference is self-closing elements such as <img> and <br>, where HTML format and XHTML format are mutually exclusive.

Personally I've never bothered with "Strict" anything. But, again, almost everything that validates as "Strict" will also validate as "Transitional". The new HTML5 DTD drops the distinction anyway.

Incidentally...

For Web sites to display correctly, always use the latest version of your browser. This Web site displays best in

Nooooooooo...

[edited by: not2easy at 7:36 pm (utc) on Jan 3, 2015]
[edit reason] referenced edited snippets [/edit]

kenmorgan

10:01 pm on Jan 2, 2015 (gmt 0)

Lucy,

If I were to "switch" to HTML5, (1) Is there a way to write the DOCTYPE explicitly stating that that is my standard? (2) Does the Validator offer a little image with a check mark and "HTML5" on it to put on your Web page to indicate to the world that your code passed the Validator? It does, of course, for XHTML! :)

Also, in your previous post, you lose me completely after the word "Incidentally..." Your quote is from my Web page, but you left out the word "Firefox." My Web sites display best in Firefox, because they are written with and for Firefox. However, they also work on IE.

Ken

[edited by: not2easy at 7:34 pm (utc) on Jan 3, 2015]
[edit reason] referenced edited snippets [/edit]

lucy24

10:53 pm on Jan 2, 2015 (gmt 0)

HTML5 has a special, minimalist doctype:
<!DOCTYPE HTML>
The only reason a dtd is needed at all is that this is the absolute minimum required to keep a browser from going into "quirks" mode. So this new form is intended to be the only DTD any document will ever need, forever afterward.

The final note was that so the next passing moderator knows I haven't inadvertently included text that will lead people straight to your site (major no-no).

mattur

11:17 pm on Jan 2, 2015 (gmt 0)

This is from an author who seems also to have written articles on HTML5. However, I do grant that when I tried the wrapping method with mattur's recommended DOCTYPE, it DID pass the validator because it was treated as HTML5.

FWIW I'm a member of the W3C HTML Working Group, not that that should make any difference of course. It's valid HTML, and it works in all browsers. I've never heard of this guy whose advice you are following - but it's terrible advice to use a blank link positioned over text imho.

I would appreciate any comments you might have of this issue. My Web site in question here has over 1000 Web pages (my biggest), but it is only one of eight that I've created. I've always done everything so that it would validate as XHTML 1.0 Strict. Do you see a problem here? Is XHTML becoming passe?

Browsers have always ignored your XHTML strict doctype and just parsed your pages as HTML. You can keep using your XHTML doctype if you want, just be aware it doesn't actually do anything ;)

(4) I was unaware that there was so "hard" a connection between XHTML and XML. I thought XML was simply another alternative to HTML5 and XHTML. Any clarification you could give would be most appreciated.

XHTML is an application of XML. It's HTML defined in XML-compliant syntax. It's also mostly pointless :) Just use HTML unless you have a specific reason for using XML.

kenmorgan

2:33 am on Jan 3, 2015 (gmt 0)

Good news: I went back to my original code (original XHTML DOCTYPE and the CSS code to make the <div>s a link rather than wrapping <div> in <a></a>). Then as Lucy suggested, I cleared the cache from Firefox. Amazingly, it now works perfectly. And...with much pride I say: it passed the Validator for XHTML Strict and the Validator for CSS3 (just had to remove the last of the three workaround lines for IE). If Firefox doesn't appreciate the accomplishment of XHTML Strict and just parses the code as HTML, as mattur said, well, what can I do? :)

I would be interested in how cached pages caused the problem.

Ken

lucy24

3:17 am on Jan 3, 2015 (gmt 0)

I would be interested in how cached pages caused the problem.

Your browser doesn't know that you've changed the content. So if you go back to some URL that you just visited half an hour ago, the browser will pull material out of its cache instead of making a fresh request. This is especially likely to happen with changed stylesheets, because browsers tend to keep them longer than pages. (Disclaimer: I don't think I've ever known how long the various browsers keep various types of content if there's no explicit header specifying a duration, and I don't know if all browsers conform to the same duration guidelines. I'm sure there is a Definitive Source somewhere.)

It's possible that your local server is set up to send different cache/expiration headers than your live site. My local htaccess file and also the htaccess for my test site both explicitly say not to cache html and php at all, because the whole point of having a local server is to be able to view changes on the fly. CSS changes may still require manual refreshing.

kenmorgan

6:54 pm on Jan 3, 2015 (gmt 0)

Thanks, Lucy.

For Firefox to pull up index.html from my "local" server and then pull up the same index.html from the "live" server (my VPS) does represent different URL's. So if the URL is the determining factor, Firefox should have downloaded the same index.html that had worked when executed locally. But from what you say, the problem is more likely the style sheet. I have the CSS style rules in a separate .CSS file which is brought into the HTML pages with a link statement. But if Firefox didn't download the new copy of this file from the "live" server, it would not have the new rules needed to make the <div> a link. Of course, Firefox SHOULD have grabbed the new version because again we are dealing with different URL's. But as you suggested, browsers may have different policies about style sheets.

Thanks again for your help.

lucy24

8:17 pm on Jan 3, 2015 (gmt 0)

Also remember that unless you've got a site that people come back to many times a day, your own experiences will be different from the average user's experience. Most likely a visitor hasn't been to your site before-- or at least not in the last few weeks-- so their browser will request everything from scratch.

I looked it up and eventually arrived at what I have to assume is the horse's mouth [tools.ietf.org]. Unfortunately it is written in something almost but not quite entirely unlike English:

Since origin servers do not always provide explicit expiration times, HTTP caches typically assign heuristic expiration times, employing algorithms that use other header values (such as the Last-Modified time) to estimate a plausible expiration time. The HTTP/1.1 specification does not provide specific algorithms, but does impose worst-case constraints on their results. Since heuristic expiration times might compromise semantic transparency, they ought to used cautiously, and we encourage origin servers to provide explicit expiration times as much as possible.

(I would like at this point to grab the nearest dictionary and look up "heuristic" but unfortunately the cat is in my lap so the only dictionaries within reach are the Sanskrit-Latin-Greek trio, and while I do recognize the Greek root for "find" this does not get me far enough.)

If none of Expires, Cache-Control: max-age, or Cache-Control: s-maxage ... appears in the response, and the response does not include other restrictions on caching, the cache MAY compute a freshness lifetime using a heuristic. The cache MUST attach Warning 113 to any response whose age is more than 24 hours if such warning has not already been added.

###, there's that word again. I begin to suspect it means "The browser should make something up".

Finally:

if the response does have a Last-Modified time, the heuristic expiration value SHOULD be no more than some fraction of the interval since that time. A typical setting of this fraction might be 10%.

Tentative translation:
If a browser arrives at a site it hasn't been to before, and if the headers say nothing about caching or expiration, then it should look at the "Last-Modified" header, figure out the elapsed time in seconds, and cache the material for 1/10 that time. I couldn't find anything about material type, so it's more of a de facto thing: maybe the images have been sitting there for three years, the stylesheet was last modified in 2013, and the page was changed the day before yesterday, so that gets you your assorted time periods for caching.

Nick-of-time edit:
The cat left. It means "the browser makes something up based on available evidence".

[edited by: lucy24 at 9:19 pm (utc) on Jan 3, 2015]

mattur

8:26 pm on Jan 3, 2015 (gmt 0)

If Firefox doesn't appreciate the accomplishment of XHTML Strict and just parses the code as HTML, as mattur said, well, what can I do?

*All browsers* ignore your XHTML doctype and parse your pages as HTML, not just Firefox.

What you could do is direct your efforts towards things that actually benefit your users, rather than investing time in publishing web pages that almost, but not quite, work as XHTML - and so *have to be parsed* as HTML anyway.

You're using undeclared entities in your pages, which isn't a problem when they're parsed as HTML, but is when they're parsed as X(HT)ML. But since no one will ever parse your pages as X(HT)ML it doesn't really matter. XHTML is a) hard to get right and b) mostly pointless. It's not an accomplishment to publish sort-of-XHTML pages that have to be parsed as HTML to actually work.

kenmorgan

9:32 pm on Jan 3, 2015 (gmt 0)

mattur,

Perhaps you missed the smiley after my comment, and took my statement as a reason to go on the attack.

Be that as it may, I don't know what you mean by my "undefined entities." Perhaps an example would help.

Also, you say these "undefined entities" would cause a problem if the code is parsed as XHTML. Similarly, you say I'm publishing "sort-of-XHTML." Neither statement seems consistent with the fact that the W3 Validator--when parsing as XHTML Strict--passes the code with no errors or warnings: "This document was successfully checked as XHTML 1.0 Strict!"

not2easy

11:10 pm on Jan 3, 2015 (gmt 0)

People are taking time to give you information that can help you. Nothing wrong with asking for help with the parts you don't understand. Since this is interactive, and everyone who participates in Webmaster World.com is "in it together", please treat others the way you wish to be treated. One way to guard against misunderstandings is to read over your response before you post it. I fail to see signs of "attack" in the help mattur posted in the response to your question. (Many of us have "smileys" turned off)

lucy24

11:58 pm on Jan 3, 2015 (gmt 0)

Many of us have "smileys" turned off

But that's just to stop ;) from turning into ;) The underlying text-smiley is still there.

mattur

12:54 am on Jan 4, 2015 (gmt 0)

Sorry, I certainly should have worded my response a lot better.

You asked what you could do if browsers parse your pages with an XHTML doctype as HTML. Since this is not going to change, and since publishing XHTML pages generally requires a bit more work, but they generally just get parsed as HTML anyway, you could instead just publish HTML pages which are a bit easier and quicker to author - eg you don't have to worry about undeclared entities.

You may find the more in-depth checking of the new w3c validator combined with the html5 doctype to be more useful. There's a good interview with one of the maintainers of the new validator at the W3c here:

[html5doctor.com...]

And the new validator is here:

[validator.w3.org...]

lucy24

2:06 am on Jan 4, 2015 (gmt 0)

You asked what you could do if browsers parse your pages with an XHTML doctype as HTML.

In practice: If the page has no XML content, does it make any difference?

mattur

10:22 pm on Jan 4, 2015 (gmt 0)

lucy24: this is already way off-topic for CSS. If you want to discuss in more detail perhaps start a new thread in the HTML forum. There's some brief discussion of this in the html5doctor link above.