Re: [whatwg] WebGL and ImageBitmaps
On Fri, May 9, 2014 at 2:58 PM, Ian Hickson i...@hixie.ch wrote: On Fri, 9 May 2014, Ian Hickson wrote: On Thu, 18 Jul 2013, Justin Novosad wrote: To help us iterate further, I've attempted to capture the essence of this thread on the whatwg wiki, using the problem solving template. I tried to capture the main ideas that we seem to agree on so far and I started to think about how to handle special cases. http://wiki.whatwg.org/wiki/ImageBitmap_Options Are the strongly desired options in the above wiki page still the options we should be adding? On the assumption that they are, I filed some bugs to cover this: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25642 createImageBitmap() options: image data orientation https://www.w3.org/Bugs/Public/show_bug.cgi?id=25643 createImageBitmap() options: color space handling https://www.w3.org/Bugs/Public/show_bug.cgi?id=25644 createImageBitmap() options: alpha channel handling As usual with such bugs, if there is interest amongst browser vendors in implementing any of these, please comment on the bug. For the record, I've commented on the above bugs. I'd personally like to see them all specified and implemented so that image loading for the purpose of uploading to WebGL textures can be more efficient. -Ken
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
Re: [whatwg] Move contentEditable/isContentEditable from HTMLElement to Element?
On Tue, May 13, 2014 at 11:21 AM, Ian Hickson i...@hixie.ch wrote: On Tue, 13 May 2014, Dirk Schulze wrote: contentEditable can be fairly useful in SVG as well. It partly works for inline SVG content in web browsers today. The question is, should SVGElement add support for contentEditable/isContentEditable and add it to its interface? Or should both attributes move to the Element interface instead? I would be very careful about moving global attributes to Element. Doing so implies that we are adding them to _all_ XML namespaces. That's a huge change to propose. Even with class it's IMHO going a bit far (we're saying that the semantics of myvocab:teacher class=.../ are that it's a space-separate list of CSS class names, even if the vocab designer intended it to be a room name or whatever). @class is a strange thing to make applicable to all random elements in all namespaces. Even so, in WebKit and Blink we do actually support it on Element which means that's already the case. I would feel more comfortable putting things on SVG, MathML, and HTML explicitly. I don't think we want contenteditable in SVG or MathML. Almost all of the operations don't make sense. What does intending in SVG do? What does making something italic? What happens when you hit enter? We can't just insert a new line in SVG, does it add some space between all the shapes? Where does your caret actually appear? We might want some new kind of Web Editing API, but contenteditable/execCommand are both pretty specific to HTML. - E
Re: [whatwg] WebGL and ImageBitmaps
On Wed, 14 May 2014, Kenneth Russell wrote: On the assumption that they are, I filed some bugs to cover this: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25642 createImageBitmap() options: image data orientation https://www.w3.org/Bugs/Public/show_bug.cgi?id=25643 createImageBitmap() options: color space handling https://www.w3.org/Bugs/Public/show_bug.cgi?id=25644 createImageBitmap() options: alpha channel handling As usual with such bugs, if there is interest amongst browser vendors in implementing any of these, please comment on the bug. For the record, I've commented on the above bugs. I'd personally like to see them all specified and implemented so that image loading for the purpose of uploading to WebGL textures can be more efficient. I see that your comment was that the WebGL WG would like them specified. Does your saying that mean that Chrome wants to implement these also? Just having a working group want them specified doesn't help get us to multiple implementations... -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] WebGL and ImageBitmaps
On Thu, May 15, 2014 at 10:59 AM, Ian Hickson i...@hixie.ch wrote: On Wed, 14 May 2014, Kenneth Russell wrote: On the assumption that they are, I filed some bugs to cover this: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25642 createImageBitmap() options: image data orientation https://www.w3.org/Bugs/Public/show_bug.cgi?id=25643 createImageBitmap() options: color space handling https://www.w3.org/Bugs/Public/show_bug.cgi?id=25644 createImageBitmap() options: alpha channel handling As usual with such bugs, if there is interest amongst browser vendors in implementing any of these, please comment on the bug. For the record, I've commented on the above bugs. I'd personally like to see them all specified and implemented so that image loading for the purpose of uploading to WebGL textures can be more efficient. I see that your comment was that the WebGL WG would like them specified. Does your saying that mean that Chrome wants to implement these also? Just having a working group want them specified doesn't help get us to multiple implementations... To clarify the Chrome team's desire to implement these I added another comment to each bug, and pointed to the relevant portion of the WebGL spec in response to the latest comment on https://www.w3.org/Bugs/Public/show_bug.cgi?id=25644 . -Ken
Re: [whatwg] @autocomplete sections
- Original Message - On Wed, May 14, 2014 at 6:59 PM, Matthew Noorenberghe mattn+wha...@mozilla.com wrote: IMO it makes sense to ignore section-* tokens for rAc for now. I don't think we need to add home, work, and other such tokens at this time. At least, I haven't heard any concrete demand for them. It likely makes sense to remove section-* tokens from the spec entirely. I'm not sure how much they're used, but I would guess almost not at all. It would be nice to have some concrete numbers; but unfortunately, I'm not aware of any metrics tracking the usage of section-* tokens. OK, I filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=25735 to remove it. If others disagree, please comment.
