Proposal for a UserPreferences static DOM Object

Proposal for a UserPreferences static DOM Object
 
Author: Ric Hardacre
 
Background
----------
 
The advent of faster processors and broadband speeds combined with more
widespread browser support for DOM and XMLHTTPRequest has caused a large
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 hardware
capabilities of their target users' systems.
 
Whilst within a traditional operating system environ a user may be able
to disable transition effects, transparencies and multimedia events -
and have hosted applications respect those settings, there exists no
commonly accessible concept of such settings within the DOM. This
proposal attempts to address that lack of user control.
 

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. Some of these will be simple read-only booleans, such as
wether or not to allow fade/transparency effects. And whilst these
settings are unenforcable by the browser (especially with regards to
third party plugins) should such a system be folded into the HTML5/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). But the DOM implimentation should be the same for all browsers
wishing to advertise compliance with this proposal.
 
 
 
Rationale
---------
 
Access to the WWW is being made increasingly possible on a range of
devices of varying computing power over connections of varying speed. A
user may wish to use a service from a low-powered laptop, for example,
and in that situation need "instant" feedback on actions without the
desire for interpolated fold out boxes. The same user, on the other
hand, may be happy with automated video playing whilst browsing from
their main desktop system.
 
Content specifications such as HTML5 should in this author's opinion,
shy away from dictating which content is suitable for which domain of
device (handheld, laptop, desktop) as future advances in connectivity,
processor power and display technology can not be easily predicted.
Instead these content preferences should be left to the user to decide,
with perhaps instead a leaning towards certain "lightweight" defaults
suggested regarding low-power portable devices.
 
 
 

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 )
         Plugin.PlayVideo();
}
 

In the above example the video only plays (automatically) if the
userpreferences object exists AND has the AutoPlayVideo boolean set to
true.
 
 
 

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.
 

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 page load).
 

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 page load).
 

int DefaultAudioVolume
 
 - User's preferred audio volume 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! 
 

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
interpolation.
 
 
 
Other settings may be prudent for image depth and resolution for
example, and may even be folded partially into future HTTP
specifications: The ability for a device to request (if available) a low
resolution version of an image, rather than rely on HTML's outdated
"LOWRES" IMG tag parameter. These discussions can be had within the
community alongside the possibilities for this Object.
 
 
 
Further Possibilities
---------------------
 
It is also possible that this object can be expanded to overcome some
security related obstacles, specifically web application access to the
user's copy-buffer. If the object contains a string that is read-write
then the web-page may copy and paste to that. 
 
The implimentation of this could, again, be left to browser vendors but
it is assumed a simple popup be employed showing the contents of the
buffer and allowing the user to perform a manual copy/paste to and from
it. Domains should each recieve their own "copy" of the buffer to
prefent cross-site-scripting. This would mean that pages hosting script
from multiple domains must sandbox each's access to the Object, but this
may be neccesary in any case depending on the user's preferences if they
are granular enough to allow blocking video originating on one site
whilst allowing it to the rest by default, for example.
 
 
 

Ric Hardacre
 
 


This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person.

Qioptiq Ltd
Registered Office Glascoed Road, St. Asaph, Denbighshire LL17 0LL
Registered in England & Wales Company Number 876004