W3C

HTML 5

A vocabulary and associated APIs for HTML and XHTML

← 11 Obsolete featuresTable of contentsIndex →

12 Things that you can't do with this specification because they are better handled using other technologies that are further described herein

This section is non-normative.

There are certain features that are not handled by this specification because a client side markup language is not the right level for them, or because the features exist in other languages that can be integrated into this one. This section covers some of the more common requests.

12.1 Localization

If you wish to create localized versions of an HTML application, the best solution is to preprocess the files on the server, and then use HTTP content negotiation to serve the appropriate language.

12.2 Declarative 2D vector graphics and animation

Embedding vector graphics into XHTML documents is the domain of SVG.

12.3 Declarative 3D scenes

Embedding 3D imagery into XHTML documents is the domain of X3D, or technologies based on X3D that are namespace-aware.

12.4 Timers

This section is expected to be moved to its own specification in due course. It needs a lot of work to actually make it into a semi-decent spec.

Objects that implement the Window interface must also implement the WindowTimers interface:

[NoInterfaceObject, ImplementedOn=Window] interface WindowTimers {
  // timers
  long setTimeout(in TimeoutHandler handler, in long timeout);
  long setTimeout(in TimeoutHandler handler, in long timeout, arguments...);
  long setTimeout(in DOMString code, in long timeout);
  long setTimeout(in DOMString code, in long timeout, in DOMString language);
  void clearTimeout(in long handle);
  long setInterval(in TimeoutHandler handler, in long timeout);
  long setInterval(in TimeoutHandler handler, in long timeout, arguments...);
  long setInterval(in DOMString code, in long timeout);
  long setInterval(in DOMString code, in long timeout, in DOMString language);
  void clearInterval(in long handle);
};

[Callback=FunctionOnly, NoInterfaceObject]
interface TimeoutHandler {
  void handleEvent([Variadic] in any args);
};

The setTimeout and setInterval methods allow authors to schedule timer-based events.

The setTimeout(handler, timeout[, arguments...]) method takes a reference to a TimeoutHandler object and a length of time in milliseconds. It must return a handle to the timeout created, and then asynchronously wait timeout milliseconds and then queue a task to invoke handleEvent() on the handler object. If any arguments... were provided, they must be passed to the handler as arguments to the handleEvent() function.

Alternatively, setTimeout(code, timeout[, language]) may be used. This variant takes a string instead of a TimeoutHandler object. define the actual requirements for this method, as with the previous one. That string must be parsed using the specified language (defaulting to ECMAScript if the third argument is omitted) and executed in the scope of the browsing context associated with the Window object on which the setTimeout() method was invoked.

Need to define language values; need to define that the script corresponding to the code argument is created before the timer is set up, so that the rule on pausing the ticker, below, makes sense.

The setInterval(...) variants must work in the same way as the setTimeout variants except that if timeout is a value greater than zero, the task that invokes the handler or code must be queued again every timeout milliseconds, not just the once.

The clearTimeout() and clearInterval() methods take one integer (the value returned by setTimeout() and setInterval() respectively) and must cancel the specified timeout. When called with a value that does not correspond to an active timeout or interval, the methods must return without doing anything.

For both setTimeout() and setInterval(), the clock upon which the timers are based must only tick while the Document of the global object of their callbacks is fully active.

12.5 Rendering and the DOM

This section is expected to be moved to its own specification in due course. It needs a lot of work to actually make it into a semi-decent spec.

Any object implement the AbstractView interface must also implement the MediaModeAbstractView interface.

[NoInterfaceObject, ImplementedOn=AbstractView] interface MediaModeAbstractView {
  readonly attribute DOMString mediaMode;
};

The mediaMode attribute on objects implementing the MediaModeAbstractView interface must return the string that represents the canvas' current rendering mode (screen, print, etc). This is a lowercase string, as defined by the CSS specification. [CSS21]

Some user agents may support multiple media, in which case there will exist multiple objects implementing the AbstractView interface. Only the default view implements the Window interface. The other views can be reached using the view attribute of the UIEvent interface, during event propagation. There is no way currently to enumerate all the views.