This wiki has been archived and is now read-only.

Handbook of Web Standards for Broadcasting Services

From Web and Broadcasting Business Group
Jump to: navigation, search


This is the live copy of a quarterly published document, through funding from the Webinos project, reflecting the current status of the Web technologies that are the most relevant on mobile devices (latest release). Contributions to this document are very welcome.

Editorial Note on Broadcasting Version

  • The aim of broadcasting version of this mobile document is to contribute to the stakeholders who intend to use web standards for expanding their broadcasting services.
    • This document focuses on a TV terminal equipped with a HTML5 browser, which is designed to provide multimedia services by synchronizing resources transmitted via both broadcasting and the Web.
    • In particular, the document is intended to help deepen the understanding of both web engineers and broadcasting engineers toward a smarter cooperation of the Web and broadcasting service by providing broadcasters' perspectives.
  • Each chapter contains the section named Broadcasting Service Perspective in which the expansion to the original doc is implemented. This is to avoid the broadcasting version becoming a reinvention of the wheel, while at the same time maintaining the independence of the mobile version.
  • Through continuing the drafting in this form, how much should be shared between the two versions and the effect of coexistence will be determined and then reviewed whether they should be described in the separate documents, in the current coexisting form, or in a fully integrated style.


  • distinguish better in-browser / outside-the-browser?


Web technologies have become powerful enough that they are used to build full-featured applications; this has been true for many years in the desktop and laptop computer realm, but is increasingly so on mobile devices as well.

This document summarizes the various technologies developed in W3C that increase the capabilities of Web applications, and how they apply more specifically to the mobile context. A good subset of these technologies are described and explained in the W3C on-line training on programming Web applications.

  1. #Graphics
  2. #Multimedia
  3. #Device Adaptation
  4. #Forms
  5. #User interactions
  6. #Data storage
  7. #Personal Information Management
  8. #Sensors and hardware integration
  9. #Network
  10. #Communication_and_Discovery
  11. #Packaging
  12. #Performance & Optimization

The data in this report should be used with caution. Feedback on every aspect of this document should be sent to the author (dom@w3.org) and will serve as input for the next iteration of the document.

The features that these technologies add to the Web platform are organized under the following categories: #Graphics, #Multimedia, #Device_Adaptation, #Forms, #User_interactions, #Data_storage, #Personal_Information_Management, #Sensors_and_hardware_integration, #Network, #Communication_and_Discovery, #Packaging, #Performance_.26_Optimization.

In each category, a table summarizes for each feature:

  • which W3C specification defines the feature; specifications that have been identified as of particular importance in the Core Mobile Web Platform 2012 report are marked with a medal,
  • which W3C group is responsible of the said specification,
  • the stage of the specification in the W3C Recommendation track (see below),
  • the estimated stability of the document, i.e. how widely the document is expected to change, as estimated by the author of this report, with three levels: low (the document is mostly stable), medium (some parts are stable, others are expected to change significantly), high (the document is expected to evolve significantly),
  • a link to the latest editors draft of the document, and a representation of the recent editing activity;
  • some qualitative indication on availability of implementations on mobile devices, based on data collected primarily from Can I Use… and mobile HTML5, completed with data from Mozilla developer network, QuirksMode, as well as the author’s understanding of the mobile devices market (see also the code used to generate the support icons)
  • When available, a link to a relevant tutorial on WebPlatform Docs, and to relevant on-line training courses on W3DevCampus
  • a link to the test suite for the said feature, and when relevant, a github ribbon to access the underlying git repository.

As a reminder, W3C creates Web standards by progressing documents through its Recommendation track, with the following stages:

  • “Editors drafts” represent the current view of the editors of the specification but have no standing in terms of standardization.
  • “Working Drafts” (WD) are early milestones of the Working Group progress.
  • “Last Call Working Drafts” signal that the Working Group has determined that the specification fulfills its requirements and all the known issues have been resolved, and thus requests feedback from the larger community.
  • “Candidate Recommendations” (CR) trigger a call for implementations where implementers are invited to implement the specification and send feedback; Working Groups are expected to show the specification gets implemented by running test suites they have developed.
  • “Proposed Recommendations” (PR) manifests that the group has gathered sufficient implementation experience, and triggers the final review by W3C Members
  • “W3C Recommendations” (Rec) are stable and completed Web standards; these documents only get updated rarely, through the “Edited Recommendation” process, as a results from errata collected by Working Groups.

Prior to starting standardization, a Working Group needs to be chartered, based on input from W3C Members, often through the organization of a workshop, or after the reception of a W3C Member Submission.

W3C has set up Community Groups, a mechanism that allows anyone to do experimental work within the W3C infrastructure, under IPR rules that are compatible to transition the work to the W3C standardization process.

Broadcasting Service Perspective

  • The feedback of the broadcasting service perspective shall be provided to Web and Broadcasting BG not dom@w3.org.
  • For the table column, the mark column for the recommendation directly referred at Hybridcast will be added. This type of column is assumed to be added when the broadcasting specification adopting HTML5 increases in the future. Ex. HbbTV2.0.
  • One important trend in the broadcasting industry that can affect multiple chapters of this document is UHD such as 4k and/or 8k. It is possible that this trend will influence future web technologies, just like Retina displays brought the idea of responsive design to developers and is a source of developing new web standards.
  • There is the tendency of the basic user interface elements (broadcasting images, news tickers, menu buttons, etc.) not to be scrolled in the TV application design. Because of this tendency, unique care may need to be taken when the application is developed such as display of the broadcasting images and graphics.

Hybridcast Note

  • Hybridcast mentions the following three points especially as characteristics for web applications on TV that are different from applications on smartphones and tablet computers.
    • Pointing device
      • Users expect that they can control TVs with traditional remote controllers, even though there are emerging remote-less technologies such as voice control.
      • Also, the use of pointing devices for PCs, such as a mouse or trackball, that indicates the specified positions on the display needs to be considered.
    • 10 feet UI
      • In general, TV is designed to be operated remotely unlike smartphones and tablet computers. The size and number of characters displayed need to be considered to be visible and readable from a distance.
    • Application implementation according to the temporal progress of the image sound
      • The application control information that manages the activation and termination of applications needs to be implemented according to change of programs and/or the temporal progress of audio-visual signals sent through broadcasting.
      • Switching web applications while continuously presenting broadcasting video content is not considered in W3C recommendations but needs to be considered.


SVG, Scalable Vector Graphics, provides an XML-based markup language to describe two-dimensions vector graphics. Since these graphics are described as a set of geometric shapes, they can be zoomed at the user request, which makes them well-suited to create graphics on mobile devices where screen space is limited. They can also be easily animated, enabling the creation of very advanced and slick user interfaces.

The integration of SVG in HTML5 opens up new possibilities, for instance applying advanced graphic filters (through SVG filters) to multimedia content, including videos. SVG 2.0 is set to facilitate that integration and complete the set of features in SVG.

In complement to the declarative approach provided by SVG, the <canvas> element added in HTML5 enables a 2D programmatic API that is well-suited for processing graphics in a less memory intensive way. That API not only allows rendering graphics, but can also be used to do image processing and analysis — HTML 5.1 adds the ability to do that processing in a separate Web Worker.

Both SVG and HTML can be styled using CSS (Cascading Style Sheets); in particular, CSS3 (the third level of the specification) is built as a collection of specifications set to offer a large number of new features that make it simple to create graphical effects, such as rounded corners, complex background images, shadow effects (CSS Backgrounds and Borders), rotated content (CSS Transforms, including with 3D effects), animations (CSS Animations, and CSS Transitions).

Animations, which can also be managed via scripting through the API exposed in Web Animations, can be resource intensive — the possibility offered by the Timing control for script-based animations API to manage the rate of updates to animations can help keep them under control.

Fonts play also an important role in building appealing graphical interfaces, but mobile devices are in general distributed with only a limited set of fonts. WOFF (Web Open Font Format) addresses that limitation by making it easy to use fonts that are automatically downloaded through style sheets, while keeping the size of the downloaded fonts limited to what is actually needed to render the interface.

Another important aspect in graphics-intensive applications (e.g. games) is the possibility to use the entire screen to display the said graphics; the Fullscreen API lets a Web application requests and detects full screen display.

Likewise, in these scenarios, it is often useful to be able to lock the orientation of the screen; the Screen Orientation API allows not only to detect orientation change, but also to lock the orientation in a specific state.

NB: a 3D graphic API for HTML5 canvas, called WebGL, has been developed outside of W3C, as part of the Khronos Group; this API has been built to be compatible with OpenGL ES, i.e. for embedded systems, and is intended to work on mobile devices.

FeatureSpecificationWorking GroupMaturityStabilityLatest editors draftCurrent implementationsDevelopers docTest suite
2D Vector GraphicsSVG 1.1SVG Working GroupRecommendationFinishedNew version of SVG (SVG 2.0) in preparationWidely deployedSVG TutorialsHigh coverage
SVG 2Working DraftEarly draftRegularly updatedN/AN/A
2D Programmatic APIHTML Canvas 2D ContextHTML Working GroupCandidate RecommendationStableUpdated regularlyWidely deployedCanvas tutorialHTML5 on-line courseGood coverage
HTML 5.1 Canvas ProxyWorking DraftEarly draftUpdated regularlyNoneNone
Complex layoutsCSS Flexible Box Layout ModuleCSS Working GroupCandidate RecommendationMostly finishedUpdated regularlyWell deployedWell started
Rounded CornersCSS Backgrounds and BordersCandidate RecommendationMostly finishedUpdated regularlyWell deployedGood coverage
Complex background imagesWell deployedCSS Background images tutorial
Box shadow effectsWidely deployed
2D EffectsCSS TransformsWorking DraftMostly stableLatest update Jul 2013Well deployedCSS Transforms tutorialGood coverage
3D EffectsStabilizingWell deployed
AnimationsCSS Animations Module Level 3Working DraftEarly draftUpdated regularlyWell deployedCSS Animations tutorialNone
CSS Transitions Module Level 3Working DraftEarly draftLatest update Sep 2013Well deployedCSS Transitions tutorialNone
Web AnimationsCSS Working Group and SVG Working GroupWorking DraftEarly draftRegularly updatedNoneNone
Timing control for script-based animations APIWeb Performance Working GroupLast Call Working DraftStabilizingLast update Feb 2013Well deployedWell started
Downloadable fontsWOFF File Format 1.0WebFonts Working GroupRecommendationFinishedFinishedGood deploymentOverview of Web fontsGood coverage
Fullscreen displayFullscreen APIWeb Apps and CSS Working GroupsWorking DraftEarly draftLast update Oct 2012LimitedUsing the full-screen APINone
Orientation LockThe Screen Orientation APIWeb Apps Working GroupsWorking DraftEarly draftRegularly updatedVery limitedNone

Broadcasting Service Perspective

  • Some broadcasting services require that content should be shown as is the broadcaster or content provider intended regardless of the difference of devices such as sizes and resolutions of monitors.
  • It's necessary to have a function different from that used for mobile in order to realize the use case where the broadcasting stream and the frame rate are synchronized to operate the graphics.
  • In the multi-language environment, the complexity of Japanese hyphenation may become a more important issue in the viewing environment of TV, for which the characters are displayed in a large size on a big screen.
  • There may be limitations for graphics and animation based on hardware limitation and performance constraints.
    • For example:
      1. different to mobile, hardware is more of an issue than bandwidth
      2. using large images rather than css generated images may be more performant

Hybridcast Note

  • While the drawing technology and function of the terminal is becoming diversified, the resolution and the pixel of the graphics and the terminal at the time of transmission are designed to be controlled by HTML viewport meta and CSS Media Query in order to realize the presentation intended by the application developer in a diverse environment as much as possible.


HTML5 adds two tags that dramatically improve the integration of multimedia content on the Web: the <video> and <audio> tags. Respectively, these tags allow embedding video and audio content, and make it possible for Web developers to interact much more freely with that content than they would through plug-ins. They make multimedia content first-class citizens of the Web, the same way images have been for the past 20 years.

The playback content can be augmented and completed via Media Source Extensions that lets developers generate media content in JavaScript.

To cater for the needs of some content providers, a proposal to enable playback of protected content, Encrypted Media Extensions is an API that is under consideration in the HTML Working Group.

The Pick Media Intent offers a Web-intent based approach to search and retrieve locally or remotely stored media content, while the Networked Service Discovery API opens the door for integrating DLNA-hosted content into Web applications.

While the new HTML5 tags allow to play multimedia content, the HTML Media Capture defines a markup-based mechanism to access captured multimedia content using attached camera and microphones, a very common feature on mobile devices. The Web Real-Time Communications Working Group and the Device APIs Working Group are building together an API (getUserMedia) to directly manipulate streams from camera and microphones, as well as an API to record these streams into files, and another API to use access to cameras to take photos programatically.

Beyond capturing and recording, two additional APIs add multimedia manipulation capabilities to the Web platform. We have already mentioned the Canvas 2D Context API: it enables modifying images, which in turn opens up the possibility of video editing.

In a similar vein, the Audio Working Group is working on an API that that makes it possible to modify audio content, as well as analyze, modify and synthesize sounds, the Web Audio API.

The combination of all these features marks the starting point of the Web as a comprehensive platform for multimedia, both for consuming and producing. The rising interest around bridging the Web and TV worlds (manifested through the W3C Web and TV Interest Group) should strengthen that trend in the coming months. Mobile devices are expected to take a growing role in many users TV experience, providing a “second screen” experience, where users can find more information on or interact with a TV program they're watching via their mobile devices.

FeatureSpecificationWorking GroupMaturityStabilityLatest editors draftCurrent implementationsDevelopers docTest suite
Video playbackHTML5 video elementHTML Working GroupCandidate RecommendationMostly stableUpdated regularlyGood deploymentVideo BasicsHTML5 on-line courseWell started
Audio playbackHTML5 audio elementCandidate RecommendationGood deploymentAudio tag tutorialHTML5 on-line courseStarted
Protected content playbackEncrypted Media ExtensionsWorking DraftEarly draftLatest update Sep 2013Very limitedNone
Multimedia Gallery accessPick Media IntentDevice APIs Working GroupWorking DraftEarly Web-intents based approach; stalled due to lack of progress on Web IntentsLast updated Aug 2012N/A
Networked Service DiscoveryWorking DraftEarly draftLast updated Mar 2013NoneNone
Capturing audio/videoHTML Media CaptureDevice APIs Working GroupCandidate RecommendationStableLatest update May 2013Growing deploymentstarted
Media Capture and StreamsJoint work between Web Real-Time Communications Working Group and Device APIs Working GroupWorking DraftStabilizingRegularly updatedLimited but growingwell started
MediaStream Recording APIWorking DraftEarly draftUpdated regularlyNoneNone
Mediastream Image CaptureWorking DraftEarly draftLast updated July 2013NoneNone
Generation of media contentMedia Source ExtensionsHTML Working GroupLast Call Working DraftStabilizingRegularly updatedLimitedNone
Image & Video analysis, modificationHTML Canvas 2D ContextHTML Working GroupCandidate RecommendationStableUpdated regularlyWidely deployedGood coverage
Audio analysis, modificationWeb Audio APIAudio Working GroupWorking DraftStarting to stabilizeRegularly updatedLimitedAn introduction to the Web Audio APIStarted

Broadcasting Service Perspective

  • Video elements and Media elements have been developed rapidly with a focus on W3C in the last few years. Active discussion and consideration of new specifications such as MSE and EME are currently being made. Regarding use of such a developing technology to the broadcasting service and how, various decisions are possible in the area of service architecture design. For broadcasting, there may be different criteria from other platforms and industries in terms of quality of service, e.g. timing is more important than content continuity in some situations.
  • For their use to the broadcasting service, discussion at W3C needs to be watched carefully. In addition, if the needs specific to the broadcasting service are specified, they should be provided to W3C as a requirement. Such further cooperation is preferable.
  • The access API for in-band resources of the broadcasting stream has been considered by W3C. There are two types being considered. One is mapping with out-band API for the stream such as MPEG2TS as an example of video element implementation, which is considered by HTML WG. The other is organization of use cases by Media APIs TF of Web and TV IG.
  • There are various technologies available for synchronization with broadcasting. The method using the fingerprint information and watermarks of sounds and images is also available. The Web standard for using these methods from the browser is discussed by Web and TV IG and Web and Broadcasting BG.

Hybridcast Note

  • Hybridcast uses object elements to present broadcasting images.
    • If the appropriate object element is described statically, it is specified that the broadcasting image is continuously presented over multiple HTML files.
    • In addition, the API controlling the full screen is specified to the appropriate object element.
  • VOD image presentation is complied to the IPTVF-J internet scope service approach specification (the official name needs to be checked).
  • In Hybridcast, the receiving function of some broadcasting resources is equipped with security for which access is available from the URL application written in AIT included in the broadcasting stream and the application which has the same base URL only. (Check the communication-broadcasting integrated specification for the better description.)
  • Hybridcast specifies in-band resources of the broadcasting stream and API for the receiver function. The following are covered.
    • In-band stream of the broadcasting stream
      • Location information of resource
      • Network ID, Stream ID,..., DSM-CC Module ID, DSM-CC Module Name, DSM-CC Resource Name, etc.
      • AIT (Application Information Table)
      • EIT (Event Information Table)
      • NPT (Normal Play Time)
      • DSM-CC Event Message stream
    • Receiver function
      • Channel selection
  • [Comments from BG f2f attendees] Content protection function of Hybridcast should be explained here.

Device Adaptation

Mobile devices not only differ widely from traditional computers, but they also have a lot of variations among themselves, in term of screen size, resolution, type of keyboard, media recording capabilities, etc.

The Device Description Repository API is a unified server-side API that allows Web developers to retrieve data on the devices that are accessing their pages on a variety of device information database.

The Media Capture Streams API exposes some specific information on capabilities of camera and microphones to make it possible to take advantage of the large variety of media capturing devices provided on mobile phones.

CSS Media Queries offer a mechanism that allows adapting the layout and behavior of a Web page based on some of the characteristics of the device, including the screen resolution — to which Media Queries Level 4 proposes to add the availability and type of a pointing device, the ability to hover over elements, and the ambient luminosity. CSS Device Adaptation defines a set of CSS directives to define the size on which this layout should be based, relatively to the size of the underlying device — specifying what has been implemented using the <meta name="viewport"> element so far.

The proposal for a new picture element, initially developed by the Responsive Images Community Group, has been taken up by the HTML Working Group as one of the proposed extensions to HTML. It lets authors define what image to show depending on the rendering context as determined through media queries.

As a complementary approach, the srcset attribute, developed in the WHATWG and also published an extension to HTML, let Web developers define the various existing resolutions of an image, letting the browser pick the best choice for the resolution of the screen. At this time, this approach is the one that seems to be gaining the most momentum among some of the browser vendors.

A brand new proposal made to the Responsive Images Community Group, the srcN attribute, offers to combine the two proposals behind another syntactical approach.

FeatureSpecificationWorking GroupMaturityStabilityLatest editors draftCurrent implementationsDevelopers docTest suite
Device informationDevice Description Repository Simple API (server-side)Device Description Working Group (now closed)RecommendationfinishedN/ALimitedGood Coverage
Media Capture CapabilitiesMedia Capture and StreamsWebRTC and Device APIs Working GroupWorking DraftEarly draftRegularly updatedNoneNone
CSS-based adaptationMedia QueriesCSS Working GroupRecommendationFinishedFinishedWidely deployedCSS Mediaqueries presentationGood coverage
Media Queries Level 4Editors draftEarly draftRegularly updatedNoneNone
CSS Device AdaptationWorking DraftEarly draftLatest update Mar 2013Very limitedMobile ViewportN/A
Adaptive imagesThe picture elementHTML Working GroupWorking DraftFirst draftRegularly updatedNoneN/A
The srcset attributeWorking DraftFirst draftRegularly updatedNoneNone
srcN attributes for responsive imagesResponsive Images Community GroupN/AN/ARegularly updatedNoneNone

Broadcasting Service Perspective

  • DASH (Dynamic Adaptive Streaming over HTTP) is an adaptive video distribution technology which is analogous to responsive images for image distribution. There are two recommendations in W3C related to DASH: one is EME or Encrypted Media Extensions, and the other is MSE or Media Source Extensions.

Hybridcast Note

  • Hybridcast specifies the APIs for the following terminal information and functions.
    • Identifiers determining the receiver type


The ability to build rich forms with HTML is the basis for user input in most Web-based applications. Due to their limited keyboards, text input on mobile devices remains a difficult task for most users; HTML5 address parts of this problem by offering new type of form controls that optimize the way users will enter data:

  • date and time entries can take advantage of a number of dedicated form controls (e.g. <input type="date">) where the user can use a native calendar control;
  • the <input type="email">, <input type="tel"> and <input type="url"> can be used to optimize the ways user enter these often-difficult to type data, e.g. through dedicated virtual keyboards, or by accessing on-device records for these data (from the address book, bookmarks, etc.);
  • the inputmode attribute (proposed in HTML 5.1) defines the type of textual input expected in a text entry;
  • the pattern attribute allows both to guide user input as well as to avoid server-side validation (which requires a network round-trip) or JavaScript-based validation (which takes up more resources);
  • the placeholder attribute allows to guide user input by inserting hints as to what type of content is expected in a text-entry control;
  • the <datalist> element allows creating free-text input controls coming with pre-defined values the user can select from;
  • HTML 5.1 defines a mechanism for the autocomplete attribute to automatically fill input fields based on well-known data for the user.
FeatureSpecificationWorking GroupMaturityStabilityLatest editors draftCurrent implementationsDevelopers docTest suite
Date and time entriesHTML5 Date and Time state of input elementHTML Working GroupCandidate RecommendationMostly stable, but feature marked at riskUpdated regularlyGrowingHTML5 Form featuresHTML5 on-line courseJust started
Customized text entries (tel, email, url)HTML5 telephone, email and URL state of input elementCandidate RecommendationStableUpdated regularlyGrowingJust started
Input modalityHTML 5.1 inputmode attributeWorking DraftEarly draftUpdated regularlyNoneNone
Input patternHTML5 pattern attributeCandidate RecommendationStableUpdated regularlyLimited but growingJust started
Input hintHTML5 placeholder attributeCandidate RecommendationStableUpdated regularlyWell deployedStarted
Autocomplete for text entriesHTML5 datalist elementCandidate RecommendationStableUpdated regularlyLimitedNone
HTML 5.1 autocomplete attribute valuesWorking DraftEarly draftRegularly updatedNoneNone

Broadcasting Service Perspective

  • The characteristic is that the input terminal to the TV terminal is mainly a different device from a remote controller or other devices (e.g. smartphones) in the broadcasting device, sharing the constraints and diversification of the input keyboard with the mobile version. This item will be revisited in the section of User Interactions.

User interactions

An increasing share of mobile devices relies on touch-based interactions. While the traditional interactions recognized in the Web platform (keyboard, mouse input) can still be applied in this context, a more specific handling of touch-based input is a critical aspect of creating well-adapted user experiences, which Touch Events in the DOM (Document Object Model) enable. The work on that specification is now nearly finished.

Meanwhile, the Pointer Events Working Group has made good progress on an alternative approach to handle user input, Pointer Events, that allows to handle mouse, touch and pen events under a single model. This new approach is expected to replace the currently more widely deployed Touch Events.

As more and more content gets rendered as long scrollable lists, more and more logic is attached to scrolling events, and the quality of the user experience of these actions is highly dependent on their performances. The CSSOM View Module determines when scrolling events get fired, and let developers specify the type of scrolling behavior they want.

Many mobile devices use on-screen keyboards to let users type; the Input Method Editor (IME) API makes it possible to coordinate the interactions between that on-screen keyboard and Web applications.

Conversely, many mobile devices use haptic feedback (such as vibration) to create new form of interactions (e.g. in games); work on a vibration API in the Device APIs Working Group is making good progress.

But as the Web reaches new devices, and as devices gain new user interactions mechanisms, it also becomes important to allow Web developers to react to a more abstract set of user interactions: instead of having to work in terms of “click”, “key press”, or “touch event”, being able to react to an “undo” command, or a “next page” command independently of how the user instructed it to the device will prove beneficial to the development of device-independent Web applications. The IndieUI Events specification, developed by a joint task force between the Web Events Working Group and the Indie UI Working Group, aims at addressing this need.

Mobile devices follow their users everywhere, and many mobile users rely on them to remind them or notify them of events, such as messages: the Web Notifications specification proposes to add that feature to the Web environment.

Mobile devices, and mobile phones in particular, are also in many cases well-suited to be used through voice-interactions; the Speech API Community Group is exploring the opportunity of starting standardization work around a JavaScript API that would make it possible for users to interact with a Web page through spoken commands, and a W3C Working Group charter is currently under review by the Advisory Committee.

The hardware constraints of mobile devices, and their different usage context can make mobile users experience similar barriers to people with disabilities. These similarities in barriers mean that similar solutions can be used to cater for them, making a Web site accessible both for people with disabilities and mobile devices a natural goal.

How Web Content Accessibility Guidelines (WCAG) and User Agent Accessibility Guidelines (UAAG) provide guidance on mobile accessibility — that is, making websites and applications more accessible to people with disabilities when they are using mobile phones and a broad range of other devices — is discussed in Mobile Accessibility.

WAI-ARIA provides semantic information on widgets, structures and behaviors hooks to make Web applications more accessible, including on mobile devices.

FeatureSpecificationWorking GroupMaturityStabilityLatest editors draftCurrent implementationsDevelopers docTest suite
Touch-based interactionsTouch Events SpecificationWeb Events Working GroupProposed RecommendationMostly finishedUpdated regularlyLargely deployedMobile TouchMobile Web 2: Programming Web Applications on-line courseStarted
Pointer EventsPointer Events Working GroupCandidate RecommendationStableUpdated regularlyLimited deploymentPointer Events primerJust started
Smooth scrollingCSSOM View ModuleCSS Working GroupWorking DraftStill changingUpdated regularlyNoneN/A
On-screen keyboard interactionsInput Method Editor APIWeb Applications Working GroupWorking DraftStill changingLast updated Aug 2013NoneN/A
VibrationVibration APIDevice APICandidate RecommendationMostly stableUpdated regularlyLimited but growingStarted
Intent-based eventsIndieUI: Events 1.0Indie UI Working Group and Web Events Working GroupWorking DraftEarly draftLast updated Aug 2013NoneNone
NotificationWeb NotificationsWeb Notifications Working GroupLast Call Working DraftStabilizingLast update Aug 2013Growing deploymentNotification API tutorialNone
Speech-based interactionsN/ASpeech API Community GroupN/AN/ALast update Jan 2013N/AN/A
Accessibility Relationship between Mobile Web Best Practices (MWBP) and Web Content Accessibility Guidelines (WCAG) Mobile Web Best Practices Working Group & Education and Outreach Working Group Working Group Note Finished N/A N/A N/A
Accessible Rich Internet Applications (WAI-ARIA) 1.0 Protocols & Formats Working Group Candidate Recommendation Stable Latest update Aug 2013 Growing deployment Well started

Broadcasting Service Perspective

  • Web Applications WG is working on the reorganization of key values of various terminals including TV terminals and gaming systems in order to finalize the DOM3 Event.
  • Meanwhile, as for DOM, various opinions, for which specifications shall be adopted, exist such as DOM3 and DOM4 in parallel, transferring DOM4 to HTML WG, etc.

Hybridcast Note

  • In Hybridcast, the detail on handling remote controller focus assumes realization in 7. Outline properties in HTML5 7.3 Focus and CSS Basic User Interface Module Level 3 (CSS3 UI).
  • Hybridcast adopts the Document Object Model (DOM) Level 3 Events Specification for event handling and adds the insufficient part for handling of the remote control key. The related keys are defined uniquely.
    • Specifically, red, green, yellow, blue, up, down, left, right, enter, return, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, d, play/pause, forward, rewind, page up, page down, tab on the remote controller are defined.

Data storage

A critical component of many applications is the ability to save state, export content, as well as integrate data from other files and services on the system.

For simple data storage, the Web Storage specification offers two basic mechanisms, localStorage and sessionStorage, that can preserve data respectively indefinitely, or on a browser-session basis.

For richer interactions, the Web platform has a growing number of APIs to interact with a device filesystem: the File Reader API makes it possible to load the content of a file, the File Writer API allows saving or modifying a file, while the nascent FileSystems API give access to more general file operations, including directory management. Discussions have started on whether these two latter APIs would better be implemented on top of IndexedDB, and a proposal for a new sandboxed filesystem API has been brought forward.

On top of this file-based access, the Indexed Database API (IndexedDB) defines a database of values and hierarchical objects that integrates naturally with JavaScript, and can be queried and updated very efficiently. Note that the work around a client-side SQL-based database, which had been started in 2009, has been abandoned in favor of this new system.

As more and more data need to be stored by the browser (e.g. for offline usage), it becomes critical for developers to get reliable storage space, which the proposed Quota Management API will offer to Web applications.

Likewise, as some of this data need to be encrypted, the emerging Web Cryptography API from the Web Cryptography Working Group exposes strong cryptography primitives to Web applications, and can be bound to pre-provisioned keys via the WebCrypto Key Discovery API.

FeatureSpecificationWorking GroupMaturityStabilityLatest editors draftCurrent implementationsDevelopers docTest suite
Simple data storageWeb StorageWeb Applications Working GroupProposed RecommendationStableUpdated regularlyWell deployedOffline storage tutorialComplete
File readingFile APILast Call Working DraftStabilizingRegular updatesGetting well deployedMobile Web 2: Programming Web Applications on-line courseStarted
File writingFile API: WriterWorking DraftEarly draft, unsure futureLatest update Mar 2012Limited but growingNone
Filesystems operationsFile API: Directories and SystemWorking DraftEarly draft, unsure futureLatest update Mar 2012Limited but growingNone
N/AN/AN/AEarly proposalN/ANone
Database query/updateIndexed Database APICandidate RecommendationStableRegularly updatedGrowingOffline storage tutorialHTML5 on-line courseGood coverage
Web SQL APIWorking Group NoteAbandonedN/ASomewhat deployed, but won’t be further deployedN/A
Quota for StorageQuota Management APIWorking DraftEarly workLast updated Mar 2013Very limitedNone
Encrypted storageWeb Cryptography APIWeb Cryptography Working GroupWorking DraftEarly workRegularly updatedLimitedNone
WebCrypto Key Discovery Working DraftEarly workLast updated July 2013NoneNone

Broadcasting Service Perspective

  • The mobile version is supposed to have the same view on this item as that of the PC. The current status is the same with the broadcasting service.

Personal Information Management

Applications can benefit from integrating with existing data records; on mobile devices, the address book and calendar are particularly useful source of information, which the Contacts API and the Calendar API bring access to.

For integration in browser-based Web Apps, Web Intents based approaches have been suggested, but are now stalled due to the lack of progress around that technology.

For Web apps outside of the browser, a purely programmatic approach is part of the System Applications Working Group, with work on a Contacts Manager API in progress.

FeatureSpecificationWorking GroupMaturityStabilityLatest editors draftCurrent implementationsDevelopers docTest suite
Address book data Contacts Manager APISysApps Working GroupWorking DraftEarly draftLast updated Aug 2013NoneNone
Pick Contacts IntentDevice APIs Working GroupWorking DraftEarly Web-intents based approach; stalled due to lack of progress on Web IntentsLast updated Aug 2012NoneEarly draft based on previous API
Calendar dataCalendar APIWorking DraftWill likely change significantlyLast updated Oct 2012NoneNone

Broadcasting Service Perspective

  • There is some viewer information stored in the existing digital TV terminal such as viewing area information. In general, the primary user interface is a resident application of the TV terminal, not the browser. It is necessary to define an API separately from the browser.
  • How the conventional viewing habit and form of TV at each household and optimization of application for each individual as well as improvement of user experience are blended in always needs to be considered, while taking various situations into account.

Hybridcast Note

  • Hybridcast defines the API for viewer information such as the viewing area information.

Sensors and hardware integration

Mobile devices are packed with sensors, making them a great bridge between the real and virtual worlds: GPS, accelerometer, ambient light detector, microphone, camera, thermometer, etc.

To take full advantage of these sensors in mobile Web applications, Web developers need to be provided with hooks to interact with them.

The Geolocation API provides a common interface for locating the device, independently of the underlying technology (GPS, WIFI networks identification, triangulation in cellular networks, etc.). Work towards a new version of the API that would include geofencing and indoor location is under consideration.

Web applications can also now access orientation and acceleration data via the DeviceOrientation Event Specification.

The work on a generic Sensor API has been put on hold in favor to designing APIs for specific sensors, such as the Proximity Events API, the Ambient Light Events API or the proposed Ambient Humidity Events API.

As already mentioned in the section on #Multimedia, there is ongoing work on APIs to open up access to camera and microphone streams.

The opportunity for Web applications to use Near-Field Communications (NFC) mechanisms have led to the chartering of the NFC Working Group to develop a Web NFC API.

A more global access to sensors and hardware (including USB and bluetooth) is in scope for the System Applications Working Group.

FeatureSpecificationWorking GroupMaturityStabilityLatest editors draftCurrent implementationsDevelopers docTest suite
GeolocationGeolocation APIGeolocation Working GroupProposed RecommendationMostly finishedLast update Sep 2013Widely deployedIntroduction to Geolocation APIMobile Web 2: Programming Web Applications on-line courseGood coverage
Motion sensorsDeviceOrientation Event SpecificationLast Call Working DraftStabilizingLast update Jun 2012Well deployedUsing device orientationMobile Web 2: Programming Web Applications on-line courseStarted
Battery StatusBattery Status APIDevice APIs Working GroupCandidate RecommendationStableLast update Apr 2013Very limitedGood coverage
Proximity sensorsProximity EventsLast Call Working DraftStableRegularly updatedVery limitedStarted
Ambient Light sensorAmbient Light EventsLast Call Working DraftStableRegularly updatedVery limitedStarted
Humidity sensorAmbient Humidity EventsN/AUnofficial draftLast updated Aug 2012NoneN/A
Camera & Microphone streamsMedia Capture StreamsWeb Real-Time Communications Working Group and Device APIs Working GroupWorking DraftStabilizingRegularly updated Limited but growingwell started
NFCWeb NFC APINFC Working GroupEditors draftVery early draftLast update Aug 2013NoneNone

Broadcasting Service Perspective

  • Regarding the relationship between various sensors equipped with mobile terminals such as location information and the broadcasting service, the important fact is that the broadcasting service for mobile objects has become widespread in some countries which plays an important role in information provision when a wide-scale disaster occurs. It is important to share and standardize the use cases and function requirements at the time of a wide-scale disaster internationally, learning from various types of disasters from now on.


Network connectivity represents a major asset for mobile devices: the Web is an immense store of content, as well as an almost endless source of processing power, overcoming two of the limitations of mobile devices.

The Web platform is growing a number of APIs that facilitate establishing network connectivity in different contexts.

XMLHttpRequest (the “X” in AJAX) is a widely deployed API to load content from Web servers using the HTTP and HTTPs protocol: the W3C specification (formerly known as XMLHttpRequest Level 2) completes the existing deployed API with the ability to make requests on servers in a different domain, programmatic feedback on the progress of the network operations, and more efficient handling of binary content. The work on documenting the currently deployed API (XMLHttpRequest Level 1) has been abandoned in favor of getting the new API developed more quickly.

By default, browsers do not allow to make request across different domains (or more specifically, across different origins, a combination of the protocol, domain and port) from a single Web page; this rule protects the user from having a Web site abusing their credentials and stealing their data on another Web site. Sites can opt-out of that rule by making use of the Cross-Origin Resource Sharing mechanism, opening up much wider cooperation across Web applications and services.

XMLHttpRequest is useful for client-initiated network requests, but mobile devices with their limited network capabilities and the cost that network requests induce on their battery (and sometimes on their users bill) can often make better use of server-initiated requests. The Server-Sent Events API allows triggering DOM events based on push notifications (via HTTP and other protocols.)

Early work on a Push API would allow Web applications to receive server-sent messages whether or not the said Web app is active in a browser window. As patents have been disclosed on that API, a Patent Advisory Group is being formed to assess how to make further progress possible on this work item.

The WebSocket API, built on top of the IETF WebSocket protocol, offers a bidirectional, more flexible, and less resource intensive network connectivity than XMLHttpRequest.

The Web Real-Time Communications API provides direct peer-to-peer data connections between browsers with real-time characteristics, opening the way to collaborative multi-devices Web applications.

Of course, an important part of using network connectivity relies on being able to determine if such connectivity exists, and the type of network available. The HTML5 onLine DOM flag (and its associated change event, ononline) signals when network connectivity is available to the Web environment.

The network-information API addresses discovery of the network characteristics, allowing to determine for instance the rough bandwidth of the current connection. The Resource Timing API offers to measure precisely the impact of the network on the time needed to load various resources, offering another approach to adapt a Web app to its network environment.

FeatureSpecificationWorking GroupMaturityStabilityLatest editors draftCurrent implementationsDevelopers docTest suite
HTTP(s) network APIXMLHttpRequestWeb Applications Working GroupWorking DraftStill changing, but starting to stabilizeLatest update May 2013Very broad for level 1 features, growing for level 2Well started
Cross-domain requestsCross-Origin Resource SharingWeb Applications Working Group and Web Applications Security Working GroupCandidate RecommendationStableLatest update June 2012Getting well-deployedUsing CORSWell started
Server-pushed requests Server-Sent Event Web Applications Working Group Candidate Recommendation Stable Regularly updated Getting well-deployed Streaming updates with server-sent events Good coverage
Push API Working Draft Early draft; Under review by a Patent Advisory Group Last updated Aug 2013 None N/A
Bidirectional connectionsThe WebSocket APICandidate RecommendationStableRegularly updatedGood deploymentUsing WebSocketsMobile Web 2: Programming Web Applications on-line courseWell started
P2P data connectionsWebRTC 1.0: Real-time Communication Between BrowsersWeb Real-Time Communications Working GroupWorking DraftEarly draftRegularly updatedLimited but growingWebRTC IntroductionNone
on-line stateonLine DOM stateHTML Working GroupCandidate RecommendationMostly stableregularly updatedLimitedNone
Network characteristicsThe Network Information APIDevice APIs Working GroupWorking DraftEarly draft, not getting much tractionLast update Nov 2012Very limitedNone
Resource TimingWeb Performance Working GroupCandidate RecommendationStableLast updated Aug 2013Very limitedEarly start

Broadcasting Service Perspective

  • The hardware resources of TV for broadcasting services are generally restricted more severely than those for mobile. The effect of commissioning the processing to the server side using a Web-standard communication function is expected to be higher.

Communication and Discovery

Beyond connection to on-line services, allowing communications between users, but also between devices and between applications is an important aspect of a good mobile development platform. To communicate with unknown devices or pre-existing services, a discovery component is critical.

For Web apps not in a browser, the System Applications Working Group is working on a complete Messaging API.

The postMessage API of HTML5 Web Messaging allows for Web Applications to communicate between each other.

A joint task force of the Device APIs and Web Apps Working Groups had been looking at a mechanism called Web Intents: it aimed at closer integration of Web applications, as well as of Web applications with native applications. Some of the initial use cases for Web Intents have proved hard to expose through the regular Web browser UI, and discussions on how to properly scope that technology are on-going. In the mean time, progress on Web Intents and derived APIs has stalled.

The Network Service Discovery API offers to discover services on the local network (such as the ones offered via DLNA), enabling mobile Web applications to integrate seamlessly with these services. An alternative approach based on Web Intents has also been under exploration, but is unlikely to progress due to Web Intents being stalled.

The Web Real-Time Communications Working Group is the host of specifications for a wider set of communication opportunities:

  • Peer-to-peer connection across devices,
  • P2P Audio and video streams allowing for real-time communications between users.
FeatureSpecificationWorking GroupMaturityStabilityLatest editors draftCurrent implementationsDevelopers docTest suite
Emails, SMS and MMS with generated attachmentsMessaging APISystem Applications Working GroupWorking DraftFirst draftRegularly updatedNoneNone
Inter-app communicationsHTML5 Web MessagingWeb Applications Working GroupCandidate RecommendationStableRegularly updatedWell deployedGood coverage
Inter-app triggersWeb IntentsDevice APIs Working Group and Web Apps Working GroupWorking Group NoteEarly draft; currently stalledregularly updatedExperimentalNone
Network services discoveryWeb Intents Addendum - Local ServicesWorking DraftVery early draft; based on Web Intents that is currently stalledLatest updated Oct 2012NoneNone
Network Service DiscoveryDevice APIs Working GroupWorking DraftEarly draftLast updated Sep 2013NoneNone
P2P connectionsWebRTC 1.0: Real-time Communication Between BrowsersWeb Real-Time Communications Working GroupWorking DraftEarly draftRegularly updatedNoneWebRTC IntroductionNone
P2P Video/Audio streams

Broadcasting Service Perspective

  • As mentioned in the section regarding the user interface, in the broadcasting service, the input terminal to the TV is usually a separate device such as a remote controller or other devices such as a smartphone. Therefore, this item, Communication & Discovery, may become more important for the broadcasting service than those for mobile.
  • In W3C Web and TV IG Media APIs TF and Web and Broadcasting BG, use cases and function requirements for a second screen scenario and a multi screen scenario.
  • Note from breakouts in TPAC2013
    • Hybridcast allow only companion application to change channel or volume because of the security problem.
    • For the future, user Authentication will be important.
    • Simple identification is required by some use cases, like "drawing application" by hybridcast.
    • Just service discovery should be standardized?
    • The standardization of Time Synchronization is needed?

Hybridcast Note

  • Hybridcast specifies the concept and the protocol of companion applications. The protocol of the companion application allows the application developer to abstractly write the application collaborating between terminals as a high-level API as well as allows diversification in the communication method between the TV terminal and its collaborating terminal as a low-level layer. Refer to IPTVF HTML5 browser specifications for the details.


An important aspect of the user experience of applications is linked to how the user perceives the said application is available permanently (even when off-line, which is particularly important on mobile devices), as well as how it can be shared and distributed, typically through purchases via applications stores — this is adequately addressed by packaging the application.

The Web platform offers two complementary approaches to packaging Web applications:

  • HTML5’s ApplicationCache enables access to Web applications off-line through the definition of a manifest of files that the browser is expected to keep in its cache; while relatively well deployed, the current approach has shown some strong limitations and the HTML and Web Applications Working Groups are considering a potentially major overhaul of the technology, likely based on ServiceWorker
  • a JSON-based manifest format in development by the the Web Apps Working Group (as replacement for the W3C Widgets family of specifications). The System Applications Working Group is building a runtime and security model on top of that packaging, but that specification is likely to replaced by a different approach at this time.
FeatureSpecificationWorking GroupMaturityStabilityLatest editors draftCurrent implementationsDevelopers docTest suite
Offline Web appsHTML5 Application CacheHTML Working GroupCandidate RecommendationFeature at risk (Possibly major overhaul under consideration)Regularly updatedWell deployedIntroduction to using the application cacheMobile Web 2: Programming Web Applications on-line courseNone
Service WorkerWeb Applications Working GroupN/AEarly draftUpdated regularlyNoneNone
Packaged Web AppWeb ManifestWeb Applications Working GroupEditors draftN/ALast update Aug 2013N/AN/A
Runtime and Security Model for Web ApplicationsSystem Applications Working GroupWorking DraftEarly draft, will likely be replaced by a different approachLatest update Sep 2013N/AN/A

Broadcasting Service Perspective

  • Offline feature for web application is essential for broadcasting services which uses broadcasting wave to deliver web applications.
  • The broadcasting industry may be able to provide use cases of delivering web applications through broadcasting signals.

Hybridcast Note

  • Hybridcast recommends app developers using AppCache for packaging applications delivered via network. Regarding packaging for web apps delivered via broadcasting signal, Hybridcast adopted zip archives containing HTML5 and relate resources as DSM-CC module resources.

Performance & Optimization

Due to their limited CPU, and more importantly to their limited battery, mobile devices require a lot of attention in terms of performance.

The work started by the Web Performance Working Group on Navigation Timing, Resource Timing, Performance Timeline and User Timing, gives tools to Web developers for optimizing their Web applications.

Early work on a Resource Priorities specification, part of the Web Performance Working Group new charter, would let developers indicate which network requests should be prioritzed.

The proposed work on Efficient Script Yielding offers the opportunity to Web developers to use more efficiently asynchronous programming, but has some far gained very limited traction.

The API to determine whether a Web page is being displayed (Page Visibility API) can also be used to adapt the usage of resources to the need of the Web application, for instance by reducing network activity when the page is minimized. Likewise, the Timing control for script-based animations API can help reduce the usage of resources needed for playing animations.

The battery API allows adjusting the use of resources to the current level of power available in the battery of a mobile device.

Beyond optimization of resources, the perceived reactivity of an application is also a critical aspect of the mobile user experience. The thread-like mechanism made possible via Web Workers allows keeping the user interface responsive by offloading the most resource-intensive operations into a background process.

The Mobile Web Application Best Practices provide general advice on how to build Web applications that work well on mobile devices, taking into account in particular the needs for optimization.

FeatureSpecificationWorking GroupMaturityStabilityLatest editors draftCurrent implementationsDevelopers docTest suite
Network prioritizationResource PrioritiesWeb Performance Working GroupEditors draftProposalLast updated Aug 2013ExperimentalNone
Timing hooksNavigation TimingRecommendationFinishedFinishedGood coverage
Resource timingCandidate RecommendationStableLast updated Aug 2013NoneEarly start
Performance TimelineCandidate RecommendationStabilizingRegularly updatedNoneStarted
User timingCandidate RecommendationStableRegularly updatedNoneWell started
Priority handlingEfficient Script YieldingEditors draftEarly draftLast update Apr 2013Very limitedNone
Page Visibility detectionPage visibility APIRecommendationFinishedFinishedWell deployedGood coverage
Animation optimizationTiming control for script-based animationsLast Call Working DraftStabilizingLast update Feb 2013Well deployedWell started
ThreadingWeb WorkersWeb Applications Working GroupCandidate RecommendationStableRegularly updatedWell deployedIntroduction to Web WorkersMobile Web 2: Programming Web Applications on-line courseWell started
Battery StatusBattery Status EventsDevice APIs Working GroupCandidate RecommendationStableLast update Apr 2013Very limitedGood coverage
Optimization Best PracticesMobile Web Application Best PracticesMobile Web Best Practices Working Group (now closed)RecommendationFinishedN/AN/AMobile Web 1: Best Practices on-line courseN/A

Broadcasting Service Perspective

  • Services synchronised with broadcasting streams require real time processing on multimedia resources. Monitoring the realtimeness of the system is important. Also, measuring actual frame rate of animations a browser renders is critical to evaluate actual user experiences. W3C Web Performance WG discussed the importance of measuring the actual frame rate of animations for TV and game applications but API development has not yet achieved it in terms of WG priority.