[whatwg] content models clarity
The content models [1] section is pretty clear, however, whenever one wants to know which elements fall into a specific content model, one has to look at the categories definition of each element. A (possibly non normative) overview would be helpful. I understand it is repeating information, hence possibly leading to conflicts when not paying attention while editing, but I think it would clarify a lot. Consider a similar overview to the one found in [2] listing the applicable attributes to various input types. [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/dom.html#content-models [2] http://www.whatwg.org/specs/web-apps/current-work/multipage/forms.html#the-input-element Regards, Rikkert Koppes
[whatwg] section element example
The example presented at the section element definition [1]. The given markup could be ok, however, with a look at the actual contents (a nice essay about apples), the h1 elements found in the section elements should actually be h2 elements, giving rise to the folowing document structure: Apples - Red Delicious - Granny Smith [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#the-section-element Cheers, Rikkert Koppes
Re: [whatwg] content models clarity
On 6 Mar 2009, at 11:53, Rikkert Koppes wrote: The content models [1] section is pretty clear, however, whenever one wants to know which elements fall into a specific content model, one has to look at the categories definition of each element. A (possibly non normative) overview would be helpful. I understand it is repeating information, hence possibly leading to conflicts when not paying attention while editing, but I think it would clarify a lot. Consider a similar overview to the one found in [2] listing the applicable attributes to various input types. [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/dom.html#content-models [2] http://www.whatwg.org/specs/web-apps/current-work/multipage/forms.html#the-input-element It is intended that such a thing be part of the as-of-yet unwritten index. -- Geoffrey Sneddon http://gsnedders.com/
[whatwg] Persistent SharedWorkers
My team at Google is experimenting with supporting persistent SharedWorkers
(SharedWorkers whose lifetime is not linked to being entangled with an
active browser window). I've reviewed some of the mailing list archives, so
I'm aware of at least some of the past discussions on this topic - I wanted
to give everyone a braindump of some of the ideas/issues we're kicking
around and get some feedback from the community at large before going
forward.
- Motivation:
There are a number of use cases where a web application would like to
provide long-running services for the user that do not go away when the user
closes his browser window. A canonical example of this is calendar
notifications - a calendar application might like to have a persistent
worker that monitors the user's calendar events, and displays notifications
to the user when he has a meeting. Likewise, a user might want his mail
application to display an unobtrusive notification when new mail arrives at
the server. These are all use cases that native applications have supported
for years, but which web-based applications currently have no way to
achieve.
- Persistent worker lifetime:
A persistent worker would never be shutdown by the closing orphan workers
mechanism, although it could still be killed by the User Agent (infinite
loop protection, explicit user management, revocation of permissions) or by
the worker explicitly invoking WorkerGlobalScope.close(). Once a persistent
worker is created, it would be started up on every subsequent invocation of
the user agent until it has been killed. The intent is that user agents that
have registered persistent workers would launch on startup (i.e. launch when
the user logs in to his OS account) to allow persistent workers to always
run as long as the user is logged into the machine, although this is not
required behavior.
- Permissions:
Installing a persistent worker is essentially giving a web application a
near-permanent footprint on your PC - we need explicit permission from the
user, and we need some mechanism in the user agent to revoke this
permission. There are a number of examples of similar permission-granting
user flows (ActiveX installation, plugin install, gears) which we could use
as a model for our grant/revoke permission UI.
The idea is that when an application instantiates a persistent worker for
the first time, the user would be prompted to grant permission (the worker
thread would not be started until the user granted permission) - in the case
that the user does not grant permission, the parent page would have its
worker.onerror() handler invoked. Revoking permission would happen on a
per-domain basis and would kill all persistent workers for that domain via
the existing kill worker mechanism described in the WebWorkers spec.
We're not certain whether we need to expose APIs to allow a client to test
whether permission has been granted or not (for example, a web application
may want to interact with a persistent worker if it exists, but there isn't
currently any way to tell if a worker exists or not without instantiating a
worker, which might prompt the user for permissions). Gears had an explicit
permissions variable applications could check, which seems valuable - do we
do anything similar elsewhere in HTML5 that we could use as a model here?
- Changes to worker APIs:
The existing SharedWorker APIs should be sufficient for interacting with the
worker - SharedWorkers can already precede/outlive individual browser window
instances, so from the standpoint of a given Window they should operate
similarly.
An application can create a persistent worker via the PersistentWorker()
constructor:
var worker = new PersistentWorker('worker.js', 'core');
The namespace for PersistentWorkers are identical to those of SharedWorkers
- for example, if you already have a PersistentWorker named 'core' under a
domain and a window tries to create a SharedWorker named 'core', a security
exception will be thrown, just as if a different URL had been specified for
two identically-named SharedWorkers.
From an entangled Window's standpoint, the persistent workers appear
identical to SharedWorkers - they implement the SharedWorker interface and
so expose identical APIs.
- Worker UI:
From the worker standpoint, the main difference between a PersistentWorker
and other types of workers is that the normal way of interacting with the
user (via an open browser window) is not available, since there may be no
windows open to the parent domain. We have yet to enumerate through all of
the use cases, but our initial brainstorming came up with a few possible
types of desired interactions:
1) Display an icon in the OS status bar. This would be an unobtrusive way
for a given domain to display things like you have new mail or even errors
like unable to contact server. If supplied with an onclick handler, this
could also be the footprint for further types of user interaction:
2) Open a browser window to a specific URL. I
Re: [whatwg] section element example
Rikkert Koppes wrote: The example presented at the section element definition [1]. The given markup could be ok, however, with a look at the actual contents (a nice essay about apples), the h1 elements found in the section elements should actually be h2 elements, giving rise to the folowing document structure: Apples - Red Delicious - Granny Smith No, the example is correct. It's actually illustrating how you can use h1 elements in combination with the section elements to achieve the same structure. See the section on headings and sections and creating an outline for more info. http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#headings-and-sections -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] Persistent SharedWorkers
Drew Wilson wrote: - Permissions: Installing a persistent worker is essentially giving a web application a near-permanent footprint on your PC - we need explicit permission from the user, and we need some mechanism in the user agent to revoke this permission. There are a number of examples of similar permission-granting user flows (ActiveX installation, plugin install, gears) which we could use as a model for our grant/revoke permission UI. I think it'd be great if these things could behave in almost all respects like an extension or plugin that's been installed by other means. For Firefox it'd show up in the Add-ons dialog, for example. As a user, I don't really want to care which mechanism a site is using to install its extension, so having them all listed together regardless of whether they're NSAPI plugins, Gecko extensions or persistant workers would be nice. In some ways, it seems like effectively what you're trying to achieve is a standardized approach to Gecko extensions or Browser Helper Objects or whatever, hopefully also associated with some kind of permissions model that constrain what the extension is allowed to do in the browser to a greater extent than allowed by traditional extensions.
Re: [whatwg] Persistent SharedWorkers
Agreed, there is definitely some overlap between extensions and persistent workers. I've been trying to sort out exactly how similar they are (Note: I'm mostly familiar with Firefox extensions/plugins, and mostly as an end-user - some of my assumptions may be incorrect): * Install - they both have some sort of permissions/installation model where the user is prompted to grant permission to do whatever the module wants to do. This may just be a problem of perception, but I've always viewed plugins/extensions as having a much higher cognitive burden than persistent workers - if a website wants to install a plugin or extension, that plugin/extension can potentially do lots of stuff: view/modify page content, break cross-domain boundaries, render content, etc. A PersistentWorker can't do anything that the web page itself can't already do - it just continues to do it after the last window for that domain has been closed - so saddling persistent workers with the full permissions model of extensions/plugins seems too heavyweight, and a drag on user adoption. * Updates - extensions are installed by the user, and on some platforms are never updated except by explicit user action. Extensions have the ability to say I'm only compatible with version X of the browser but don't really have a way to say I'm only compatible with the 2/23/2009 build of Website X. This seems to run counter to the paradigm that web applications have full control over their own source code. That said, undoubtedly there are ways for web applications to work around these restrictions (for example, by prompting the user to update their extension if it's determined to be out-of-date). * Compatibility - as you note, there doesn't seem to be much cross-platform consensus on extension APIs. So, I suppose one view is that I'm defining a tiny subset of extension behavior, codifying it in a cross-platform manner, and calling it PersistentWorkers. But you could say the same thing for Workers in general :) I think part of my reluctance to tie this too closely to extensions/plugins is that I quail at the thought of trying to define cross-browser extension behavior. But I do agree that sharing some of the install/management UI probably makes sense. -atw On Fri, Mar 6, 2009 at 2:11 PM, Martin Atkins m...@degeneration.co.ukwrote: Drew Wilson wrote: - Permissions: Installing a persistent worker is essentially giving a web application a near-permanent footprint on your PC - we need explicit permission from the user, and we need some mechanism in the user agent to revoke this permission. There are a number of examples of similar permission-granting user flows (ActiveX installation, plugin install, gears) which we could use as a model for our grant/revoke permission UI. I think it'd be great if these things could behave in almost all respects like an extension or plugin that's been installed by other means. For Firefox it'd show up in the Add-ons dialog, for example. As a user, I don't really want to care which mechanism a site is using to install its extension, so having them all listed together regardless of whether they're NSAPI plugins, Gecko extensions or persistant workers would be nice. In some ways, it seems like effectively what you're trying to achieve is a standardized approach to Gecko extensions or Browser Helper Objects or whatever, hopefully also associated with some kind of permissions model that constrain what the extension is allowed to do in the browser to a greater extent than allowed by traditional extensions.
[whatwg] URL encoding for XHR and Workers.
Hi, I have a couple of questions about Web Workers and text encoding of URLs. Usually, 'server' and 'path' portions of URLs are always sent in UTRF-8, the 'query' portion may be sent encoded if it contains non-ascii characters. I'm looking at what should be an encoding used for this. Lets say we have the Page that creates a Worker which uses includeScripts to load the NestedScript. Lets say the Page has some text encoding (from http header, meta tag or otherwise). For example, in latest FF nightly (Minefield) the following behaviors can be observed: - XmlHttpRequest created on the Page would send its URL to server encoded using UTF8, irrespective to the encoding of the Page. However, a XmlHttpRequest created in the Worker would send the URL encoded using Page's encoding. It seems that either XHR on the Page should also use Page's encoding, or XHR in the Worker should use UTF-8. Bug? - When a script of the Worker is decoded, the encoding of the Page is used, unless Worker's script comes with http header overriding the ecncoding. That sounds right. However, if the Worker in turn creates a nested Worker, uses an XHR or importScripts(url), the URL encoding defaults back to the Page's, even if there was overriding http header. It might be ok but seems a bit illogical - the nested worker or imported scripts are 'sub resources', their relative url is resolved against the Worker's base url, so it feels that their default encoding should be inherited from Worker. Is it a bug? Thanks, Dmitry
[whatwg] Script loading and execution order for importScripts
So I've been looking at importScripts (http://www.whatwg.org/specs/web-workers/current-work/#importing-scripts-and-libraries
) and found that the behaviour of Mozilla differs from the behaviour
defined in the spec. The spec behaviour is
(pseudo code, skipping url validation, etc)
function importScripts(sources) {
for (source in sources) {
script = loadScript(source);
if (load failed)
throw NETWORK_ERR
execute(script);
}
}
This means that any scripts specified before the failing resource load
will have executed, whereas Mozilla's behaviour appears to be:
function importScripts(sources) {
scripts = [];
for (source in sources) {
script = loadScript(source);
if (load failed)
throw NETWORK_ERR
scripts.push(script);
}
for (script in scripts)
execute(script)
}
Which means that none of the scripts will execute if any script fails
to load.
In all honesty i'm not sure which is the better approach as the spec
approach requires developers to manually handle the potential for
partial library execution, but the Mozilla approach removes the
ability to load and execute scripts in parallel, which may cause
latency problems.
Does anyone else have any thoughts as to whether the spec should be
changed to match Mozilla behaviour, or whether the Mozilla behaviour
should be considered incorrect?
--Oliver
Re: [whatwg] Script loading and execution order for importScripts
On Fri, Mar 6, 2009 at 8:40 PM, Oliver Hunt oli...@apple.com wrote: So I've been looking at importScripts (http://www.whatwg.org/specs/web-workers/current-work/#importing-scripts-and-libraries ) I dislike the synchronous design of that feature. An asynchronous solution brought up very recently in a thread about loading external scripts. Garrett
