Abstract

The Network Information API provides an interface for Web Applications to access the underlying
network information (connection info) of the device.

Status of This Document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.

The functionality described in this specification was initially specified as part of the
System Information API but has been
extracted in order to be more readily available, more straightforward to implement, and
in order to produce a specification that could be implemented on its own merits without
interference with other, often unrelated, features.

Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

1. Conformance

As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.

The key words must, must not, required, should, should not, recommended, may, and optional in this specification are to be interpreted as described in [RFC2119].

This specification defines conformance criteria that apply to a single product: the user agent that
implements the interfaces that it contains.

Implementations that use ECMAScript to expose the APIs defined in this specification must implement them in a manner
consistent with the ECMAScript Bindings defined in the Web IDL specification [WEBIDL].

3.2.1 Attributes

Exposes the current connection type. The value returned is one of the following strings,
case-sensitively: unknown, ethernet, wifi, 2g,
3g, 4g, none. Implementers may expose other values,
in which case it is recommended that they are prefixed with a vendor-specific identifier, e.g.
acme-superluminal. Other identifiers may be added in the future.

The existing implementation, Android, uses integer constants for this (which is a shame since
other parts of the Android platform use the more reasonable strings instead). Should we just go with
it?

Note that this may cause the same event (online or offline) to be triggered
multiple times in succession rather than toggling between either value.

There is discussion about whether this justifies a new event or not. People may have some initialisation
code that runs on online which they don't expect to have to run when one switches from
Wi-Fi to ethernet. By its very nature, such code should be able to run multiple times with no harm, but
it may still be wasteful to do so.