CSS3 Menu Hover Troubles

My Current struggle is making pure-CSS3 menus (note: I use foundation grid)

Upon Hover
1. Unable to run mouse over other list items without it closing (too much space between each word?)

2. More than 3 items causes the last items to display inline/across

3. The drop down menu is always covered by the box that precedes it

/******************************************************* Navigation */

.a_nav{
    /*Menu Backgrund, border-radius, height and width settings*/
   
    line-height: 2.8125rem;
    background-color: #ddec44;
    padding:2%;
    border-top-right-radius: 1em;
    border-top-left-radius: 1em;
   
   
    /*border-radius: 12px;*/

   
}

.a_nav a {
  color: #008CBA;
  text-decoration: none;
  line-height: inherit;
 
  }


.a_nav  a:hover  {
   
    padding:0;
    color:blue;
   

   
}

.seperator{
    border-top: solid 1px #1a1a1a;
    clear: both;
    height: 1px;
    width: 100%;
}


/*Main Menu*/

.a_nav ul{
      background: #ddec44;
      text-align: left;
      display: inline-block;
      margin: 0;
      padding: 0 0 0 0;
      list-style: none;
     
     

}
   


.a_nav li{
      padding: 15px;
      display: inline-block;
      position: relative;

    /*right:5em;'
   
    margin-bottom: 0;
    */

}

.a_nav li a{
    display:block;
    /*padding: 0 14px;*/
    margin: 6px 0;
    line-height: 28px;
   
}


/*Drop Area Menu*/

.a_nav li li{
    padding: 10px 10px;
   
    /*display:none;
   
    /* REMOVES GAP/SPACE Between Menu Buttons
    /*margin-left: -11px;
    /*margin-top: 10px;
    */
   
    /*Changes Width of the Drop Down Buttons
    /*width: 400px;*/

}

.a_nav:hover li li{
    /*display: block;*/
   
}


/* This displays sub menu list on hoover*/
.a_nav ul li:hover ul {
      display: block;
      opacity: 1;
      visibility: visible;
     
     
}

/*Styles the menu and pops it out*/
.a_nav ul li ul {
     
      position:absolute; /*This makes the dropdown menu move out of the row element, no longer being contained the drop down menu works.
     
      Moves elements outside of the layout within its current box based on what its nearest ancestor is, even if it's  'body'. Absolutes are used to create columns, by creating to div's that will then move around within the contained relative box. Other boxes below it may be effected by it. It can sit on top of things. **Can go absolutely anywhere it wants like superman flying within their relative contained box
   
      */
     
      left: 0;
      width: 150px;
     
     
      overflow:hidden;
     
     
      /*This hides the menu by default until hover reveals it*/
      display: none;
      visibility: hidden;
     
     
}

/* This simply styles the sub menu a different colour not sure why it's 'separate' from above
.a_nav ul li ul li {
      background: #555;
      display: block;
      color: #fff;
      text-shadow: 0 -1px 0 #000;
}
*/

Code (CSS):

 <div class ="a_text row">
          <div class="a_header small-12 medium-12 large-12 columns end">
              Header
           
            </div>
           
    </div>

   
    <div class ="b_text row b_main">

   

    <div class="a_nav small-12 medium-12 large-12 columns">
            <ul>
                <li><a href="#">My dashboard</a></li>
                <li><a href="#">Likes</a>
                     <ul>
                        <li><a href="#" class="documents">Documents</a></li>
                        <li><a href="#" class="messages">Messages</a></li>
                        <li><a href="#">Views</a>
                        <li><a href="#">Dogs</a>
                    </ul>
               
                </li>
               
                <li><a href="#">Log  Out</a></li>
                 <li><a href="#">Uploads</a></li>
                <li><a href="#">Videos</a></li>
           
            </ul>
   
        </div>       
   
   
       

       
       
    <!-------------------------------------------------BODY ------------------------------->
        <div class="b_body small-12 medium-12 large-12 columns">
               
               
                <br>
               
                <br>
                <p>
                Body<p>
                Body<p>
                Body<p>
                Body<p>
                Body<p>
                Body<p>
                Body<p>
                Body<p>
                Body<p>
                Body<p>
                Body<p>
                Body<p>

        </div>   

    <div class="c_foot small-12 medium-12 large-12 columns">
           
    </div>
       
    </div>

HTML:

I don't have any pictures of the problem but when I can upload some I will.

 

After much tampering and exploring CSS3 menu's that the problem I'm having is based on settings within 'foundations' coding. Their default codes have been affecting my CSS3 menus. I'm currently weeding through and removing presets that I don't use to figure out what's effecting what >.>

This Code was the reason I couldn't hover without my menu closing

*,
*:before,
*:after {
  -webkit-box-sizing: border-box;
  -moz-box-sizing: border-box;
  box-sizing: border-box; }

Code (CSS):

And this code was the reason why my sub menu fonts were screwed up:

/* Lists */
ul,
ol,
dl {
  font-size: 1rem;
  line-height: 1.6;
  margin-bottom: 1.25rem;
  list-style-position: outside;
  font-family: inherit; }

ul {
  margin-left: 1.1rem; }
  ul.no-bullet {
    margin-left: 0; }
    ul.no-bullet li ul,
    ul.no-bullet li ol {
      margin-left: 1.25rem;
      margin-bottom: 0;
      list-style: none; }

/* Unordered Lists */
ul li ul,
ul li ol {
  margin-left: 1.25rem;
  margin-bottom: 0; }
ul.square li ul, ul.circle li ul, ul.disc li ul {
  list-style: inherit; }
ul.square {
  list-style-type: square;
  margin-left: 1.1rem; }
ul.circle {
  list-style-type: circle;
  margin-left: 1.1rem; }
ul.disc {
  list-style-type: disc;
  margin-left: 1.1rem; }
ul.no-bullet {
  list-style: none; }

/* Ordered Lists */
ol {
  margin-left: 1.4rem; }
  ol li ul,
  ol li ol {
    margin-left: 1.25rem;
    margin-bottom: 0; }

Code (CSS):

Can anyone explain why? (I'm still trying to figure out what exactly is effecting the menu hiding behind other boxes when foundation.css is in use); I'm also new to using frameworks and CSS3 in general and not sure exactly how or why that bit of default code was effecting my menus like that and how to go around it.

Only that doing so (fixing it) breaks my grid. :-/ so all css3 menus have to be styled differently based on this.

 

Welcome to why frameworks are mouth-breathing halfwit BS that you'd be better off NOT using. The mere fact it has you slapping steaming piles of manure like this presentational classname BS:

<div class="a_header small-12 medium-12 large-12 columns end">

Code (markup):

or this:

<div class="a_nav small-12 medium-12 large-12 columns">

Code (markup):

Is proof enough of that. That it's trying to make you think GRIDS have anything to do with web design is even further proof of how far down the road to /FAIL/ you are being led. (since fixed positioning / grid nonsense is a print concept that has no damned business on the web)

Much like other presentational framework crap like bootcrap, I'd suggest finding a stick to scrape that off with and learn to use CSS properly BEFORE diving for the wheelchair. Sometimes you have to learn to run before you can walk.

Hell, that second train wreck of CSS you posted ALONE being reason enough to walk away from Foundation. Do yourself a favor and forget ANY of that nonsense exists. Anyone telling you otherwise doesn't know enough about HTML or CSS to flap their gums on the subject.

 

Thanks deathshadow, I've been considering doing away with foundations. Before I used foundations my only struggle was positioning boxes.

The odd thing is, you mentioned not needing frameworks (I use it for rapid development mostly). When I removed foundations however, it broke my page someone but the code I'd written myself outside of foundations worked fine even when I reduced the page it was still responsive independent of the foundations area. The only thing it affected was slight position readjustments which was quickly fixed. If anything Foundation grids seemed to serve as a crutch to give me the confidence I needed to put things where they were supposed to be?

I've been thinking of getting rid of foundations but have to admit the Grid system is one I like. To quickly use a predefined class system that aligns everything when I want without having to do it all manually has been a relief. The headache has come from wanting to just code and not rely on foundations default settings for everything and having their defaults clash with what I want to do on a customized level, and then having to hunt out what they'd written that is clashing with mine---pain in the ass.

Mostly CSS3 for me is a means to an end. I see what I want to make and then fight with CSS3 positioning and boxes to try to achieve that vision quickly so I can get to the content (what's important to me up) while having more control than something like Weebly or Wix which boxes you into their platformer, and more control than my finances allow me (buying a web developer/designer). And for some reason coding myself feels more intuitive than dreamweaver.

With Foundations it's sort of been discouraging spending a week trying to do something in foundations that was working fine without it, spending days fixing code and breaking it apart that wasn't broken to fit Foundation, and then being unable to get timely help in the area has been a bit discouraging as well.

Another discouragement is the fact that learning to code the way foundation is telling me to doesn't seem to work 'outside' of foundation, and things coded outside of foundation don't work inside it.

Gotta admit the Grids (the only thing I wanted) have helped, but not the extra headache that has come with it regarding this framework.

 

Trust the guy when he says its BS.

I started with Bootstrap too, but as I learnt proper HTML & CSS scripting, I've realized that I can build it from scratch without too much difficulties. And I have more control over the entire site. One look and I know where the problem is.

 

Thing is, the "grids" stuff teaches you even WORSE positioning habits. Grids are by their nature "fixed" meaning you have to design your content to fit the grid, instead of having the layout adjust to the content. Really that's what should be done, the layout adjusting to the content instead of the content HAVING to be designed to fit the layout. That's why things like "Equal height boxes across the screen" are nonsense that have no business on websites in the first place... no matter how many PSD jockeys with the giant pair of brass to call themselves "designers" will try to do so in their ignorance of what a website actually is.

... and you said it right there, it's a crutch -- as prone to slowing you down and tripping you up as it is to actually help when you need it.

Sadly said "predefined classes" piss on the entire reason to be using HTML and CSS in the first place from so on-high, you'd think the almighty had just left a kegger. NOTHING in your markup should be saying what things look like -- and that's EXACTLY what those stupid code-bloat classes are doing. Say what things ARE, or WHY they would be getting an appearance, NOT what that appearance IS. Failing to do so? You might as well go back to writing HTML 3.2 as if CSS never even existed. That's why classes like "col-12" or "large-3" are just as idiotically mouthbreathingly stupid as "red" or "left'.

A good goal, content FIRST. I say it all the time, CONTENT FIRST -- but content first means that thinking visual layout when making the content is basically putting the cart before the horse; completely back-assward. Remember your for-screen layout is just one of MANY layouts and media targets you should be concerned with... Screen readers, braille readers, and of course the simple fact that search engines don't have eyeballs are all concerns which is why semantic markup and logical document structure should be in place before you even THINK about layout.

You take your content, or a reasonable facsimile of future content, put it into a editor in a logical order as if HTML never even existed. You then mark it up semantically (which means no DIV or SPAN at this point) so that non screen media non-css user-agents have something meaningful to work with. You use numbered headings and HR properly at this point, and HTML 5's halfwit SECTION, NAV, ARTICLE and FOOTER become pointless redundancies.. THEN you go in adding DIV and SPAN only as needed while creating your for-screen layoutS -- yes, PLURAL. First I suggest a non-media query desktop layout, then use media queries to strip off things like columns when/if the screen is too small. I realize this is reverse from what many say with the "mobile first" CSS, I consider that approach to be backwards as mobile is smart now, we can target it for behaviors!

GOOD layouts should:

1) Use dynamic fonts (em based) so users needing accessibility aren't diving for the zoom

2) Be elastic (em based) in widths so that things expand based on that default font size

3) Be semi-fluid, basically having a max-width in place so that long lines of text don't become hard to follow. A min-width for the non-media query capable layout is also a good idea if as I suggest you are using non-media query desktop as your base target.

4) Be responsive -- use media queries to strip off columns and re-arrange elemements to be as useful as possible based on the width of the device it's being shown on.

... and those four things mean a LOT of the things "grids" provide are NOT good layout techniques and to be frank have NO damned business on websites; no matter how many arsty fartsy "designers" will argue that and get their panties in a knot over anyone daring to say so.

You can also at that point make a larger display format breaking things up into more columns -- using as much of the display as possible on larger displays is a GOOD thing.

Then and only then should things like JavaScript be added, keeping in mind the unwritten rule of JavaScript -- "If you can't make it work without JavaScript FIRST, you likely have no business adding JavaScript to it!" -- JS should enhance functionality, and never supplant it.

It's called progressive enhancement, and doing so means you get "graceful degradation" as the result. When those fancy bits (CSS, JS, even images) are blocked/unwanted, the visitor will still get what's important -- your CONTENT -- in a useful and usable manner.

Something I've never seen ANY framework provide in a meaningful manner.

It goes back to something I was telling @serialentre in another thread -- when "designing" a site you are NOT designing it to stroke the graphic artists ego, you are NOT designing it to showcase your L33t Scripting sk1llz, you are NOT even designing it for the client or site owner's desires; you are designing it to deliver content to users and to meet the needs of vistiors to the site. That should first and foremost be the concern and EVERYTHING else is little more than window dressing.

... and that means accessibility and graceful degradation. You don't provide those, what does the rest matter? See why most off the shelf templates are utter and complete nube-predator BS and why places like ThemeForest and TemplateMonster are filled with nothing but sleazy scam artists. See how most sites who fail to provide those things usually rarely last out a year in a meaningful form unless their content is THAT DAMNED GOOD. (so good that visitors are willing to put up with the BS). It's why in many cases the goofy fancy artsy-fartsy bull ends up nothing more than dumping a can of shellac on a pile -- no matter how much you polish it the result is just bug excrement on horse manure.

As I've said many times, look at the big success stories of the Internet -- Google, E-Bay, Amazon, Wikipedia, Craigslist, Futaba/Wakaba boards like 4chan -- do these really look like they use "grids" or have some PSD jockey sitting there spanking it on the screen in Photoshop? No, they don't. For good reason. CONTENT people, CONTENT!

About the only time a "grid" of any sort makes any sense is a image gallery... and even then that's inline-block or float's job, not some arbitrary grid and class based nonsense.

We'll need to break you of the "grids" nonsense. I think you are probably falling into the trap of thinking "layout before content" which is back-assward, even if it's sadly become an industry standard practice.

Layout is actually pretty simple -- more so if you have content to work with from the start. There are a few easily recycled and reliable techniques, and if you stop trying to do things (like equal width equal height content elements laid out in a mosaic) that have no business on websites in the first place, it gets even easier.

Design the layout to the content, NOT the other way around... and suddenly all that "framework" nonsense and idiocy like "grids" seems like an utter and complete waste of time. The result might not be as pretty, but it's far more functional.

... and if you look at the big successful websites you realize that functionality over flashiness is FAR more important -- see CraigsList which is so hideous it gives graphics designers nightmares. You could actually do far worse than to follow their example.

 

So many peeps having this particular issue recently.

 

That's because SO many nubes are falling for the outright lies that most of this framework asshattery promises, and none of the "names" in the industry are promoting "the basic concepts" because those aren't hot, trendy, and certainly do not put buns in seats at lectures or sell books off shelves.

The part I don't get is how so many people who should know better -- long time developers -- see anything resembling merit in a lot of the nonsense out there other than as I often say, having never pulled their heads out of 1997's backside. That goes for mindless garbage scripttardery like jqueery, outright idiotic HTML/CSS trash like bootcrap, blueprint and foundation, mind-numbingly stupid rubbish like OOCSS, LESS and SASS, brain refuse like HTML 5, or any of the other things people make wild claims about being better, easier, simpler or faster when they are in fact THE EXACT OPPOSITE!

The easier part is the one that burns the most. jQuery is "easier", bootstrap is "easier", foundation is "easier", LESS is "easier", HTML 5 "structure" is "easier'...

You keep on using that word...

There is so much bloated, slow, inaccessible halfwit mouth-breathing chazzerai being promoted as good practice right now, it's a miracle any of the drek and shlock vomited up by these shmendrik, shmucks and shlemiels works at all. Of course you dare point ANY of this out most places, you're in instaban territory since Joe forbid anyone say anything negative about "experts" in the industry acting like a bunch of predatory scam artist putz.

Particularly if you are someplace where Kevin Yank-holes, Eric Meyer weiners and Paul Irish whiskey are trying to hock their latest smontzess.

Oy, If you can't say anything nice, say it in Yiddish.

 

Your tips were awesome and great many of which I've taken down into my notes. I've researched pros and cons of Grids and Frameworks to the end and back before bothering to learn one, your voice included, and am learning about the pitfalls myself in regards to how they interfere and hinder 'my' goals and needs.

Currently I jumped from Foundation Zurb to PocketGrid and from that I will build something that is bare bones meeting my content needs. I've been trying to build websites since tables, and struggling with website layouts since CSS. I can say the grids/frameworks not only met my needs, but when I removed them and worked without them I quickly learned that I didn't need them as much as I thought I did, and what I did need them for I could fix on my own.

I believe the reason why so many long-time developers see the use in Grids/Frameworks is because they acknowledge the problems you do but feel in reverse that the pros of them aren't bad and can show functional websites built with them that no one but programmers who hold a cross towards frameworks have a problem with.

I will always believe 100% customized is better than a framework or a grid, I have never heard any developer or book on learning a framework argue otherwise. I hear more people wondering why reinvent the wheel. Most books say, 'it's better to build your own according to your needs'. Moreso the fact that Designers and Developers acknowledge the problem but feel the pros work for what they or some others need to do is better.

And yes, it is easier in one way...but harder in others. There are always tradeoffs, we decide what it's worth and if the headache is worth working around.

Not everyone is a guru or wants to learn web design the way some are so passionate about it. Most people just want to build a site quickly that is functional and gets the job done without hiring someone who can do all that, to do what they can't for them.

Websites are a means to an end for me, I deal with them because I have to. The average joe isn't really struggling to use a website made with Wix or Weebly vs. a Framework vs. Content first approach vs. a Mix. That's what we as creators struggle with.

How we reach functionality and solve that, is part of it. Content First makes it easier, Design first is designing backwards, but it still can and does get the job done as you readjust for it, whether it's efficient or not. (Note: I am not arguing for Design First, just that these things target even seasoned developers and designers because they work for what they want to do or 'can' do with minimum effort. That's why.).

Content first is my general philosophy and it's what I've been doing, but right now my main goal is to explore building layouts and my ability to do so. Trying to get and feel comfortable. I can't spend a month conjuring up imaginary content when all I want to do is feel comfortable putting something together and explore what I can and can't do and my limitations and the limitations of how I choose to tackle it.

These are great tips you have. No need to 'break' me into anything. For all their limitations I like grids, don't use them for my entire mock-up sites, and there are good business sites (ex. National Geographic) that are both functional and use them. I am learning the pitfalls of them as I continue to use them for meeting 'my needs' (along with the major pitfalls of frameworks). They're decent training wheels that have given me the confidence I need to move from them at my own pace. And there's nothing wrong with training wheels, before riding a bike. (see games made for teaching kids how to Program).


I've learned that I can build my own barebones basic frameworks if I want. And that where grids really shine is the fact that I have more flexibility with it than using Gimp or Photoshop to create a mockup. So I can create something I want to see quicker than I can in Gimp.


I find myself naturally on my own moving away from Frameworks and Grids simply because they can't do what I want with ease without a major tradeoff (for me), but what they can do they do well. I wouldn't throw the baby out of the bathwater. And we don't have to agree on that matter. I see the pitfalls, I'm aware of them and become more aware of them as I go along, I'm learning. Whether I decide to use them or not or build my own doesn't say much except I did what met my needs at any given time.

Again great advice and great tips. Your opinion that Grids/Frameworks are a horrible invention that should be done away is less important to me than your list of detailed cons for why they interfere when someone who really wants to code a functional website, starts coding. Making the pros for Grids/Frameworks in a great number of cases unnecessary. But an exaggeration that they are a bane to existence.

What I would love to see is more honesty about the limitations of Grids/Frameworks when it comes to customization, and more talk about how to do what they can do but better and with a content-first approach. I've yet to see any book or website or person teach this and have actually learned this by using frameworks, encountering problems and coming here to solve these headaches.

Until people ask these questions or teach that then you'll continue to see Grids/Frameworks exist as an option especially among people who want to learn the right way or don't have the patience and time.

This all said your tips were wonderful, I took them all to heart. I differ on the opinions of frameworks/grids, but agree that there are better methods for people who really want to develop/build/create websites.

 

See for me, the thing is I've been doing websites for just over 16 years -- I've NEVER seen these things produce websites that were worth a damn, nor have I EVER seen it ACTUALLY be easier in terms of producing anything of value. That's why I'm so against them. They DELUDE people into THINKING it's easier, but the result is so pathetic that to be frank, they probably shouldn't even have bothered in the first place.

It's like Steve Jobs was shilling for them with his reality distortion field or something. I just don't get where this "easier" part comes from, or given what ABSOLUTE USELESS TRASH ends up as the result why anyone would use it by choice except a complete and utter level of ignorance that means the people doing so really has NO business making anything more complex than a blog for grandma that will never have more than five or six regular return visitors.*breathe* I am NOT a Salarian...

Grids most certainly falling into that -- by their very nature they are the antithesis of accessible design and REEK of the same "appearance BEFORE content" idiocy that makes things like WYSIWYGs utter and complete nube-predating scam artist rubbish. Just as something else you mentioned -- dicking around in Photoshop and calling it "design" -- is utter and complete nube-predating scam artist rubbish.

... and you said exactly the point; they are for people who don't want to learn the right way or lack the patience and/or time... and that's why they should NOT be surprised when what they make is epic /FAIL/!

Whenever I hear lame excuses like that, all I can think is "If you don't want to learn to make websites why are you making websites?"

Though the REAL problem is that as a whole the industry has been subverted by snake oil doctors and ignorant halfwits. How else could the WhatWG gain so much influence with the W3C that their steaming pile known as HTML 5 gained acceptance despite it trying to dial the clock back to the worst of 1997 pre-strict development practices.

Well, apart from ignorant fools love of sick buzzwords... See "Web 2.0" and how SEO is now an industry unto itself. Dimestore hoodoo, five and ten voodoo.