W3C home > Mailing lists > Public > whatwg@whatwg.org > November 2012

Re: [whatwg] Declarative web worker creation and communication?

From: Andrew Wilson <atwilson@google.com>
Date: Mon, 5 Nov 2012 10:41:00 +0100
Message-ID: <CAArhhisuBCm13NzEfWxMyDwuBjVTJaNoozMeCTntTtoRJ4CsEw@mail.gmail.com>
To: Fred Andrews <fredandw@live.com>
Cc: "whatwg@whatwg.org" <whatwg@whatwg.org>, Simon Pieters <simonp@opera.com>
On Mon, Nov 5, 2012 at 10:24 AM, Fred Andrews <fredandw@live.com> wrote:

> Hi Simon,
>
> The use I have in mind is a work-in-progress, see:
> http://www.w3.org/community/pua/wiki/Draft#Examples
>
> However the HTML standard already permits a UA to disable JS, and there is
> the iframe sandbox, or CSP, or browser extensions, to disable JS.  I would
> like to make any extensions as widely applicable as possible in the hope of
> building support for them, and think there is a good case for a web
> application with document JS disabled that can still communicate with web
> workers to implement AJAX style designs.
>

I guess I'm not convinced that a web worker (which has an architecture
designed for asynchronous background processing) is the right vehicle for
your "shared context" idea. My concern is that you're looking at the
limited APIs currently available to web workers, and concluding that this
makes them similar to shared contexts, when in reality the primary driver
behind the limited worker APIs is thread safety, not UA privacy.


>
> The aim is not to work around JS being disabled, but to allow web pages to
> be designed with document JS disabled that still support a lot of features
> that are currently handled by the document JS.
>
> After giving it some more thought it would seem best to add new attributes
> for communication with web workers so that the existing attributes could
> implement a backup using a HTTP request - this might help support backwards
> compatibility or allow content to degrade gracefully if web workers are not
> supported.  For example, if a form is declared to be submitted to a web
> work via a message post then it could also have a backup 'method' and
> 'action' to make a HTTP request to a server.
>
> The best path for supporting DOM updates from received web worker messages
> is not so clear to me.  Perhaps an iframe, or a more general element
> extension that allows an innerHTML update to be received from web worker
> messages and perhaps from server sent events.
>
> cheers
> Fred
>
> > To: whatwg@whatwg.org; fredandw@live.com
> ...
> > On Sat, 03 Nov 2012 03:29:10 +0200, Fred Andrews <fredandw@live.com>
> wrote:
> ...
> > > 1. Declarative web worker creation.
> > >
> > > Feedback and suggestions for appropriate markup to declare web workers
> > > would be appreciated.
> > >
> > > The use case is a document with JS disabled or restricted so that it
> can  not
> > > create web workers, yet still wants to create web workers to process
> page
> > > input and to update the document.
> >
> > Can you give some concrete examples where JS is disabled or restricted?
> >
> > --
> > Simon Pieters
> > Opera Software
>
>
Received on Monday, 5 November 2012 09:41:29 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 30 January 2013 18:48:11 GMT