Forum Moderators: open
-paste
Here's a snippet of code as an example:
HTML:
<div id="sampleOneBlock">
<a href="#">
Some text in here. You can also put images, and use tags like <em> and <strong>...
</a>
</div>
CSS:
#sampleOneBlock {
width:300px;
margin:0 auto 0;
border:2px solid #f60;
background:#fff
}
#sampleOneBlock a:link,
#sampleOneBlock a:visited
{padding:5px;background:#fff;display:block}
* html #sampleOneBlock a {width:100%}
#sampleOneBlock a:hover {background:#ccc}
This may not be exactly what you are after, 'cause if you want to have other block level elements in there (other divs, paragraphs or heading tags, for example) you would need JS to do it right...
You can then use the CSS height & width properties to dimension the block, just like a div.
Using the javascript method you could stuff whatever you'd like in that div: paragraphs, other div's, lists etc.
Actually, if you make the whole anchor tag a block element it can contain divs or whatever. The cursor will change to the default (usually an arrow) when hovering over such elements, but the link is still in effect. Try this, just use a proper filename in the href property:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN""http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<title>Untitled</title>
<style type="text/css">
a {position:relative;display:block;height:300px;width:400px;background:silver;}
</style>
</head>
<body>
<a href=""><div style="position:relative;height:20px;width:20px;background:red;cursor:pointer;"></div></a>
</body>
</html>
Note that if you only wanted to affect certain anchor tags, this could be done with a class. In this example I've overridden the cursor change by giving the div a cursor attribute of pointer.
however to be 'valid' the div can only contain inline elements
Here's your code with a doctype and character encoding. Now try and validate and see what happens:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
<title>Untitled</title>
<style type="text/css">
a {position:relative;display:block;height:300px;width:400px;background:silver;}
</style>
</head>
<body>
<a href=""><div style="position:relative;height:20px;width:20px;background:red;cursor:pointer;"></div></a>
</body>
</html>
When I first started with CSS, I tried the same thing as your code above, though a touch more complicated; the result wasn't cross browser friendly...
Thing is, I try and stick to the standards, makes life a little more predictable!
The fact that you can't use block-level elements inside <a> tags seems an academic point - why would you want or need to?
Simply place the <a> inside the <div>
<!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">
<head>
<meta http-equiv="content-type" content="text/html; charset=iso-8859-1" />
<title>Untitled</title>
<style type="text/css">
div {
height: 200px;
width: 200px;
border: 1px dashed #333;
}
a {
display: block;
height: 100%;
background: #fc0;
}
a:hover {
background: #f00;
}
</style>
</head>
<body>
<div><a href="#">blah blah</a></div>
</body>
</html>
Voilà! One fully-clickable link/div using XHTML 1.0 Strict compliant markup.
-
S'worth remembering that anywhere between 5-15% of the general web audience are browsing without javascript capabilities/enable browsers.
Js links will be unusable to them, quite possibly with little or no clear indication why.
check out message #2.
#sampleOneBlock a { width: 100%; }
#sampleOneBlock a had already been declared display: block; so its width is by default 100% so doesn't require an explicit declaration.
At its most basic, my post simply showed a simple method to fill a div with predeclared height/width attributes which is more likely to be the case in some designs which use certain css techniques.
It's no biggie. Both of our solutions are equally correct - we just showed different ways of skinning the same cat. ;)
I was actually more intrigued by the 'wrong turns' suggested by jonathanleger and Rambo Tribble.
-
fwiw (puts pedantic hat on), block elements can contain inline elements *or* other block elements.
Inline elements can contain only other inline elements.
…just clarifying. ;)
wiw (puts pedantic hat on), block elements can contain inline elements *or* other block elements.
Inline elements can contain only other inline elements.
Good call, I should have said that the anchor inside the div can only contain inline elements.
but considered some of the css to be redundant.
Check again!
With respect to setting the width, there is a small difference bewteen your code and mine that requires it...
Our friend internet explorer needs either a width or a height applied to the anchor in order to fill the div; you supplied a height because you set a height on the containing div that was greater than it's content, I supplied a width because the height of the div in my code is controlled by the height of it's content.
We have two different methods in use here, we're not skinning the same cat, just similar cats ;-]
Though IE is quite robust and probably wont let you down, what you are doing with this line of argument is undoing what CSS and proper XHTML were supposed to acheive, and that is the separation of style from structure by relying on a css declaration to 'correct' your markup.
At any rate I have played with wrongly nested elements and applying anchors and CSS etc., and found that as what you would be writing is known as 'tag-soup', not all browsers will treat it equally - that's why standards exist, so we don't write tag-soup and can acheive predictable cross browser results.
I believe the error at validation is actually derivative of the parser's failure to acknowledge the anchor tag's elevation to a block element. Once the anchor tag is a block element, by having such status assigned with the CSS display attribute, it should behave like any other block element, thereby allowing the containment of other block elements.
Not quite right there.
It's not a bug or error on the part of the X/HTML validation process at all. display: block; is a purely stylistic adjustment.
CSS and markup are two different, but mutually beneficial elements which each validate according to its own specifications.
The markup (x/html) should still be validated according to its own, original specs regardless of any stylistic/behavioural 'switches' that have been made in the css.
Altering an element's stylistic behaviour via css should have no impact on its semantic/structural predefinition as prescribed in the x/html specs.
What scenario are you picturing where using a span would be advantageous over the valid, well-structured and 'lean' methods already posted?
I see your point as regards a single link with a single div. Where I see a problem is if the div contains other elements subsequent in the code to the link. Then your z-index is going to become an issue and the code will have to become more complex to accommodate that. For ease in deciphering the markup after the fact, setting such attributes on a link may be better served by an inline style, dependent, of course, on whether this is a single instance. Multiple instances would be better served by a class, but I doubt the original author wants all links on the page to behave this way.
Alternatively, keeping everything nested within the anchor tag also makes it clear what is contained within its activation area.
Oh, and another point, on your original markup you neglected a position attribute on the anchor element's CSS. That may prevent you from getting the desired result.
-
If the div contains additional elements then a height attribute could be added to the a declaration, thereby leaving the remaining height for the additional elements.
But that is by the by as the request was for ways to have a link fill a div - indicating that there would be no other elements within that div.
-
Can't agree on the use of inline css- more aggro than it's worth.
Imho (and experience), css is *always* easier to handle/alter from within a well notated external css file, even if the declaration block only refers to a single element on a single page of a site.
-
Also not sure why a position attribute is required.
The default is relative which has so far suited my use of 'expanded' anchors just fine across all modern browsers.
--
I honestly don't mean to sound contrary.
Either I'm not really getting the scenarios you're describing or we have a fundamentally different approach to achieving good markup/css. :)
<div onclick="javascript:document.location.href='http://www.target.com';">This is a div.</div>
With regards to the answer to the question, javascript-wise, the solution could be rendered much nicer, in terms of usability, by applying the following CSS to the javascript-hyperlinked div:
div.hyperlink{
cursor: pointer;/* modern browsers */
cursor: hand; /* IE 5.0 */
}
Not to mention, if the CSS 'full div link' isn't possible because perhaps a heading tag or list or something is necessary in the link, one could apply the 'JS layer' and back it up by having another 'back-up' anchor inside the div.
<div class="hyperlink" onclick="javascript:document.location.href='http://www.target.com';">
<h2>Looking for widgets?</h2>
<p><a href="/widgets/" title="Widgets!">We have a serious
collection of wigets for serious widgeters. <strong>Click
here to find out more about our widgets!</strong></a></p></div>
Tiny additional point…
re:
onclick="javascript:…
onclick (et al) is by design a javascript event, so doesn't need to be followed by javascript:
I've never really understood why some people are inspired/driven to do that.
-
Each to their own of course, but I'm not sure I'd go along with the idea of using the 'js link layer' over proper (even repeated) use of <a> tags to activate the heading and paragraph as individual items.
…reason being that not only are you potentially losing functionality for non-js browsers, but you're also losing out on the keyword goodness that comes from the triple-whammy of a keyword appearing in a link which has a heading's SE weight.
I can see the functional js-users' bonus of using the js link layer on top of using <a> links for both the heading and its accompanying text, but not as a replacement for one or the other.
-
Anyway, it's all good. ;)
First we need to look at why we would want a link on an entire div. Presumably, it's so we can populate the div with other elements, possibly inline elements, possibly other block elements. In the code Bill provided, let's see what it's doing.
First, he has a dimensioned div. Then he has an anchor tag, elevated to block display status, that has the instruction to fill the entire div. In other words, it's being told to leave no room for any other content, fill the div to capacity and overflow any additional content. The only linked content is inside the anchor tag, so block elements are illegal. Is this what we want? I doubt it.
So, okay, let's give the anchor tag a position:absolute attribute. Now the other content can populate the div, unaffected by the anchor. That solves it, doesn't it? Not exactly, because now any content that might follow the anchor tag will have, by definition, a higher z-index and could, potentially, obscure the link in the area it occupies. So we have two choices: make sure the anchor tag is the last thing in the div or give it a higher z-index than everything else. Now we have it working, no problem, right?
At this point it works, but what have we done? We have changed every anchor tag in the document to behave this way. Is that what we want? Doubtful. So we have three choices: if this is a one time circumstance we can go with an id style in the style sheet or an inline style; if we want to use the style on multiple tags, we can style it with a class.
Okay, let's say we want just this one occurance, the id works fine but does suffer from separating the style from the element it acts upon. Problem? That depends on your personal preference (or, dare I say, style?) The only reason I suggest the inline style is that if someone else is reading your code, having the style in the element it affects is often easier to read. Again, entirely your call, I'm just being devil's advocate.
On the issue of external style sheets, they make good sense if a style sheet is shared between documents, but aren't as appropriate for styles that affect only one page. Why? Because an external style sheet is a separate file. This means the HTML page loads, has to send another HTTP request, the server has to do a separate file lookup, generate a HTTP header and TCP packets, in other words, a whole bunch of overhead that isn't necessary if the style only affects one page.
Finally, onclick is not JavaScript, but an HTML event handler that calls a JavaScript function, either an internal one, such as Date.toGMTString() or a user-defined one. The javascript: pseudo-URL is designed to allow the href attribute of an anchor tag to call a JavaScript function, in other words, it allows a link to call JavaScript. It is something of a holdover and can be replaced by an anchor tag without an href value but with an onclick value.
If I still haven't made my concerns clear, just let me know and I will try to be even more explicit.
First we need to look at why we would want a link on an entire div. Presumably…
One of the differences in the way you and I conceptualise what's taking place might be evident through your use of the term 'status'.
To me, that would infer some kind of semantic elevation, but I've always (as mentioned) seen it as purely a purely visual technique that offers the behaviour of block elements without impacting on an elements structural inline 'semantic status'.
My use of the unclassified a {… was meant as a raw basics demo of the mechanics required.
I assumed that it would be understood as such, so while your passage about changing every anchor tag, position: absolute; and z-index was well-meaning, it was a needlessly detailed critique of my example.
I think the problem may be that you have a very specific idea of how and why a link might be expanded to fill a div and may not appreciate that legitimate scenarios exist where the technique might be used, but without the need for position: absolute; z-index: …;
-
I'm not sure why you seem to think that a uniquely-styled link would need its own stylesheet (along with the associated overheads).
If an author is styling one link uniquely, then it is almost a certainty that their familiarity with css has lead them to implement it elsewhere on their site.
I've never known anyone to use css on no more than a single link on a single page of their site.
Given that, it is likely that a stylesheet already exists and there is no reason that the additional declaration for the uniquely-styled ink couldn't be included alongside the other css declarations in that stylesheet.
-
…id works fine but does suffer from separating the style from the element it acts upon
-
Re: 'javascript events'.
While it's clear you also own a pedantic hat ( ;) ) I assumed you 'd appreciate the point I was making.
In layman's terms, onclick is an event specifically for triggering/handling javascript, it has no other purposes other than to pre-announce javascript code to the browser.
For this reason onclick="javascript:…" is a redundant repetition of that announcement.
I made no comment on the use of javascript: within an href, so again, while being well-meant, your passage had no relevance to any of the remarks I had made concerning that point.
(That said, I'm no fan of using javascript: in the href as it so often means a wasted opportunity to offer non-js users access
to the content behind the link. Caveat… caveat… ;) )
-
It seems we are each being being misunderstood by the other, so rather than go on posting endless 'illuminations' and caveats for the other it's probably best to appreciate that we each know what we're doing and what we're talking about and stop trying to fill the gaps that we believe exist in the other's understanding.
It's all good. :)
