Re: [whatwg] Notifications and service workers
Apologies if I miss some subtleties in the preceding discussion - I've
scanned the thread, but I haven't been following closely.
On Fri, Sep 26, 2014 at 4:36 PM, Peter Beverloo bever...@google.com wrote:
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.
I suspect it's OK to change this, especially since (for Chrome, at least)
most platforms are moving to a model where notifications don't stay on the
screen anyway (they move to a notification center). That said, I've never
really understood the interest in auto-closing notifications, since if a
web page wants to close its notifications, it's trivial to do so in an
onclose handler - I guess the issue might be notifications coming from a
worker, where the worker doesn't get notified that it's going away? Maybe
the right fix is that workers should get a close event also :)
In any case, agreed with Jonas that if we're going to build non-persistent
notifications, then perhaps they should have a fixed time limit (possibly
UA-adjustable) and not be tied explicitly to a source's lifetime.
* 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?
Gmail tracks information internally about all open notifications so it
knows what chat window, email, etc to display when the user clicks on one.
It cleans up those data structures as notifications are closed, so if we
stop generating close events, then gmail will leak even more memory than it
currently does :)
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.
I'm not aware of any particular use cases here. Gmail isn't listening to
show events, AFAICT.
* 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
Re: [whatwg] Notifications and service workers
On Sun, Sep 28, 2014 at 11:15 PM, Andrew Wilson atwil...@google.com wrote: * 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? Gmail tracks information internally about all open notifications so it knows what chat window, email, etc to display when the user clicks on one. It cleans up those data structures as notifications are closed, so if we stop generating close events, then gmail will leak even more memory than it currently does :) Could this be solved by using the 'data' attribute when creating a Notification? / Jonas
Re: [whatwg] Notifications and service workers
Sounds exactly like an use case of the 'data' attribute. 2014-09-29 12:23 GMT+03:00 Jonas Sicking jo...@sicking.cc: On Sun, Sep 28, 2014 at 11:15 PM, Andrew Wilson atwil...@google.com wrote: * 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? Gmail tracks information internally about all open notifications so it knows what chat window, email, etc to display when the user clicks on one. It cleans up those data structures as notifications are closed, so if we stop generating close events, then gmail will leak even more memory than it currently does :) Could this be solved by using the 'data' attribute when creating a Notification? / Jonas
Re: [whatwg] Notifications and service workers
That only works if 'data' is a structured-cloneable data structure. I mean, typically in a full-featured web app, you have a large, complex data structure and you typically want to keep references into that data structure - you can't typically just copy pieces out and expect to perform operations on them. On Mon, Sep 29, 2014 at 11:54 AM, Robert Bîndar robertbin...@gmail.com wrote: Sounds exactly like an use case of the 'data' attribute. 2014-09-29 12:23 GMT+03:00 Jonas Sicking jo...@sicking.cc: On Sun, Sep 28, 2014 at 11:15 PM, Andrew Wilson atwil...@google.com wrote: * 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? Gmail tracks information internally about all open notifications so it knows what chat window, email, etc to display when the user clicks on one. It cleans up those data structures as notifications are closed, so if we stop generating close events, then gmail will leak even more memory than it currently does :) Could this be solved by using the 'data' attribute when creating a Notification? / Jonas
Re: [whatwg] Notifications and service workers
On Mon, Sep 29, 2014 at 3:10 AM, Andrew Wilson atwil...@google.com wrote: That only works if 'data' is a structured-cloneable data structure. Per spec it is yes. / Jonas
Re: [whatwg] Notifications and service workers
I'm sorry, I meant that you can only use the 'data' attribute, if the data you want to associate with the notification is structured-cloneable. Which precludes lots of interesting stuff, like objects with attached methods, memoized functions, etc. I'm aware that 'data' is structured-cloneable - I'm saying that's not sufficient for many uses. -atw On Mon, Sep 29, 2014 at 12:34 PM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Sep 29, 2014 at 3:10 AM, Andrew Wilson atwil...@google.com wrote: That only works if 'data' is a structured-cloneable data structure. Per spec it is yes. / Jonas
Re: [whatwg] Notifications and service workers
On Mon, Sep 29, 2014 at 4:35 AM, Andrew Wilson atwil...@google.com wrote: I'm sorry, I meant that you can only use the 'data' attribute, if the data you want to associate with the notification is structured-cloneable. Which precludes lots of interesting stuff, like objects with attached methods, memoized functions, etc. I'm aware that 'data' is structured-cloneable - I'm saying that's not sufficient for many uses. But if the data that you want to associate with the notification isn't structured clonable, how are you going to make that data survive a page reload? Keep in mind that for persistent notifications, the notification often outlives the page that created the notification. It might help to have some concrete examples of what you're trying to do here. / Jonas
Re: [whatwg] Notifications and service workers
On Mon, Sep 29, 2014 at 4:55 AM, Andrew Wilson atwil...@google.com wrote: On Mon, Sep 29, 2014 at 1:40 PM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Sep 29, 2014 at 4:35 AM, Andrew Wilson atwil...@google.com wrote: I'm sorry, I meant that you can only use the 'data' attribute, if the data you want to associate with the notification is structured-cloneable. Which precludes lots of interesting stuff, like objects with attached methods, memoized functions, etc. I'm aware that 'data' is structured-cloneable - I'm saying that's not sufficient for many uses. But if the data that you want to associate with the notification isn't structured clonable, how are you going to make that data survive a page reload? Keep in mind that for persistent notifications, the notification often outlives the page that created the notification. OK, I get it - we're talking about different models. I'm talking about the current Gmail use case, where I don't want notifications to live forever (in fact, I close them all when you close the main Gmail pane). I understand that for persistent notifications, the uses are different. And again, apologies if I missed the context and the idea was to only remove the close event for persistent notifications - it's the danger of dropping into the middle of a thread :) Hopefully the plan is to continue enabling web properties that want to go the Gmail route to continue doing so, and for those pages, I think a 'close' event is useful. I think we're talking about both. But I wanted to point out that the code flow you were talking about didn't seem to work for persistent notifications. I'd rather keep persistent and non-persistent notifications as similar as possible. Though as possible being key. I.e. I think it's ok for them to be different when that makes sense. I still don't understand the use case you are talking about though. Could you perhaps provide an example of the features that gmail is building and which needs these non-clonable data structures? / Jonas
Re: [whatwg] Notifications and service workers
OK, looked back into the Gmail code (since it'd been a couple of years since I was really down in that notification code). There are two places where we listen for close events currently: 1) When closing an email notification - gmail keeps its own queue of pending notifications (so if several emails arrive at once, we don't display seven notifications simultaneously, but instead we display one at a time, cycling through them after 5-6 seconds). If the user closes a notification, then we clear out our queue of pending notifications, because the expectation is that the user doesn't want any more email notifications (the experience before we did that was really annoying). 2) When closing a chat notification, we tell the chat subsystem that the notification has gone away so that it can clear its reference to the Notification. The chat subsystem keeps a reference to the notification so it can close a chat notification if the user clicks on a chat frame, but this might no longer be necessary if we implement Notification.get(). Anyhow, our reference to the chat subsystem is a reference to an object and that object isn't structured-cloneable because it has a bunch of reference to DOM elements, etc. The other reason we handle the close event is that gmail has this idea of a chat notification that the user hasn't seen yet - the chat frame has a visual highlight. But if the notification is dismissed by the user, we can clear this highlight, under the assumption that the user has seen this notification. This functionality may be somewhat broken on platforms that auto-close notifications though. On Mon, Sep 29, 2014 at 2:15 PM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Sep 29, 2014 at 4:55 AM, Andrew Wilson atwil...@google.com wrote: On Mon, Sep 29, 2014 at 1:40 PM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Sep 29, 2014 at 4:35 AM, Andrew Wilson atwil...@google.com wrote: I'm sorry, I meant that you can only use the 'data' attribute, if the data you want to associate with the notification is structured-cloneable. Which precludes lots of interesting stuff, like objects with attached methods, memoized functions, etc. I'm aware that 'data' is structured-cloneable - I'm saying that's not sufficient for many uses. But if the data that you want to associate with the notification isn't structured clonable, how are you going to make that data survive a page reload? Keep in mind that for persistent notifications, the notification often outlives the page that created the notification. OK, I get it - we're talking about different models. I'm talking about the current Gmail use case, where I don't want notifications to live forever (in fact, I close them all when you close the main Gmail pane). I understand that for persistent notifications, the uses are different. And again, apologies if I missed the context and the idea was to only remove the close event for persistent notifications - it's the danger of dropping into the middle of a thread :) Hopefully the plan is to continue enabling web properties that want to go the Gmail route to continue doing so, and for those pages, I think a 'close' event is useful. I think we're talking about both. But I wanted to point out that the code flow you were talking about didn't seem to work for persistent notifications. I'd rather keep persistent and non-persistent notifications as similar as possible. Though as possible being key. I.e. I think it's ok for them to be different when that makes sense. I still don't understand the use case you are talking about though. Could you perhaps provide an example of the features that gmail is building and which needs these non-clonable data structures? / Jonas
[whatwg] Support filters in Canvas
Hi,
I'd like to revive this discussion.
On Sat, Mar 15, 2014 at 12:03 AM, Dirk Schulze dschu...@adobe.com wrote:
I would suggest a filter attribute that takes a list of filter operations
similar to the CSS Image filter function[1]. Similar to shadows[2], each
drawing operation would be filtered. The API looks like this:
partial interface CanvasRenderingContext2D {
attribute DOMString filter;
}
A filter DOMString could looks like: “contrast(50%) blur(3px)”
This approach sounds good to me, and it's what I've implemented for
Firefox in bug 927892 [1]. The Firefox implementation is behind the
preference canvas.filters.enabled which is currently off by default.
Filter functions include a reference to a filter element and a
specification of SVG filters[4]. I am unsure if a reference do an element
within a document can cause problems. If it does, we would just not support
SVG filter references.
I've included support for SVG filters in the Firefox implementation.
It's a bit of work and it increases the number of edge cases we need
to specify, but I think it's worth it.
Here's a more fleshed-out proposal that attempts to define the edge
cases I've encountered during development.
The ctx.filter property should behave like the ctx.font property in some senses:
- It's part of the state of the context and honors ctx.save() and
ctx.restore().
- Setting an invalid value is ignored silently.
- Both inherit and initial are invalid values, as with font.
- Setting a valid value sets the current state's filter to that
value, and the getter will now return this value, possibly
reserialized.
Question: Do we want the getter to return the serialized form of the
filter? I don't really mind either way, and I'm not sure in what cases
the results would differ. I guess extraneous whitespace between
individual filter functions would be cleaned up, and 0 length values
would get set to 0px. Anything else?
- Resetting the state to no filtering is done using ctx.filter =
none. Values such as , null, or undefined are invalid and will be
ignored and not unset the filter.
Question: Is this what we want?
Filter rendering should work similarly to shadow rendering:
- It happens on every drawing operation, with the input to the filter
being what that operation would have rendered regularly.
- The transform of the context is applied during rendering of the
input. The actual filtering is not be subject to the transform and
happens in device space. This means that e.g. a drop-shadow(0px 10px
black) filter always offsets the shadow towards the bottom, regardless
of the transform.
- The results in the canvas pixel buffer will be the same regardless
of the CSS size of the canvas in the page, and regardless of whether
the canvas element is in the page at all or just a detached DOM node.
- The global composite operation is respected when compositing the
filtered results into the canvas contents. The filter input drawing
operation is always rendered with over into a conceptual transparent
temporary surface.
- The same applies for global alpha.
Interaction with shadow:
- If both a filter and a shadow are set on the canvas, filtering will
happen first, with the shadow being applied to the filtered results.
In that case the global composite operation will be respected when
compositing the result with shadow into the canvas.
- As a consequence of the other statements, this is true: If a valid
filter is used, appending drop-shadow(shadowOffsetXpx
shadowOffsetYpx shadowBlurpx shadowColor) to the filter will
have the same results as using the shadow properties, even if there is
a transform on the context.
Units:
- The CSS px unit refers to one canvas pixel, independent of the CSS
size of the canvas on the page. That is, a drop-shadow(0 10px black)
filter will have the same results in the canvas-internal pixel buffer,
regardless of whether that canvas is specified using canvas
width=100 height=100 style=width: 100px; height: 100px; or
canvas width=100 height=100 style=width: 20px; height: 20px;.
- Lengths in non-px units refer to the number of canvas pixels you
get if you convert the length to CSS px and interpret that number as
canvas pixels.
Font size relative units:
- Lengths in em are relative to the font size of the canvas context
as specified by ctx.font.
- The same applies for lengths in ex; and those use the x-height of
the font that's specified in ctx.font.
SVG filter specific considerations:
- Relative URLs in SVG filter reference url() functions are relative
to the canvas element (i.e. the base URL of the owner document of the
canvas element (?)).
- The user space for SVG filtering is (0, 0, canvas.width,
canvas.height), with one user space unit equal to one canvas pixel
(equal to one CSS pixel).
- The bounding box of the filtered element is also (0, 0,
canvas.width, canvas.height) and independent of what the filtered
drawing operation renders.
- Filter regions and subregions are respected as usual.
-
Re: [whatwg] Support filters in Canvas
Hi Markus,
Thanks for coming back with you implementation details. I think most of the
suggestions make sense overall but I’ll look at them in more detail, especially
regarding filter regions. Just a question to SVG filter references inline for
now.
On Sep 29, 2014, at 7:20 PM, Markus Stange msta...@themasta.com wrote:
Hi,
I'd like to revive this discussion.
On Sat, Mar 15, 2014 at 12:03 AM, Dirk Schulze dschu...@adobe.com wrote:
I would suggest a filter attribute that takes a list of filter operations
similar to the CSS Image filter function[1]. Similar to shadows[2], each
drawing operation would be filtered. The API looks like this:
partial interface CanvasRenderingContext2D {
attribute DOMString filter;
}
A filter DOMString could looks like: “contrast(50%) blur(3px)”
This approach sounds good to me, and it's what I've implemented for
Firefox in bug 927892 [1]. The Firefox implementation is behind the
preference canvas.filters.enabled which is currently off by default.
Filter functions include a reference to a filter element and a
specification of SVG filters[4]. I am unsure if a reference do an element
within a document can cause problems. If it does, we would just not support
SVG filter references.
I've included support for SVG filters in the Firefox implementation.
It's a bit of work and it increases the number of edge cases we need
to specify, but I think it's worth it.
Here's a more fleshed-out proposal that attempts to define the edge
cases I've encountered during development.
The ctx.filter property should behave like the ctx.font property in some
senses:
- It's part of the state of the context and honors ctx.save() and
ctx.restore().
- Setting an invalid value is ignored silently.
- Both inherit and initial are invalid values, as with font.
- Setting a valid value sets the current state's filter to that
value, and the getter will now return this value, possibly
reserialized.
Question: Do we want the getter to return the serialized form of the
filter? I don't really mind either way, and I'm not sure in what cases
the results would differ. I guess extraneous whitespace between
individual filter functions would be cleaned up, and 0 length values
would get set to 0px. Anything else?
- Resetting the state to no filtering is done using ctx.filter =
none. Values such as , null, or undefined are invalid and will be
ignored and not unset the filter.
Question: Is this what we want?
Filter rendering should work similarly to shadow rendering:
- It happens on every drawing operation, with the input to the filter
being what that operation would have rendered regularly.
- The transform of the context is applied during rendering of the
input. The actual filtering is not be subject to the transform and
happens in device space. This means that e.g. a drop-shadow(0px 10px
black) filter always offsets the shadow towards the bottom, regardless
of the transform.
- The results in the canvas pixel buffer will be the same regardless
of the CSS size of the canvas in the page, and regardless of whether
the canvas element is in the page at all or just a detached DOM node.
- The global composite operation is respected when compositing the
filtered results into the canvas contents. The filter input drawing
operation is always rendered with over into a conceptual transparent
temporary surface.
- The same applies for global alpha.
Interaction with shadow:
- If both a filter and a shadow are set on the canvas, filtering will
happen first, with the shadow being applied to the filtered results.
In that case the global composite operation will be respected when
compositing the result with shadow into the canvas.
- As a consequence of the other statements, this is true: If a valid
filter is used, appending drop-shadow(shadowOffsetXpx
shadowOffsetYpx shadowBlurpx shadowColor) to the filter will
have the same results as using the shadow properties, even if there is
a transform on the context.
Units:
- The CSS px unit refers to one canvas pixel, independent of the CSS
size of the canvas on the page. That is, a drop-shadow(0 10px black)
filter will have the same results in the canvas-internal pixel buffer,
regardless of whether that canvas is specified using canvas
width=100 height=100 style=width: 100px; height: 100px; or
canvas width=100 height=100 style=width: 20px; height: 20px;.
- Lengths in non-px units refer to the number of canvas pixels you
get if you convert the length to CSS px and interpret that number as
canvas pixels.
Font size relative units:
- Lengths in em are relative to the font size of the canvas context
as specified by ctx.font.
- The same applies for lengths in ex; and those use the x-height of
the font that's specified in ctx.font.
SVG filter specific considerations:
- Relative URLs in SVG filter reference url() functions are relative
to the canvas element (i.e. the base URL of the owner
Re: [whatwg] Support filters in Canvas
On Mon, Sep 29, 2014 at 10:20 AM, Markus Stange msta...@themasta.com
wrote:
Hi,
I'd like to revive this discussion.
On Sat, Mar 15, 2014 at 12:03 AM, Dirk Schulze dschu...@adobe.com wrote:
I would suggest a filter attribute that takes a list of filter operations
similar to the CSS Image filter function[1]. Similar to shadows[2], each
drawing operation would be filtered. The API looks like this:
partial interface CanvasRenderingContext2D {
attribute DOMString filter;
}
A filter DOMString could looks like: “contrast(50%) blur(3px)”
This approach sounds good to me, and it's what I've implemented for
Firefox in bug 927892 [1]. The Firefox implementation is behind the
preference canvas.filters.enabled which is currently off by default.
Filter functions include a reference to a filter element and a
specification of SVG filters[4]. I am unsure if a reference do an element
within a document can cause problems. If it does, we would just not
support
SVG filter references.
I've included support for SVG filters in the Firefox implementation.
It's a bit of work and it increases the number of edge cases we need
to specify, but I think it's worth it.
Can we limit it to just the set of CSS filter shorthands for now?
I think other UA's are further behind in their implementation of
integrating SVG filters in their rendering pipeline.
Here's a more fleshed-out proposal that attempts to define the edge
cases I've encountered during development.
The ctx.filter property should behave like the ctx.font property in some
senses:
- It's part of the state of the context and honors ctx.save() and
ctx.restore().
- Setting an invalid value is ignored silently.
- Both inherit and initial are invalid values, as with font.
- Setting a valid value sets the current state's filter to that
value, and the getter will now return this value, possibly
reserialized.
Question: Do we want the getter to return the serialized form of the
filter?
Since it's an attribute, it would be strange if it returns a different
string. It should return the same value that it was set to.
I don't really mind either way, and I'm not sure in what cases
the results would differ. I guess extraneous whitespace between
individual filter functions would be cleaned up, and 0 length values
would get set to 0px. Anything else?
- Resetting the state to no filtering is done using ctx.filter =
none. Values such as , null, or undefined are invalid and will be
ignored and not unset the filter.
Question: Is this what we want?
Filter rendering should work similarly to shadow rendering:
- It happens on every drawing operation, with the input to the filter
being what that operation would have rendered regularly.
- The transform of the context is applied during rendering of the
input. The actual filtering is not be subject to the transform and
happens in device space. This means that e.g. a drop-shadow(0px 10px
black) filter always offsets the shadow towards the bottom, regardless
of the transform.
- The results in the canvas pixel buffer will be the same regardless
of the CSS size of the canvas in the page, and regardless of whether
the canvas element is in the page at all or just a detached DOM node.
- The global composite operation is respected when compositing the
filtered results into the canvas contents. The filter input drawing
operation is always rendered with over into a conceptual transparent
temporary surface.
- The same applies for global alpha.
Interaction with shadow:
- If both a filter and a shadow are set on the canvas, filtering will
happen first, with the shadow being applied to the filtered results.
In that case the global composite operation will be respected when
compositing the result with shadow into the canvas.
- As a consequence of the other statements, this is true: If a valid
filter is used, appending drop-shadow(shadowOffsetXpx
shadowOffsetYpx shadowBlurpx shadowColor) to the filter will
have the same results as using the shadow properties, even if there is
a transform on the context.
Since you can do a shadow with the filter attribute, maybe we can specify
that the shadow attribute is ignored?
Units:
- The CSS px unit refers to one canvas pixel, independent of the CSS
size of the canvas on the page. That is, a drop-shadow(0 10px black)
filter will have the same results in the canvas-internal pixel buffer,
regardless of whether that canvas is specified using canvas
width=100 height=100 style=width: 100px; height: 100px; or
canvas width=100 height=100 style=width: 20px; height: 20px;.
- Lengths in non-px units refer to the number of canvas pixels you
get if you convert the length to CSS px and interpret that number as
canvas pixels.
Font size relative units:
- Lengths in em are relative to the font size of the canvas context
as specified by ctx.font.
- The same applies for lengths in ex; and those use the x-height of
Re: [whatwg] Notifications and service workers
On Mon, Sep 29, 2014 at 6:09 AM, Andrew Wilson atwil...@google.com wrote: OK, looked back into the Gmail code (since it'd been a couple of years since I was really down in that notification code). There are two places where we listen for close events currently: 1) When closing an email notification - gmail keeps its own queue of pending notifications (so if several emails arrive at once, we don't display seven notifications simultaneously, but instead we display one at a time, cycling through them after 5-6 seconds). If the user closes a notification, then we clear out our queue of pending notifications, because the expectation is that the user doesn't want any more email notifications (the experience before we did that was really annoying). Ah, so the fact that the user close one notification is seen as an indicator that the user doesn't want more notifications right now. This definitely seems like the best use case for the close event so far. Though it doesn't seem like you'd actually want a service worker, or indeed the full app, to be started up in order to handle that event. For an app that wants to do something like this, but the app uses persistent notifications, I think using Notification.get() is the best solution. This way the application can catch closing of notifications whenever they happen, but the app still doesn't need to be woken up if it's not running when a notification is closed. For an app that uses non-persistent notifications, such as gmail, I think we have two options. Either use Notification.get() here too. Or we allow close events to be fired for non-persistent notifications. 2) When closing a chat notification, we tell the chat subsystem that the notification has gone away so that it can clear its reference to the Notification. The chat subsystem keeps a reference to the notification so it can close a chat notification if the user clicks on a chat frame, but this might no longer be necessary if we implement Notification.get(). Anyhow, our reference to the chat subsystem is a reference to an object and that object isn't structured-cloneable because it has a bunch of reference to DOM elements, etc. Interesting. Yeah, Notification.get() seems like it would help you solve this. Though potentially the API should also have a function like Notification.close(DOMString tag). Seems like a common use case of wanting to close a notification when the user engages with a piece of UI, and it seems silly to have to instantiate a Notification instance through .get() to do so. The other reason we handle the close event is that gmail has this idea of a chat notification that the user hasn't seen yet - the chat frame has a visual highlight. But if the notification is dismissed by the user, we can clear this highlight, under the assumption that the user has seen this notification. This functionality may be somewhat broken on platforms that auto-close notifications though. Yeah, this is the case that Jake brought up. Though Tab pointed out that other chat systems generally does not treat close as an hint for user has read. Interesting to hear that gmail does. On what platforms do non-persistent notifications not close after a timeout? / Jonas
Re: [whatwg] Notifications and service workers
On Mon, Sep 29, 2014 at 4:35 AM, Andrew Wilson atwil...@google.com wrote: I'm sorry, I meant that you can only use the 'data' attribute, if the data you want to associate with the notification is structured-cloneable. Which precludes lots of interesting stuff, like objects with attached methods, memoized functions, etc. I'm aware that 'data' is structured-cloneable - I'm saying that's not sufficient for many uses. Based on your emails later in this thread, it sounds like gmail might not be relying on being able to associate non-structured-clonable data with non-persistent Notifications. However I realized this morning that this actually is doable. You can simply set expando properties, or use a WeakMap, to associate arbitrary data with a Notification object instance. So in case it's needed, or just beneficial, this is actually doable. / Jonas
Re: [whatwg] Notifications and service workers
On Mon, Sep 29, 2014 at 12:14 PM, Jonas Sicking jo...@sicking.cc wrote: For an app that uses non-persistent notifications, such as gmail, I think we have two options. Either use Notification.get() here too. Or we allow close events to be fired for non-persistent notifications. Actually, I just realized that perhaps neither of these would work. We've elsewhere in this thread talked about restricting Notification.get() to only return persistent notifications. And I think that on at least some platforms, possibly even most, non-persistent notifications are closed after a timeout. So the close event wouldn't indicate any user intent there. / Jonas
Re: [whatwg] Support filters in Canvas
On Mon, Sep 29, 2014 at 8:09 PM, Dirk Schulze dschu...@adobe.com wrote: On Sep 29, 2014, at 7:20 PM, Markus Stange msta...@themasta.com wrote: - For a feImage primitive, if the required image hasn't finished loading at the time of drawing, this feImage primitive renders transparent black. I think there is more than the asynch consideration. CSS does not have setting for cross origin content. While it is planned, it simply isn’t there yet. That means SVG filters can be loaded from pretty much any origin. I wonder if this should taint the canvas. Have you though about this? Good point! I hadn't thought about this. I don't see much point in disallowing the use of cross-origin filters (who would put sensitive data inside a filter?), but it certainly would be bad if one could paint images from a different domain into the canvas using feImage and then read the pixels. So cross-domain feImage loads should certainly taint the canvas. Markus
Re: [whatwg] Support filters in Canvas
On Mon, Sep 29, 2014 at 8:12 PM, Rik Cabanier caban...@gmail.com wrote:
On Mon, Sep 29, 2014 at 10:20 AM, Markus Stange msta...@themasta.com
wrote:
Hi,
I'd like to revive this discussion.
On Sat, Mar 15, 2014 at 12:03 AM, Dirk Schulze dschu...@adobe.com wrote:
I would suggest a filter attribute that takes a list of filter
operations
similar to the CSS Image filter function[1]. Similar to shadows[2], each
drawing operation would be filtered. The API looks like this:
partial interface CanvasRenderingContext2D {
attribute DOMString filter;
}
A filter DOMString could looks like: “contrast(50%) blur(3px)”
This approach sounds good to me, and it's what I've implemented for
Firefox in bug 927892 [1]. The Firefox implementation is behind the
preference canvas.filters.enabled which is currently off by default.
Filter functions include a reference to a filter element and a
specification of SVG filters[4]. I am unsure if a reference do an
element
within a document can cause problems. If it does, we would just not
support
SVG filter references.
I've included support for SVG filters in the Firefox implementation.
It's a bit of work and it increases the number of edge cases we need
to specify, but I think it's worth it.
Can we limit it to just the set of CSS filter shorthands for now?
I think other UA's are further behind in their implementation of integrating
SVG filters in their rendering pipeline.
Sure. In Firefox I can put CSS and SVG filters for canvas behind
different prefs so that we can enable the CSS part without exposing
the SVG part.
Here's a more fleshed-out proposal that attempts to define the edge
cases I've encountered during development.
The ctx.filter property should behave like the ctx.font property in some
senses:
- It's part of the state of the context and honors ctx.save() and
ctx.restore().
- Setting an invalid value is ignored silently.
- Both inherit and initial are invalid values, as with font.
- Setting a valid value sets the current state's filter to that
value, and the getter will now return this value, possibly
reserialized.
Question: Do we want the getter to return the serialized form of the
filter?
Since it's an attribute, it would be strange if it returns a different
string. It should return the same value that it was set to.
I agree, returning the exact value that was assigned would be less
surprising. I brought this up because the font attribute does
something like this: Its getter returns a serialized value that
doesn't contain the line-height part, and also leaves out some
subproperty values that have default values.
Interaction with shadow:
- If both a filter and a shadow are set on the canvas, filtering will
happen first, with the shadow being applied to the filtered results.
In that case the global composite operation will be respected when
compositing the result with shadow into the canvas.
- As a consequence of the other statements, this is true: If a valid
filter is used, appending drop-shadow(shadowOffsetXpx
shadowOffsetYpx shadowBlurpx shadowColor) to the filter will
have the same results as using the shadow properties, even if there is
a transform on the context.
Since you can do a shadow with the filter attribute, maybe we can specify
that the shadow attribute is ignored?
Hmm, we could do that but I don't really see the benefits. I think
it's more surprising to users when shadows stop working as soon as
they set a filter than if they just keep working.
Markus
Re: [whatwg] Support filters in Canvas
On Mon, Sep 29, 2014 at 2:12 PM, Rik Cabanier caban...@gmail.com wrote: Can we limit it to just the set of CSS filter shorthands for now? I think other UA's are further behind in their implementation of integrating SVG filters in their rendering pipeline. How about we put CSS + SVG filters into the one spec draft for now, and split them up into two drafts if we actually get to the point where vendors want to ship one and not the other? It seems premature to create both HTML Canvas Filters Level 1 and HTML Canvas Filters Level 2 at the same time. Rob -- oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo owohooo osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o oioso oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo owohooo osoaoyoso,o o‘oYooouo ofolo!o’o owoiololo oboeo oiono odoaonogoeoro ooofo otohoeo ofoioroeo ooofo ohoeololo.
Re: [whatwg] Support filters in Canvas
On Mon, Sep 29, 2014 at 8:52 PM, Robert O'Callahan rob...@ocallahan.org wrote: On Mon, Sep 29, 2014 at 2:12 PM, Rik Cabanier caban...@gmail.com wrote: Can we limit it to just the set of CSS filter shorthands for now? I think other UA's are further behind in their implementation of integrating SVG filters in their rendering pipeline. How about we put CSS + SVG filters into the one spec draft for now, and split them up into two drafts if we actually get to the point where vendors want to ship one and not the other? It seems premature to create both HTML Canvas Filters Level 1 and HTML Canvas Filters Level 2 at the same time. Are you proposing that this is developed as a separate spec and not as an addition to the canvas specification?
