public | 19 Nov 18:33 2014

CONFIRM s790325077

It has been requested that the following address:

       goww-public-webapps <at>

be added to the public-webapps mailing list.

The address has NOT yet been subscribed to the mailing list.
To subscribe you need to confirm the subscription
request by sending an email to the address:


with the Subject string:

         CONFIRM s790325077

(A reply to this message should be sufficient)

Please do not modify the subject line when replying. If the confirm string
has been removed or changed the confirmation will fail!

When your confirmation message has been received, the address listed above
will be (un)subscribed.  If the address above is incorrect, please do not
send the confirmation message listed above. Instead, send a new
(un)subscribe request containing the Subject: 

   subscribe correct-address <at> correct-domain 


(Continue reading)

Anne van Kesteren | 3 Nov 17:42 2014

New approach to activities/intents

A couple of us at Mozilla have been trying to figure out how to revive
activities/intents for the web. Both work relatively well in closed
environments such as Firefox OS and Android, but seem harder to deploy
in a generic way on the web.

What we've been looking at instead is solving a smaller use case. A
Sharing API to start and then hopefully reuse the building blocks for
other features that need to be liberated. has a sketch for what a very
minimal Sharing API could look like.

Our thinking is that something like the overlay browsing context could
be reused to make e.g. <input type=file> or "save as" extensible going

However, admittedly it still doesn't really click. It feels a bit too
much like e.g. the various search extensions browsers offer. Too much
work for little return. Furthermore, freeing the web somehow from
closely knitted silos seems like a worthwhile goal, but is often
counter to what those silos are interested in. So it might be that
we're still not quite there yet, thoughts appreciated.

(I put WebApps and TAG on bcc, hope that's okay.)



Sam Ruby | 1 Nov 01:01 2014

[url] Feedback from TPAC

bcc: WebApps, IETF, TAG in the hopes that replies go to a single place.

- - -

I took the opportunity this week to meet with a number of parties 
interested in the topic of URLs including not only a number of Working 
Groups, AC and AB members, but also members of the TAG and members of 
the IETF.

Some of the feedback related to the proposal I am working on[1].  Some 
of the feedback related to mechanics (example: employing Travis to do 
build checks, something that makes more sense on the master copy of a 
given specification than on a hopefully temporary branch.  These are not 
the topics of this email.

The remaining items are more general, and are the subject of this note. 
  As is often the case, they are intertwined.  I'll simply jump into the 
middle and work outwards from there.


The nature of the world is that there will continue to be people who 
define more schemes.  A current example is (search for "New URI scheme for naming 
stored modules, classes, and resources").  And people who are doing so 
will have a tendency to look to the IETF.

Meanwhile, The IETF is actively working on a update:
(Continue reading)

Mike West | 16 Oct 15:34 2014

[Credential Management]: Tiny prototype to play around with.

BCCing public-webapps <at> , as this proposal started there[1]. It looks like it might be reasonable to charter the spec work as part of the WebAppSec WG[2], however, so I'm moving the conversation here for the time being.

Way back in August, I proposed a credential management API. After some generally positive conversation with folks at Mozilla and other vendors, I started poking at a prototype in Chrome to help us evaluate whether the API made any sense. As of some time earlier this week, there's enough in Canary to start looking at.

If you visit in Canary with the '--enable-credential-manager-api' flag set, you can save credentials via `navigator.credentials.notifySignedIn()` and retrieve them via `navigator.credentials.request()`. It only supports "local" credentials, and doesn't do any of the UI song and dance that's still very much TBD, but it's a nice proof of concept.

Note: Don't do this on any profile with data you care about. The current implementation just blindly returns the first credential that matches the origin on which the API is called, without user mediation. That's probably not something you want to expose to the web in its current state. :)

I'd invite you to take a look at the strawman proposal (, and help me decide whether the API makes any sense. If nothing else, it'll give us something to talk about at TPAC.

Mike West <>
Google+:, Twitter: <at> mikewest, Cell: +49 162 10 255 91

Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Christine Elizabeth Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)
Brian Kardell | 9 Oct 19:53 2014

[Push] one or many

I'm really confused by what seems to me like contradictory prose... In
the interface definition it says

Note that just a single push registration is allowed per webapp.

But in multiple places it seems to suggest otherwise, for example, in
the section on uniqueness it says:

webapps that create multiple push registrations are responsible for
mapping the individual registrations to specific app functions as

Can someone clarify why those seem contradictory?  Can a webapp have 1
registration, or many?


Paul Knight | 19 Jun 22:09 2014

30-day Public Review for Advanced Message Queuing Protocol (AMQP) WebSocket Binding (WSB) Version 1.0 - ends July 19th

OASIS members and other interested stakeholders, 

The OASIS Advanced Message Queuing Protocol (AMQP) Bindings and Mappings (AMQP-BINDMAP) TC [1] members have recently approved a Committee Specification Draft (CSD) and submitted it for 30-day public review:

Advanced Message Queuing Protocol (AMQP) WebSocket Binding (WSB) Version 1.0 
Committee Specification Draft 01 / Public Review Draft 01 
10 June 2014 


The AMQP WebSocket Binding specification defines a mechanism for tunneling an AMQP connection over a WebSocket transport. It is applicable as an approach for general firewall tunneling and for Web browser messaging scenarios.

TC Description:

The purpose of the AMQP Bindings and Mappings (AMQP-BINDMAP) TC is to define bindings of AMQP 1.0 core protocol to underlying transports other than TCP, to define mappings of the AMQP 1.0 core protocol to existing well-known programming APIs, and to define representations of the AMQP 1.0 message format in existing well-known languages.

For more information, see the TC Charter and FAQ.

Public Review Period:

The public review starts 20 June 2014 at 00:00 GMT and ends 19 July 2014 at 23:59 GMT.

This is an open invitation to comment. OASIS solicits feedback from potential users, developers and others, whether OASIS members or not, for the sake of improving the interoperability and quality of its technical work.


The prose specification document and related files are available here: 

Editable source (Authoritative): 



ZIP distribution file (complete):

For your convenience, OASIS provides a complete package of the prose document and related files in a ZIP distribution file. You can download the ZIP file here:

Additional information about the specification and the OASIS Advanced Message Queuing Protocol (AMQP) Bindings and Mappings (AMQP-BINDMAP) TC can be found at the TC's public home page:

Comments may be submitted to the TC by any person through the use of the OASIS TC Comment Facility which can be used by following the instructions on the TC's "Send A Comment" page, or directly at:

Comments submitted by TC non-members for this work and for other work of this TC are publicly archived and can be viewed at:

All comments submitted to OASIS are subject to the OASIS Feedback License, which ensures that the feedback you provide carries the same obligations at least as the obligations of the TC members. In connection with this public review of "Advanced Message Queuing Protocol (AMQP) WebSocket Binding (WSB) Version 1.0", we call your attention to the OASIS IPR Policy [2] applicable especially [3] to the work of this Technical Committee. All members of the TC should be familiar with this document, which may create obligations regarding the disclosure and availability of a member's patent, copyright, trademark and license rights that read on an approved OASIS specification. 

OASIS invites any persons who know of any such claims to disclose these if they may be essential to the implementation of the above specification, so that notice of them may be posted to the notice page for this TC's work.

========== Additional references:

[1] OASIS Advanced Message Queuing Protocol (AMQP) Bindings and Mappings (AMQP-BINDMAP) TC

RF on RAND Mode

Paul Knight  - Tel: +1 781-861-1013
OASIS - Advancing open standards for the information society
Document Process Analyst

Arthur Barstow | 29 May 00:23 2014

CfC: publish Candidate Recommendation of DOM Parsing and Serialization; deadline June 4

[ Bcc public-webapps; please Reply-to: www-dom]

Two bugs were raised against the May 1 LCWD of DOM Parsing and 
Serialization [LC]. Travis created a tracking document for these Bugs 
[Track] and considers the two patches ([P1] and [P2]) that address the 
comments as non-substantive. As such, he proposes this spec be published 
as a Candidate Recommendation (using the following ED as the basis), and 
this is a Call for Consensus (CfC) to do so:


This CfC satisfies: a) the group's requirement to "record the group's 
decision to request advancement" to CR; and b) "General Requirements for 
Advancement on the Recommendation Track" as defined in [Proc2005].

Travis estimates it will be several months before the [TestSuite] is 
complete and there are at least two implementations that pass each test 
case. Given this, I propose the following CR "exit criteria":

This specification will not advance to Proposed Recommendation before 
the spec's <a href="">test suite</a> is completed and two or more 
independent implementations pass each test, although no single 
implementation must pass each test. We expect to meet this criteria no 
sooner than  <at> PubDate+4Months. The group will also create an <a 
href="">Implementation Report</a>.

If anyone has feedback regarding features that should be marked "at 
risk", please speak up during this CfC.

Positive response to this CfC is preferred and encouraged and silence 
will be considered as agreeing with the proposal. The deadline for 
comments is June 4 and all comments should be sent to public-webapps  <at>

-Thanks, ArtB

[LC] <>
[Track] <>
[P1] <>
[P2] <>
[TestSuite] <>

Arthur Barstow | 28 May 16:42 2014

PSA: publishing FPWD of D3E Keyboard {key,code} Values specs and WD of UI Events

[ Bcc: public-webapps; please Reply-to: www-dom ]

As previously discussed, Gary and Travis have moved the D3E event key 
and codes from the D3E and UI Events specs to the following new specs:

* DOM Level 3 KeyboardEvent key Values 

* DOM Level 3 KeyboardEvent code Values 

They are working towards publishing FPWDs of these specs next week as 
well as a new WD of the (now much smaller) UI Events spec:


If anyone has any comments or concerns about this plan, please speak up 
by June 2 at the latest.

-Thanks, AB

Simon Pieters | 12 May 11:24 2014

Re: Custom Elements: 'data-' attributes

On Mon, 12 May 2014 11:00:20 +0200, Anne van Kesteren

> On Fri, May 9, 2014 at 12:56 PM, Ryosuke Niwa <rniwa@...> wrote:
>> On the other hand, if the same element had exposed contentEditable  
>> property, then UA's native contentEditable property would simply be  
>> overridden since it would appear higher up in the prototype chain.   
>> It's true that this custom element's contentEditable would have  
>> completely different semantics from that on other elements but that  
>> wouldn't break websites that use this custom element as long as authors  
>> are only accessing contentEditable property on instances of the custom  
>> element for semantics C.
> I forgot the exact details, but we had some amount of trouble when we
> introduced min and max attributes due to sites using expandos with the
> same names.
> I think we need something better than encouraging certain conventions
> if we want this to work.

Bare names in event handler content attributes are troublesome.

For instance, sites doing:

<button onclick="action()">

made us have to rename <button action> to <button formaction> (the new  
.action reflecting action="" was closer in the scope chain than the  
intended function).

Global attributes have the same issue.

So when we research if it's safe to add a new global attribute, it's not  
enough to measure how often such an attribute is used in the wild. We need  
to research bare names in event handlers also.


Simon Pieters
Opera Software

Wilson Page | 6 May 20:19 2014

Custom Elements: 'data-' attributes

I'm unsure whether or not it is safe to use custom attributes without the 'data-', I've heard mixed opinions. How do we know that chosen attributes won't someday be global attributes?
Arthur Barstow | 1 May 17:30 2014

RfC: LCWD of DOM Parsing and Serialization; deadline May 22

[ Bcc: public-webapps and public-html-admin; please Reply-to: www-dom ]

WebApps requests comments on the May 1 Last Call Working Draft of "DOM 
Parsing and Serialization (DOMParser, XMLSerializer, innerHTML, and 
similar APIs)":


If you have any comments, please send them to [www-dom] by May 22 at the 
latest. WebApps also welcomes data about "silent reviews", f.ex. "I 
reviewed section N.N and have no comments".

HTMLWG - WebApps especially welcomes feedback from you.

-Thanks, AB

[www-dom] <>