W3C home > Mailing lists > Public > public-html-comments@w3.org > July 2008

RE: Revised : User rich-content preferences object

Date: Fri, 04 Jul 2008 10:19:37 +0200
To: ric <ric@hardacre.org>, "public-html-comments@w3.org" <public-html-comments@w3.org>
Message-id: <93AA9E47B82F684A868C217766F48905039FC129E6@EXCLU2K7.hi.inet>
Dear Ric,

I like your proposal, however, you are suggesting a very concrete set of user preferences. I think a more flexible and universal technology for user preferences should be devised.

That implies having an approach based on a vocabulary of aspects (user preferences can be an aspect) and properties very similar to what we have adopted in the DDR Simple API [1] (soon to be published as PR). In fact the DDR Simple API could be used to retrieve user preferences once a vocabulary for that kind of information has been set up.

The same could be done even with DCCI [2].

Best Regards

[1] http://www.w3.org/TR/DDR-Simple-API/

[2] http://www.w3.org/TR/DPF/

-----Mensaje original-----
De: public-html-comments-request@w3.org [mailto:public-html-comments-request@w3.org] En nombre de ric
Enviado el: martes, 01 de julio de 2008 21:52
Para: public-html-comments@w3.org
Asunto: Revised : User rich-content preferences object

´╗┐FIRST REVISION of original proposal archived at

Author: Ric Hardacre


The advent of faster processors and broadband speeds combined with more
widespread browser support for DOM and XMLHTTPRequest has caused an
upsurge in the number of rich-media sites and pages on the WWW. Many of
these host content within plugin containers and as such are
"disconnected" from the traditional Document object present in the
HTML/DOM specs.

It is becoming apparent that such sites are expanding to fill their
environments, making maximum use of available bandwith and processor
cycles and in the process making assumptions about the
capabilities of their target users' systems. This is expecially true
of mobile/roaming web users, who may be using low powered
hardware over a limited connection but still need certain javascript
features (such as XMLHttpRequest) to operate an online application.
In these instances an "all or nothing" approach to rich-content
is clearly unacceptable.

Outline of Proposal

That a static class be placed belonging to the Document node within the
DOM which hosts values set by the user to control their browsing
experience. Scripts and embedded objects should refer to the object
prior to carrying out any relevant "rich" actions. Whilst these
settings are unenforcable by the browser (especially with regards to
embedded objects) should such a system be folded into the HTML/DOM
specification these sites, pages and plugins could therefore be flagged
as being incompliant with the specification. In effect naming and
shaming them into compliance.

Browser vendors may be left to decide how to present these options to
the user, be it per domain, site, or "zone" (internet vs intranet, for
example) or to have quick toggles on the toolbars. However, the DOM
implimentation should appear the same to any hosted javascript for all
browsers wishing to advertise compliance with this proposal.

Implimentation Example

This example assumes such an object exists within the document node and
is called UserPreferences.

function Plugin_OnLoad()
   //does the browser support the implimentation?
   if( document.UserPreferences )
      if( document.UserPreferences.AutoPlayVideo )

In the above example the video only plays automatically if the
UserPreferences object exists AND has the AutoPlayVideo boolean set to

Implimentation Suggestions

The following are a suggested list of parameters that may be exposed to
web pages in a read-only manner, it is hoped they are grouped and kept
to a minimum - one boolean covers scrolling, moving and resizing effects
for example, rather than have an individual setting for each.

int MaxStreamRate (NEW IN THIS REVISION)
 - The maximum streaming rate (bytes/sec) allowed by hosted content, specifically
Audio and Video, however this may apply to other stream-loading content
such as Flash. If a user is sharing a network, or connecting via a
mobile device their available bandwidth may be limited, this could then
be used to force media into "low-res" mode. If a site's content
requires a streaming rate above this value it should still allow the
user to choose to play the content, behaving much the same as
AutoPlayVideo / AutoPlayAudio.

 - The maximum size (bytes) of an inline image or non-streaming object
allowed to be downloaded automatically. Mobile users may wish to set this
to zero to maximise use of a pay-per-byte connection plan, for example.
Users should be presented with an icon allowing them to load such images
or objects on a case by case basis, provided the inline dimensions of the
object allows it.

bool AutoPlayAudio
 - Wether or not the user wishes audio content to play automatically, if
this is set to false then the option to play the audio should still be
available but a play button should be shown and only activated by a
direct user click on that button. Never via a secondary scripting action
(including document onload).

bool AutoPlayVideo
 - Wether or not the user wishes video content to play automatically, if
this is set to false the option to play the video should still be
available but a play button should be shown and only activated by a
direct user click on that button. Never via a secondary scripting action
(including document onload).

int DefaultAudioVolume
 - User's preferred audio volume (0-9) for all embedded content, if this is set to 0 then audio and video content should play (depending on the
above two preferences) but muted. Users should be presented with the
ability to override this on a per-content per-page-load basis - unmuting
one video stream should not automatically unmute all future video
streams hosted on the same site, for example. A user is allowed to set
this to zero but still have AutoPlayAudio set to true! Note: This is
deliberately not tied to the OS-wide volume settings, a user may have
this set to 0 to allow them to listen to a podcast uninterupted whilst
browsing, for example.

bool AllowTransparency
  - User's prefrence regarding transparent/translucent overlays. The
setting here should also influence fade/transition effects that use
transparency as well as drop-shadow effects, for example.

bool AllowTransitions
 - User's preference regarding dynamic scrolling,moving and resizing
content. If this is false then dynamic content is still allowed but must
"jump" to it's final open,close,position or scrolled state with no

Future Possibilities
It is envisioned that a number of the above settings be folded into
a future HTTP revision, providing the server-side application with
direct knowledge of the user's preferences regarding interactive
content, this would allow much cleaner control for developers who
would be able to serve fallback content without relying on
client javascript degredation, overrides or redirects.

As a number of these settings are bandwidth related it is hoped that
one day a similar OS-hosted object exist with settings tied to the
current (if any) internet connection, these could then "bubble up"
into the browser for embedded objects to reference. Ultimately such
an OS-hosted option would have it's settings auto-filled dependent
on the user's current connection status, e.g. having AutoPlayVideo
auto-set to false when the user uses a mobile dial-up account but
true when using their home wifi broadband connection. This OS-hosted
object should also have a "IsConnected" boolean to prevent any
application from attempting to determine internet availability by
checking for DNS timeouts! However this final paragraph has turned
into a ramble and does not directly apply to the above proposal.

Ric Hardacre

Received on Friday, 4 July 2008 08:20:19 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:26:25 UTC