Re: [whatwg] Proposal: Wake Lock API
On Wednesday, August 20, 2014 at 5:15 AM, Olli Pettay wrote: On 08/20/2014 11:33 AM, Anne van Kesteren wrote: On Wed, Aug 20, 2014 at 10:29 AM, Jonas Sicking jo...@sicking.cc (mailto:jo...@sicking.cc) wrote: FWIW, the web platform sorely needs a construct for readonly state variable + event whenever the state changes. I.e. some form of observable which remembers the last produced value. I had hoped the Streams would get us closer to that, but the current definition seems to be too different. Isn't that Object.observe() with custom records produced by the specific object you are defining for the property you want to enable this for (in this case held, it seems like)? Object.observe() + some custom records sounds rather inconsistent API. Why would one getter in some prototype be handle differently to other getters? (and it is not too clear how one would implement that.) Agree - a custom thing would not be great. And of course Object.observe would work really nicely, but I've been told a bunch of times by various people that we can't use Object.observe on DOM APIs (this *really* sucks). Getting a bit off topic, but it would be nice if we had a DOM Observer (kinda like a mutation observer) that returned you the same record as Object.observe and could be used with the attributes of WebIDL defined objects. It would make designing, and using, these APIs much simpler.
Re: [whatwg] Proposal: Wake Lock API
On Wednesday, August 20, 2014 at 11:14 AM, Anne van Kesteren wrote:
On Wed, Aug 20, 2014 at 5:09 PM, Marcos Caceres w...@marcosc.com
(mailto:w...@marcosc.com) wrote:
And of course Object.observe would work really nicely, but I've been told a
bunch of times by various people that we can't use Object.observe on DOM
APIs (this *really* sucks).
Not by default, but we can make it work as I said. We wouldn't do it
for innerHTML, but we might for input.value or some such.
Ok, if we get [Observable] in WebIDL, then the API basically becomes something
neat like:
```
partial interface Document {
[Observable] attribute boolean keepScreenOn;
}
```
So nice.
Re: [whatwg] Proposal: Wake Lock API
On August 19, 2014 at 11:16:19 AM, Nils Dagsson Moskopp (n...@dieweltistgarnichtso.net) wrote: Tab Atkins Jr. writes: This solves the GC and locking issues (the latter by delegating state management to CSS, which everyone already knows to use). It would also make it easily possible to express logic similar to “do not power off the screen immediately after a video is playing” in UA or even user stylesheets in a no-nonsense and clearly interoperable way. A CSS solution could also limit abuse if it included a “max-wake-lock” property. Can you describe what you mean here in a bit more detail?
Re: [whatwg] Proposal: Wake Lock API
On August 19, 2014 at 2:08:04 PM, Jonas Sicking (jo...@sicking.cc) wrote:
How would you handle feature detection with this design?
This is a good question. I don't have a better solution than adding
separate DisplayWakeLock() and SystemWakeLock() classes.
Might make sense to do it this way regardless. It might be that we need to add
different behavior for each type of lock in the future.
Ok, so taking into consideration the feedback received so far - how about
something like:
```
[Constructor]
interface DisplayLock : WakeLock {
static readonly attribute boolean isHeld;
}
[Constructor]
interface SystemLock : WakeLock {
static readonly attribute boolean isHeld;
}
interface WakeLock : EventTarget {
Promisevoid request();
Promisevoid release();
attribute EventHandler onlost;
}
```
Usage:
```
//feature detect + lock check
if (DisplayLock !DisplayLock.isHeld){
var lock = new DisplayLock();
lock.request().then(yay,boo);
//listen in case the lock is lost:
lock.addEventListener(lost, function(){
//try again maybe when the battery has more juice
});
}
```
Re: [whatwg] Proposal: Wake Lock API
On August 19, 2014 at 4:39:03 PM, Tab Atkins Jr. (jackalm...@gmail.com) wrote: Why is isHeld still used here? You don't need it to avoid squashing someone else's lock with this design, and several people have pointed out that exposing it is a footgun, as people might check it and decide they don't need to request their own lock (only to be screwed when the other lock releases earlier or later than they expected). It's the only authoritative source of truth. But ok, fair point about the footgun. Consider the static dropped. -- Marcos Caceres
Re: [whatwg] Proposal: Wake Lock API
On Monday, August 18, 2014 at 6:24 PM, Kornel Lesiński wrote: I think it'd be unfortunate if this API had just one shared lock per browsing context and required components on the page to coordinate locking, but provided no means to do so. The API allows scripts to check which locks are currently held (as either a `isHeld()` or `getCurrentLocks()`, for which I just sent a PR for). This will force authors of libraries and components to create dummy iframes just to have their private lock, and libraries/pages without such workaround will be messing up each other's locks. Currently, iframes are not allowed to have locks - only top-level browsing contexts are. This is to avoid things like embedded ads from requesting wake locks. Having just a single shared DOM0-style event handler navigator.wakeLock.onlost looks especially jarring. I would expect this to be a proper DOM event that can be used with normal addEventListener (please avoid repeating the mistake of matchMedia). Oops! I forgot to put that `WakeLock` inherits from `EventTarget`. It's always been the intention that you will have .addEventListener! I've sent a PR to fix this. To make some coordination possible, the simplest method could be to keep track of number of lock requests and releases, like retain/release in Objective-C: navigator.wakeLock.request(screen); // locks navigator.wakeLock.request(screen); // increases lock count navigator.wakeLock.release(screen); // not released yet, but decreases lock count navigator.wakeLock.release(screen); // now released for real In my dummy implementation, I've just been using (the Swift equivalent of): [UIApplication sharedApplication].idleTimerDisabled = YES; On MacOS, I thought the right thing to do (tm) according to Apple was [1] (see listing 2)? I'm pretty sure that's what we do already in Gecko for videos as we've been investigating repurposing the video code for wake locks. So, I've not seen the request/release behavior you describe above (at least not in the context of wake locks on MacOS/iOS). I guess it's used as an idiom maybe in other places? However, as you probably know from Objective-C, Full disclosure, I barely know objective-c ;) perfect balancing of retain/release takes care and discipline. Personally, I wouldn't trust all 3rd party libraries/widgets/ads to be careful with this. In fact, I expect some clever libraries to ruin this with: while(navigator.wakeLock.isHeld(screen)) navigator.wakeLock.release(screen); // just release the damn thing in my leaky code! That would just halt the browser as the script would never complete: currently releasing happens async once the system acknowledges that the release has been granted. I'm not sure if there is a use case for that behavior - it's just what is currently/sorta roughly proposed in the spec. Therefore, if WakeLock needs to be purely JS API, I strongly prefer having WakeLock available only as an object instance, but without exposing GC behavior—if it's lost, it's like a missing release call. If devtools ever get monitoring of unhanded errors in Promise objects, they could also warn against lost WakeLock objects—it's the same type of problem dependent on GC. I'm assuming that release would work only once on each lock object: var lock = new WakeLock(screen); lock.release(); lock.release(); // ignored, so it doesn't unlock any other component's lock This makes coordination easier: each page component can easily create their own lock independently (without needing to create an iframe to get their own lock), and can't release any other component's lock. Personally, I don't know if I agree that it makes coordination easier. Seems that having a centralized place to check what is currently being held makes life a lot easier, because it allows scripts to check if they actually need to request a lock or not. If you have some objects requesting and others releasing, then it makes a huge mess because you need to track down which object screwed up the lock. And if GC also then works to release the locks, then there is no certainty as to what is actually releasing the lock or when. [1] https://developer.apple.com/library/mac/qa/qa1340/_index.html
Re: [whatwg] Preventing wake lock leaks with DOM nodes
On Monday, August 18, 2014 at 7:21 PM, Kornel Lesiński wrote:
My biggest concern with the WakeLock API is that it's easy to forget (or
fail) to release the lock.
It's not a problem with the API per se, but a programming problem in general:
resource management in non-trivial programs is hard. WakeLocks are especially
problematic in this regard, as a leaked lock won't cause any immediate
problems for the developer, so this type of bug can easily go unnoticed.
Sure. At least on a mobile device, it's easy enough for the user to turn off
the screen (or just switch apps or browser tabs)... on laptops, it could be a
problem. However, MacOS (at least) is pretty good at telling users if an app is
eating too much battery. So this could be also handled at the system level.
So I think lifetime of WakeLocks needs to be attached to something visible to
make failure to release the lock immediately obvious.
In case of screen lock it's especially easy: the whole purpose of this lock
is to keep something visible on screen, so we can require that something to
be explicitly connected to the lock.
I think that would be nice, actually. It's at least a kinda workaround to
having to check if something is in the drawable area manually.
However, it still doesn't really deal with the case where the dev forgets to
release the lock. What is nicer is combining this with a timeout:
navigator.wakeLock.request(screen, {element: myCanvas, timeout: aFewMinutes});
That would be the most ideal solution for me personally. Just set it, and
forget it.
It's nearly impossible to forget to remove a visible DOM element from the
document — the mistake is likely to be quite obviously visible. If screen
lock lifetime was dependent on visibility of a DOM element, then it would
also be very hard to leak the lock without noticing it!
(that's a variant of wake-lock:display CSS proposal, but less explicitly
dependent on CSS).
Yes, absolutely. So long as CSS lacks some way to detect if something is
offscreen, it makes sense. The current ways of checking if an element is within
the viewport are quite expensive (bunch of jQuery plugins do this - and I think
they depend on the onscroll event).
With CPU lock it's less clear cut. I think tying it to a notification may be
a good idea.
Need to think about it.
Alternatively, perhaps the lock itself could be an instance of the progress
element that author is supposed to insert to the document? ;)
heh:) Yeah, need to think about that.
Re: [whatwg] Preventing wake lock leaks with DOM nodes
On Monday, August 18, 2014 at 8:10 PM, Domenic Denicola wrote: In general I feel this thread has taken a turn for the complex. Why don't we just do what other platforms do, and provide a simple global request/release mechanism (or toggleable Boolean property!), which developers can build on top of? A lot of the ideas here seem to be trying to create the perfect, developer-friendly, foolproof API. Some of them seem quite clever too, tying to page visibility and the like. But all of them could be built, as libraries, on top of a global request/release. That way users could get reference counting if they want that, visibility-based locking if they want that, promise-based locking if they want that, timeouts if they want those, or even just not do any of those if their use case is simple enough that it doesn't warrant anything more complicated than what they are already doing on existing platforms. We don't need to solve Hard Problems in Programming (TM) before we expose a wake lock API. Leave that as a subsequent step, which users can do, while we move on to exposing more missing platform capabilities
Re: [whatwg] Preventing wake lock leaks with DOM nodes
(sorry, accidental send before!) On Monday, August 18, 2014 at 8:10 PM, Domenic Denicola wrote: In general I feel this thread has taken a turn for the complex. Why don't we just do what other platforms do, and provide a simple global request/release mechanism (or toggleable Boolean property!), which developers can build on top of? A lot of the ideas here seem to be trying to create the perfect, developer-friendly, foolproof API. Some of them seem quite clever too, tying to page visibility and the like. But all of them could be built, as libraries, on top of a global request/release. That way users could get reference counting if they want that, visibility-based locking if they want that, promise-based locking if they want that, timeouts if they want those, or even just not do any of those if their use case is simple enough that it doesn't warrant anything more complicated than what they are already doing on existing platforms. The reason I didn't make it a boolean was because of the IPC involved and because I wanted to support multiple types of locks without needing to add new attributes in the future (and if we need to add the complex stuff later). The request()/release() mechanism is well suited for that, IMO. And it's also fairly simple, even if it vends a promise. Admittedly, I could just make it a bunch of boolean attributes. The spec is kinda already designed to work that way (what lock is applied is just a flag, which is checked synchronously)... it's how `isHeld(lockType)` works. About tying it to visibility, and time, etc. Those are nice to have, but can certainly do without for now. We already dropped the timeout stuff from the original spec - but certainly a nice to have in the future. Having said that, if we know that this API is going to be used in conjunction with scroll events, then we know we are going to have potential battery eating problems (beyond just keeping the screen on). We don't need to solve Hard Problems in Programming (TM) before we expose a wake lock API. Leave that as a subsequent step, which users can do, while we move on to exposing more missing platform capabilities Yeah, certainly want to keep it as simple as possible. Just want to cover keeping the screen on for now.
Re: [whatwg] Feature-detectable WakeLocks
On Monday, August 18, 2014 at 6:41 PM, Kornel Lesiński wrote:
WakeLock.request() expecting a string isn't very friendly to feature
detection.
The API tells you if a wake lock type is not supported by either rejecting with
a TypeError or by a DOMException whose name is NotSupportedError.
I'd prefer if individual lock types were instances of objects, e.g.
navigator.*Lock objects could be instances of a variant of the WakeLock
interface:
navigator.screenLock.request();
navigator.screenLock.isHeld();
navigator.cpuLock.request();
navigator.cpuLock.release();
Personally, this doesn't strike me as good API design. It means having a bunch
of attributes that all use the same class but only differ in name.
Alternatively, if the WakeLock was instantiable (to have a standard way for
independent page components to share locks) then these objects could be
constructors:
if (navigator.ScreenLock) {
var lock = new navigator.ScreenLock();
…
lock.release();
}
(or `new navigator.wakeLocks.Screen()`, etc.)
We don't have any APIs like this today on the Web. It would be weird :)
It would just be better to have a constructor on the interface: `new
WakeLock(screen)` or whatever.
But then we are just back discussing the other email about GC, etc.
Having specific instances for different types of locks could also enable
elegant extensibility of the API, e.g.
var screenLock = new navigator.ScreenLock();
screenLock.dimScreen(); // completely made-up API
var cpuLock = new navigator.CpuLock();
cpuLock.setThreadPriority(low); // completely made-up API
IMO, this is not really different from:
navigator.wakeLock.request(cpu, {
setThreadPriority: low
});
If we need to start returning an actual WakeLock objects in the future, we can
add that.
Re: [whatwg] Proposal: Wake Lock API
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.
Re: [whatwg] Proposal: Wake Lock API
On Wednesday, July 16, 2014 at 5:59 AM, Mounir Lamouri wrote:
On Wed, 16 Jul 2014, at 05:21, Marcos Caceres wrote:
I do not think we should have this timeout option. That sounds like a
very week use case and something fairly easy to do with the tools the
platform already provides. The argument to support this feature in the
github issue was that it will prevent developers to forget releasing the
lock but I have a hard time believing that developers forgetting to
release a lock would use a timeout that is probably more painful and
error-prone.
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.
I'm happy to see how people make due without it, and if we find too many
problems we can always add this later.
### Check if lock is already set
It might be useful to also have a way of checking if a lock is already
set:
``
readonly attribute WakeLockType? lockType
```
You might want something like:
partial interface WakeLock {
readonly attribute WakeLockType[] currentLocks;
};
Given that there can be multiple locks applying at the same time.
Otherwise, the proposal sounds good to me.
Could be... I was thinking that the locks are kinda like a fallback chain. That
is, if you have the screen you also have system. If you lose screen
(notified via an event), you request system before the device goes to sleep.
If it's not possible to do things in that order, then yes: we would need to
return a list of the current locks.
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.
[whatwg] Proposal: Wake Lock API
## Use cases
A website wants the prevent a device from entering a power-saving state to
allow a user to complete a task where it's not practical for the user to touch
the screen (e.g., a maps application while driving, a VR headset like
Cardboard).
A website needs to be able to complete a task, but without requiring the user
to keep the screen on (e.g., importing and processing a bunch of contacts).
Having a wake lock on the system would allow the user to turn off the screen,
while allowing a webpage (or worker) to continue processing some data in the
background.
A complete list of use and abuse cases can be found at [1].
## Workarounds
There is some evidence that …Developers are resorting to hacks like playing
hidden videos to prevent the screen from sleeping. [2]
## Why now?
There are lots of applications on the Web that would benefit from this feature.
E.g., maps, games, cooking websites, ebooks, and sites that stream non-video
content in real time (e.g., sports scores). Also, both Google and Mozilla are
looking into VR, and they will likely need this (see [2]). See [1] for list of
applications that rely on this feature in other platforms.
Other platforms that already support this kind of feature: iOS, Android,
Firefox OS, Windows mobile, and Tizen.
# Proposal:
```
partial interface Navigator {
attribute WakeLock wakeLock;
}
interface WakeLock{
promise request(WakeLockType type);
void release(WakeLockType type);
}
enum WakeLockType{ system, display }
```
## Example
//lock display when the recipe is showing:
$( #recipe ).on( show, function(){
navigator.wakeLock.request(display).then(haveFun, boo)
} );
//release lock:
$( #recipe ).on( hide, function(){
navigator.wakeLock.release(display)
} );
## Optional enhancements
### Timeouts
We are thinking of adding a dictionary to hint at the system the amount of time
it should hold the lock for (in ms). So, then the developer can express holding
the lock for 5 minutes (e.g., ebook case, instead of having to bind a whole
bunch of listeners and constantly having to request the wake lock). This would
allow the UA to add whatever time the developer requested to its normal wake
lock timer + additional time the developer might want. If the timeout is less
than the default timeout, it can just be ignored.
```
dictionary WakeLockOptions{
unsigned long timeout;
}
```
For example:
```
//I only need this for ~5 mins here.
var options = {timeout: 1000 * 60 * 5};
navigator.wakeLock.request(display, options);
```
### Events
It might be necessary for applications to be notified, via an event, if they've
lost a lock after one was granted to it.
### Check if lock is already set
It might be useful to also have a way of checking if a lock is already set:
``
readonly attribute WakeLockType? lockType
```
Appreciate any feedback on the design and help with the security model.
[1] https://w3c-webmob.github.io/wake-lock-use-cases/
[2] https://code.google.com/p/chromium/issues/detail?id=386255
Re: [whatwg] Proposal: Wake Lock API
On July 15, 2014 at 3:31:32 PM, Jasper St. Pierre (jstpie...@mecheye.net) wrote: Should the lock automatically be released if the user switches to a different tab or somehow makes the content unviewable? Yes. But it could be automatically reapplied once the user switches back to the tab/window. This could happen transparently. Should the web content know about this, or should it just silently think the lock is still being held? Ideally, it should just be silent. This might affect the timeout situation. It would be strange to be unable to lock or suspend due to some random map embedded in a Yelp page somewhere taking a lock. The locks are fairly soft, at last for screen. But yes, for system locks that would suck. We might need to limit those somehow. What about for cases like laptops where the user can force a suspend, like closing the lid? If the system is configured to lock or suspend the machine, should this prevent it? No, in this case it could be notified that it has lost the lock. Are there any tasks like instant messaging where users might want to have it inhibit suspend, and the user can still be notified of it because the system might make a sound? Should the web content be aware of this as well? I think that's a different use case: That could be better suited for push notifications + service workers + the notification API. I'm at least happy that the web doesn't have the burning a CD task that we had to deal with with our desktop. :) That was a messy set of edge cases to deal with. Heh, I'm sure similar cases will come up in the future (e.g., 3D printing over serial port API).
[whatwg] `brand-color` meta extension
Folks at Mozilla and Google would like to standardize the `brand-color` meta extension. The `brand-color` keyword has been added to the MetaExtensions WHATWG wiki and a rough spec is below (prepared by some folks at Google). # Overview The browser will use this brand color when distinct color is needed, i.e. it could be used as Web App’s title bar. Other browsers have similar features, but each defined as its own specific meta tag, IE uses mapplication-navbutton-color, Safari’s is apple-mobile-web-app-status-bar-style, they are all similar with brand-color, but have a little different usage. # Syntax meta name=brand-color content=#ff The content attribute can be any value defined in css color specification http://www.w3.org/TR/css3-color/ , the value might be adjusted by browser if it is not proper for display, i.e. extremely bright. the leading and trailing whitespace (defined in http://www.w3.org/TR/html401/struct/text.html) is permitted. The brand-color meta tag must be in head element, If there are multiple brand-color meta tags in head element, first one takes effect. Brand color could be changed by script, browser shall respect this change. Relevant issues/discussions: https://bugzilla.mozilla.org/show_bug.cgi?id=1013913 https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/nzRY-h_-_ig/IeXq74xUWzkJ Thanks! -- Marcos Caceres
Re: [whatwg] `brand-color` meta extension
On June 26, 2014 at 1:58:17 PM, Tab Atkins Jr. (jackalm...@gmail.com) wrote: Here's a first crack at a better spec: Moved your text here: https://github.com/whatwg/meta-brand-color We can better capture issues, etc. there. I also updated the Wiki to point there as the official version. We can put the right license and allow more people to edit the document on GH (it was a read only Google doc, which is not great). I'm not volunteer to edit it :) -- Marcos Caceres
Re: [whatwg] `brand-color` meta extension
On June 26, 2014 at 2:17:22 PM, Ian Hickson (i...@hixie.ch) wrote: I think it would make sense to allow vendors to treat these all as independent values (in particular, we wouldn't want IE to be forced to extend their interpretation of msapplication-TileColor and msapplication-navbutton-color to be redundant), but I do think it would make sense to encourage UAs to draw colours from whichever values are provided, so that authors don't have to include different values for each browser. I would be in favor of this. It would be good to support the legacy content as its use on the Web is significant. Search I did back in Oct 2013 found these proprietary tags appeared on something like 1% of pages in Alexa's top 78K pages (specially the msTileColor one is quite popular). I don't have the data any more, unfortunately - but could get it again if needed. The thing would be to see if it really does make sense to reuse those things in contexts where `brand-color` is to be used and not produce unexpected results. -- Marcos Caceres
Re: [whatwg] The src-N proposal
On Sunday, November 17, 2013 at 8:07 PM, whatwg-requ...@lists.whatwg.org wrote: Date: Sun, 17 Nov 2013 08:19:00 -0800 From: Tab Atkins Jr. jackalm...@gmail.com (mailto:jackalm...@gmail.com) To: Ryosuke Niwa rn...@apple.com (mailto:rn...@apple.com) Cc: whatwg wha...@whatwg.org (mailto:wha...@whatwg.org), Timothy Hatcher timo...@apple.com (mailto:timo...@apple.com) Subject: Re: [whatwg] The src-N proposal Message-ID: CAAWBYDB34Wh6fLCBodozKOABGLrib53A=B2-0Yv=bcd0qge...@mail.gmail.com (mailto:bcd0qge...@mail.gmail.com) Content-Type: text/plain; charset=UTF-8 On Sun, Nov 17, 2013 at 5:16 AM, Ryosuke Niwa rn...@apple.com (mailto:rn...@apple.com) wrote: Without starting a debate on what semantics or aesthetics mean, syntax is a big deal. A bad syntax can totally kill a feature. Believe me, I agree; I named my last coding project Bikeshed, after all. ^_^ This is why I find it puzzling that a syntax accepted by the RICG and a lot of authors is being shot down by a few implementors. This is why I've been classifying the objections as personal aesthetic concerns - I don't know how to classify them otherwise. The proposed syntax doesn't seem to offend average authors, who grasp it well enough (it's a pretty simple translation from what they already liked in picture). It just offends a few of you from WebKit, some of whom have been a bit hyperbolic in expressing their dislike. Agree. It would be ideal to try to find a way forward here with src-n. Mozilla is not really interested in restarting this whole effort again with imgset or new CSS-in-the-head proposals (though, of course, orthogonal improvements to the preload scanner are quite interesting and probably quite beneficial, but let’s keep that as separate!). We’ve already seen all the proposals for using CSS, JavaScript, and so on for the last 3 years (ad nauseam!), so can we please try to keep the discussion focused on src-n, picture, and, if we really need to, srcset. The developer community already made significant sacrifices in compromising on picture because of issues that implementers raised about nested elements (even if the RICG felt picture was a more useable solution, they were willing to drop it in favor of src-n to appease implementers and to end the stalemate for the good of actually getting something reasonable implemented). As we’ve already indicated, Mozilla are strongly behind src-n as we feel it best meets the use cases, and has the broadest developers support. Aesthetic concerns would seem to be very low on the priority of constituencies. Let’s not further erode those principles for the sake of markup aesthetics. So, I kindly ask that we seek to find a way forward with src-n. Kind regards, Marcos -- Marcos Caceres
Re: [whatwg] The src-N proposal
On Monday, November 18, 2013 at 3:34 PM, Jirka Kosek wrote: On 18.11.2013 14:38, Marcos Caceres wrote: we really need to, srcset. The developer community already made significant sacrifices in compromising on picture because of issues that implementers raised about nested elements Are those issues with nested elements described somewhere? I wasn't able to find anything and I would really like to know what the issue was. Simon Pieters (cc'ed) can provide you with the details. He did most of the QA for video and the decision to drop picture was based mainly on his objections and feedback to the RICG. of constituencies. Let’s not further erode those principles for the sake of markup aesthetics. It's not just about aesthetics. From markup point of view src-n goes against common sense and principles. Existing APIs and languages for working with markup don't have easy way to access src-n attributes, especially if order based on n is significant. This is very different from nested elements where it's very easy to iterate over them. Sure, but what’s the use case for accessing them? Also, given that we have `data-` already, we could look to that if we need some kind of API. This also doesn’t exclude matching on different attributes (class, id, etc.). But it really depends on what you are trying to do, and I don’t know what that is yet. Compare this to srcset also, which doesn’t provide any API at all. It’s the same mess - but there was no use case presented that required the need for such an API (the RICG also pointed this out in Bugzilla, and they were unable to come up with a use case - hence srcset provides not API for traversing sources). Try to write JS+DOM, or XPath, or ... your preferred language here ... code for looping through src-n attributes in a right order. Compare it to the same code for subelements, which are ordered and have same name. Sure, it might suck, or I could write a little javascript to order them and return them with an iterator (won’t be as painful as it would be with srcset). But I’m still not sure what one would achieve with this once the elements have been processed and d/ls have started.
[whatwg] Serial API
Hi, Just wanted to let people know that a few of us are working on a Serial API that would be layered on top of streams. The Serial API provides a way for websites to read and write from a serial device through script. Such an API would bridge the web and the physical world, by allowing documents to communicate with devices such as microcontrollers, 3D printers, and other serial devices.” Right now, we are just gathering use cases and requirements. Your input and participation would be greatly appreciated. **Please comment in the GH issue tracker [2]. Many people working on the API are not subscribed to this list and are unlikely to respond!** The spec can be viewed at [1]; the GH repository is at [2]. [1] http://whatwg.github.io/serial/ [2] https://github.com/whatwg/serial -- Marcos Caceres
Re: [whatwg] Proposal: Locale Preferences API
Ping?
Mozilla would like to know if anyone else is interested or specially if people
are NOT interested. We would like to implement this and expose it on the
platform.
See:
https://bugzilla.mozilla.org/show_bug.cgi?id=780953
On Friday, July 26, 2013 at 8:14 PM, Marcos Caceres wrote:
tl;dr: Mozilla would like your feedback on the following proposal to extend
HTML to expose the user's locale preferences - which would allow for more
dynamic localization of content. To HTML, we would like to add a
`navigator.languages` attribute and a `languageschange` event (and
corresponding EventHandler on the Navigator interface).
The following markdown is also viewable online (feedback in the form of Pull
Requests is welcome!):
https://github.com/marcoscaceres/Locale-Preferences-API/blob/master/proposal.md
# Proposal: Locale Preferences API
## Abstract
This document proposes an extension to HTML's `Navigator` interface to enable
dynamic localization of content. The idea is to expose to script the language
tags that represents the user's locale preferences (akin to the language tags
that are normally sent with HTTP's `Accept-Languages` header).
Also proposed is a `languageschange` event, so that scripts can be notified
if
the user changes the ordering of their preferred locales.
## Problem we are trying to solve
In order to support dynamic localization of content on the client-side,
developers need to have access to the user's locale preferences. In user
agents, this is generally represented as an ordered list of [BCP47] language
tags, which is shared with servers through the `Accept-Languages` HTTP header.
Traditionally, to access this list of language tags developers need to query a
server to tell them what the browser's language preferences are set to (i.e.,
by
reflecting the `Accept-Languages` HTTP header - and usually stripping away the
q values). This has led to the creation of various xhr-based hacks and
workarounds on the client side. See: [JavaScript for detecting browser
language
preference](http://stackoverflow.com/questions/1043339/javascript-for-
detecting-browser-language-preference) .
There are a number of issues with this work-around:
* because of the reliance on making a HTTP request, the values are not
immediately available to script.
* because of the reliance on making a XHR-based request, this becomes
impractical if the user is not connected to the network.
* because of the reliance on HTTP requests, it's not possible to immediately
know if the user's preferred language order has changes (even though it is
rare - FireFox applications rely on this to be able to maintain the UI
localized
without needing to reboot the device).
To overcome these limitations, and solely in Mozilla's FirefoxOS, developers
are
relying on a proprietary
[mozSettings
API](https://developer.mozilla.org/en-US/docs/Web/API/window.navigator.mozSettings)
to get notified when the user's locale preferences change.
In order to address the issues described above, and to move away from having
to
rely on a proprietary solution, this document proposes the following
extensions
to the [HTML]'s Navigator interface.
## Acquiring the end-user's locale preferences
The end-user's locale preferences represents the end-user's preferred
languages
and regional settings, which are derived from the operating system or directly
from the user agent. As there are numerous ways a user agent can derive the
end-
user's preferred languages and regional settings, the means by which those
values are derived are beyond the scope of this document and left up to the
implementation.
## Extensions to Navigator interface
```WebIDL
partial interface Navigator : EventTarget {
readonly attribute DOMString[] languages;
attribute EventHandler onlanguageschange;
}
```
Note: We've received feedback that TC39 is not in favor of API's using frozen
/read-only arrays. Alternatives to the above attribute are:
1. `sequenceDOMString getLanguages()` method - thought this has been
internally criticized as being javaish.
2. Willfully violate WebIDL's ban on using sequences on attributes, and make
`languages` just return `sequenceDOMString`.
## The `languages` attribute
When getting, the languages attribute returns a read only platform Array
[WebIDL] of valid language tags in canonical form [BCP47]. The array is
ordered
from most preferred to least preferred, where the first item is the language
tag
that represents the user's most preferred language.
## Event handlers
If the user updates their locale preferences in such a way that it would cause
the ordering of language tags change, then the user agent MUST perform the
following steps:
1. Let lang list be the updated list of preferred locales.
2. Queue a task to perform the following:
2.1 If the first item of the lang list
[whatwg] Proposal: Locale Preferences API
As with navigator.language, there are privacy implications in exposing the user's language preferences, as it can potentially be used to infer both the physical location (to at least a country level) and potentially the user's ethnic background (in those that choose have explicitly selected more than one language preference). These values can also be exploited, together, with other data to uniquely identify users. However, these values are already shared with servers with every HTTP request, thus this API does not exacerbate the finger-printing situation. Regardless, implementors are encouraged to reflect the value of navigator.language unless the user has explicitly indicated that the site in question is allowed access to the information. ## Known usability issues It is envisioned that the primary purpose for this API will be to take a list of language-tags supported by an application and compare it with the list of language-tags that represent the user's locale preferences. Because of the nature of language tags, working with language tags can be notoriously difficult - particularly when comparing two lists for changes. See: https://bugzilla.mozilla.org/show_bug.cgi?id=889616 To make this API useful in practice currently requires a supporting i18n library (e.g., [Mozilla's L20n: Localization 2.0 library ](https://github.com/l20n/l20n.js)). To make it possible to use this API on its own, Mozilla is discussing with TC-39 the possibility of exposing the LookupSupportedLocales and CanonicalizeLanguageTag abstract algorithms as part of an extension of [Ecma-402]. ## References [BCP47] - [Tags for Identifying Languages](http://tools.ietf.org/html/bcp47) [Ecma-402] - [ECMAScript® Internationalization API Specification ](http://www.ecma-international.org/ecma-402/1.0/ECMA-402.pdf) ## Related Mozilla bugs The following bugs motivated Mozilla to put together this proposal. The use cases are have mainly been driven by FirefoxOS, though they've also come up else where (e.g., in with Firefox Extensions). * [bug 889335 - navigator.languages](https://bugzilla.mozilla.org/show_bug.cgi?id=889335) * [Bug 780953 - Add language change event](https://bugzilla.mozilla.org/show_bug.cgi?id=780953) * [Bug 889617 - Provide API for user requested language fallback](https://bugzilla.mozilla.org/show_bug.cgi?id=889617) * [Bug 288670 - Use intl.accept_languages to choose the locale for a package if the current locale is unavailable](https://bugzilla.mozilla.org/show_bug.cgi?id=288670) * [Bug 562648 - Prioritized locale list for fallback of strings or add-ons](language/translation fall-back; fallback is always en-US)] -- Marcos Caceres
