The less folder is getting a little cluttered. It would be nice to have all of the themes grouped into their own folders.

The Problem

I think autoprefixer has determined that the market share of Firefox < 22 is small enough that it doesn't need to add -moz- prefixes for the old flexbox syntax. You can see proof of that in the compiled css.

This would be fine, as it should gracefully fall back to display: table. However, elsewhere in the code we're making the assumption that we support all browsers that match Modernizr's test for flexboxlegacy, and we're wiping out the display: table-cell.

The Solution?

If we're going to let Modernizr assume that we're supporting flexboxlegacy I guess we really do need to support all of flexbox legacy. We should be able to configure autoprefixer to support older versions of Firefox by setting some options in our Grunt build.

Any other options?

Currently, the unthemed version of the navbar looks pretty similar to the dark theme. Anything specific to the dark theme should be moved out of the base version and into the dark theme. The base CSS should just handle layout. This will make it easier for new themes to be added without overriding lots of styles.

When opening a menu on mobile, it would be nice to have a smooth animation instead of just toggling between display: none and block.

This is especially true for themes with a height > 36px. We should also make sure that the background is only repeating on the x-axis.

For starters, the menu columns should stack on narrow displays, and maybe expand accordion-style.

We can't try to override every possible way that a theme could break its responsive-ness. All we can do is make the theme-template good at fixing common mobile issues.

For starters, rounded corners are a little strange on mobile. For example, ul > li > a should have rounded corners on the top-right and top-left, but that isn't happening. Also, we should un-indent .wide menus when switching to the mobile view.

Now that we have a good workaround for creating guarded mixins without breaking variable definitions, we can probably un-scope the variables in the themes.

It would be good if the README actually explained the point of this project, its advantages over other navigation systems, etc. This should probably be done before the 0.3 release.

Prefixr isn't getting a lot of love these days, and some of its prefixes are a bit outdated. Going forward we'll just add our prefixes manually. We can safely drop support for:

• Most -ms- prefixes (which were required by IE10 previews, but not the final release)
• Most -moz- prefixes (which are no longer needed as of Firefox 16)
• -o- prefixes (which are generally not needed as of 12.10)

This will go in the soon-to-be created builds folder. It should be packaged as a tarball which will include:

• images
• compiled, prefixed, compressed CSS
• minified JS
• the html demo

Sure, it may be easier to test the template if it sets unique variables, but for future theme creators, it will be much simpler if the template defaults match the real defaults. This is at least true for @rad and @height because those properties only get set if they are different from the default.

It should now be easy enough to create a theme that we don't need a big collection of mixins to help it. It just causes confusion, and we should probably just get rid of it (after it has been ripped out of any existing themes that use it).

https://github.com/mlms13/Navtacular/blob/master/less/menu.less#L15 isn't being prefixed for some reason, does autoprefixer not deal with !important?

It looks funny when a menu is narrower than the parent li (and text) above it. I'm not sure if we can fix this using CSS alone, or if we'll have to resort to Javascript for this one.

When using the dark theme -- and probably others -- the mobile (stacked) menu doesn't have consistent widths for the border. Menus that were originally wide still have thin borders, and menus that were originally "normal" have much thicker borders.

There are several places (especially with "mega-menus") that we currently use a fixed pixel width. This should be avoided as much as possible. In those cases, we can probably use box-sizing to let us set a menu that is 100% wide and also has padding.

We'll need a fallback for IE7. Maybe add css-boxsizing detection to our Modernizr build. Then either use a Javascript fallback or make some attempt at fixing it with css.

When Modernizr detects flexbox support, we will need to reset the li items to display: list-item to avoid having a mess with fake CSS-generated tables. But in general, this will be a big improvement over our current float fallback.

Currently we're setting a height for the main ul to make sure the background color stretches down to cover the whole navbar. This should really be a min-heightinstead of a height. If a theme sets a border-top and/or border-bottom for ul > li > a elements, suddenly they have a greater total height than ul.navbar and suddenly things start to look weird.

Near the bottom of the document, there is a &:hover .menu style rule all by itself. Why not group this with the rest of the li:hover stuff?

Modular design for the win! This way, if a site needs a nice navbar style without the magic of menus, it can easily recompile the LESS without bringing in the extra menu styles.

By forcing a fixed height, it makes it difficult to have two rows of links. It also creates more work for our responsive stylesheet.

If that title sounds confusing, you're not the only one. Basically when the nav is visible on small screens, you can click on the document to close the nav. If that click on the document lines up with a link on the page, you actually click on that link (which I find mildly infuriating). If we can disable all links on the page so that when you click on the document to close the menu you don't navigate to another page unintentionally that would be great.

Currently it's crazy painful to override styles. I may have thought I was clever with all of those child selectors, but really I was just making a mess for my future self.

BEM should offer some inspiration for HTML class structure. This whole process basically necessitates a rewrite.

For small screens, the text is right up against the left edge. Tan looks like it's adding some padding or margin somewhere. If other themes are all doing this as well, we should probably abstract this out and just put it in the main navbar code.

IE7 has a bug when using backgrounds, line-height, and position: relative all at the same time: http://jsfiddle.net/WrYJy/1/

As you can see, the background starts at the top of the text instead of the top of the box. This bug affects our ul.navbar > li > a elements on :hover. Since the position: relative is only used for generated content -- and IE7 doesn't support generated content -- it should be safe to do something like this:

ul.navbar > li > a {
    .no-generatedcontent & {
        position: static;
    }
}

The changes to the .container class (particularly the position: absolute) don't play nice with Bootstrap.

hammer.js would be a good option to help us with this. In particular, it would be cool to...

• allow swiping from the left edge of the screen to open the menu
• allow swiping left to close the menu
  • ideally the menu will move with your finger until you let go
  • when you let go, the menu should collapse if the gesture was a swipe or reset itself (smoothly, of course) if the gesture wasn't a swipe
  • try not to move the menu on incidental left-right touch movement
• look at the Google Plus app for inspiration

If you add and remove the left style in the inspector, it animates. But if you use it like a normal person would, the menu doesn't animate into place. It may have something to do with the added class on the html element? I put a div container around everything and transitioned that and it behaved the same, so it's not because we're moving the body. This is in Firefox 26 on Windows and Mac.

While we're rewriting... mobile should be handled a little better. As long as JS is enabled, we should collapse everything to a button. Nav that slides in from the side will probably be the best way to handle massive lists of links.

We should set a fallback background color, or even better, a semi-transparent image background.

Instead of using floats by default and only using flexbox if modernizr detects it, we should use flexbox by default and fall back to floats if modernizr doesn't detect support.

Ouch, looks like I took the easy way out in 968517e. It may have fixed #25, but is it worth cluttering up my lovingly crafted styles with non-standard properties? All for a stupid IE7 bug? No.

Try playing around with min-height... I think that might work.

On mega menus in firefox, the nav items are still using display:table-cell and flexbox doesn't override it. Should we change the display to block to support Firefox or will that break something in another browser?

The dark theme's label button thing got some love, but the other themes haven't been affected.

Right now, if you try to scroll the main content area, the touch outside the navbar triggers the nav to close. It should scroll just the navbar.

Second, when you successfully scroll the navbar, the background is only as tall as the unscrolled window (100%).

Using the stock Android browser in 4.2, tapping on the .navbar-label triggers a touchstart first, which expands the navbar. Then, it immediately follows up with a click event, which either hits inside the navbar and follows a link, or it hits outside the navbar and re-collapses it. Both of these scenarios are pretty undesirable.

I think we can fix this with e.preventDefault() or e.stopPropagation() or both. This should prevent any subsequent events from firing.

jQuery slideUp and slideDown add an inline style of display: none. If we remove this style, we can remove every !important declaration in our css and possibly fix issue #52 in the process. I think dropping all inline styles would be a bad idea, so we may need to make our own slide animation or do a .css('display', ''). Any ideas?

Move source to src folder, add a builds folder where we can keep compressed snapshots of the releases.

Not only are we setting ul to height: 36px and making sure that each ul > li > a has a line-height + padding that totals 36px, we're also explicitly setting ul > li to have a height of 36px. That just seems unnecessary.

I've tested Chrome and IE7+. Removing this shouldn't break anything.

Currently we're only using flexbox for full-width navbars. Really, we could use flexbox for all navbars. Instead of setting all ul > li elements to box-flex: 1 we could just set the :last-child to box-flex: 1 unless the navbar is .full-width.

This change -- while definitely not supported by all browsers -- would make for cleaner code overall, and it's definitely the best bet for the future, as browser support for flexbox improves.

@stezu says it's caused by some display: block that he knows about, so I'm assigning to him.

There are a couple places that we use image fallbacks (e.g. RGBA, linear-gradient, etc). Right now we have those wrapped in modernizr classes, but they wouldn't need to be. If we get rid of the modernizr classes, we lose nothing, but our code gets a little smaller. It also reduces our dependency burden.

If we're falling back to display: table which has much better support than flexbox and does everything we need in our limited use case, we might as well make the full-width class default.

We're assuming that there is going to be a navbar on the page if we're loading the script which won't always be the case. Outside of our return this.each() function we have a few functions and some event handlers which should not be fired if there is no navbar on the page.

Our current fix is a bit ugly, and @mlms13 is looking into a better solution.

When the browser window is resized, if the navigation menu is flexible, some of the menus may no longer need to align to the right (if the window got wider) or additional menus may need to align right (if the window is now narrower).

As soon as you tap outside of an expanded menu, that menu collapses. If you tap below the menu (e.g. to open a different menu), the tap is processed as the previous menu is collapsing, and the tap doesn't go where you expected it to. This only seems to happen on Android (tested on 4.0.3).

A small delay before collapsing the previous menu will probably be sufficient for fixing this.

Does ul > li > a even need 'padding'? It seems like we could just use line-height, which would make some of the theme mixins less complicated.

When the (expanded) navbar is taller than the content and taller than the height of the device/browser, the navbar's background stops at the bottom of the browser. If you scroll the page, you see a weird chopped off background near the bottom of the nav.

Most of the time this won't be a problem, because page content is usually longer than navbar content. But that isn't the case in our demo, and either way we should try to handle it gracefully.

If we have more than one navbar, the slide out functionality doesn't show the proper navbar respective to the navtacular-label you clicked on. It shows the last one on the page because of css.