SitePoint Sponsor

User Tag List

Results 1 to 21 of 21

Thread: Wrap Anchor?

  1. #1
    SitePoint Wizard DoubleDee's Avatar
    Join Date
    Aug 2010
    Location
    Arizona
    Posts
    3,914
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)

    Wrap Anchor?

    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

  2. #2
    Community Advisor silver trophybronze trophy
    dresden_phoenix's Avatar
    Join Date
    Jun 2008
    Location
    Madison, WI
    Posts
    2,812
    Mentioned
    34 Post(s)
    Tagged
    2 Thread(s)
    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.

  3. #3
    It's all Geek to me silver trophybronze trophy
    ralph.m's Avatar
    Join Date
    Mar 2009
    Location
    Melbourne, AU
    Posts
    24,293
    Mentioned
    460 Post(s)
    Tagged
    8 Thread(s)
    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.

  4. #4
    SitePoint Wizard DoubleDee's Avatar
    Join Date
    Aug 2010
    Location
    Arizona
    Posts
    3,914
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by ralph.m View Post
    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...
    HTML Code:
    	<!-- 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...
    Code CSS:
    .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

  5. #5
    It's all Geek to me silver trophybronze trophy
    ralph.m's Avatar
    Join Date
    Mar 2009
    Location
    Melbourne, AU
    Posts
    24,293
    Mentioned
    460 Post(s)
    Tagged
    8 Thread(s)
    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?!?!????? )

  6. #6
    SitePoint Wizard DoubleDee's Avatar
    Join Date
    Aug 2010
    Location
    Arizona
    Posts
    3,914
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by ralph.m View Post
    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

  7. #7
    It's all Geek to me silver trophybronze trophy
    ralph.m's Avatar
    Join Date
    Mar 2009
    Location
    Melbourne, AU
    Posts
    24,293
    Mentioned
    460 Post(s)
    Tagged
    8 Thread(s)
    Quote Originally Posted by DoubleDee View Post
    I like to be different and EMPHASIZE things!!
    What was it you were saying about a professional look?

  8. #8
    SitePoint Wizard DoubleDee's Avatar
    Join Date
    Aug 2010
    Location
    Arizona
    Posts
    3,914
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by ralph.m View Post
    What was it you were saying about a professional look?
    One question mark, Ralph!

  9. #9
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by dresden_phoenix View Post
    As usual the answer is "it depends". An Anchor is an inline element and should not be siblings with block elements.
    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.

  10. #10
    It's all Geek to me silver trophybronze trophy
    ralph.m's Avatar
    Join Date
    Mar 2009
    Location
    Melbourne, AU
    Posts
    24,293
    Mentioned
    460 Post(s)
    Tagged
    8 Thread(s)
    Quote Originally Posted by deathshadow60 View Post
    MYTH! It's not in the specifications, and I've never once had it cause problems in one of my layouts.
    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.

  11. #11
    billycundiff{float:left;} silver trophybronze trophy RyanReese's Avatar
    Join Date
    Oct 2008
    Location
    Whiteford, Maryland, United States
    Posts
    13,708
    Mentioned
    7 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by ralph.m View Post
    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.
    Always looking for web design/development work.
    http://www.CodeFundamentals.com

  12. #12
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by RyanReese View Post
    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.

  13. #13
    It's all Geek to me silver trophybronze trophy
    ralph.m's Avatar
    Join Date
    Mar 2009
    Location
    Melbourne, AU
    Posts
    24,293
    Mentioned
    460 Post(s)
    Tagged
    8 Thread(s)
    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:

    Quote Originally Posted by RyanReese View Post
    I'd lovet osee some examples of it.
    This is an English forum, dude.

  14. #14
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    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.

  15. #15
    It's all Geek to me silver trophybronze trophy
    ralph.m's Avatar
    Join Date
    Mar 2009
    Location
    Melbourne, AU
    Posts
    24,293
    Mentioned
    460 Post(s)
    Tagged
    8 Thread(s)
    Quote Originally Posted by deathshadow60 View Post
    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.

  16. #16
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by ralph.m View Post
    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.

  17. #17
    billycundiff{float:left;} silver trophybronze trophy RyanReese's Avatar
    Join Date
    Oct 2008
    Location
    Whiteford, Maryland, United States
    Posts
    13,708
    Mentioned
    7 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by ralph.m View Post
    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.
    I can never bring myself to fix my typos. They just happen too often. It's readable and that's all that matters
    Always looking for web design/development work.
    http://www.CodeFundamentals.com

  18. #18
    Community Advisor silver trophybronze trophy
    dresden_phoenix's Avatar
    Join Date
    Jun 2008
    Location
    Madison, WI
    Posts
    2,812
    Mentioned
    34 Post(s)
    Tagged
    2 Thread(s)
    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.

    Code:
    <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>

  19. #19
    It's all Geek to me silver trophybronze trophy
    ralph.m's Avatar
    Join Date
    Mar 2009
    Location
    Melbourne, AU
    Posts
    24,293
    Mentioned
    460 Post(s)
    Tagged
    8 Thread(s)
    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.

  20. #20
    Ripe Tomatos silver trophybronze trophy Rayzur's Avatar
    Join Date
    Jun 2007
    Location
    Texas
    Posts
    4,174
    Mentioned
    4 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by deathshadow60 View Post
    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.
    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.

    9.2.1.1 Anonymous block boxes


    In a document like this:

    Code:
    <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.

  21. #21
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Rayzur View Post
    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.
    Which honestly sounds like another "lame browser side optimization" -- much akin to the "tables are slow to render" nonsense. (when a 386/40 with 8 megs of RAM and windows 3.1 can handle a table, it's a BS claim when even handhelds are pushing past 1ghz and multi-core)... or the "Implementing video/audio on the existing OBJECT tag instead of on new tags is too complex" bull.

    Since if (excuse the pseudocode)

    Code:
    if (thisNode.type=='textNode') {
      thisNode.level=(
        (thisNode.parentNode.level==BLOCKLEVEL) &&
        (thisNode.nextSibling!=null) &&
        (thisNode.nextSibling.level==BLOCKLEVEL)
      ) ? BLOCKLEVEL : INLINELEVEL;
    }
    Qualifies as a "burden", there's something wrong with the person writing the browser... Though admittedly between Mozilla and Microsoft, that could indeed be the case.


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •