I recently did the Chris Coyier tutorial from the css-tricks.com weblog #38: Basics & Tips on Designing for the iPhone. Needless to say I got very excited and suggested to a guy that I do some code monkey work for that we could now offer iPhone websites to his clients. He said cool, but what about other mobile devices? good question. So what is the low down on designing websites for Android, Blackberry, WindowsMobile, etc? Are people bothering with the other platforms? Thanks.
R – Websites for the iPhone – but what about other platforms
browseriphonemobile
Related Solutions
It's certainly possible to develop on a Windows machine, in fact, my first application was exclusively developed on the old Dell Precision I had at the time :)
There are three routes;
- Install OSx86 (aka iATKOS / Kalyway) on a second partition/disk and dual boot.
- Run Mac OS X Server under VMWare (Mac OS X 10.7 (Lion) onwards, read the update below).
- Use Delphi XE4 and the macincloud service. This is a commercial toolset, but the component and lib support is growing.
The first route requires modifying (or using a pre-modified) image of Leopard that can be installed on a regular PC. This is not as hard as you would think, although your success/effort ratio will depend upon how closely the hardware in your PC matches that in Mac hardware - e.g. if you're running a Core 2 Duo on an Intel Motherboard, with an NVidia graphics card you are laughing. If you're running an AMD machine or something without SSE3 it gets a little more involved.
If you purchase (or already own) a version of Leopard then this is a gray area since the Leopard EULA states you may only run it on an "Apple Labeled" machine. As many point out if you stick an Apple sticker on your PC you're probably covered.
The second option is more costly. The EULA for the workstation version of Leopard prevents it from being run under emulation and as a result, there's no support in VMWare for this. Leopard server, however, CAN be run under emulation and can be used for desktop purposes. Leopard server and VMWare are expensive, however.
If you're interested in option 1) I would suggest starting at Insanelymac and reading the OSx86 sections.
I do think you should consider whether the time you will invest is going to be worth the money you will save though. It was for me because I enjoy tinkering with this type of stuff and I started during the early iPhone betas, months before their App Store became available.
Alternatively, you could pick up a low-spec Mac Mini from eBay. You don't need much horsepower to run the SDK and you can always sell it on later if you decide to stop development or buy a better Mac.
Update: You cannot create a Mac OS X Client virtual machine for OS X 10.6 and earlier. Apple does not allow these Client OSes to be virtualized. With Mac OS X 10.7 (Lion) onwards, Apple has changed its licensing agreement in regards to virtualization. Source: VMWare KnowledgeBase
Short answer - de facto limit of 2000 characters
If you keep URLs under 2000 characters, they'll work in virtually any combination of client and server software.
If you are targeting particular browsers, see below for more details on specific limits.
Longer answer - first, the standards...
RFC 2616 (Hypertext Transfer Protocol HTTP/1.1) section 3.2.1 says
The HTTP protocol does not place any a priori limit on the length of a URI. Servers MUST be able to handle the URI of any resource they serve, and SHOULD be able to handle URIs of unbounded length if they provide GET-based forms that could generate such URIs. A server SHOULD return 414 (Request-URI Too Long) status if a URI is longer than the server can handle (see section 10.4.15).
That RFC has been obsoleted by RFC7230 which is a refresh of the HTTP/1.1 specification. It contains similar language, but also goes on to suggest this:
Various ad hoc limitations on request-line length are found in practice. It is RECOMMENDED that all HTTP senders and recipients support, at a minimum, request-line lengths of 8000 octets.
...and the reality
That's what the standards say. For the reality, there was an article on boutell.com (link goes to Internet Archive backup) that discussed what individual browser and server implementations will support. The executive summary is:
Extremely long URLs are usually a mistake. URLs over 2,000 characters will not work in the most popular web browsers. Don't use them if you intend your site to work for the majority of Internet users.
(Note: this is a quote from an article written in 2006, but in 2015 IE's declining usage means that longer URLs do work for the majority. However, IE still has the limitation...)
Internet Explorer's limitations...
IE8's maximum URL length is 2083 chars, and it seems IE9 has a similar limit.
I've tested IE10 and the address bar will only accept 2083 chars. You can click a URL which is longer than this, but the address bar will still only show 2083 characters of this link.
There's a nice writeup on the IE Internals blog which goes into some of the background to this.
There are mixed reports IE11 supports longer URLs - see comments below. Given some people report issues, the general advice still stands.
Search engines like URLs < 2048 chars...
Be aware that the sitemaps protocol, which allows a site to inform search engines about available pages, has a limit of 2048 characters in a URL. If you intend to use sitemaps, a limit has been decided for you! (see Calin-Andrei Burloiu's answer below)
There's also some research from 2010 into the maximum URL length that search engines will crawl and index. They found the limit was 2047 chars, which appears allied to the sitemap protocol spec. However, they also found the Google SERP tool wouldn't cope with URLs longer than 1855 chars.
CDNs have limits
CDNs also impose limits on URI length, and will return a 414 Too long request
when these limits are reached, for example:
- Fastly 8Kb
- CloudFront 8Kb
- CloudFlare 32Kb
(credit to timrs2998 for providing that info in the comments)
Additional browser roundup
I tested the following against an Apache 2.4 server configured with a very large LimitRequestLine and LimitRequestFieldSize.
Browser Address bar document.location
or anchor tag
------------------------------------------
Chrome 32779 >64k
Android 8192 >64k
Firefox >64k >64k
Safari >64k >64k
IE11 2047 5120
Edge 16 2047 10240
See also this answer from Matas Vaitkevicius below.
Is this information up to date?
This is a popular question, and as the original research is ~14 years old I'll try to keep it up to date: As of Sep 2020, the advice still stands. Even though IE11 may possibly accept longer URLs, the ubiquity of older IE installations plus the search engine limitations mean staying under 2000 chars is the best general policy.
Related Topic
- The maximum size of a web browser’s cookie’s key
- The maximum possible length of a query string
- Javascript – the best way to detect a mobile device
- Ios – How to develop or migrate apps for iPhone 5 screen resolution
- Asp – HttpHandlers with ASP.NET MVC
- Javascript – the difference between Hot Reloading and Live Reloading in React Native
- Ios – Detect if the device is iPhone X
Best Answer
Recent Webkit and Opera:
For iPhone Safari, Opera Mobile, and Webkit on Android development are similar (but not identical), and development for those is quite simple.
You can rely on CSS2.1 and JavaScript+DOM (but be careful with UI events). You might get away with serving your regular website with just few changes to stylesheets.
The trick is in serving of these stylesheets. Don't use
User-Agent
string.Because some mobile browsers read handheld media, and some insist on screen styles and pretend to have 960px-wide screen (iPhone :/), you'll need to serve mobile stylesheet with both:
The latter is CSS3 Media Query – very useful and works with other mobile browsers too (you can use it in stylesheets with
@media {}
).Don't rely on
:hover
oronmouseover
because these events don't work on touch screens.
Viewportonclick
is delayed,mousemove
may not work. Custom DHTML widgets (dropdowns, sliders) and drag'n'drop won't work on touchscreens, unless you use touch events (which thankfully all newest browsers adopted).In addition to Apple's proprietary (and IMHO inflexible and violating separation between markup and layout)
<meta name=viewport>
have a look at CSS3 @viewport, which currently is supported in latest Opera as@-o-viewport
and hopefully others will follow.Simulators/Emulators
To test page in Opera Mobile, get the simulator (or just older desktop version and choose View → Small Screen).
Opera Mini is special, as CSS is re-formatted a bit and DHTML is executed on server-side, which doesn't always give results you'd expect. There's simulator available.
Android
You need Android SDK, fiddle with commandline to launch its clunky UI, download bunch of packages, create virtual device with dozen of irrelevant obscure settings, have patience for this monster to load and turn computer's fans into a quadcopter, and then you can sss..sss..slooowlyyyy test in the "Browser" (my Intel i5 is too slow to simulate Galaxy Tab - browser "stops responding" even before I finish typing URL)
It's easier to get a phone/tablet with Android and test on a real device (but avoid Samsung's Player "iPod" equivalent, as it's rubbish with obsolete software).
Android browser is really painful for anyone who doesn't love Linux way of doing things — just to read JS console you need to fiddle with remote debug connections and log filtering on commandline.
Firefox Mobile (previously Fennec)
There's simulator available (links for "Windows / Mac OS X / Linux" below mobile downloads are not the desktop version, but mobile-for-desktop-OS).
Simulator is very basic, Mobile Firefox itself is IMHO really good, e.g.
overflow:scroll
works great, while on WebKit-based browsers overflow implementation varies between very unintuitive and totally broken.Pocket IE:
PIE for Windows Mobile < 7 is not the same engine as IE on Windows. It's mostly as primitive and buggy as IE4 was, but (barely) supports some surprisingly advanced properties like
display:table
.It reads both
handheld
andscreen
stylesheets at the same time, violating the standard and shooting itself in the foot. If you're going to suppot PIE, then put link tohandheld
stylesheet last and reverse/override all the rules from screen styles in it.Anyway, it's dead and it's hard to get an emulator.
Windows Phone 7 currently ships with IE7-alike, and Microsoft promised something of IE9 level later.
New (minority) BlackBerry
The latest WebKit-based BlackBerry browser is quite good, you can treat it as 1st-class citizen (see WebKits comparison linked at the top).
Currently most popular BlackBerry & OpenWave, Blazer, etc.:
Before the BB OS6, it's a nightmare. Only basic HTML works. CSS works on some models, but is primitive and broken. JavaScript works only on some models and it's incredibly slow and lacking (forget about even basic DHTML).
There's free BB simulator available from RIM (annoying registration required). If you're unlucky, it'll launch properly once and then you'll have to completely reinstall it :)
The same thing is with hundreds of other mobile browsers on low-end phones (powered by likes of OpenWave, which has decent simulator) . You'll have to prepare 1-column basic HTML stripped down website for them.
Google Wireless Transcoder
Even if you create nifty (X)HTML optimized for every mobile device out there, users of Google Mobile Search will never see it! Instead, every page will be proxied through "Wireless Transcoder" which brutally chops the code, stripping all stylesheets and scripts (regardless whether browser supports them or not), and even
<font>
:(