Re: [whatwg] Proposal: Wake Lock API
On Wed, Aug 13, 2014 at 9:46 PM, Biju bijumaill...@gmail.com wrote: On 13 August 2014 21:00, Jonas Sicking jo...@sicking.cc wrote: An alternative design would be something like x = new WakeLock(display); x.request(); x.release(); Extra calls of either request() or release() are ignored, but pages can create any number of WakeLocks of the same type. If application made a x.request() then x got garbage collected system should automatically do x.release(); No. We don't want authors to come to rely on GC to have their locks released. That would cause very erratic behavior where sometimes the lock would be held for 2 seconds after the last reference to 'x' was removed, and sometimes the lock would be held for 30 minutes past that point. In other words, it would make GC observable. Not always observable by the page, but by the user which can be just as bad. / Jonas
Re: [whatwg] Proposal: Wake Lock API
On 14 August 2014 03:07, Jonas Sicking jo...@sicking.cc wrote:
On Wed, Aug 13, 2014 at 9:46 PM, Biju bijumaill...@gmail.com wrote:
On 13 August 2014 21:00, Jonas Sicking jo...@sicking.cc wrote:
An alternative design would be something like
x = new WakeLock(display);
x.request();
x.release();
Extra calls of either request() or release() are ignored, but pages
can create any number of WakeLocks of the same type.
If application made a x.request() then x got garbage collected
system should automatically do x.release();
No. We don't want authors to come to rely on GC to have their locks
released. That would cause very erratic behavior where sometimes the
lock would be held for 2 seconds after the last reference to 'x' was
removed, and sometimes the lock would be held for 30 minutes past that
point.
In other words, it would make GC observable. Not always observable by
the page, but by the user which can be just as bad.
/ Jonas
So what happens when we have following function call.
How do we release the runaway lock request.
Another case is a page made lock and user navigate away from the page.
Do the browser keep the lock for ever ?
function xyz(){
do_something_1();
x = new WakeLock(display);
x.request();
do_something_2();
throw some runtime error occurred;
do_something_3();
x.release();
do_something_4();
}
Re: [whatwg] How to determine content-type of file: protocol
duanyao duan...@ustc.edu writes: On 07/28/2014 22:08, Gordon P. Hemsley wrote: On 07/28/2014 08:01 AM, duanyao wrote: On 07/28/2014 06:34, Gordon P. Hemsley wrote: Sorry for the delay in responding. Your message fell through the cracks in my e-mail filters. On 07/17/2014 08:26 AM, duanyao wrote: Hi, My first question is about a rule in MIME Sniffing specification (http://mimesniff.spec.whatwg.org): 5.1 Interpreting the resource metadata ... If the resource is retrieved directly from the file system, set supplied-type to the MIME type provided by the file system. As far as I know, no main-stream file systems record MIME type for files. Does the spec actually want to say provided by the operating system or provided by the file name extension? Yeah, you've hit a known (though apparently unrecorded) bug in the spec, originally pointed out to me by Boris Zbarsky via IRC many months ago. The intent here is basically just whatever the computer says it is—whether that be via the file system, the operating system, or whatever, and whether it uses magic bytes, file extensions, or whatever. In other words, feel free to read that as the correct behavior is undefined/unknown at this point. Thanks for the explanation. Recently, file: protocol becomes more and more important due to the popularity of packaged web applications, including PhoneGap app, Chrome app, Firefox OS app, Window 8 HTML app, etc (not all of them use file: protocol directly, but underlying mechanisms are similar). So If we can't specify a interoperable way to determine a local file's mime type, porting of packaged web applications can be problematic in some situations (actually my team already hit this). I know that currently there is no standard way to determine a local file's mime type, this may be one of the reason that mimesniff spec has not defined a behavior here. Well, the most basic reason is because I never delved into how it actually works, because I was primarily concerned with HTTP connections. It's possible that there is no interoperable way to determine a local file's MIME type, but see below. I'd like to propose a simple way to resolve this problem: For mime types that has already been standardized by IANA and used in web standards, determine a local file's supplied-type according to its file extension. This list could include htm, html, xhtml, xml, svg, css, js, ipeg, ipg, png, mp4, webm, woff, etc. Otherwise, UAs can determine supplied-type by any means. I think this rule should resolve most of the interoperability problems, and largely maintain compatibility with current UAs' implementations. There is already a standard in place to detect file types on the operating system level: http://www.freedesktop.org/wiki/Specifications/shared-mime-info-spec/ http://cgit.freedesktop.org/xdg/shared-mime-info/ I could just refer to that and be done with it. Do you think that would work? (That specification has complex rules for detecting files, including magic bytes and whatnot, and is already used on a number of Linux distros and probably other operating systems.) Maybe no. (1) it's a standard of *nix desktops, I doubt MS widows will adopt it, I see this as pure speculation. and maybe it's a bit heavy for mobile OS; Widely used mobile operating systems are based on Unix (e.g. iOS, Android). Based on your measurements, how long does file(1) take? (2) many packaged web apps are ported from (and share codes with) normal web apps, and most web servers simply deduce mime type from file extension, so doing the same thing in UAs probably results in better compatibility. It may not be possible to deduce the media type from the file extension alone, since there can be parameters to the media type like “charset” or “codecs”, e.g. “text/html; charset=UTF-8” or “audio/ogg; codecs=vorbis”. (3) UAs are already required to do mime type sniffing, which should be enough to correct most wrong supplied-type. Is this interoperable enough yet for the purpose at hand? -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] Proposal: Wake Lock API
Jonas Sicking jo...@sicking.cc writes: On Thu, Jul 17, 2014 at 7:17 AM, Marcos Caceres w...@marcosc.com wrote: On Thursday, July 17, 2014 at 6:12 AM, Mounir Lamouri wrote: On Thu, 17 Jul 2014, at 01:56, Marcos Caceres wrote: I don't have a strong opinion. My concern was mostly about developers having to watch for a whole bunch of different interaction queues (touch events, mouse events, focus events, orientation-change events, etc.) in order to release the lock at the right time. Do you have specific UC? The basic UC I have in mind (reading a book, watching a video, playing a game) would not use a timeout. Yes, Google Play Books will wait five minutes from the last interaction to turn off the screen. This is nice if you fall a sleep while reading and long enough for a user to read a page without having the screen dim. See: http://w3c-webmob.github.io/wake-lock-use-cases/#google-play-books I was trying to model that problem with the API. Question remains if there are other kinds of locks that we might need. For example, Firefox OS has wifi as a lock type. I'm assuming that their model keeps the cpu on, but the device can still shut down the radios on a device. In the proposal, we lump wifi and cpu into system. Why not breaking these in different sub-systems? I can definitely imagine my phone having the CPU kept at 100% while the screen is off if it requires to do a heavy computation. Forcing the screen to stay on while doing that would be a waste of battery. Sorry, I was trying to say exactly what you said above. No need to keep the screen on when using system, obviously. Ideally, we could do something like: display = keep display on + system/cpu + network network (wifi/cell) = system/cpu + network (screen off) system = just cpu, turn off screen and radio. Hopefully, something like that means you don't need to pick an choose amongst numerous options. I think the locks are fairly orthogonal. Holding the display lock just prevents the normal turn off device because user hasn't interacted with it for X minutes timer from firing. I.e. while the display lock is held, the screen won't automatically time out and put the device to sleep. However if the user presses the power button the screen would still turn off and the device would still go to sleep. Holding the system lock however wouldn't prevent the screen from turning off. But it would prevent the CPU from going to sleep even if the screen times out or if the user presses the power button. So what would happen if I want my laptop to go to into low-power mode by closing the lid? Would I have to close a lot of risky web pages first? Holding both display and system means that the screen won't time out. If the user presses the power button the screen would turn off but the CPU would still not be put to sleep. Such a CPU lock function looks to me like they can be easily abused, without users necessarily finding out why their battery is drained or their handset is becoming warm – while having no recourse except for not using the offending web page (but note that web pages deemed important by users can get away with all kinds of abusive stuff, like displaying advertising and therefore using up bandwith and battery). So I think it makes sense to expose an array of which locks the page holds since all combinations of the system and display locks yield different behavior. I am however more worried about that only having a request() and a release() function means that pages that contain multiple independent subsystems will have to make sure that they don't stomp on each other's locks. Simply counting request() calls vs. release() calls helps, but doesn't fully solve the problem. It's very easy to accidentally call release too many times, in response to some UI action for example. An alternative design would be something like x = new WakeLock(display); x.request(); x.release(); Extra calls of either request() or release() are ignored, but pages can create any number of WakeLocks of the same type. Regarding timeouts, the use case that I've come across many times is pages that contain a lot of text, or some form of puzzle. In those cases you don't want to completely disable the screen timeout. But you might want to set it to some larger large value, say 15 minutes. I believe this is something that can be entirely done by the device already, for example using motion or proximity detection built in. It's somewhat hard to work around the lack of a timeout. What you could do is to release the lock after 15 minutes, but then that means that the normal screen timer kicks in, which adds an unknown number of minutes of the screen being on. If you instead were able to create a display lock with a 15 minute timeout, the platform could use the longest value of 15 minutes and the platform screen timeout. And note that you in normal use cases *do* want the normal
Re: [whatwg] Fetch Objects and scripts/stylesheets
Ben Maurer ben.mau...@gmail.com writes: Another concrete example with img tags: sometimes an abusive user will use a site like Facebook as a CDN -- they'll upload a picture and hotlink it from elsewhere. We could insert a time-stamped authentication token as a custom header. Today we sometimes do this via the query string -- giving the user a token that lasts for a few days. This means we bust the user's cache every time we rotate the token. With a custom header, the browser cache stays in tact. Why not just check the referer or origin header and act on that? Images would also be a great example of where logging headers could be extremely helpful. For example, we could log what module within a page rendered an image and monitor bandwidth usage and CDN cache hit rate on a per module basis. In the past it's taken us a long time to debug issues that could easily be found with this method. This means more analytics and logging – privacy intrusions justified by the sheer complexity of systems created by several thousand monkeys on thousands of electronic typewriters. Incidentally, more fingerprinting. I do not see any immediate benefit to the user here. -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] Proposal: Wake Lock API
Hi
Would it make sense to tie the system lock to a notification?
For example:
new Notification(Processing..., {tag: abc, progressBar: 0.8,
wakeLock: system});
There are many myths and rumors about how to conserve battery on mobile
devices. A small improvement could be to require apps to show some kind
of UI whenever they are allowed to consume resources in the background.
-
Jesper Kristensen
Den 14-08-2014 kl. 03:00 skrev Jonas Sicking:
On Thu, Jul 17, 2014 at 7:17 AM, Marcos Caceres w...@marcosc.com wrote:
On Thursday, July 17, 2014 at 6:12 AM, Mounir Lamouri wrote:
On Thu, 17 Jul 2014, at 01:56, Marcos Caceres wrote:
I don't have a strong opinion. My concern was mostly about developers
having to watch for a whole bunch of different interaction queues (touch
events, mouse events, focus events, orientation-change events, etc.) in
order to release the lock at the right time.
Do you have specific UC? The basic UC I have in mind (reading a book,
watching a video, playing a game) would not use a timeout.
Yes, Google Play Books will wait five minutes from the last interaction to turn
off the screen. This is nice if you fall a sleep while reading and long enough
for a user to read a page without having the screen dim.
See:
http://w3c-webmob.github.io/wake-lock-use-cases/#google-play-books
I was trying to model that problem with the API.
Question remains if there are other kinds of locks that we might need.
For example, Firefox OS has wifi as a lock type. I'm assuming that
their model keeps the cpu on, but the device can still shut down the
radios on a device. In the proposal, we lump wifi and cpu into
system.
Why not breaking these in different sub-systems? I can definitely
imagine my phone having the CPU kept at 100% while the screen is off if
it requires to do a heavy computation. Forcing the screen to stay on
while doing that would be a waste of battery.
Sorry, I was trying to say exactly what you said above. No need to keep the screen on
when using system, obviously.
Ideally, we could do something like:
display = keep display on + system/cpu + network
network (wifi/cell) = system/cpu + network (screen off)
system = just cpu, turn off screen and radio.
Hopefully, something like that means you don't need to pick an choose amongst
numerous options.
I think the locks are fairly orthogonal.
Holding the display lock just prevents the normal turn off device
because user hasn't interacted with it for X minutes timer from
firing. I.e. while the display lock is held, the screen won't
automatically time out and put the device to sleep.
However if the user presses the power button the screen would still
turn off and the device would still go to sleep.
Holding the system lock however wouldn't prevent the screen from
turning off. But it would prevent the CPU from going to sleep even if
the screen times out or if the user presses the power button.
Holding both display and system means that the screen won't time
out. If the user presses the power button the screen would turn off
but the CPU would still not be put to sleep.
So I think it makes sense to expose an array of which locks the page
holds since all combinations of the system and display locks yield
different behavior.
I am however more worried about that only having a request() and a
release() function means that pages that contain multiple independent
subsystems will have to make sure that they don't stomp on each
other's locks. Simply counting request() calls vs. release() calls
helps, but doesn't fully solve the problem. It's very easy to
accidentally call release too many times, in response to some UI
action for example.
An alternative design would be something like
x = new WakeLock(display);
x.request();
x.release();
Extra calls of either request() or release() are ignored, but pages
can create any number of WakeLocks of the same type.
Regarding timeouts, the use case that I've come across many times is
pages that contain a lot of text, or some form of puzzle. In those
cases you don't want to completely disable the screen timeout. But you
might want to set it to some larger large value, say 15 minutes.
It's somewhat hard to work around the lack of a timeout. What you
could do is to release the lock after 15 minutes, but then that means
that the normal screen timer kicks in, which adds an unknown number of
minutes of the screen being on.
If you instead were able to create a display lock with a 15 minute
timeout, the platform could use the longest value of 15 minutes and
the platform screen timeout.
And note that you in normal use cases *do* want the normal screen
timeout to kick in when a display lock is released. I've seen the
lack of this many times and it's really annoying. What happens is that
after you're done watching a 30 minute movie, the application releases
the lock and the screen immediately shuts off. Attempting to work
around this by holding the lock for a few minutes past the movie ends
means
Re: [whatwg] Proposal: Wake Lock API
On Thu, Aug 14, 2014 at 4:44 AM, Biju bijumaill...@gmail.com wrote:
So what happens when we have following function call.
How do we release the runaway lock request.
Another case is a page made lock and user navigate away from the page.
Do the browser keep the lock for ever ?
function xyz(){
do_something_1();
x = new WakeLock(display);
x.request();
do_something_2();
throw some runtime error occurred;
do_something_3();
x.release();
do_something_4();
}
Same thing as
function xyz(){
do_something_1();
navigator.wakeLock.request(display)
do_something_2();
throw some runtime error occurred;
do_something_3();
navigator.wakeLock.release(display)
do_something_4();
}
I.e. the lock is held forever.
/ Jonas
Re: [whatwg] Proposal: Wake Lock API
On Thu, Aug 14, 2014 at 6:33 AM, Nils Dagsson Moskopp n...@dieweltistgarnichtso.net wrote: So what would happen if I want my laptop to go to into low-power mode by closing the lid? Would I have to close a lot of risky web pages first? We need indeed something to prevent abuse here. Especially for CPU locks given that they are largely invisible (and unactionable) to the user. This is of course independent of what API syntax we use. One solution that I think we'd use in FirefoxOS is to bring up a dialog when the system lock is used. Unless the user has installed the page by using bookmark to homepage or something similar. And for things that have been bookmarked to homepage we'd track their battry usage and inform the user how much battery each bookmarked website uses. / Jonas
Re: [whatwg] Proposal: Wake Lock API
On Thu, Aug 14, 2014 at 9:55 AM, Jesper Kristensen
m...@jesperkristensen.dk wrote:
Hi
Would it make sense to tie the system lock to a notification?
For example:
new Notification(Processing..., {tag: abc, progressBar: 0.8, wakeLock:
system});
There are many myths and rumors about how to conserve battery on mobile
devices. A small improvement could be to require apps to show some kind of
UI whenever they are allowed to consume resources in the background.
The main use case for system locks in my mind is for applications that
need to do some short but important processing. For example a camera
app wanting to do some HDR processing of an image before saving it to
disk. It seems like it would be very annoying if a notification was
shown any time the user took a picture.
I still think it's a very interesting idea though.
/ Jonas
Jesper Kristensen
Den 14-08-2014 kl. 03:00 skrev Jonas Sicking:
On Thu, Jul 17, 2014 at 7:17 AM, Marcos Caceres w...@marcosc.com wrote:
On Thursday, July 17, 2014 at 6:12 AM, Mounir Lamouri wrote:
On Thu, 17 Jul 2014, at 01:56, Marcos Caceres wrote:
I don't have a strong opinion. My concern was mostly about developers
having to watch for a whole bunch of different interaction queues
(touch
events, mouse events, focus events, orientation-change events, etc.) in
order to release the lock at the right time.
Do you have specific UC? The basic UC I have in mind (reading a book,
watching a video, playing a game) would not use a timeout.
Yes, Google Play Books will wait five minutes from the last interaction
to turn off the screen. This is nice if you fall a sleep while reading and
long enough for a user to read a page without having the screen dim.
See:
http://w3c-webmob.github.io/wake-lock-use-cases/#google-play-books
I was trying to model that problem with the API.
Question remains if there are other kinds of locks that we might need.
For example, Firefox OS has wifi as a lock type. I'm assuming that
their model keeps the cpu on, but the device can still shut down the
radios on a device. In the proposal, we lump wifi and cpu into
system.
Why not breaking these in different sub-systems? I can definitely
imagine my phone having the CPU kept at 100% while the screen is off if
it requires to do a heavy computation. Forcing the screen to stay on
while doing that would be a waste of battery.
Sorry, I was trying to say exactly what you said above. No need to keep
the screen on when using system, obviously.
Ideally, we could do something like:
display = keep display on + system/cpu + network
network (wifi/cell) = system/cpu + network (screen off)
system = just cpu, turn off screen and radio.
Hopefully, something like that means you don't need to pick an choose
amongst numerous options.
I think the locks are fairly orthogonal.
Holding the display lock just prevents the normal turn off device
because user hasn't interacted with it for X minutes timer from
firing. I.e. while the display lock is held, the screen won't
automatically time out and put the device to sleep.
However if the user presses the power button the screen would still
turn off and the device would still go to sleep.
Holding the system lock however wouldn't prevent the screen from
turning off. But it would prevent the CPU from going to sleep even if
the screen times out or if the user presses the power button.
Holding both display and system means that the screen won't time
out. If the user presses the power button the screen would turn off
but the CPU would still not be put to sleep.
So I think it makes sense to expose an array of which locks the page
holds since all combinations of the system and display locks yield
different behavior.
I am however more worried about that only having a request() and a
release() function means that pages that contain multiple independent
subsystems will have to make sure that they don't stomp on each
other's locks. Simply counting request() calls vs. release() calls
helps, but doesn't fully solve the problem. It's very easy to
accidentally call release too many times, in response to some UI
action for example.
An alternative design would be something like
x = new WakeLock(display);
x.request();
x.release();
Extra calls of either request() or release() are ignored, but pages
can create any number of WakeLocks of the same type.
Regarding timeouts, the use case that I've come across many times is
pages that contain a lot of text, or some form of puzzle. In those
cases you don't want to completely disable the screen timeout. But you
might want to set it to some larger large value, say 15 minutes.
It's somewhat hard to work around the lack of a timeout. What you
could do is to release the lock after 15 minutes, but then that means
that the normal screen timer kicks in, which adds an unknown number of
minutes of the screen being on.
If you instead were able to create a display lock
Re: [whatwg] Proposal: Wake Lock API
Additionally in the browser UI, if user can get a way to find which tabs/pages are locking the system/display it will be great help.
Re: [whatwg] Notifications: the ability to specify notifications behavior
On 08/13/2014 04:36 PM, Jonas Sicking wrote:
On Wed, Aug 13, 2014 at 2:12 PM, Robert Bindar
robertbin...@gmail.com wrote:
Concerning web notifications, it would be very helpful for content
and web
apps
to have a way of specifying the behavior their notifications should
have.
For instance, a chat client may not always want to play a sound when
sending
a notification pertaining to a new message. Or in the mobile web, an app
may want to avoid waking the screen on every notification to save
battery
life. Web content could have a way to suggest these behaviors to
the user
agent.
Agreed. We've run into similar shortcomings when writing mobile webapps.
new Notification('title', {
tag: 'tag',
behavior: {
vibration: true,
silent: true,
lights: false,
list: true,
noclear: true,
squash: true,
}
});
It might be good to structure these such that the default is always
'false'. That way it's more intuitive what behavior you get if you
leave out a property.
We can not say accurately if the default will always be false because
the platform may or may not support the behavior, or it might be overridden
by a user defined setting.
* vibration - vibrate the device
* silent - true means do not play a sound when firing the
notification(the sound
is enabled by default in firefox for OSX, not
available
in Linux and Windows)
The tricky thing with these is how to deal with situations when the
user has turned of audio or turned off vibration for notifications.
If the user turned off/on audio/vibration then UA will ignore any app
specified
behavior. The user defined settings will always take priority over these
behaviors.
If the user has turned off audio for notifications, and the page
specifies vibration: false, does that mean that this notification is
entirely silent? I suspect that's not what the user expected when
turning off audio.
If the user had previously turned on the vibration for notifications,
then no,
the device will still vibrate, but otherwise the notification will indeed
be entirely silent.
* lights - turn the screen on
Agreed on this one.
* list - add a new entry to the notification list
I don't understand this one.
Some platforms have a notification center, like the notification tray
in Android. This behavior is about bypassing display in the notification
center.
* noclear - this notification shouldn't be closed when pressing the
ClearAll button
This one is interesting. I could see the value for notifications that
deliver progress notifications about an ongoing event to the user.
Though I hate the idea of users not being in control of their
notifications area. Perhaps it's ok that the notification doesn't get
cleared if a 'clear all' button is pressed, but that the user can
somehow explicitly clear that certain notification.
* squash - every time you'll find a notification with the same
tag, do
not disrupt the
user, just update the existing notification
This is the main purpose of using tags. When would you not want this
behavior?
It is the main purpose of using tags, but using this option we could specify
to the UA to update the notification silently, do not produce any other
action
that could disrupt the user (play a sound every time, flash the screen,
etc).
This behavior could be very useful for intensive notifiers like email
updates,
maybe this name is not the best choice.
Again, the `behaviors` object is just a package of suggestions for how a
notification should behave,
but it is up to the user-agent to determine whether it wants to
honor these
behaviors
(based on platform support, user settings, or even general user
experience).
I don't think it makes much difference to say this is just a
suggestion. UAs won't magically know what's right and what's wrong.
If we can't on this list think of good heuristics to use, then I don't
think we should expect UAs to do either.
/ Jonas
By suggestion I meant that UAs should analyze if there are any user
defined
preferences regarding those behaviors and if they are of course able to
follow
them (an web app could pass vibration: true to the Notification
constructor,
but a desktop browser will not be able to fulfil this request).
The heuristic I'm proposing is:
1) Does the platform/UA support it?
2) Is there a user defined setting that overrides this behavior?
Robert-
Re: [whatwg] Notifications: the ability to specify notifications behavior
On Thu, Aug 14, 2014 at 4:37 PM, Robert Bindar robertbin...@gmail.com
wrote:
On 08/13/2014 04:36 PM, Jonas Sicking wrote:
* vibration - vibrate the device
* silent - true means do not play a sound when firing the
notification(the sound
is enabled by default in firefox for OSX, not
available
in Linux and Windows)
The tricky thing with these is how to deal with situations when the
user has turned of audio or turned off vibration for notifications.
If the user turned off/on audio/vibration then UA will ignore any app
specified
behavior. The user defined settings will always take priority over these
behaviors.
If the user has turned off audio for notifications, and the page
specifies vibration: false, does that mean that this notification is
entirely silent? I suspect that's not what the user expected when
turning off audio.
If the user had previously turned on the vibration for notifications,
then no,
the device will still vibrate, but otherwise the notification will indeed
be entirely silent.
On this note, it would be useful if content could query the UA for the
default behaviors of any notifications it would send. Also, it would be
nice to know which of these behaviors could be overridden by the behavior
options. Perhaps something like:
var promise = Notification.getBehaviors();
promise.then(function (behaviors) {}
with behaviors looking something like this:
{
vibrate: {
default: true,
overridable: false
},
...
}
So, each behavior would have a default (which the system determines through
platform support and user settings), and whether or not the behavior is
overridable for the current content script. The way an app could have the
information necessary to degrade gracefully.
[whatwg] exposing dependencies + weights (aka, priorities) to web developers
(followup / continuation of [1]) Trying to hash out some ideas for how to connect Fetch and the new transport capabilities of HTTP/2. Would love to hear everyone's thoughts: https://docs.google.com/document/d/1jSpWc6jkrUoYtGWcxev9Blkkv9RhoO1XtqinBvXqhgY/edit ig [1] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2014-July/297257.html
