Re: [whatwg] Notifications and service workers
On Wed, Oct 1, 2014 at 12:31 PM, Anne van Kesteren ann...@annevk.nl wrote: On Fri, Sep 26, 2014 at 4:36 PM, Peter Beverloo bever...@google.com wrote: * Life-time of existing notifications. Chrome currently treats Web Notifications as persistent ones. When the page goes away, the notification stays. Interaction with the notification is not going to trigger anything anymore. While I'm in favor of changing this, we have to be very cautious to not break user expectations of existing users of the Web Notification API, for example in calendar applications. I think from the perspective of the specification this does not change anything. If a platform wants to log all notifications that is fine. What we want to start calling persistent notifications are those for which a service worker will get notified and which can be retrieved using Notification.get(). Hopefully browsers and platforms evolve over time to distinguish the two more clearly. * Dropping the close event. Synchronizing closing of the notification on all the user's devices is an interesting one, but opt-in would be sufficient for this. Yeah, it seems like we need to keep this. Through opt-in works. * Not using the constructor for persistent notifications. I have no strong feelings here either, and think it's fine to continue using the constructor with the serviceWorker property set. Both would still use the Notification statics. Having a promise would clean up the error handling a bit, which may occur in the no-permission case. It seems nicer to have the association with the registration be implicit by having a method on that object (reg.createNotification()). However, it's very much the factory pattern which is somewhat frowned upon. But hopefully it's not too bad here. It could just be an accessor on the ServiceWorkerRegistration for both convenience and consistency, mapping to the constructor with the serviceWorker property set. We'll need to keep the constructor in either case. Combined with dropping the open event, I think I have enough to rework the current Notifications API. Is there anything I'm missing? One argument I came across for overloading requestPermission is the following: Promise.all([ Notification.requestPermission(), swRegistration.push.requestPermission() ]).then(...); Might be worth considering, it's relatively cheap to support and can be implemented without breaking backwards compatibility. Thanks, Peter -- https://annevankesteren.nl/
Re: [whatwg] Notifications and service workers
Let me reply to a few points mentioned in this thread -- it's quite
overloaded :-).
I've also added Andrew, who might know some historical reasons for the
events. (Andrew: most of this is in context of persistent notifications.)
* Life-time of existing notifications.
Chrome currently treats Web Notifications as persistent ones. When the
page goes away, the notification stays. Interaction with the notification
is not going to trigger anything anymore. While I'm in favor of changing
this, we have to be very cautious to not break user expectations of
existing users of the Web Notification API, for example in calendar
applications.
* Dropping the close event.
I've been wondering myself whether it's valuable to support this. Like Tab,
I'm not aware of any messaging application actually using the close event
as an indication that the message has been read. There is the dismiss all
button on most platforms, which definitely does not imply having read the
message. It's actually an interesting privacy question as well, for
example, if a user dismisses a Facebook notification in their notification
center without actually starting the app, should the sender be informed
about them having at least looked at their phone?
Synchronizing closing of the notification on all the user's devices is an
interesting one, but opt-in would be sufficient for this.
Given the cost of starting up a Service Worker, I'm interested in exploring
opt-in. One potential optimization a UA could do is detect the events bound
on a Service Worker's global when it starts, and check whether
notificationclose is part of this for future invocations.
* Dropping the show event.
There is one scenario in which Chrome doesn't fire the show event, and
that's when no permission has been granted to show notifications (in which
case we fire the error event). One theoretical concern with this property
is that if we choose to support delayed notifications, it could be used to
set precise timers. Depending on how we're going to deal with
(asynchronous) errors for persistent notifications, I'm fine with dropping
this for them.
* Supporting non-persistent notifications in Service Workers.
I'd prefer not to, especially if we would auto-close the notifications.
There seems to be little point beyond indicating to the user that the
Service Worker is running, which feels more like a UA thing if they choose
to do so.
* Supporting non-persistent notifications in Shared and Dedicated Workers.
As long as we continue to support non-persistent notifications, I see no
reason not to do this. The globals of both kinds of workers have well
defined lifetimes, making the notifications as reliable as in-page ones,
most notably on desktop.
* Not using the constructor for persistent notifications.
There is one more argument to make in favor of creating a promise
somewhere, and that's consistency with other Service Worker based APIs. As
I understand it, both Web Push and Background Sync are planning to expose
their creation methods on the ServiceWorkerRegistration object. If we were
to do something analogous, it'd be:
navigator.serviceWorker.ready.then(function (registration) {
registration.createNotification('Title', { ... });
});
Instead of:
navigator.serviceWorker.ready.then(function (registration) {
new Notification('Title', { serviceWorker: registration });
});
I have no strong feelings here either, and think it's fine to continue
using the constructor with the serviceWorker property set. Both would still
use the Notification statics. Having a promise would clean up the error
handling a bit, which may occur in the no-permission case.
* Extra-persistent notifications (non-removable ones)
Let's have a separate thread about this. I think it's a loaded subject
given that it's incredibly easy to badly annoy the user when using these,
and we have to make some careful considerations here.
Thanks,
Peter
On Fri, Sep 26, 2014 at 2:41 PM, Anne van Kesteren ann...@annevk.nl wrote:
On Fri, Sep 26, 2014 at 1:42 AM, Tab Atkins Jr. jackalm...@gmail.com
wrote:
None of Twitter, Hangouts, or IRCCloud cares a whit if you close their
notifications; they still record stuff as unread until you actually
visit the app. I can't recall any other app I've ever used treating a
notification closing as a significant event and taking any action,
either. So, at least based on my immediate testing and long-term
memory of the notification patterns of the apps I use, I don't think
there's any use-case for a close event.
Jake, would be interesting to hear your thoughts on this. If we can
simplify notifications by getting rid of some events I'm all for it.
--
https://annevankesteren.nl/
Re: [whatwg] Notifications improvements
On Mon, Aug 11, 2014 at 9:27 AM, Andrew Wilson atwil...@google.com wrote:
On Fri, Aug 8, 2014 at 2:48 PM, Peter Beverloo bever...@google.com
wrote:
Hi Andrew,
On Wed, Aug 6, 2014 at 12:59 PM, Andrew Wilson atwil...@google.com
wrote:
On Wed, Aug 6, 2014 at 12:48 PM, Anne van Kesteren ann...@annevk.nl
wrote:
On Wed, Aug 6, 2014 at 10:08 AM, Andrew Wilson atwil...@google.com
wrote:
I understand your concern that is driving this proposal: you don't
want to provide rich APIs that can't be well implemented on every
platform, and thereby fragment the web platform. I just don't want to
see us go down this path of adding these new notification types that
are so limited in ability that people will just keep using general
notifications anyway - I'd rather just stick with the existing API.
Are you unenthusiastic about any of the proposed additions (what about
those already added?) or is this more about the more complex
features such as indication of progress?
I'm (somewhat) unenthusiastic about the new semantic types, because
I'm not sure they'd get enough uptake to be worth the effort to
implement (note that this is just my personal opinion - I'm no longer
as heavily involved in the notification work within Chromium, so Peter
B's opinion carries much more weight than mine when it comes to
determining what we'd implement).
I find myself being in favor of the semantic types.
The primary reason for this is that it allows us to provide a much more
consistent user experience, especially on platforms where we don't
control
rendering of the notification, compared to HTML notifications. On Chrome
for
Android we want to provide for a consistent user experience, where
notifications should be visually indistinguishable (aside from clarifying
the origin) from those created by native apps. The proposed semantic
types
would get us there.
Furthermore, support for HTML notifications will be much more difficult
to
implement across the board. Some mobile OSes, notably Firefox OS and iOS,
wouldn't support this at all. Others, such as Android, theoretically
could
support it, but won't because it means creating an entire WebView --
causing
very significant memory pressure on already resource constrained devices.
To be clear, I'm not arguing for HTML notifications - as I said in my
original post to this thread, HTML notifications were removed from the
spec for various good reasons. But I think it's a mistake to just bake
in canned notification types. What if a developer wants a progress bar
with a cancel button? A progress bar with a timestamp? A list
notification that contains an event with timestamp? Or some other
different notification that doesn't specifically match one of your
curated templates, but could easily be built if you gave him a
lower-level set of primitives?
You raise an interesting question. Given the following notification:
var notification = new Notification('Title', {
body: 'Hello, world!',
icon: '/my-icon.png',
items: [
{ title: 'Message 1', body: 'Contents of message 1' },
{ title: 'Message 2', body: 'Contents of message 2' },
{ title: 'Message 3', body: 'Contents of message 3' }
],
buttons: [
'Reply',
'Reply to all',
'Forward'
],
date: new Date('2014-08-11T16:35:00'),
progress: 40
});
What do we expect to be displayed?
I *think* Android can mix and match some of those, but expect at least
progress bars and lists of items to be mutually exclusive. I don't have a
good answer for this right now. UAs rendering their own notifications could
support this more easily, but it will still raise interesting UX questions.
Thanks,
Peter
Re: [whatwg] Notifications improvements
Hi Andrew, On Wed, Aug 6, 2014 at 12:59 PM, Andrew Wilson atwil...@google.com wrote: On Wed, Aug 6, 2014 at 12:48 PM, Anne van Kesteren ann...@annevk.nl wrote: On Wed, Aug 6, 2014 at 10:08 AM, Andrew Wilson atwil...@google.com wrote: I understand your concern that is driving this proposal: you don't want to provide rich APIs that can't be well implemented on every platform, and thereby fragment the web platform. I just don't want to see us go down this path of adding these new notification types that are so limited in ability that people will just keep using general notifications anyway - I'd rather just stick with the existing API. Are you unenthusiastic about any of the proposed additions (what about those already added?) or is this more about the more complex features such as indication of progress? I'm (somewhat) unenthusiastic about the new semantic types, because I'm not sure they'd get enough uptake to be worth the effort to implement (note that this is just my personal opinion - I'm no longer as heavily involved in the notification work within Chromium, so Peter B's opinion carries much more weight than mine when it comes to determining what we'd implement). I find myself being in favor of the semantic types. The primary reason for this is that it allows us to provide a much more consistent user experience, especially on platforms where we don't control rendering of the notification, compared to HTML notifications. On Chrome for Android we want to provide for a consistent user experience, where notifications should be visually indistinguishable (aside from clarifying the origin) from those created by native apps. The proposed semantic types would get us there. Furthermore, support for HTML notifications will be much more difficult to implement across the board. Some mobile OSes, notably Firefox OS and iOS, wouldn't support this at all. Others, such as Android, theoretically could support it, but won't because it means creating an entire WebView -- causing very significant memory pressure on already resource constrained devices. Implementation wise, Chrome recently switched to rendering Notifications using a new message center implementation, which already supports rich data such as progress bars, timestamps, lists and buttons. On Android many of these features will come down to calling an extra method on the Java Notification.Builder. I am quite enthusiastic about adding support in the API around allowing users to interact with notifications after the parent page has closed, however. Having a new field timestamp that carries a particular point in time related to the message seems quite useful for instance and not very intrusive. Perhaps I'm not understanding how this would be used. What would such a notification look like for (say) a calendar event (Your 1PM meeting starts in 5 minutes) versus a countdown timer (In 73 seconds, your hard boiled egg will be done cooking)? Would we have to provide a format string so the UA knows where to inject the time remaining, or would it always have to be put at the end? Do we need to specify granularity of updates (i.e. if I have a stopwatch app, I probably want to update every second, but for a calendar app, updating every 5 minutes is probably sufficient, until we get down to the last 5 minutes)? I would argue that this is a feature that should be defined by the UA or platform. I'm not sure whether using a counting notification is the right way to implement a count-down -- I would expect normal, foreground UI displaying a counter, and a notification if that UI was moved to the background and the counter expired. The timestamp doesn't necessarily need to be in the future either. At least for me, a calendar notification that is constantly updating its countdown every minute but has no snooze functionality is actually a mis-feature, because it's distracting. The notification wouldn't visually re-announce itself on every update. Again, I don't want to be overly negative about this - maybe there are use cases like list notifications where the new API would be really useful, but as soon as I start thinking about more complex display scenarios, I immediately want to start having more control over the formatting of the text being displayed, and i wouldn't get that with this proposal. I think the benefit of being able to closely match the UI and UX of native notifications on the platforms is something that's enabled by using declarative properties, whereas that would be near impossible to do with HTML notifications. As long as advanced features, especially more compatible ones (say, buttons or timestamps) can be feature detected by developers so that they can provide a fallback when they're not available, I would be in favor of extending the future set with Jonas' declarative proposals. Thanks, Peter
Re: [whatwg] [Notifications] Persistent notifications depending on Service Workers
On Tue, Aug 5, 2014 at 3:48 PM, Anne van Kesteren ann...@annevk.nl wrote: On Tue, Jul 29, 2014 at 4:28 PM, Peter Beverloo bever...@google.com wrote: When used from a Service Worker, the attribute will implicitly default to the ServiceWorkerRegistration of the running Service Worker. Is that available within a service worker? It would be reasonable to expose it, but it currently isn't (afaik). If serviceWorker is set to null/undefined within a ServiceWorker context, a TypeError will be thrown. I thought the idea was to have it default somehow. It seems to me within a service worker you cannot specify it and you simply always get a notification associated with that service worker. Defaulting to the current Service Worker sounds good. One case Jake and I thought of was if/when a Service Worker could get registrations for other SWs in the origin, but that's only a theoretical case today. 1. If registration.activeWorker is null, then: 1. Throw a DOMError with name “InvalidStateError” 2. Abort these steps. We could throw a TypeError. (DOMError is not a thing.) Equivalent to what happens when you get the type wrong. I think it would be nice to be able to distinguish the invalid-value-type case from the no-service-worker case, wouldn't you lose that by throwing TypeErrors in both cases? Events will be delivered to either the Notification instance, or to the Service Worker, not both. All four events will be exposed to a Service Worker [onnotificationshow, onnotificationclick, onnotificationclose, onnotificationerror]. The events will receive a NotificationEvent which will contain a notification instance. So with each event you get a new instance of the object? I guess that's probably what we want given how getClones() et al work. A bit wasteful, but not too bad. I don't think this is a massive problem, in general Notification objects will be very small (depending on the data property, of course). Peter -- http://annevankesteren.nl/
Re: [whatwg] [Notifications] Persistent notifications depending on Service Workers
To summarize a discussion we had about this on IRC today:
http://krijnhoetmer.nl/irc-logs/whatwg/20140729#l-509
Jungkee wrote a helpful document for features using Service Workers as well:
https://gist.github.com/jungkees/3154398b8deee7c70139
The |serviceWorker| attribute can be added to the NotificationOptions
dictionary and to the Notification interface, and should be set by the
developer to the ServiceWorkerRegistration instance.
navigator.serviceWorker.ready.then(function(registration) {
new Notification(‘Hello, World!’, {
serviceWorker: registration
});
});
When used from a Service Worker, the attribute will implicitly default to
the ServiceWorkerRegistration of the running Service Worker. If
serviceWorker is set to any non-SWR value, a TypeError will be thrown. If
serviceWorker is set to null/undefined within a ServiceWorker context, a
TypeError will be thrown.
1. If registration.activeWorker is null, then:
1. Throw a DOMError with name “InvalidStateError”
2. Abort these steps.
Events will be delivered to either the Notification instance, or to the
Service Worker, not both. All four events will be exposed to a Service
Worker [onnotificationshow, onnotificationclick, onnotificationclose,
onnotificationerror]. The events will receive a NotificationEvent which
will contain a notification instance.
Thanks,
Peter
On Fri, May 16, 2014 at 3:17 PM, Anne van Kesteren ann...@annevk.nl wrote:
On Fri, May 16, 2014 at 4:02 PM, Peter Beverloo bever...@google.com
wrote:
On Fri, May 16, 2014 at 2:57 PM, Anne van Kesteren ann...@annevk.nl
wrote:
Service worker integration makes sense to me. I guess I'll wait with
updating the Notifications API until that is further along.
Do you have a specific milestone in mind?
Probably once it exposes a stable hook for does the current global
have an associated service worker. And if I am to define the service
worker events I suppose some more hooks are needed. Having service
workers in two implementations would also help, as at that point the
stability is a lot less uncertain.
--
http://annevankesteren.nl/
[whatwg] [Notifications] Behavior of Notification.requestPermission in workers
Since the entire Notification object is exposed both on window and in workers, I'd like some clarification on the intended behavior of Notification.requestPermission() when called in the background. http://notifications.spec.whatwg.org/#dom-notification-requestpermission Some options: (1) Request permission in any available foreground contexts. This could be confusing. It could also be achieved by the worker sending a message to any foreground windows, allowing the page to provide context about the request. (2) Invoke |callback| with the current permission level. This allows developers to copy their code between windows and workers if they use the Notification constructor within the callback when |permission| == granted. This has my preference. (3) Ignore. Any opinions? Thanks, Peter
Re: [whatwg] [Notifications] Behavior of Notification.requestPermission in workers
That'd work for me too. Peter On Mon, Jul 28, 2014 at 1:00 PM, Anne van Kesteren ann...@annevk.nl wrote: On Mon, Jul 28, 2014 at 6:55 PM, Peter Beverloo bever...@google.com wrote: Any opinions? I prefer (4), add [Exposed=Window]. -- http://annevankesteren.nl/
Re: [whatwg] [Notifications] Persistent notifications depending on Service Workers
On Fri, May 16, 2014 at 2:57 PM, Anne van Kesteren ann...@annevk.nl wrote: On Thu, May 15, 2014 at 6:12 PM, Peter Beverloo bever...@google.com wrote: For |notificationshow|, there is a worry here that if we decide to support delayed notifications, it would enable developers to use notifications to set precise timers: create a delayed notification to be displayed an hour from now, get the |notificationshow| event, and call |notification.close()|. This is something which I'd hope would only be possible through some kind of alarms API, which in itself may be undesirable to start with. Delayed notifications seems like a new feature of sorts we should probably discuss separately. Although now you can create Notification objects from a service worker you could get them as the result of e.g. a server push so maybe it's not so new as it could be polyfilled in that way... Keeping possible future additions in mind allows us to avoid ending up with a precise alarms-like API if and when we decide to do so. Beyond that, the subject of delayed notifications indeed is a separate discussion. Service worker integration makes sense to me. I guess I'll wait with updating the Notifications API until that is further along. Do you have a specific milestone in mind? Thanks, Peter -- http://annevankesteren.nl/
Re: [whatwg] [Notifications] Persistent notifications depending on Service Workers
One amendment to (3), which events to expose on the
ServiceWorkerGlobalScope, is that we should only expose the
|notificationclick| and |notificationclose| events.
The benefit of not exposing |notificationerror| is that there are two
situations in which we would fire the event: (a) when there is no service
worker, and (b) when there is no permission. Both are known shortly after
creating the Notification object (but not synchronously). This avoids
confusion about where to listen for errors.
For |notificationshow|, there is a worry here that if we decide to support
delayed notifications, it would enable developers to use notifications to
set precise timers: create a delayed notification to be displayed an hour
from now, get the |notificationshow| event, and call
|notification.close()|. This is something which I'd hope would only be
possible through some kind of alarms API, which in itself may be
undesirable to start with.
Thanks,
Peter
On Tue, May 13, 2014 at 3:33 PM, Peter Beverloo bever...@google.com wrote:
Based on Anne's Reviving Notification Objects thread from last year, I
would like to propose an alternative solution.
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2013-March/251058.html
There are known lifetime issues with Notifications, and rather than tying
them all to the page, how about considering event delivery to a Service
Worker instead? This solves (a) the case in which the tabs are no longer
available, (b) the case where multiple tabs with the launch URL have been
opened, and (c) the case where the user clicks on several notifications
before the page load is complete.
Concretely:
(1) Extend the NotificationOptions interface with a serviceWorker
property. When set to true, event delivery will *only* go to the Service
Worker. However, we should probably still fire |onerror| when no service
worker is current for the page.
(2) Extend the Notification interface with the serviceWorker property,
as a read-only boolean. For browsers which correctly expose properties on
the prototype chain[1], this can therefore be feature-tested using
Notification.prototype.hasOwnProperty('serviceWorker').
(3) Extend the ServiceWorkerGlobalScope interface[2] to define
|notificationactivate| and |notificationshow| events. Both receive a
NotificationEvent object, which exposes a |notification| property providing
access to (a clone of) the relevant notification.
I don't have a strong opinion on whether we should have a
|notificationclose| event in the SW scope. It could be useful for a
background music player, in which dismissing the notification stops
playback (through a postMessage to an open tab, supposedly).
In the future, the NotificationActivateEvent property could be extended to
include information from rich features, e.g. |button|, if we decide to take
that route.
Thanks,
Peter
[1] Chrome bug: http://crbug.com/43394
[whatwg] [Notifications] Persistent notifications depending on Service Workers
Based on Anne's Reviving Notification Objects thread from last year, I
would like to propose an alternative solution.
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2013-March/251058.html
There are known lifetime issues with Notifications, and rather than tying
them all to the page, how about considering event delivery to a Service
Worker instead? This solves (a) the case in which the tabs are no longer
available, (b) the case where multiple tabs with the launch URL have been
opened, and (c) the case where the user clicks on several notifications
before the page load is complete.
Concretely:
(1) Extend the NotificationOptions interface with a serviceWorker
property. When set to true, event delivery will *only* go to the Service
Worker. However, we should probably still fire |onerror| when no service
worker is current for the page.
(2) Extend the Notification interface with the serviceWorker property,
as a read-only boolean. For browsers which correctly expose properties on
the prototype chain[1], this can therefore be feature-tested using
Notification.prototype.hasOwnProperty('serviceWorker').
(3) Extend the ServiceWorkerGlobalScope interface[2] to define
|notificationactivate| and |notificationshow| events. Both receive a
NotificationEvent object, which exposes a |notification| property providing
access to (a clone of) the relevant notification.
I don't have a strong opinion on whether we should have a
|notificationclose| event in the SW scope. It could be useful for a
background music player, in which dismissing the notification stops
playback (through a postMessage to an open tab, supposedly).
In the future, the NotificationActivateEvent property could be extended to
include information from rich features, e.g. |button|, if we decide to take
that route.
Thanks,
Peter
[1] Chrome bug: http://crbug.com/43394
[whatwg] [Notifications] Notification.hasPermission() instead of Notification.permission
The Notification specification defines a static Notification.permission
accessor, which returns one of {granted, denied, default}. This requires
the browser to synchronously determine whether the page has permission to
show notifications, whereas checking this may be an asynchronous operation.
This is the case in Chrome.
Before this becomes a paradigm, could we consider having a static
hasPermission() instead, returning a Promise?
I'll add a UseCounter to Blink for tracking Notification.permission usage,
but it will take some time before conclusive usage data comes in.
Thanks,
Peter
Re: [whatwg] At Inclusion (a declarative way to Ajaxise a website)
On Sun, Jun 17, 2012 at 10:32 AM, Florent FAYOLLE florent.fayoll...@gmail.com wrote: Hello, I have written a proposal that introduces a new way to include remote contents into the document (in other (bad) word, to Ajaxise it) using a declarative way. This proposal is named At Inclusion, and can be read here : http://fflorent.github.com/At-**Inclusion-Proposal/http://fflorent.github.com/At-Inclusion-Proposal/ To rapidly sum up, At Inclusion is a part of the URL that describes pairs. Each pair is composed of : - the ID of the target element (the element that gets the remote content); - the URL leading to the content to include. and the At Inclusion has this form : @TARGET_ID1=URL1,TARGET_ID2=**URL2... For example, let's suppose we have this main document (located at http://myserver/mypage.html) : html head.../head body ... a href=@myTarget=/myaddition.**htmlclick me/a ... div id=myTargetpdefault content here/p/div ... /body /html and the content to include in myTarget (located at /myaddition.html) : phello world/p By clicking on the link, the HTML code of #myTarget will be replaced with this one : div id=myTargetphello world/p/div and the new location of the page will be : http://myserver/mypage.html@** myTarget=/myaddition.htmlhttp://myserver/mypage.html@myTarget=/myaddition.html Feedbacks welcome. Thanks, Florent Without having read your proposal in detail, it seems like seamless iframes in combination with a target should address the majority of your use-case: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-iframe-element.html#attr-iframe-seamless There is no way to map a parameter from the request URL to the iframe's source without JavaScript, however, but personally I don't think there is a necessity for a non-JavaScript way of doing that. Peter
Re: [whatwg] device use cases
On Tue, Mar 15, 2011 at 14:26, Jörn Zaefferer joern.zaeffe...@googlemail.com wrote: Where did you hear that device was cancelled? On Tue, Mar 15, 2011 at 14:10, jesp...@opera.com wrote: Hi! I just heard that device was canceled and replaced by navigator.getUserMedia()... Just wanted to point out a couple of use cases that I was looking forward to, that seems to maybe have gotten a bit lost on the way? I was really looking forward to start playing around with USB MIDI interfaces to control my synth and maybe even do really creative stuff the other way around. Just imagine being able to play on your synth (or any other device with MIDI output) and generate sound or graphics in a canvas web application or so! Or... be able to control other devices using serial connection. Maybe do lirc-alike stuff, using your IR based remote to control Youtube or other HTML5 video services, etc. Amazing new possibilities, that would be (almost) endless... :) The following change was committed to the specification yesterday: http://html5.org/tools/web-apps-tracker?from=5944to=5945 Most references to the device element have been removed as well, and this section has been introduced: http://www.whatwg.org/specs/web-apps/current-work/multipage/dnd.html#obtaining-local-multimedia-content Regards, Peter Beverloo
Re: [whatwg] Clarifying the use and requirements of Data URL
On Tue, Aug 24, 2010 at 17:49, Julian Reschke julian.resc...@gmx.de wrote: On 18.08.2010 15:21, Peter Beverloo wrote: Currently the specification requires the use of Data URLs for canvas.toDataURL[1] and refers to usage of them a number of times as well[2][3]. While steps describing how to generate a Data URL are defined in the specification[4], they are not being referenced by the other occurrences. These steps seem to be identical to the contents of RFC 2397[5], The data URL scheme by Larry Masinter. I raised http://www.w3.org/Bugs/Public/show_bug.cgi?id=10399, but it appears Ian thinks that not citing RFC 2397 is ok. Next to that, the specification does not list when Data URLs should be supported by an User Agent. WebKit, Gecko and Presto seem to accept them as any resource, including locations entered via the address bar, while Trident only accepts Data URLs for images and scripts. Yes. But there aren't requirements for other schemes as well, right? I believe the use and requirements of Data URLs in the specification could be clarified by: - Referring to RFC 2397 for information about their composition and syntax *or* generalize the steps described in the form submission algorithm[4], so they can be applied on the entire document. - Extend the accepted values of @src, @href, @action et al to include support for data: URLs. ... Why do you think @src, @href etc need to be extended for that? Best regards, Julian Hi Julian, Thank you for pointing me towards the bug report. Referring to rfc 2397 would be one solution to generalizing the steps involved in creating and/or parsing data: URLs, moving these steps out of the form submission algorithm is another solution. Right now I think that it's under-defined, as some places don't refer to anything else than the name. I've learned that data URLs could validate as unescaped path-rootless IRIs, defined by rfc 3987[1]. Because of that any extension of the attributes will not be required. Best regards, Peter Beverloo [1] http://www.ietf.org/rfc/rfc3987.txt
[whatwg] Clarifying the use and requirements of Data URL
Currently the specification requires the use of Data URLs for canvas.toDataURL[1] and refers to usage of them a number of times as well[2][3]. While steps describing how to generate a Data URL are defined in the specification[4], they are not being referenced by the other occurrences. These steps seem to be identical to the contents of RFC 2397[5], The data URL scheme by Larry Masinter. Next to that, the specification does not list when Data URLs should be supported by an User Agent. WebKit, Gecko and Presto seem to accept them as any resource, including locations entered via the address bar, while Trident only accepts Data URLs for images and scripts. I believe the use and requirements of Data URLs in the specification could be clarified by: - Referring to RFC 2397 for information about their composition and syntax *or* generalize the steps described in the form submission algorithm[4], so they can be applied on the entire document. - Extend the accepted values of @src, @href, @action et al to include support for data: URLs. Thank you, Peter Beverloo [1] http://www.whatwg.org/specs/web-apps/current-work/#dom-canvas-todataurl [2] http://www.whatwg.org/specs/web-apps/current-work/#submit-data-post [3] http://www.whatwg.org/specs/web-apps/current-work/#sandboxOrigin [4] http://www.whatwg.org/specs/web-apps/current-work/#submit-data-put [5] http://tools.ietf.org/html/rfc2397
Re: [whatwg] Proposal for a widget tag
On Sun, Jun 13, 2010 at 17:17, Schalk Neethling sch...@ossreleasefeed.com wrote: Hi there, I have watched one video after the other, and read articles just the same. I know we are all unsure when to use section and when to use article. But marking up something as simple as a blogroll as an article? This really makes no semantic sense to me. Therefore I suggest the addition of the widget tag. Below is the most obvious use case and makes much more sense to me. Thoughts? section widget id=”blogroll” /widget widget id=”search” /widget /section Kind Regards, Schalk Neethling What advantages would widget have over section, article or simply a grouping div? I fail to see why widget id=search would make significantly more sense than div id=search, or even a fieldset (because that's what a search-area usually consists of). Same goes for blog-roll, why not simply use an ol element? There has been a lot of discussion about the new elements lately, their use-cases and rationales, not only about section and article, but also the aside element. Before starting yet another discussion you might want to include several use-cases, advantages of the new element (also in terms of accessibility) and define how it's going to improve semantics in general. The term widget can be very widely interpreted, as a widget technically can contain anything, how is that going to make choosing a sectioning element easier? Peter
Re: [whatwg] Potential Danger with Canvas API in html5 #html5 #canvas
On Wed, Jun 9, 2010 at 22:05, narendra sisodiya naren...@narendrasisodiya.com wrote: On Thu, Jun 10, 2010 at 12:20 AM, Peter Beverloo pe...@lvp-media.com wrote: On Wed, Jun 9, 2010 at 20:29, narendra sisodiya naren...@narendrasisodiya.com wrote: Canvas API is just great and I love it, You will also love it , if not, just see Canvas demos - http://www.canvasdemos.com But we have potential danger to misuse it also for the sake of non-standards. prediction Case 1 - Abode can make its flash-player inside canvas API. I know, it will not be 100% compatible. They can create a CanvasAPI based flash player. Their are already 2 client side run time engine in JavaScript - Smokescreen and Gordon - http://twitter.com/jdowdell/statuses/14985295733 , Biggest advantage with JS and client side is that you can see sourcecode. In order to hide the source code , Adobe can use server side. Some processing will be on server side and output will be streamed (in form of image) to client side and renders into CANVAS area with pixel. You can grab event from canvas area and send bacl to server. This way Developer may come up with a Server Side HTML5 toolkit which will reuse BAD standards like flash with Hiding Source code of a Web Application . Adobe or other companies can modify their products and generate server side HTML5 code which will render the application CANVAS API. A huge number of dummy developer use such non-standards tools and with this, they will be able to reuse skills by this and will not adopt a true spirit of HTML5. So, This I do not like,,,-- ''designer/developers will be using non-standard server side code, generated from non-standards ToolKits, and pretend that we also use HTML5 We urgently need HTML5 authoring tool. we urgently needs SVG authoring tools. /prediction I guess, with the advance of html5, Adobe has been working hard to run flash on canvas from server inorder to save its presence. . -- ┌─┐ │ Narendra Sisodiya │ http://narendrasisodiya.com └─┘ Yet another HTML5 Developer. Hello Narandra, Do you have any links or sources backing up that Adobe is working on the server-side? While your scenario certainly is possible, even with today's possibilities, I see a number of problems with it: No, i do not have any info. I am independent developer who enjoy making predictions - http://blog.narendrasisodiya.com/2010/06/how-and-why-browser-share-ratio-will-be.html 1) The number of simultaneous users in any web application will be severely limited by the available processing power of the server. Thinking of the current uses of Flash, a really large part of which are video players and games, it does not seem realistic. Extend this to Flash applications such as FarmVille on Facebook and server-side processing and rendering will be pretty close to impossible. Yes, you are correct at this points, 2) How exactly is this different from normal webpages? A lot of websites use scripting languages as their back end, such as PHP, delivering a certain flexibility which is not directly visible to the user. The same thing can be applied to achieve creating personalized Application Cache Manifests. PHP script generate HTML code along with JavaScript. It make our task easy. But, Lets imagine if we have a very good Tookkit which have everything for webdesign like buttions, menus, dropdown and final code renders everything in CANVAS. ToolKits may use altogether different higher level sytax to generate canvas based applications. further this toolkit has JavaScript unzip library. then you will be able to create a application in zipped format. Let me explain this more Designer/Developer will use drag and drop based Toolkit which has altogether different higher level sytax which generate CANVAS based application. Toolkit Or some JavaScript code will generate JavaScript code with all resource like image, htmlcode, source code and everything in application directory. Toolkit will zip the whole application and finally designer/developer will get a myfirstgame.wapp Now developer/designer need to write this much code script src=./js/wapp-engine.js/script div class='wapp-application' data-src='./myfirstgame.wapp' width='600' height='800' / This wapp-engine.js will be a wapp player which load myfirstgame.wapp using Ajax and unzip files. Create a dynamic canvas, and render the game in canvas area. So we are using HTML5 canvas but what are we doing Fast and GUI based development tools with a non-standards/proprietary ToolKit for generating a .wapp files which can be distributed and developed easily .wapp will be played in browser will be JS wapp player which render it inside CANVAS API with hiding images, text and everything under pixels which is the prime requirement of many website
Re: [whatwg] Prefetch issues
On Thu, Jun 10, 2010 at 17:01, Eric Schurman eri...@gmail.com wrote: As described, the link prefetching capability seems to have some limitations that work counter to the performance of the page using it. It appears as though LINK elements are metadata elements and that these may only be supported inside the HEAD of the document. If so, then this is an issue in the real world, because at the time a web server flushes chunks containing the HEAD section of a document, the links we would want to prefetch are often not known. This is true for all the large sites I've analyzed or worked at. For example, many pages on a site will contain the same visual header, and we want to flush the HEAD and visual header content while the server is in the process of figuring out what the content of the page will be - which will contain the links we'd like to prefetch. Am I reading this correctly? Or is there a something that would allow the flushing scenario I describe above? One of the simplest approaches may be to add support for rel=prefetch to A and AREA's, but it's been explicitly excluded from those. Why? Another approach could be to allow LINK throughout the document. This would allow for prefetching content like images even if you didn't know them at HEAD rendering time. Any opinions? While I have not found the original discussion about including the prefetch relation in area and anchor tags, my guess would be that it's a feature that would quite easily be abused by web authors. Adding @rel=prefetch to all anchors is a lot easier than putting them in the header, so why not just preload every page on the site? Again, someone else will probably have the answer you're looking for. Mozilla's Developer Center has a page about the attribute value[1] which already suggests that they might add the feature on normal anchor tags if there is sufficient interest in that. Their page also contains a chapter about how to implement prefetching using the Link HTTP header, which would be a solution if your website uses output buffering. Considering you're specifically talking about flushing the header before the links are known, however, I'm assuming that won't be a possibility either. The link tag is specifically used for metadata about the current document, so using that across the entire document doesn't sound like a good idea to me. Despite the possibility of abuse by authors, it seems to me that it's a fair use-case for including the attribute. Regards, Peter Beverloo [1] https://developer.mozilla.org/En/Link_prefetching_FAQ
Re: [whatwg] Potential Danger with Canvas API in html5 #html5 #canvas
On Wed, Jun 9, 2010 at 20:29, narendra sisodiya naren...@narendrasisodiya.com wrote: Canvas API is just great and I love it, You will also love it , if not, just see Canvas demos - http://www.canvasdemos.com But we have potential danger to misuse it also for the sake of non-standards. prediction Case 1 - Abode can make its flash-player inside canvas API. I know, it will not be 100% compatible. They can create a CanvasAPI based flash player. Their are already 2 client side run time engine in JavaScript - Smokescreen and Gordon - http://twitter.com/jdowdell/statuses/14985295733 , Biggest advantage with JS and client side is that you can see sourcecode. In order to hide the source code , Adobe can use server side. Some processing will be on server side and output will be streamed (in form of image) to client side and renders into CANVAS area with pixel. You can grab event from canvas area and send bacl to server. This way Developer may come up with a Server Side HTML5 toolkit which will reuse BAD standards like flash with Hiding Source code of a Web Application . Adobe or other companies can modify their products and generate server side HTML5 code which will render the application CANVAS API. A huge number of dummy developer use such non-standards tools and with this, they will be able to reuse skills by this and will not adopt a true spirit of HTML5. So, This I do not like,,,-- ''designer/developers will be using non-standard server side code, generated from non-standards ToolKits, and pretend that we also use HTML5 We urgently need HTML5 authoring tool. we urgently needs SVG authoring tools. /prediction I guess, with the advance of html5, Adobe has been working hard to run flash on canvas from server inorder to save its presence. . -- ┌─┐ │ Narendra Sisodiya │ http://narendrasisodiya.com └─┘ Yet another HTML5 Developer. Hello Narandra, Do you have any links or sources backing up that Adobe is working on the server-side? While your scenario certainly is possible, even with today's possibilities, I see a number of problems with it: 1) The number of simultaneous users in any web application will be severely limited by the available processing power of the server. Thinking of the current uses of Flash, a really large part of which are video players and games, it does not seem realistic. Extend this to Flash applications such as FarmVille on Facebook and server-side processing and rendering will be pretty close to impossible. 2) How exactly is this different from normal webpages? A lot of websites use scripting languages as their back end, such as PHP, delivering a certain flexibility which is not directly visible to the user. The same thing can be applied to achieve creating personalized Application Cache Manifests. On top of that, there are various Javascript obfuscators around which convert code to nearly unreadable pieces of text. While code formatting can be normalized using a range of tools, variables like _ and ___ will be continue to be confusing nonetheless. Such obfuscation is enough to stop 99% of the people from getting/copying the code, going through the trouble of continuous connections and server-side processing for that last percent seems unlikely. If any application is that critical, the author should consider limiting access to the application altogether. Regards, Peter
Re: [whatwg] Comment on 6.6 Offline Web Applications
On Thu, Jun 3, 2010 at 15:01, Daniel Glazman daniel.glaz...@disruptive-innovations.com wrote: Hi there, I noticed the Application Cache does not allow to remove a single cached web application from the cache. Is that on purpose? I am under the impression the cache is here more an offline storage for webapps than a normal cache, and that in the long run browsers will have to implement an Offline Web Apps manager. Since the user is supposedly already provided with a dialog asking permission to make a webapp available offline, it makes sense to give him/her a way to remove a single application from the cache. /Daniel Section 6.6.7 talks about expiration of cached data [1], but also includes a few notes about removing items from the store. It specifically states that user-agents could have a delete site-specific data feature which also covers removing application caches, but also hints towards a feature that removes caches on request of the user. The API does not state a way allowing an application to remove itself from the cache, which could be desirable for web authors. If there's interest for such an addition I'm willing to make a proposal, as it isn't hard to think about use-cases for such a feature. Regards, Peter Beverloo [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/offline.html#expiring-application-caches
Re: [whatwg] Problem with http://www.webmproject.org/
On Thu, May 27, 2010 at 17:12, Michael A. Puls II shadow2...@gmail.com wrote: Off topic (but I couldn't find any contact info on the site) Could someone please fix http://www.webmproject.org/? The left side of the page is inaccessible at 1024 x 768 (800 x 600 for example), which makes the site unusable. (It has to be some common css that Google uses on their sites as the same problem happens on Vemo-branded pages on youtube) Thanks -- Michael Hello Michael, You should write a message to the WebM discussion groups as it's listed on the Tools page, and in the latest blog entry. http://groups.google.com/a/webmproject.org/group/webm-discuss/topics Thank you, Peter
Re: [whatwg] forwarded: Google opens VP8 video codec
On Thu, May 20, 2010 at 11:55, David Gerard dger...@gmail.com wrote: 2010/5/20 Peter Beverloo pe...@lvp-media.com: Microsoft has announced playback support for VP8 in Internet Explorer 9[1] under the condition that one has to install a VP8 codec manually, albeit via inclusion in another program: In its HTML5 support, IE9 will support playback of H.264 video as well as VP8 video when the user has installed a VP8 codec on Windows. I think that's fairly significant. I don't. They're trying to make if you install it yourself, it'll work look like they're actually doing anything at all. But they're not, because the same applies already to Vorbis and Theora. If anything, they're just offering not to deliberately stop it from working. - d. Microsoft showing interest in a codec they're not specifically participating in, different from their involvement in H264, is a good start. In their revised comments about HTML 5 video[1] they already stated that they would consider implementing other codecs if the industry reaches a consensus and is confident that the uncertainties are resolved. Their wording in the recent blog-post refers to an industry announcement rather than a Google announcement, which is why I think it's plausible to assume including the codec by default will be, partially, dependent on Apple's stance on it. As Philip already said, right now there simply are a number of uncertainties limiting the discussion to mere speculation. Let's hope more clearity will be available soon. Peter [1] http://blogs.msdn.com/ie/archive/2010/05/03/follow-up-on-html5-video-in-ie9.aspx
