Develop Reference

Cross-browser CSS horizontal nav with dropdowns - is there such a thing?

I've created a website with horizontal navigation and one level of dropdown menu on each. It works great in all browsers except IE7 (dropdowns don't work) and IE6 (each <li> and <a> is 100% body width). I'm loathed to go through another 10 tutorials on the web and test each one in all browsers. Debugging my current one will probably take even longer.
I wondered if anyone has a concrete solution that works in all browsers? It's such a common design element. I'm happy to rely on CSS, Javascript, browser hacks, etc - whatever produces a consistent usable nav in all browsers.
tl;dr What code do you use for horizontal nav with drop-down menus, to work in IE6 and IE7?

"Suckerfish Dropdowns" is what springs into my mind.
Here's an updated version: http://www.htmldog.com/articles/suckerfish/dropdowns/
Note that the required JavaScript code to make it work in IE6 is included.

Almost in all of my designs, I had to add conditional styles for the stinky browsers IE6, IE7 and IE8. And to share with you, IE9 is not better, as it doesn't support CSS3 Transitions. Anyway, I strongly suggest that you stop searching an all-encompassing solution and try to create conditional styles and if necessary, even conditional scripts for IE, due to these reasons:
We developers almost always need to support IE as it has a considerable browser market share.
IE has many known problems which are never solved by Microsoft, and community found tricks and workarounds for it.
Addressing IE separately is known to cost less, than trying to address IE and other browsers in a package (experience)

what's the best practices for building a mobile/tablet-compatible web app

Seems that with handheld devices on the rise, one has to start taking them into account more and drop IE6 instead.
With that in mind, it has come to my attention that certain things don't work as well as can be or at all on say, my iphone.
what seems to break includes (but not limited to):
mouseover/mouseout events (can break almost anything)
CSS pseudos :hover as well, naturally (breaks nav CSS-only menus, for instance)
DOUBLE CLICKS - it zooms instead of the event handler
CSS-related issues (minute, it seems to work just like in Chrome w/o the gradients + some font-size issues)
the real question is: do you have any guidelines, articles or whatever that can cover things below or any advice you can give.
where do you start in order to transliterate the experience for desktop users over to mobile ones? do you try to make a separate skin for mobile devices or do you alter / fix your site to work as best as possible - how much maintenance and work is involved in either approach
are there any frameworks (CSS or JS) that can abstract that and do the graceful degradation where required? boilerplate comes to mind, jquery-mobile mootools-mobile (power tools)?
what do you replace things like the ones above with, click events?
how do you incorporate swipes into a web app? can you handle and respond to finger zooms? should you?
additional events like shake, tilt - do they bubble to the browser window?
do you do anything to accommodate awkward OS elements like select, checkbox and radio?
resource management - do you use a detection layer that will only send whatever files are particular to the device as opposed to generic js libs that can deal with both?
as for device support, I am interested in droid and ios only so javascript support will be pretty good - would you drop your main framework and go with a micro js lib instead?
and finally - do you have any impressions on how viable handheld devices are for e-commerce and monetisation (currently and in the near future). I would like to make sure from a business standpoint that the dev work will be worth the expenditure and we're not going to go after buzzword gimmick like '#socialmedia'. any data on conversion values in comparison to the desktop ones? this can help me gauge if these are used as a quick browsing instrument or can actually do the full monty.
any examples of a site that does a great job of working in mobile and desktop at the same time or through different designs, I would like to see them and find what's even possible.
thanks in advance.

You've just asked a lot of questions I've been asking myself recently. I can't give great answers yet as I'm still researching and exploring. but here are some useful links.
Rethinking the mobile web
Mobile emulators
How to build a mobile site
I hope this is at least a little helpful.

I can answer the conversion rate/business viability part of your question.
I had the chance to see Omniture numbers for some very, very big ecommerce interests and the answer is that conversion can be somewhat less, somewhat more, or about the same. There was a pretty good amount of variance depending on the device and the seller's site.
It's what you'd expect though, I think. The quality of the mobile/tablet experience varies a lot right now depending on how well each business optimized for mobile (and for which mobile devices). I think conversion varies a lot as a result.

following link should help. To make website like a nativeapp, jQuery plays amazing role
http://blog.2partsmagic.com/2012/07/developing-web-application-ipad-android-tablet/

Modernizr, html5shiv, ie7.js, and CSS3 Pie. Which to use and when?

I'm just starting to use HTML5 and CSS3 in my documents.
I understand the need for JavaScript to bring Internet Explorer up to speed with these new tags and styles, but I don't know which to use and when!
My plan was to use html5shiv and IE9.js to look after the HTML5 tags as well as the transparent pngs (and whatever other pesky errors they fix) but then Modernizr and CSS3 Pie were brought to my attention.
My question is, if I use Modernizr, does it look after my need for html5shiv as well as IE9.js? Or should I include these as well? What is the overlap, if any?
And what does CSS3 Pie do that Modernizr or the others doesn't? Or vice versa?
I appreciate your guys help. Let me know what you do!?

I've got extensive experience with all of these, having used them for a few years each.
Modernizr
Includes HTML5shiv functionality
Also does a lot more – if you don't use the other features, then don't use it, it does slow down page loads, but is worth it if you need it!
HTML5shiv
Very small, just fixes html5 elements in IE, nothing else.
CSS3PIE
Lets you use border-radius, gradients and box shadow in older versions of IE. Also can allow PNGs in IE 6. Adds a noticeable delay to page load.
ie7.js (and ie9.js)
Gives you many CSS3 selectors, min and max width, multiple classes and fixed positioning. Also can have a png fix if you like. Doesn't seem to slow things down much.
Conclusion
My advice would fall into two categories:
If you are just using the new (is 2 years new on the internet?!) elements, and CSS3 selectors, then use ie9.js + the html5shiv. This is lightweight, and just lets you get on with things without having to remember that IE6 doesn't support anything.
If you are using a lot of CSS3 stuff, then CSS3PIE will sort out border-radius and box-shadow. The gradient support seems a little flaky, so I've always used a fallback image instead. Modernizr lets you easily deliver different properties to browsers with different support. I've mainly used this for determining whether a browser has CSS transitions and transforms, as they are useful for any image sliders or content carousels. It's worth using the customisation tool to only include the functionality that you want – the webforms stuff shows a textbox with 50 in it for a couple of milliseconds, so it's worth disabling if you don't want it.
Hope that's helpful!

I would recommend you use only what you need. Build your app in a browser that supports the features you are using, and periodically test in other browsers that you support. If something isn't working correctly, find the appropriate fix, whether it be html5shiv, IE9.js, Modernizr, or CSS3 Pie. You are not going to use all of the new features in HTML5 and CSS3 all in one page, so you don't need to include every polyfill library in existence. Wait until you find problems with the features you're trying to use, then try and find the library necessary to do that.

I've used mainly CSS3Pie...it works great. But this afternoon i tested it on my laptop with I.E8 and there was an problem with it...it was disabling some css lines...when i removed the css3pie code my site gained twice the speed...then i came accross the posts with people arguing about the css3 slowdown...So at the moment i'm busy to find another way for IE7 & IE8 to have border-radius and shades.
If you want to use it...please test alot as it is NON-official fixes

Where to begin with Smartphone Web Development? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
Ha all,
So I've been taksed with developing a smartphone website for our property portal and first thing I did was see what lessons others had to tell online but I've found very little.
I'm not building an app, I'm building a website and I'm looking for do's and don't with regards to html, css, widths/heights approaches, javascript (is jquery going to play nice on all platforms?) and anything else that relvant to this kind of platform.
Looking around at others I like http://mobile.whistlerblackcomb.com/ very much.
Regards,
Denis

UPDATE:
While most of the text below still applies, I would now say that jQuery Mobile does a great job of providing a well-designed and usable set of UI components, while also alleviating a lot of the device testing and detection issues that I've used WURFL for in the past. It's still in beta, but seems to be working pretty well. I recommend checking it out.
The two most important issues to consider when getting started are:
1) Device detection
2) Mobile UI design
For issue number 1, I strongly recommend looking at the WURFL device dataset:
http://wurfl.sourceforge.net/
Using this, you can retrieve (some) capabilities of devices that are accessing your site, using their User Agent string. Testing mobile web apps is kind of like browser testing from hell--there are so many different combinations of devices and browsers, that it's a difficult task. If you can focus on developing one or two versions for fairly capable phones, say:
1) minimum 300px width with claimed "web" support and a touch screen
2) The same as above, but without a touch screen
you can create a very usable site that will work for most "smartphones," or "app phones" as David Pogue has more accurately named them. For the actual testing, you can try:
1) Making a list of all of your friends and what kind of phones they have
2) Going to a phone store and using those phones to test your site
and, regardless of what you do, you'll have to be agile when you receive the inevitable user feedback about broken/slow content on their device.
Regarding UI design, there are a couple of issues. The simplest one is nice looking CSS. Here, just look at some mobile sites you like and steal their CSS. Once you've done this, you're basically doing regular old web development, just on a small screen. ul's will become nice iPhone-y tables, etc.
The bigger problem is mobile web usability. In a lot of ways, we're in a 90s-web situation with mobile web development. What I mean is that we working without well-established design patterns. This makes doing mobile web development really fun, but it also means that you have to be ready to adjust your ugly/broken UI as better ideas evolve. One current example are the global nav/breadcrumbs you see on a lot of mobile sites. A surprising number of folks out there are trying to mimic the behavior of native iPhone apps by providing a persistent navigation tool (back button) within the mobile app. While this is kind of pretty, it has a few problems:
1) It is redundant, given that the browser comes with a back button that users are very familiar with. The reason these global navs exist in native apps is that they don't come with a free navigation tool.
2) The web is great. You can enter, leave and re-enter "apps" at any point in their structure. By assuming that a user takes a linear path through your app, you are decreasing its webiness, making it a lot more crude relative to the rest of the web.
3) It breaks. Either you can get in a situation where the app nav and the browser nav point in opposite directions (hitting the back button in your app steps forward through the app history), or you fake a back button with javascript, which breaks if they don't start at the beginning of an app (emailed link, bookmark), or you set up sessions, which can be a big pain just to replicate what you get from the browser for free. Sessions are also vulnerable to brokenness (emailed links, bookmarks), and you're really not gaining much.
I guess my main points here are:
1) Don't forget you're on the web. The web is cool, browsers are cool, make use of that.
2) Don't be afraid to play around. There aren't many well-established patterns here, so you may have to try out some of your own.

A List Apart can get you started:
"Put Your Content in My Pocket" by CRAIG HOCKENBERRY

With modern smartphones there's actually no difference between developing a conventional webpage and a dedicated website.
But you could try the emulators that the major players like Apple, RIM, Motorola and Nokia provides to see how they look.

I'd suggest taking a look at some other mobile sites. I posted a few below.
m.reddit.com
diggriver.com
mobile.washingtonpost.com

Since modern mobile browsers work quite much like desktop browsers, the old adage of "minify JS and CSS, optimize images" should be your primary concern, as bandwidth is more valuable on mobile devices.
In addition, consider following:
Think if you need all your images, and if they are too large for small screens. Consider removing or reducing the size of large images.
Check your JavaScript - Will your site work without it? It may be beneficial to disable parts of it, as it may easily reduce speed on mobile browsers
You can often get by simply by including specialized CSS styles tailored for small screen devices in your main site
You might also find this helpful: Why your mobile site probably sucks

Mobile sites are often used on regular phones, and often go to m.example.com instead of www.example.com. These sites have little/no javascript or css compatibility. When you ask about mobile sites, keep in mind that there are two types of mobile sites.
Modern smartphone are supposed to handle browsers the same as a full fledged browser, but they are not. In fact, the iPhone lives in a fantasy world and will report a window width of over 900 pixels!
There are tricks that you can do for a smartphone. A touchscreen has no use for the :hover pseudo-class. This can be a problem for menus that require hovering. You can design around this. How? you ask...
Apple looks at a new meta tag (do a google search on it) and other smartphone browsers look at this as well. With this, you can force the smartphone to report it actual screen size in pixels, and not it's pre-programmed fantasy size.
Now that you have done this, you can use css conditional statements,
#media only all and (max-width:600px){
CSS RULES THAT ONLY APPLY IF THE SCREEN WIDTH IS <600 PIXELS
}
I've used this to block <div>s that cluttered up a mobile device screen: lightbox, for example. I also used this to modify image widths, so they fit on the device better. Why did I choose 600 px? I felt that many of the newer "netbooks" should be lumped in here as well.
I hope this helps.
--Dave

If you are looking to do development specifically for an iPhone or iTouch use thise conditional statement.
[if SafMob] #import url(iphone.css);
Here is an article about building sites for mobile.
http://www.alistapart.com/articles/pocket/

Meagan Fisher's talk on Designing Effective Mobile Interfaces provides a good overview. She recommends the book "Mobile Web Design" by Cameron Moll. Technology wise, I'd start by getting familiar with XHTML Mobile Profile if you're not already.
As far as design goes, think thin. Snag a book with nice typography and see if you can duplicate the page layout with CSS. "Elements of Typographic Style Applied to the Web" is a good starting point for that. Phone websites are about scrolling, not complex navigation. Rhythm and spacing are important. Keep images small and your text high contrast, and you'll end up with something that loads fast and looks good.

There is also this threeparter, "Mobile Web Design" by Cameron Moll:
State of the Mobile Web
Methods to the Madness
Tips & Techniques
The series is from 2005, but many of the info is still relevant. The last part "Tips & Techniques" also lists a lot of other resources on mobile web development.

How are programmers tackling ie6 bugs these days?

I have been using dean edwards ie7/8 script. Not sure if it's my implementation or not but sometimes I would experience ie6 issues that weren't quite fixed or required special handling which meant I would be back where I started, caring about ie6. So, I was wondering if ie7/8 is still the go or if some other practice/solution was better.

Update: I expanded my answer here with a tutorial on my site, which will probably be more helpful than my answer here. Ultimate IE6 Cheatsheet: How To Fix 25+ Internet Explorer 6 Bugs
Here's how I tackle IE6:
I validate both my XHTML and CSS.
I keep my designs simple, even the complicated ones.
I don't use hacks that invalidate my
CSS.
I use a JavaScript framework/library
(I like MooTools, but you'll get a
lot of votes for jQuery, Prototype,
YUI, Dojo, and many others) that
handles most of my cross-browser
JavaScript problems.
I progressively enhance my pages so
that they first work without
JavaScript and then add all the bells
and whistles.
For some of the double margin
problems, I use display:inline;
If I absolutely have to, I use a
separate stylesheet, though I'm
finding I have to do this less and
less.
I try to avoid transparent images in
my layouts. If I absolutely need
them, I use a PNG8 with alpha
transparency, which IE6 actually does
support.
To get at the min-height problem, I
do the following:
This for IE6, which interprets height as min-height:
.classNameHere {height:300px;}
This for for everything else:
div>div .classNameHere {min-height:300px; height:auto;}
Incidentally, if you need to isolate IE6 with CSS, that's a good way to do it, as it doesn't support child selectors.

I try not to support IE6

YUI reset and YUI grids have allowed me to keep my sanity when support IE6.
IE 6 is an "A-grade" browser, which means that bugs and errors get priority.

I'm using:
"Reset.css" to minify the difference between the browsers default CSS computed styles (e.g. YUI reset.css)
Conditional Comments to put additional css file into the scope ;) (e.g. ./ieFix.css)
W3C Validator to tell if the difference in rendering is caused by bad nesting or it's just IE ;)
if that fails, jQuery helps a lot ;)

To be completely honest, I don't really handle IE6-issues much lately. My design-process is simple:
Reset margin/padding on everything. I mean everything.
Test my page layout every few minutes. Takes one tap on F5.
If any change breaks the page, I stop everything and evaluate the change.
If the desired method cannot be used, I research alternative methods, excluding 'hacks'.
I validate both markup and css. And always use XHTML 1.0 Strict.
I make sure my site works first without Javascript, and then later use jQuery.
These basic practices have kept me from having to work around IE6 issues a lot over the years. The only issue I still get upset over is IE6's support for PNG24 with Transparency, but IEPNGFix takes care of those - usually without breaking my layouts too.
It may be the opinion of a foolish man:Great developers don't find complaints, they find solutions.

Conditional comments, patience and sometimes ie7-js.

I agree with the responses that talk about a process involving clean code, conditional comments, keeping ie6 happy but not perfect, etc etc. But it's a very cautious, little by little process which is still, at the heart, quite time consuming when really it's all for one browser.
I am reluctant to tick any response as answered because all the responses talk about existing methods I am familiar with. It may be that my question is answered "No" :) because essentially I was after a framework that meant you didn't even have to worry about ie6's nuances, just code in a modern way - something I thought ie7/8's js would do but even just today I realise that min-height isn't being fixed!!.
Thanks anyway for the replies - it's helped re-enforce that my approach is still the status quo and I am using my time as efficiently as I can.

I instituted a policy recently with regards to IE6, basically, as long as it does not break the site on IE6, don't spend time on it.
I don't think IMHO, that IE6 still has enough use to make it worthwhile for my company to continue spending money fixing small issues with it.
Here is a quick sample of data from several of the sites that my company has tracking data on. This is a combination of recent data (today) and some data from about 1 year ago, so there is a higher percentage of IE6 than we actually get now, and even then all but 3% of the hits are to 1 of the 8 sites included in the data.
alt text http://unkwndesign.com/browerUsage.png
**Note Chrome is built on webkit but its numbers are not included in webkit, just to show how fast it has grown. The total percentage is 100.5% because of rounding.

I don't think there is ever a standard as to what browser you can or can't ignore. It depends on the organization -- or the audience in the case of your start-up. Any JS you write should "gracefully degrade" but making sure that actually happens requires some artfulness at times.

There is really just one "fix" for IE-problems which is to help facilitate its suicide. The only way I've discovered to help IE commit suicide is to educate my visitors. This can be done by sniffing the browser and if IE is detected you display a "help upgrade the web" banner.
Kind of like GMail does...
We're doing this at ra-ajax and stacked (visit the site with any versions of IE)

Build for firefox first, nuke or downgrade design elements experience tells you IE6 can't handle at the outset, and not spend more time than the client spec warrants
TBH experience is the #1 preventative measure for IE6 problems

Make it work in Firefox;
Check to see if it looks and works the same in IE7;
Check to see if it sorta works in IE6 (because that's good enough).
If you can't do the layout with simple CSS (no crazy relative+absolute positioning or float:after fixes) then just do it with tables;
Put a DOCTYPE in to force the browser into compliance (rather than quirks) mode;
Minimize box model issues by minimizing the use of contained borders (or by giving invisible borders to other similar elements) and nesting elements to minimize padding/margin/border combos, which will just cause you grief;
Don't bother trying to get a CSS menu to work across all browsers. It isn't 2003 anymore. Just use Javascript (eg jQuery/superfish).
Only use :hover on links. If necessary change them with display: block.

Kill ALL default styling before starting.
Throw Dean Edwards script at it.
If problems persist to tell users to upgrade.
If IE6 is vital, use an IE stylesheet that removes whatever doesn't work and replaces them with less complex styles.
jQuery :hover etc. to .hover, input[type=submit] to input.submit etc. Helps with older versions of FF and Opera aswell occasionally.

I've decided yesterday to not support it anymore. There's a movement starting trying to kill IE 6.
Thanks to IE's conditional comments it's easy to show a message for just those users.

I build it for Chrome, then I optimize for Firefox most of the time its just little things then I go into IE 8 and then I go into IE 7 since most bugs I will have eliminated by then. After IE 7 I take a brief look at Opera and am finished for the day. Who cares about IE 6 anymore?
Are you complaining to the Intel manufaturers that the cpu doesn't fit into your comodore? There are technology advancements and I think IE 6 should be killed the best way to do that is to tell the the user he has to upgrade and let the site look like crap thats the only way to force them to switch. Some will eventually ask their children why the internets are broken and then the son will come along install all updates and the mom or dad can be happy again.
My answer in short: No more optization at all is how I handle it.

By encouraging users to upgrade to something—ANYTHING—better.