On 4/17/15 2:44 AM, Mike West wrote:
Consider Geolocation, for instance: users can disable the API entirely
in Chrome (and, I assume, other browsers). Should we remove the API in
these cases as well?
There's no user-facing UI to disable geolocation in Firefox, but there
is a preference that
On 4/17/15 2:52 AM, Boris Zbarsky wrote:
If that preference is toggled, we in fact remove the API entirely, so
that 'geolocation' in navigator tests false.
Oh, I meant to mention: this is more web-compatible than having the API
entrypoints throw, because it can be object-detected. Of course
I'd be fine with this, if it's what folks end up preferring.
That said, throwing/rejecting gives us the opportunity to explain to a
developer _why_ her favorite API isn't available. It's not clear how we'd
help them understand what's going on if we just remove the API entirely.
Consider
It's preferable not to do that for us because you can then create a static
heap snapshot at compile time and memcpy to start JS contexts faster.
On Apr 17, 2015 12:03 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 4/17/15 2:52 AM, Boris Zbarsky wrote:
If that preference is toggled, we in fact
I like the idea of this. It reminds me of polymer's core-ajax component.
On Apr 16, 2015 11:39 PM, Glen Huang curvedm...@gmail.com wrote:
Inspired by HTML imports, can we add JSON imports too?
```html
script type=application/json src=foo.json id=foo/script
script type=application/json id=bar
Basic feature like this shouldn't rely on a custom solution. However, it does
mean that if browsers implement this, it's easily polyfillable.
On Apr 17, 2015, at 9:23 PM, Wilson Page wilsonp...@me.com wrote:
Sounds like something you could write yourself with a custom-elements. Yay
Sounds like something you could write yourself with a custom-elements. Yay
extensible web :)
On Fri, Apr 17, 2015 at 1:32 PM, Matthew Robb matthewwr...@gmail.com
wrote:
I like the idea of this. It reminds me of polymer's core-ajax component.
On Apr 16, 2015 11:39 PM, Glen Huang
Since we're talking about a binary distinction (privileged vs.
unprivileged), presumably you could just make two snapshots?
On Fri, Apr 17, 2015 at 3:38 AM, Elliott Sprehn espr...@chromium.org
wrote:
It's preferable not to do that for us because you can then create a static
heap snapshot at
I think the existence of the API functions should indicate the browser has
the capability, and then the API returns an error if it's not allowed to be
used in the current context. I think this would improve the quality of
messages seen by users, since for example removing the Geolocation API
On the one hand, I like the idea of giving developers and users better
information about why things are failing.
On the other hand, it seems unpleasant to make every API that is so
restricted accommodate a failing because of non-privileged context
modality, which they will undoubtedly do in
On 4/17/15 3:38 AM, Elliott Sprehn wrote:
It's preferable not to do that for us because you can then create a
static heap snapshot at compile time and memcpy to start JS contexts faster.
For this specific case, where there are only two possibilities
(privileged or not) it seems like you can
On 4/17/15 2:44 AM, Mike West wrote:
Either way, expressing the constraint via IDL seems totally reasonable.
OK, so let's say we do the API is still present but fails somehow
thing. How would one express that constraint via IDL? What would the
normative language be? It seems like the best
On 4/17/15 7:58 AM, Ashley Gullen wrote:
I think the existence of the API functions should indicate the browser
has the capability, and then the API returns an error if it's not
allowed to be used in the current context. I think this would improve
the quality of messages seen by users, since for
On Fri, Apr 17, 2015 at 4:09 PM, Boris Zbarsky bzbar...@mit.edu wrote:
I say this because I'm seeing people want to apply this to a variety of
different APIs which should do a variety of different things in the
disabled state, as far as I can tell.
Am I missing something and there's something
On 4/17/15 11:13 AM, Anne van Kesteren wrote:
A bunch of the new non-legacy APIs (that is geolocation doesn't count)
have some kind of promise thing you need to get past before things
start working. For those APIs we could have something with normative
language. I don't see how we could make
On Fri, Apr 17, 2015 at 7:06 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 4/17/15 3:38 AM, Elliott Sprehn wrote:
It's preferable not to do that for us because you can then create a
static heap snapshot at compile time and memcpy to start JS contexts
faster.
For this specific case, where
https://www.w3.org/Bugs/Public/show_bug.cgi?id=28505
Bug ID: 28505
Summary: Synchronous XHR removal makes patching
Error.prepareStackTrace impossible
Product: WebAppsWG
Version: unspecified
Hardware: PC
OS:
On 17 April 2015 at 08:16, Boris Zbarsky bzbar...@mit.edu wrote:
If the API returns a Promise type, return a Promise rejected with
a TypeError (??). Otherwise, the operation steps MUST fail in some
way.
Or some such.
SecurityError perhaps. But I still like the idea of an IDL
One benefit is that browsers can start downloading it asap, instead of waiting
util the fetch code is executed (which could itself be in a separate file).
On Apr 18, 2015, at 8:41 AM, Elliott Sprehn espr...@chromium.org wrote:
On Fri, Apr 17, 2015 at 6:33 AM, Glen Huang
link rel=prefetch does that for you.
On Apr 17, 2015 7:08 PM, Glen Huang curvedm...@gmail.com wrote:
One benefit is that browsers can start downloading it asap, instead of
waiting util the fetch code is executed (which could itself be in a
separate file).
On Apr 18, 2015, at 8:41 AM, Elliott
On Fri, Apr 17, 2015 at 6:33 AM, Glen Huang curvedm...@gmail.com wrote:
Basic feature like this shouldn't rely on a custom solution. However, it
does mean that if browsers implement this, it's easily polyfillable.
What does this get you over fetch() ? Imports run scripts and enforce
ordering
21 matches
Mail list logo
