Opera Mini Web Browser _TOP_
First, there are browsers that run the same engine as desktop browsers, such as Opera Mobile and Safari on the iPhone. Since the same engine is used, websites are supported as well as they are on desktop browsers. Most devices do not have enough CPU power or memory to run these browsers and so they tend to only be found on high-end phones.
Opera Mini web browser
Second, there are browsers designed specifically for mobile: these generally have limited support for Web standards. Some of these only support WAP browsing (such as the OpenWave browser), some support other standards like cHTML or XHTML MP (such as the Japanese NTT DoCoMo iMode browsers), and some support a limited subset of general Web standards (such as Netfront, Pocket IE, and Blazer).
Third, there are browsers that use a proxy system to deliver content to the phone. In this setup, there is a client on the device that connects to a proprietary server, which then connects to the wider web for page requests, does some server-side processing and sends content back the client. Opera Mini falls into this category: when the user navigates to a new page, the server fetches the page and transforms it into a lightweight compressed binary markup language called OBML. This decreases bandwidth usage by up to 90% and saves CPU usage on mobile devices, and as such makes browsing on resource-restricted devices much more viable. It also has speed benefits, since the majority of data transfer occurs between the Mini servers and website servers, both of which are on high-speed connections.
Opera strongly recommends building one site for all devices. We believe in one Web that works across platforms and devices, and this is why we work hard to create browsers that support Web standards as well as possible and use the same rendering engine for all of our products. Developing one site has the advantage of reducing development, QA, and maintenance time, and with the growth of standards-supporting browsers, it is an achievable goal.
If you do create a separate site, be aware that serving different content based on the browser is not foolproof. Make sure you include links from the mobile version of the site to the full version, so that if you misidentify the browser or if the user is using a mobile browser that can handle the full site, the user is not blocked from your content.
Desktop rendering renders pages in much the same way as a desktop browser, with the exception that it will try to force columns of text to not exceed the width of the screen, to reduce the need for horizontal scrolling.
Because of this compression, and for accessibility reasons, we strongly recommend that you do not use images to display text. If you must do so (e.g. because you are using image replacement for a header font), then include the image using CSS and optimise the image's size and clarity for Mini's low quality mode. You can also use different stylesheets for screen and handheld browsers and include the image only on the former, though this only works in Mobile view. Regardless, always make sure the original text is available for screen readers to access, whether with alt text or replaced content.
Mini supports basic Web page metadata such as document title and favicons, both of which are shown at the top of the browser. It is recommended to use the element with a rel value of shortcut icon to locate the relevant icon for each page, like so:
The load and unload events are triggered the same as they are in desktop browsers. All elements with mousedown, mouseup or click event listeners, as well as hyperlinks, will be turned into selectable areas on the Mini client. When clicked by the user, those elements will receive the mouseover, mousedown, mouseup and click events, in that order, as you would expect on a desktop browser. Note that Mini does not send the mouseout event and that mouseover is only triggered if a click happens.
As a result of scripts being kept paused on the server while there is no user interaction, "Ajax" techniques may not work as expected. Code registered with setTimeout() and setInterval() may be run before the page is sent, but it is unlikely that it will be called more than once because of script pausing. XMLHttpRequest is supported just as it is on desktop browsers, but triggering such requests from timeouts and intervals will not cause dynamic page updates, since that code will not be run in the background.
Setting operamini.page.maxAge will change the maximum amount of time a page is kept in Mini's cache on the client side, measured in minutes. Setting it to 0 will mean that a page is never cached. Values above 65535 will be cut down to 65535 (around 45 days).
Setting operamini.page.samePage to true will tell the server that the page should not be zoomed out when the page is loaded, but should remain zoomed in at the location it was on the previous page. It is intended to be used in situations where you navigate to a new page but want to keep the same focus area.
Opera Mini has the ability to send SMS messages on devices that support them. You can use this functionality by setting the number and body properties of the operamini.sms object to the number you want to send an SMS to, and the contents of the SMS, respectively. Devices will prompt the user before sending an SMS and some may allow editing of the message and/or number before sending. Example usage of this functionality:
Phone manufacturers and mobile carriers often customise browser user-agent strings, sometimes on a site-specific basis, so testing the user agent string is discouraged. Instead, you should detect individual features present on the device you are sending to. This approach is more flexible and future-proof, and means that if the Opera Mini servers are upgraded (which may lead to an adjusted UA string), then you can continue to support Opera Mini with no extra effort on your part.
Opera Mini, along with most other browsers, sends the Accept-Language HTTP header with its page requests. Accept-Language specifies what language(s) the browser would prefer the HTTP response to be in using standard ISO-639 language tags in a comma-delimited list. Each language is given a "quality" value that indicates the user's ability in that language. The quality can range from 0 to 1, with 1 being most preferable and 0 least.
In practice, the contents of this header will be determined by the current language of the device making the request (this is the case on both desktop and mobile browsers). If you have content in multiple languages, you should also provide an in-page way to switch between them because Accept-Language strings are not always accurate. Other circumstances may also arise, for example you may have a native German speaker using someone else's phone, the language of which is set to Afrikaans, or another language.
In this example, we have a basic two-column layout with a navigation column and a content column, and images have a 10px margin. When the browser's viewport is less than or equal to 480px, we stop it being two-column and instead collapse it so that the content and navigation sections follow each other in a single column. We also center images rather than allowing text to flow around them. Then, at viewport widths less than or equal to 240px, we stop displaying all images marked with a class of "decorative". 041b061a72