- 15 September 2011: change from Opera CDK to Opera TV Emulator
- 20 December 2011: clarify
- 11 April 2012: clarify lack of support for
- 25 September 2012: include note about
outline:nonesupport in Opera Device SDK 3.4
- 22 January 2013: clarification on lack of support for
This guide is aimed at web developers wishing to optimize their web sites and applications for better compatibility with web-enabled/connected televisions — with a particular emphasis on the Opera for Devices SDK and its functionality.
For discussions on creating web content for TV, visit our Opera TV Content Development Discussions forum.
The Opera SDK and Opera TV Emulator
The Opera for Devices Software Development Kit (SDK) is aimed at device manufacturers wishing to provide a customized browser and widget manager for use on their devices. It is compatible with pretty much any device that could conveniently require web access, with existing implementations ranging from web-enabled TV sets and set-top boxes to tablet PCs and connected picture frames.
The SDK provides building blocks, modules and example implementations. Manufacturers who choose the Opera SDK then do further integration work to hook the browser (and other components not covered in this guide, such as the widget manager) into their specific devices. As such, the SDK itself is not publicly available for download.
However, developers wanting to more easily test and debug their sites for delivery on web-enabled devices can use the Opera TV Emulator. Built on the same core technology as the SDK, the emulator comes as a VirtualBox image which runs on Windows, Linux and Mac OS X. It allows for a more accurate test environment that matches the capabilities of the SDK. In addition, the Opera TV Emulator allows for remote debugging with Opera Dragonfly — a feature that is normally turned off on retail TVs and devices.
Download the Opera TV Emulator.
It’s worth noting that, even though the emulator can facilitate testing and debugging, developers should — if possible — still test their content on actual devices, as certain features and specific constraints (such as the speed of the device’s processor and available memory) can vary from device to device.
Standards support on web-enabled TVs
When building web sites and applications accessed through a web-enabled TVs regular web browser, developers can take full advantage of the web standards supported by the browser on the device. For Opera’s suite of products (desktop, mobile and devices), the specific features that are supported depend on the Presto engine version running at the heart of each browser. At the time of writing, the Opera SDK deliveries are based on Presto 2.6 — the same engine found in the current desktop and mobile releases. This allows developers to take advantage of some of the latest standards:
<video>, expanded forms support (although certain features, such as the new datetime types, are implemented, but not currently optimised for keyboard/spatial navigation access)
- CSS3: backgrounds and borders, Web Fonts, Media Queries, transitions and 2D transforms
Developers can find which Presto version is present in a particular Opera browser by checking the user agent identification string in the internal
opera:about information page. In the case of the Opera SDK, the string is currently:
Designing for context and form factor
Although actual usage may vary, there are some general considerations with regards to context when talking about web content on TV.
Consumption of content (including web content) on TV, because of its traditional setting in the living room, is often a shared/social experience.
Primary activity often revolves around quick information look-up (for instance, cast and crew details for a particular movie, weather reports, TV listings) and quick access to services. Web content for TV should therefore be optimised — in terms of overall presentation, navigation and functionality — and task-focused, giving quick and clear access to all relevant features and information.
TVs usually run at the following resolutions:
- Standard-definition television (SDTV): 720×480 (NTSC) and 720×576 (PAL), splits the display into two separate interlaced fields (243 and 288 lines, respectively).
- Enhanced-definition television (EDTV): 720×480 (NTSC) and 720×576 (PAL), delivered as single progressive scan images.
- High-definition television (HDTV): 1280×720 (also referred to as “HD Ready” or 720p, using progressive scan) and 1920×1080 (“Full HD”, in either 1080i interlaced or 1080p progressive scan variants).
Most modern web-enabled TVs support 1280×720 as a minimum resolution. On TVs capable of displaying the full HD resolution of 1920×1080, 720p content is usually upscaled (although this depends on the individual device). Set-top boxes and similar web-enabled devices may be connected to standard-definition or enhanced-definition TV sets — in these situations they will usually downscale and letterbox their virtual resolution to fit the physical resolution of the TV screen.
Regardless of what type of TV set they’re connected to, some web-enabled devices may run at a variety of virtual resolutions — as an example, the Nintendo Wii Internet Channel (which uses a custom version of the Opera desktop browser) has a virtual width of 800 pixels, with the height varying based on the type of TV (4:3 or 16:9 aspect ratio) and user settings.
Developers targeting only web-enabled TV devices should opt to design for 1280×720 as a minimum, or provide separate versions of their content optimised for 1280×720 and 1920×1080.
If content should also be displayed on standard-definition and advanced-definition TVs, developers could potentially create an additional version optimised for this resolution as well.
However, a more sustainable and maintainable solution would be to ensure that content — and specifically the screen layout — is built with enough flexibility to adapt to a variety of screen resolutions.
There are a few technologies that can be employed for these types of adaptive layouts:
Using percentage-based values to define the width and height of layout containers. This can further be combined with
min-height in pixel values, to provide some upper and lower limits to the fluidity of the containers.
CSS2.1 Media Types
CSS2.1 allows for the definition of styling blocks that only apply to specific classes of device. This technique is most commonly used to provide separate styling for screen and print, negating the need for creating separate printer-friendly pages. CSS2.1 also allows the definition of styles specifically for TVs.
Whether or not a web-enabled device identifies itself as a TV depends on how its browser has been set up and integrated by the manufacturer, so developers should only use this method if they’re sure their target platform has this setting enabled. For reasons of compatibility with the majority of web content “in the wild” which assumes a
media="screen" device, practically all current-generation devices ignore
CSS2.1 Media Types can be specified when linking to separate external stylesheets:
or within a single stylesheet, by defining separate
CSS3 Media Queries
While CSS2.1 Media Types classify devices into very broad categories (
tv, etc.), and rely on devices actually identifying themselves as such, CSS3 extends this concept by allowing developers to define specific conditions under which styles should be applied, providing far more granular control over how a layout is to be rendered under different conditions. For example, it is possible to create layouts that change depending on various factors, including the device’s screen width, screen height, resolution and color depth.
CSS3 Media Queries, just like CSS2.1 Media Types, can be defined as part of the
@mediasections in the stylesheet:
Traditionally, TV sets were not able to display the full width and height of their nominal resolution, resulting in content positioned in the edges of the screen to be cut off or not displayed at all. Although this problem has been mitigated or – on some high end devices – resolved on modern digital TV sets, developers are still advised to only place important content and controls in the “safe area”, leaving a margin of approximately 5% along each edge of the viewport.
Ideally, developers should aim to present all content contained within their TV-optimised sites and applications on the screen, without the need for the user to scroll. If this is not possible, content should at least fit the width of the screen, requiring the user to just scroll vertically.
Using iframes or containers styled with
overflow: auto; will work as expected in the Opera SDK, and users will be able to scroll these — as well as the entire page, if needed — using the default spatial navigation method of their web-enabled device. However, it may be more user-friendly to create customised controls and interface elements (such as content carousels) instead of relying on the browser’s default scrollbar mechanism.
Use of text
Although TVs run at resolutions that are comparable to desktop and notebook devices, users are traditionally positioned further away from the screen (typically a few meters). It’s important to keep this in mind when deciding on the size of text and graphical elements.
To increase the readability of text on a TV screen, developers should:
- Choose an appropriately large font size. The exact dimensions will vary depending on the specific typeface used, the physical size of the screen and the virtual resolution the device runs under, but a general minimum size of around 22px is advised
- Keep overall line length to around 10 words or less
- Use generous leading/line-spacing
The number of fonts available on devices is usually limited — much more so than on desktop computers. Typically, only widely available Linux fonts such as Bitstream Vera (serif, sans-serif and monospaced) are present. End users are not able to install any fonts beyond those that came pre-installed with their device. However, the Opera SDK browser offers support for CSS3 web fonts (including fonts served through third-party services like Typekit or the Google Font API).
For graphical elements, it is best to make the design bold and “chunky”, particularly for interface elements such as buttons. Overly fine detail such as single pixel borders should be avoided, as these can be particularly problematic on devices running on interlaced resolutions (such as SDTV and 1080i). This does not mean that subtlety and texture should be avoided altogether, but distinguishing features need to be clearly visible even when viewed at a distance.
When combining graphical elements with adaptive layout techniques, it may be useful to employ Scalable Vector Graphics (SVG), which can be resized and transformed without distortion or pixelation. However, complex SVG elements (involving a large number of vectors and layered, semi-transparent sections) do require more processing power to calculate and render, so their usefulness needs to be balanced against their performance impact.
Certain colour combinations can be problematic when displayed on a TV screen. Even on high-end devices pure white, orange and red, as well as extreme contrasts, can lead to distortion and interference of the image and should be avoided.
In addition, the dynamic range of TV screens may not be the same as traditional computer monitors. Subtle gradients and low contrast colours may result in colour bands or indistinguishable combinations.
User interfaces and controls
TVs are “low interaction” devices. When designing interfaces, developers should ensure that they are clear and uncluttered, and that controls are pared down to the minimum necessary.
User interaction with a web-enabled TV is usually performed via a remote control. In addition to the regular number/channel keys, these remote controls feature directional/cursor buttons, OK/confirmation buttons, and a variety of special feature keys.
Devices will also provide users with a way to enter regular text — for instance, to fill in username/password fields in a login dialog or to enter keywords in a search field — by means of an on-screen keyboard or multi-tap interface. This is similar to traditional mobile phones, where a series of characters is mapped to a single key — ABC on the 1 key, DEF on the 2 key, and so on. However, these text entry methods are often slow and cumbersome for users. Applications should avoid or minimise the need for this kind of text entry, opting instead for alternatives such as selectable drop-downs, menus, checkboxes or custom-built scrollable interfaces.
Some devices may offer the option of providing an on-screen pointer, which is moved with the cursor keys or motion sensors in the remote control, as is the case on the Nintendo Wii. On-screen controls should generally be large, with ample padding, to provide a large hit area that facilitates user activation without the need for too much accuracy in moving the pointer.
As is the case on desktop, the Opera browser uses spatial navigation. While on the desktop this mode requires the use of SHIFT+cursor keys, on TV spatial navigation is mapped directly to the directional keys on the remote.
The most common interaction method is functionally equivalent to keyboard access on desktop/notebook devices. Therefore, designers should ensure that their content is keyboard accessible.
In addition, Opera’s spatial navigation mode features built-in heuristics that allow the focus to also be placed on any element that has a
onmouseover attribute, or hooked into the element via the
addEventListener method. In addition, spatial navigation also allows elements with a
tabindex attribute (with a value of 0 or above) to receive focus.
Note that for these non-traditional elements, spatial navigation mimics mouse behaviour, meaning that only
mouseout events are automatically fired when moving to/from these elements.
blur events are still only fired on elements that can receive traditional keyboard focus.
Although spatial navigation works “out-of-the-box” in most situations, developers can take further control over the order in which elements receive focus using the CSS3 Basic User Interface specification for directional focus navigation. See our separate article on Tweaking spatial navigation for TV browsing for more details.
By default, Opera will place an outline around the element that currently has focus. If the design of the specific content does require it, though, this standard outline can be partially suppressed.
The appearance of this outline can vary between devices, as manufacturers can re-skin the default styles applied to the focus indicators and the various elements of a web page. Developers should therefore test their sites on a variety of devices, or ensure that their styles explicitly set all necessary values rather than relying on defaults.
In Opera Device SDK versions prior to 3.4, suppressing the outline with
outline:none is ignored, as this particular rule has traditionally been (ab)used on a variety of common
reset.css stylesheets, without authors providing any alternative indications of focus.
Starting with the Opera Device SDK 3.4, it’s possible to suppress the outline using a simple:
However, for backwards compatibility with older Opera Device SDK versions, developers should still use the slightly longer syntax to suppress Opera’s default outline indicator:
Developers will still need to ensure that there is a sufficiently clear alternative way of indicating to the user where their current focus on screen is, such as setting a contrasting background colour on control elements instead. For example:
Developers using specific styles for
:hover should — as with generic keyboard accessibility considerations — also consider doubling-up these style rules for the more generic
:focus state (note that this still requires the elements to be focusable in the first place).
Instead of just using something like
the style selector should be modified to also cover
:focus, like so:
As is common across all browsers at the time of writing, keyboard navigation (including Opera’s spatial navigation, as used in the Opera Devices SDK) does not trigger any
:active styles that may be defined. For this reason, additional style rules such as
will not have any effect. If your application relies on giving the user feedback when a particular element (such as a link or button) has been activated, this will need to be “faked” with something like
.active class on the
Processors and hardware acceleration
Typical web-enabled TV sets have modest hardware specifications compared to desktop computers. The main processor power of a TV comes somewhere between high-end smart phones and low end laptops.
The main processor is also used for software-based blitting of the rendered page to the screen itself.
TVs often come with specialised chipsets that can provide hardware acceleration for “expensive” operations such as decoding of video streams. Whether or not the browser running on a TV set takes advantage of these chipsets will depend on the specific device, as it’s a step usually taken by the manufacturers during the integration stage of the SDK. On recent TV sets, the most commonly accelerated feature is the blitting stage, through standardised DirectFB and OpenGL libraries.
It is possible to accelerate most processor intensive features of the Opera SDK — including Vega and Carakan itself — but in general developers should not rely on any particular feature being hardware-accelerated, and instead be mindful of the processing power on web-enabled TVs being comparatively modest.
Layering and opacity
The act of displaying images on a webpage (blitting images onto the viewport) is generally hardware-accelerated on most devices. However, complex layouts — for example with overlapping, semi-transparent graphics and layered blocks with reduced opacity that blend together — require large amounts of additional processing power to calculate the actual value of each pixel that needs to be displayed on screen. These can adversely impact overall performance of pages — particularly scrolling and animations — and should be used sparingly.
Generally however, such effects should be kept to a minimum, as any form of animation can be expensive in terms of performance, potentially rendering sites and applications slow and unresponsive.
Caching and content optimisation
Most web-enabled TVs don’t have a hard drive or solid state drive to cache web content (although some DVRs will, these are generally used to record videos, and are not generally available for use by the browser). In these circumstances the browser will run in diskless mode, using only the available RAM to cache any downloaded web content.
The amount of memory available for caching can vary from device to device, but is generally in the region of 5-10MB.
Starting with Presto 2.5, Opera comes with built-in support for the HTML5
<video> elements, allowing developers to include multimedia content in their web sites without plugins. However, the specifics of which codecs are supported on devices can vary considerably, as this depends on the underlying platform and integration work carried out by device manufacturers. Current devices are often optimised for hardware-accelerated playback of MP4/H.264 content in the
<video> element. Other codecs (such as MPEG2 for video or MP3 for audio) may be available, but this cannot be guaranteed on all web-enabled TVs.
Certain TVs allow for the use of Adobe Flash or Adobe Flash Lite content — for instance the latter is available to the Opera browser on the Nintendo Wii. Others may come with integrated support for displaying audio/video files delivered through an
<object> element. Once again though, this cannot be relied on as it’s an integration feature. Consumers cannot install plugin technologies and codecs themselves, and such plugins are updated regularly, meaning potential compatibility issues with future content that relies on new features.
This guide only gives a generic overview of content on TV. If you are developing for environments like the Opera TV Store, please consult the specific articles relating to those products, as there will be further restrictions and requirements with regards to visual design, layout and multimedia codec availability.