Marcos Caceres | 21 Feb 19:33 2014

[Manifest] Study on installable web apps

(bcc'ing SysApps and WebApps)

Over the last week, the WebMob IG did a somewhat large study of installable web apps based on iOS.  

In the hope that the findings help with standardization of the manifest, I'd like to share the findings and
some recommendations with the WGs. 

If you would like to read the whole study, including methods, limitations, and data, see [1]. You can also
file bugs there. 

Despite the issues outlined below, we must acknowledge that Apple has done exceptional work in pioneering
the concept of "installable web apps" (and continue to make this stuff better and better with each release
of iOS). This is not intended to be a criticism of iOS - just a reflection of how the technology is being used
in the wild. 

## Key findings
The number of sites claiming to run as standalone is insignificant: of all sites we had access to, they
represent 1.4% of the dataset (i.e., 1097 out of 78,155 claim to be "`apple-mobile-web-app-capable`").
So, despite this capability being available since 2009, and irrespective of iOS being the dominant
mobile platform, few developers bother to create standalone web apps.

Despite these 1097 sites claiming they can be used as standalone, what we found was that the majority of web
apps (90%, or 324 out of 360) **can not be used as standalone**. Only a tiny fraction (10%, or 36 out of 360)
are able to run as standalone - and 28% of those had significant limitations (described below). There is,
in fact, a greater percentage (12%) of desktop sites masquerading as installable web apps than there are
actual standalone applications. 

Another significant problem is that 85% (307 out of 360) of apps rely on a user's ability to follow
hyperlinks. iOS standalone apps don't support following hyperlinks: unless a developer intervenes via
(Continue reading)

John Mellor | 19 Dec 18:02 2013

Background sync & push messaging: declarative vs imperative

[cross-posted to public-webapps and public-sysapps]

A couple of us from Chrome have taken a holistic look at how we could add standardized APIs for web apps to execute/sync in the background.

This is an important capability, yet can be safely granted to low-privilege web apps, as long as battery consumption and metered data usage are (very) carefully limited.

This is not a spec proposal - instead I’m looking for feedback on the high-level choice between an imperative or declarative set of APIs.


1. Sync when next online

- Need to send emails & document edits written offline as soon as the device goes back online (even if app is not open), and get back sending status, or for documents the result of merging the user's diff with any changes made by other users.

e.g. document editing / email client / instant messaging / play-by-mail games

2. Background sync

- Need to periodically fetch new content in the background, so user will have fresh content if they open the app offline.

- Content often depends on device location (hence requires polling).

e.g. news / weather / maps / social stream

3. Large background transfers

- Need to upload/download large files. App won't remain in the foreground for long enough, so this must happen in the background; and even in the background, the app is unlikely to be allowed to stay open long enough (e.g. iOS 7 limits the execution time of Background Fetch to 30 seconds), so there needs to be a way of handing over large transfers to the browser/OS to perform efficiently without the app having to keep running.

- Ideally such transfers would auto-resume after device reboots.

e.g. file syncing / movies / video camera

4. Push notifications

- Need instant push notification of messages received by the server, or as soon as the device comes online if it was offline (even if app is not open).

e.g. email client / instant messaging / play-by-mail games

5. Push to sync (tickle)

- Sometimes a push needs to trigger a sync, for example to fetch email attachments.

e.g. file & document syncing / email client / play-by-mail games

6. Delayed local notifications

- Need to show notifications at some time in the future.

- Various possible interactions with timezone changes and daylight savings time.

e.g. egg timer / alarm clock / calendar

7. Delayed remote notifications

- Consider a calendar app: it must reliably show notifications for remotely-added events, even if the app hasn’t been opened since the event was added. Hence there must be some mechanism for a push message from the server to cause a local notification to be set at some time in the future.

e.g. calendar / cloud synced alarm clock

Solving all of these requires a variety of different APIs. But it's important that they fit together well, and it turns out that the API design choices are closely interrelated.

There are two broad approaches to providing such capabilities on the web:


One approach is to allow JavaScript to be run on demand in the background. The prime candidate for this is to extend ServiceWorkers to be a generic mechanism for receiving events in the background (without a page having to be open).

1. Sync when next online

To address use case #1, add an API that requests your ServiceWorker to get woken up once in the background, as soon as possible after the device next goes online. This could be an extension of the Task Scheduler API. This API should probably only be available when running in the foreground.


   requireOnline: true

}, myData);

2. Background sync

Similarly, to address use case #2, let web apps request their ServiceWorker to be periodically run in the background, at an interval of the UA’s choice (using aggressive heuristics to choose the most battery/data-efficient moment to run it); though we could allow the developer to specify a minimum interval (i.e. if content updates daily, you could specify that there’s no point syncing more often).


   minInterval: "2h"  // UA will pick a >= interval

}, myData);

We’d probably strictly limit the execution time of the ServiceWorker to conserve battery (by comparison, in native apps iOS 7 limits the execution time of Background Fetch to 30 seconds).

3. Large background transfers

Although we’d be limiting background execution time of the ServiceWorker, we can compensate by making it possible to initiate long-running up/downloads, managed by the browser/OS.

This could be done by letting you mark async XMLHttpRequests as "persistent", somewhat like the Beacon API, except that the browser would periodically retry requests if the device was offline, and make the results available to the page or ServiceWorker next time the web app is launched.

Alternatively we could reuse ServiceWorker’s scriptable Cache objects. You’d get syntax something like this:

caches.set("movie-cache", new Cache(




This would cause the UA to download these large files in the background. Once all the downloads in the cache are finished, they would show up in caches.get("movie-cache").

4. Push notifications & 5. Push to sync (tickle)

To address use cases #4 and #5, implement something like the Push API, allowing servers to remotely wake up a ServiceWorker. The ServiceWorker can then sync, show a notification, etc. (For battery life reasons, silent push messages probably need to be throttled, in which case we could consider adding a never-throttled variant for messages that show a user-visible notification).

PUT /push/send/device-c0fa407591 HTTP/1.1



6. Delayed local notifications

To address use case #6, extend the Notifications API so notifications can exist independently of the lifetime of a web page, and when activated will wake up the ServiceWorker or web page and fire an event on them.

There also needs to be a way to fire a notification after a precise time delay; the natural way to do this would be to also allow exact scheduling of time sensitive tasks using the Task Scheduler API, but for battery reasons we shouldn’t give web apps carte blanche here; instead to prevent abuse we might want to only allow exact scheduling if you also show a user-visible notification. So we could either silently throttle precisely scheduled tasks if it turns out they’re not showing notifications, or we could not implement exact scheduling in Task Scheduler at all, and instead extend Notifications to have an optional time delay.

new Notification("Meeting about to begin", {

   utcTime: 1386011460303,

   body: "Room 101",

   launchUrl:  ""


7. Delayed remote notifications

By combining the APIs from the previous two sections, you can have a push message handler that schedules a delayed notification, satisfying use case #7.


Alternatively, it would be possible to solve almost all these use cases without having to run JavaScript in the background, with a combination of declarative APIs. This seems to be a new idea, so it warrants more detailed explanation.

A key premise of this approach, is that it’s always ok to wake up the device/app in order to display a user-visible notification, since these provide value to the user (or if they don’t, the user can deal with it by revoking the permissions of the web app). But other than that, it’s best to limit battery/bandwidth/RAM consumption in the background.

*These are just pseudo-APIs to demonstrate possible capabilities and not actual proposals.*

1. Sync when next online & 3. Large background transfers

For use cases #1 and #3, uploads and downloads need to happen in the background, and in a declarative world these would need to be fully managed by the browser. As in the imperative approach to use case #3, we could reuse ServiceWorker’s scriptable Cache objects for background downloads, either from a ServiceWorker, or by exposing them to ordinary web pages:

caches.set("movie-cache", new Cache(




This would cause the UA to download these large files in the background. Once all the downloads in the cache are finished, they would show up in caches.get("movie-cache").

Similarly background uploads are sometimes necessary. For use case #1 (e.g. email), it is important that the background upload happen as soon as possible once the device goes back online; for use case #3 (e.g. video sharing), the background uploads need to support uploading large files, however timeliness is less important, and it might be best for the upload to only happen over WiFi. It might still be possible for the two to use the same syntax; for example we could allow adding a Request object to a Cache instead of just URLs:

caches.set("outbox", new Cache(new Request({

   method: "POST",

   url: "",

   body: my_mime_multipart_message

}), ...));

The UA would perform these requests in the background, and store the response in the cache object. As for urgency, perhaps there could be some "urgent_request_by_user" flag that the web developer can set to indicate that the user explicitly requested this and intends it to be sent over cellular data.

2. Background sync

The mechanism above is powerful, but sometimes instead of a one-shot up/download you need to sync data that regularly updates.

Push can be great for that; but sometimes you have to poll, for example weather/map apps syncing forecasts/tiles based on your current location. And sometimes (though perhaps rarely) even when you can push it’s more efficient to poll smartly - for example if my social network feed has new posts several times a minute, I really don’t want it waking up my phone radio every few minutes while I’m asleep (especially if I forgot to plug it into a charger).

We could extend the caches mechanism above with the ability for the UA to periodically check -- in the background -- for updates to the files in the cache (using standard HTTP caching logic). The UA could optionally include the user’s geolocation in a header when doing so.

caches.set("sync-cache", new Cache(url1, url2, ...));

caches.requestBackgroundSyncing("sync-cache", {

   geolocation: true


The client would indicate with cookies or somesuch any user preferences about what should be synced. The server could update the cookies to indicate how much it has synced, so during the next sync it knows what to do.

However this is still quite limiting, as it requires the client to know in advance the URLs of the files the server will want it to download. It would probably lead to hacks where clients request that a bunch of meaningless foo1, foo2, foo3 urls get synced, and the actual content of those urls gets rotated server-side. A more flexible approach would add indirection, and let the server provide a barebones "manifest" file, that would just be a newline-separated list of URLs to sync.

caches.set("sync-cache", new CacheManifest("/sync-manifest"));

caches.requestBackgroundSyncing("sync-cache", {

   geolocation: true


The UA would periodically check for updates to the manifest file, fetch any new URLs, update existing ones, and delete cache entries for any URLs removed from the manifest. Updates would presumably be atomic (sync all files in the manifest before updating the cache exposed to the page). I’ve glossed over various details, such as what constitutes an update to the manifest file, but it should be possible to define something reasonable, learning from the lessons of AppCache.

As with the imperative approach, the UA would use various heuristics to determine when is a good time to sync each app, such as batching, screen on, wifi available, charging, or even what times of day each web app is typically used.

4. Push notifications

For use case #4, there needs to be a standardized way for an app’s server to instantly push user-visible notifications to the device (with automatic retry if the device is offline). Interacting with the notification would launch the app, at the given URL.

POST /push/send/device-c0fa407591 HTTP/1.1


Content-Type: application/json


   "title": "Message from Ben",

   "body":  "This should arrive instantly :)",

   "sound": "",

   "launchUrl":   ""


5. Push to sync (tickle)

In the push notification example above, the notification didn’t contain any data other than the notification text, and the URL to launch when the notification was clicked. It would be reasonable to add a "data" member to the JSON, which would somehow be passed to the web page when the notification is clicked.

However most push messaging servers have strict size limits on the payload (e.g. 4096 bytes). There are many cases, where an app needs to send more than this, for example an email client that needs to download the attachments that accompany an email, so that if the user clicks the notification whilst offline, they will be able to view the attachments.

To handle this case, we can allow a silent push message that kicks off an immediate background sync of one or more of the named caches from "2. Background sync" above:

POST /push/send/device-c0fa407591 HTTP/1.1


Content-Type: application/json


   "updateCaches": ["sync-cache", "attachments-cache"]


6. Delayed local notifications

For use case #6, there needs to be a way to locally schedule notifications with a time delay (since the device might be offline the whole time, you can’t rely on push notifications for this). We could extend the Notifications API as follows:

new Notification("Meeting about to begin", {

   utcTime: 1386011460303,

   body: "Room 101",

   launchUrl:  ""


The notification would be delayed until the given moment. A URL is provided to launch the app in response to the user clicking on the notification, if the app isn’t already running; usually, this URL would be available offline due to AppCache or a ServiceWorker. An API like Notification.get() would let you read and cancel pending notifications.

7. Delayed remote notifications

A subtle variant of notifications is use case #7. If you add a same day event to your cloud calendar with a reminder 10 minutes before the event, then the device goes online for a while but the calendar app does not get launched by the user, and the device goes back offline for the hours leading up to the event, the calendar app needs to be able to fire that notification 10 minutes before the event, despite (in this declarative model) having been executed neither at the time the push notification arrived, nor at any time since then.

Since it doesn’t get executed, such an app can’t locally schedule a delayed notification, so instead the push notification API introduced for use case #4 could be extended so you can specify a time delay before the notification fires (as with delayed local notifications).

POST /push/send/device-c0fa407591 HTTP/1.1


Content-Type: application/json


   "utcTime": 1386011460303,

   "title":   "Meeting about to begin",

   "body":    "Room 101",

   "launchUrl":     ""


We’d need to also support push messages that cancel earlier delayed push notifications (e.g. if the event later gets removed from your cloud calendar). And the same API that lets you inspect local delayed notifications could also read/cancel pushed delayed notifications.


The imperative approach (A) seems a cleaner set of APIs, from an extensible web point of view.

However whenever a ServiceWorker (or equivalent) runs in the background, it requires a full JS interpreter, and all the associated browser machinery to support APIs like Geolocation, which together consumes a significant amount of RAM. This can be a problem on mobile; for example on Windows Phone, background agents are restricted to 11 MB of RAM on devices with less than 1GB, otherwise 20 MB, and are terminated if they exceed this limit. This is presumably in order to ensure that the foreground app (and other important processes) remain responsive (and don’t get evicted). The limits on Android and iOS are vaguer and device-dependent, but increased background RAM usage could potentially be a deal-killer for the imperative approach.

(The UA can tightly control battery and data usage in both the imperative and declarative approaches described above, which is why I’m not focusing on those here).

We’re currently thinking of prototyping the imperative approach. But it seems that the 2 main capabilities introduced incrementally in section B (declarative push message actions, and the caches mechanisms) could provide a viable plan B if the imperative approach turns out to use too much RAM.

*Please don’t bikeshed the syntaxes yet*; at this stage the main open questions are:

  1. Is this a reasonable vision for the set of imperative capabilities?

  2. Would such declarative capabilities be sufficient to address all important use cases?

  3. How easy would web developers find developing against such declarative APIs, compared to the imperative approach? The server would play a slightly greater role in driving the sync logic; but that may not be so terrible.

  4. How much RAM would such a declarative approach ultimately save? Is it worth it?


Arthur Barstow | 19 Dec 15:54 2013

[testing] Common way to "manage" test bugs?

[ Bcc: public-webapps-testsuite ]

Hi All,

I think it would be helpful if WebApps had a common way to "manage" test 
case bugs,  in particular:

1. A common way to report a test bug

2. An easy way to determine if a specific test suite has any open bugs. 
(For example, if someone goes to the websockets test suite on WPT, it 
should be easy to determine if any of the test cases have open bugs.)

Currently, tests bugs are reported in a few different ways:

* Bugzilla - WebApps has a single Testing component in Bugzilla for all 
of the specs and it has been used to report a few test case bugs [Bugs]. 
Using Bugzilla addresses #1, however, a single component makes #2 a bit 
tricky although that could be addressed by prefixing titles with the 
spec name (e.g. [workers] ...).

* GitHub PRs - some bugs are noted in comments to a PR (and thus making 
#2 a bit difficult).

* GitHub Issues - some bugs are reported as a Github Issue but GH's 
Issue granularity is for all of [WPT] and not per spec (thus making #2 a 
bit tricky, although title prefixing could help).

* The WPT root [WPT] is silent on how to file bugs (although some 
sub-resource could address that) and that could be appropriate if we 
expect every test suite to be able to customize its bug reporting policy.

If we agree Bugzilla should be used to report all test case bugs: 1) 
should we have an agreed way for a test suite in WPT to point to 
Bugzilla (although Bugzilla has bug reports for websockets and workers 
tests, that link is missing from the test suites); 2) should we continue 
to lump all of the tests in a single component or create per test suite 
components (e.g. tests-workers, workers-tests, ...).

Comments, proposals, etc. are welcome.

-Thanks, ArtB

[WPT] <>

[ime-api]Add Some Background about Chinese Input Methods in a Mobile Platform

Hi, all.

Here's some suggestions about the background part of the spec.

1. In section 2.1.3, the spec mentions the layout of the input method in mobile phone or tablet platforms very briefly, and takes the English keyboard or Japanese keyboard as an example. Is it possible that we say some more about composer into this part?

fig1 Pinyin Keyboard

fig2 Bihua Keyboard

I think it's very important to tell the difference between Phonetic Composer and Radical Composer in mobile platforms, given the fact that we also have phonetic keyboards(e.g., Pinyin keyboards) and radical keyboards there. In Fig1, "pinyin" keyboards use Phonetic Composer, and Fig2, we can see that radical keyboards should use Radical Composer.

2. I hope the T9 Keyboard(Fig3), which is very popular among Chinese input method producer, could be added to section 2.1.3. In addition, I think handwriting keyboards(fig4) should be put into this section as well since it has a large population of users in mobile devices compared to PC.

fig3 Pinyin T9 Keyboard

fig4 Handwriting Keyboard

3. In section 2.2, we can find the concept of selected clause. I would like to say some more about this if you don't mind. T9 keyboards are widely used because the screens of mobile devices have limited space[e.g., ios7], and we should notice the problem of duplicate characters here. For example, the candidate character "米" and "你" are input by the same code "64". That's why we provide a clause-select window to help the users to select the clause for converter. The red zone of Fig5 shows a clause-select window.

fig5 Clause-select window

Best Regards,
GuanQun Zhang
Desktop Input Method Department
sougou inc.
China P.R.

Arthur Barstow | 18 Dec 13:31 2013

[pointerlock] Call for Implementations and Tests

[ Bcc public-webapps-testsuite ]

Hi All,

On December 17 a Candidate Recommendation of Pointer Lock was published 
and that triggered a Call for Implementations:


Congratulations to Vincent (who also agreed to be the spec's Test 

Currently, there are no Reviewed and Approved tests for this spec 
although Philippe submitted the following Pull Request that has two test 
files (Web IDL and constructors):


I would appreciate it, if at least one person would please review this 
PR and submit their comments (even if just basically something like "I 
reviewed this file and it looks ok to me").

The originally submitted tests can be run directly in a UA via:


Of course additional test contributions are also welcome.

-Thanks, AB

SongTao(桌面事业部 | 16 Dec 11:01 2013

[IME API]Some Insights from Chinese Input Methods

Hello all,


It's very pleased to see we are making a great progress in IME API.


I do appreciate the second part of the spec about Chinese Input Composer and Converter. It's true that Chinese IMEs are very similar to Japanese IMEs. In fact, Chinese IMEs usually use a Phonetic Composer based on Pinyin, which require the users to select the correct character from a candidate window. Here's what I thought after reading the IME API WD as a Chinese input method developer. 


1) The compatibility of the InputMethodContext:: oncandidatewindowshow.

Most Chinese input methods use the input and candidate windows which are self-rendered, instead of windows embedded to a certain position. That's why I don't think the oncandidatewindowshow event can tell us whether a window is blocked or not correctly. Why not try Composition Event? How about hiding the suggestion when composition starts, and show it when composition ends?


2) Add support for web app to get the candidate list of IMEs.

For the current suggestion list, we use compositionupdate event to get the content of the input from the users, and construct our request only based on the search of composition string. Could we further the search request with the Candidate String, such as the case of search in Win8? I believe by this the input method and search engine would work together and give the users a better suggestion.



3) Can we extend ime-mode in CSS and use it to hide or show the input method window?

If [2] can be solved, which means we could get a candidate suggestion list, it will make sense to hide the input method window and self-render the suggestion list, which will be very helpful for the input method in web-games. I think the current ime-mode tag is used to star or end a input method, is it possible that we use it to hide or show the input method window some day?


These suggestions comes to me after reading the IME API as well as Composition Event, Composition Interface, Input Method Context Interface. Hope it helps. 

Song Tao
Desktop Input Method Department
Sougou Inc.

bugzilla | 16 Dec 16:33 2013

[Bug 24114] New: [imports]: add support for async loading

            Bug ID: 24114
           Summary: [imports]: add support for async loading
           Product: WebAppsWG
           Version: unspecified
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Component Model
          Assignee: dglazkov <at>
          Reporter: bmcquade <at>
        QA Contact: public-webapps-bugzilla <at>
                CC: esprehn <at>, mike <at>, morrita <at>,
                    public-webapps <at>
            Blocks: 20683

Resources imported via <link rel=import> are not parser blocking, but are
typically render blocking. Render blocking but not parser blocking is the right
default behavior, as the primary use case for <link rel=import> is to load
content (e.g. custom elements) needed to render that document.

However, a web developer may wish to load an import without blocking rendering.
Use cases:
* developer wishes to prefetch a custom element that is not needed to render
the initial view, but which will be needed once the user interacts with the web
app. developer would like the resource to be loaded and processed once it is
available, but does not want rendering of the page to block on the load of that
* developer uses a web component that can be sufficiently styled before being
upgraded using :unresolved, and thus it is not necessary to block rendering on
that component. This only works well for components whose size is known before
their custom element has finished loading; else a reflow happens when the
component loads and the element changes size.

In these cases, it is preferable that the user of the page not have to wait for
the import to finish downloading before they are able to see the other content
in the web app display on the screen. However, it is desirable that once the
import finishes downloading, that import should be processed and loaded into
the document (i.e. this isn't just a prefetch of content into the browser
cache), so it is fully loaded and available by the time the web app needs it
(thus it's also important that these elements fire a load event so developers
know when they are available for use).

Thus, we propose that, like <script async>, we add support for <link rel=import
async> to address this use case. At a high level, developers should think of
these similarly: "I want to load this script/import but I don't want its load
to block the rest of the content on the page from rendering."

There is a key difference between <script async> and <link async>: <script
async> indicates that the script should not block the parser. <link rel=import>
is already spec'd to not block the parser by default, async or not. However,
since imports are intended to block rendering by default, <link async
rel=import> indicates that the browser should not block rendering on the load
of the imported resource.

I am not aware of render-blocking behavior being spec'd as part of HTML5, and
this is probably for good reason: it is up to each user agent (browser) to
decide when and what to paint during the course of a web page load. However, in
practice, all browsers I'm aware of block rendering on the load of pending
stylesheets, and similarly, will block rendering on the load of pending
imports. Thus, <link async> is an indicator to the user agent that the load of
the imported resource should not block rendering.

In a conversation with dglazkov and esprehn, we proposed that <link async>
apply not only to imports, but also to stylesheets. The spec'd behavior should
be the same in each case: an import or stylesheet with an async attribute
should not block rendering of the page.

Whether to spec this as "should not" or "must not" block rendering is unclear:
at first glance, "should not" seems appropriate. However, if spec'd as "should
not" and one UA decides not to implement this behavior (they allow async
imports to block rendering) then developers will likely abandon this technique
and resort to JavaScript workaround that don't work particularly well (i.e.
loading the import after a requestAnimationFrame callback, which has various
drawbacks). Thus, in order to provide a way to load stylesheets and imports
without blocking render that is guaranteed to work across browser vendors, my
inclination would be to spec this behavior as "must not block rendering while
being loaded".


You are receiving this mail because:
You are on the CC list for the bug.

bugzilla | 15 Dec 11:28 2013

[Bug 24102] New: Specify the targets for events

            Bug ID: 24102
           Summary: Specify the targets for events
           Product: WebAppsWG
           Version: unspecified
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: File API
          Assignee: arun <at>
          Reporter: Ms2ger <at>
        QA Contact: public-webapps-bugzilla <at>
                CC: public-webapps <at>

For example, in readAsText:

"Fire a progress event called loadstart."

Nothing actually defines that the event is fired at the FileReader object.
(Consider using the term 'context object' to match DOM.)


You are receiving this mail because:
You are on the CC list for the bug.

bugzilla | 15 Dec 11:26 2013

[Bug 24101] New: Missing word in "Return the readAsText() method, but continue to process the steps in this algorithm"

            Bug ID: 24101
           Summary: Missing word in "Return the readAsText() method, but
                    continue to process the steps in this algorithm"
           Product: WebAppsWG
           Version: unspecified
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: File API
          Assignee: arun <at>
          Reporter: Ms2ger <at>
        QA Contact: public-webapps-bugzilla <at>
                CC: public-webapps <at>

Should probably be 'return from...'


You are receiving this mail because:
You are on the CC list for the bug.

Arthur Barstow | 13 Dec 13:39 2013

[push-api] Discussion with TAG on December 19

One of the discussion topics for the TAG's December 19 call [Agenda] is 
the Push API [ED]. Members of the TAG have assembled comments in:


As well as the following thread:


If this spec is of keen interest for you, please feel free to join the 
December 19 call (13:00 Boston time). Logistics are in the agenda page 
(join the W3C's #tagmem IRC channel at the start of the meeting to get 
the Zakim voice conference PIN).

-Thanks, AB

[Agenda] <>
[ED] <>

Maciej Stachowiak | 13 Dec 09:59 2013

Custom form elements (was Re: [webcomponents] Inheritance in Custom Elements (Was Proposal for Cross Origin Use Case and Declarative Syntax))

On Dec 7, 2013, at 4:38 PM, Dominic Cooney <dominicc <at>> wrote:

Built-in HTML elements have lots of hooks to modify their behaviour (for example, HTMLVideoElement's autoplay attribute.) The analogy is extending a Java class which has private and public final members, but no protected or public non-final ones.

If someone were to make proposals about adding more hooks to the web platform to enable more subtyping use cases (for example, a protocol for participating in form submission) I would look forward to working with them on those proposals.

Let's say you have the ability to define a custom element inheriting from a form element, but completely replace its rendering and behavior with custom shadow DOM.

Is that actually sufficient to participate correctly in form submission? I don't think it is. In particular, I don't see how a custom element could inherit from HTMLInputElement, fully support the interface, and correctly submit a value that is specified via a completely custom mechanism.

Also, even if it worked, inheriting from HTMLInputElement is a particularly clunky approach to participating in form submission. To actually correctly support the interface, you need your component to support every input type. But that is way overkill if you only want to replace a single kind of input, or define a new type of your own. The more convenient approach would be to ignore type-switching and as a consequence make a "subclass" that does not respect the Liskov Substituton Principle and is therefore bad OO.

I think giving custom elements a specific API for participating in form submission, to enable defining new kinds of form elements, would be a better approach to this problem and ultimately easier to use. It is also much more relevant as a way to "explain how the way the Web platform works". Built-in form elements participate in form submission by having special hooks to participate in form submission, not by inheriting from other form elements.