To the right of my “Log In” button on my Log In Form, I want to add the hyperlink (Forgot Password??)
Can an anchor element <a> stand on its own, or should it be wrapped in a block element like a <p>??
Debbie
As usual the answer is “it depends”. An Anchor is an inline element and should not be siblings with block elements.
BAD: <div> <p>some txt</p><a href=“#”>anchor</a></div>
GOOD : <div> <span>some txt</span><a href=“#”>anchor</a></div>
However, exceptions are made if you intend to give the anchor element position:absolute.
Hope that clarifies things.
As above, better to wrap it in a block element. It’s also better not to have an inline element sitting next to a block element. But an inline element sitting next to another inline element is fine … and in this case, the <a> may be sitting alongside something like an <input>, which should be OK. So the context / code needs to be seen.
Here is a larger snippet…
<!-- LOG-IN FORM -->
<form id="login" action="" method="post">
<fieldset>
<legend>Log-In</legend>
<!-- Email -->
<label for="email">E-mail:</label>
<input id="email" name="email" type="text" maxlength="80" />
<!-- Password -->
<label for="pass">Password:</label>
<input id="pass" name="pass" type="password" maxlength="40" />
<br />
<!-- Submit Form -->
<input type="submit" name="logIn" class="button" value="Log In" />
<!-- Reset Password -->
<a href="reset_password.php">(Forgot Password??)</a>
</fieldset>
</form>
And for my “Log In” button I have…
.button{
display: inline-block;
width: auto;
overflow: visible;
margin: 2em 0 1em 0;
padding: 0em 2em 0 2em; /**/
}
So what do you think now??
Thanks,
Debbie
To be honest, that looks OK to me.
(I would just get rid of one of the question marks, though, as multiple question marks etc. is not proper grammar. Know what I mean??? 
)
I like to be different and EMPHASIZE things!!
Debbie
What was it you were saying about a professional look? 
One question mark, Ralph! 
MYTH! It’s not in the specifications, and I’ve never once had it cause problems in one of my layouts. I’ve seen some people around here who should know better propagating that myth too… It’s like the nonsense of wrapping a IMG tag in a lone P with nothing else – no point to it.
Also, be clear if you mean LEVEL or DISPLAY, since the default display for a level may be the same, they don’t mean the same thing.
Not that it matters in DD’s case – all her elements are inline-level, so that’s rock and roll.
Well, I have, and I’m pretty sure Paul O’B has. For example, I’ve had images sent to display: block up against divs and had really buggy results with it (sometimes displays one way, sometimes another), so I always wrap them in a div or something. I find that totally reliable.
Really? I’d lovet osee some examples of it.
I’m not doubting you or calling you a liar, I’m sure there might be some oddball case, but I’ve never heard of that happening, or seen it.
That’s where I’ve been at with it since I first heard of it years ago… as I’ve never seen a working testcase.
… or should that be failing testcase?
I’ve heard of it, NEVER seen it. Might be something as silly as another thing legacy IE screws up without haslayout or some similar oddity that’s not really a problem with the inline-level tag itself, so much as it is a certain family of browsers not reporting values right.
I had an example something like this once (not sure if it was exactly the same) but despite being display: block, Firefox and at least one other browser kept showing the image hard up against the text on first page view, and then on refresh the gap would appear. Anyhow, this was one of a few experiences that put me off putting inlines beside blocks.
Off Topic:
This is an English forum, dude.
That demo is funny, might explain why I don’t see the error in my layouts too…
I rarely if ever use margins facing margins… ‘colllapse’ is too inconsistent and too much of a pain in the backside cross-browser.
Yeah, I don’t know if the original example had margins on both sides like that. I just remember the two items collapsing together and jumping back into place on refresh. I can’t replicate in now, though. Maybe browsers have fixed whatever was causing it.
With Mozilla and Chrome’s current “new version every five minutes” it wouldn’t surprise me… unable to recreate in 3.5x though, so maybe it’s a FF2 bug?
After all, FF 2 and earlier were buggier than IE5 on a LOT of things… though most of the bugs weren’t related to rendering; while most of the rendering bugs/implementation gaps are still unfixed and teenagers now.
I can never bring myself to fix my typos. They just happen too often. It’s readable and that’s all that matters 
DS60,
MYTH! It’s not in the specifications, and I’ve never once had it cause problems in one of my layouts.
hmmm.
Ok I followed up on this. I located an old macbook that still has FF2! and Saf3.0 and followed up on ralphs link. No problems at all, not even with facing margins.
I like the idea of less tags… but I am still wondering structurally, ( which is essentially the OP) DO INLINE ELEMENTS stand alone semantically? In the case of IMGs this may seem more clear cut, but anchors? or lets say you had a heading, with a long emphasized non-paragraph pseudo branding statement after it. Play along with me on this: if the situation required motto/mission statement is to have EM semantically… shouldn’t it still… be wrapped in a block element ( a DIV, if not a P?.. in some cases I see this a BLOCKQUOTE even). The point is, regardless of rendering, an EM floating next to an H1 seems odd?? As would an A outside a UL or a P??? And thus my reasoning as to this being more than a mere pet peeve.
<div id="branding">
<h1 id="logo" >MyCo<small>We intend to make money</small></h1>
<em>The purpose of a corporation is not to make a product or provide a service for customers; it is to make money for stakeholders.</em>
</div>
Maybe in the original exxample where there were problems the image was not set to display: block. I have a feeling that was the problem. Still, an inline element is not really a block element even if set to display: block. The fact that such fakery is needed makes me wonder if it’s a good idea.
I wouldn’t call it a myth, I’d be more inclined to call it Rare Problem. From what I remember, problems seem to usually happen on very busy pages with a LOT of content for the browser to parse through. With the browser computing very quickly sometimes a lone inline-element (between blocks) lower down in the page source can get misplaced. It’s not easy to reproduce the problem in a simple stand alone test case.
Your right, it’s not in the specs, in regards to being illegal. But here’s what is in the specs which I would say is VERY closely related.
[URL=“http://www.w3.org/TR/CSS2/visuren.html#anonymous-block-level”]
9.2.1.1 Anonymous block boxes
In a document like this:
<DIV>
Some text
<P>More text
</DIV>
(and assuming the DIV and the P both have ‘display: block’), the DIV appears to have both inline content and block content. To make it easier to define the formatting, we assume that there is an anonymous block box around “Some text”.
In other words: if a block container box (such as that generated for the DIV above) has a block-level box inside it (such as the P above), then we force it to have only block-level boxes inside it.
You see, the browser is being forced to generate an anonymous block box around any inline elements that are siblings of a block within a block. If you don’t wrap your inline elements in a block yourself then you are depending on the browser to figure it out on it’s own. That inline content is going to get a block box around it one way or another. By doing it yourself you take the burden off the browser and allow it to parse through the page without having to stop for a millisecond and make a block box.
As I mentioned above, we usually see the problem crop up on busy pages. When people post threads about it, this comment is almost always found in their post… “When I refresh the page everything is fine”.
I’m guessing that’s because the browser got the anonymous block box in place the second time around.