On Wed, 1 Oct 2014, at 15:01, Jonas Sicking wrote:
On Tue, Sep 30, 2014 at 4:40 AM, Mounir Lamouri mou...@lamouri.fr
wrote:
On Wed, 24 Sep 2014, at 11:54, Jonas Sicking wrote:
Thoughts?
Do you have any data that makes you think that those websites would stop
using UA sniffing but start
On Wed, Oct 1, 2014 at 2:27 AM, Mounir Lamouri mou...@lamouri.fr wrote:
On Wed, 1 Oct 2014, at 15:01, Jonas Sicking wrote:
On Tue, Sep 30, 2014 at 4:40 AM, Mounir Lamouri mou...@lamouri.fr
wrote:
On Wed, 24 Sep 2014, at 11:54, Jonas Sicking wrote:
Thoughts?
Do you have any data that
On Wed, Oct 1, 2014 at 7:43 PM, Jonas Sicking jo...@sicking.cc wrote:
On Wed, Oct 1, 2014 at 2:27 AM, Mounir Lamouri mou...@lamouri.fr wrote:
On Wed, 1 Oct 2014, at 15:01, Jonas Sicking wrote:
On Tue, Sep 30, 2014 at 4:40 AM, Mounir Lamouri mou...@lamouri.fr
wrote:
On Wed, 24 Sep 2014, at
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
I understand the focus is on the client-side, understandably, but
please note that on both client and server side UA sniffing is used
for 'responsive' design. On the server side for example it can be used
to route requests or format responses.
On 30/09/2014 02:20, Markus Stange 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
On Oct 1, 2014, at 12:28 PM, Mark Callow callow.m...@artspark.co.jp wrote:
On 30/09/2014 02:20, Markus Stange 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
On Thu, Sep 25, 2014 at 9:52 PM, Anne van Kesteren ann...@annevk.nl wrote:
Is there any platform that requires the show event? Implementers from
Gecko don't see a need for it. We could remove it without harm as far
as I can tell.
Per
On Fri, Sep 26, 2014 at 4:36 PM, Peter Beverloo bever...@google.com wrote:
* 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
On Wed, Oct 1, 2014 at 12:31 PM, Anne van Kesteren ann...@annevk.nl wrote:
On Fri, Sep 26, 2014 at 4:36 PM, Peter Beverloo bever...@google.com
wrote:
* Life-time of existing notifications.
Chrome currently treats Web Notifications as persistent ones. When the
page goes away, the
On Wed, Oct 1, 2014 at 2:56 PM, Peter Beverloo bever...@google.com wrote:
One argument I came across for overloading requestPermission is the
following:
Promise.all([ Notification.requestPermission(),
swRegistration.push.requestPermission() ]).then(...);
Might be worth considering, it's
On Wed, Oct 1, 2014 at 9:06 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Wed, Oct 1, 2014 at 2:56 PM, Peter Beverloo bever...@google.com wrote:
One argument I came across for overloading requestPermission is the
following:
Promise.all([ Notification.requestPermission(),
On Wed, Oct 1, 2014 at 3:14 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
Wait, what? Anytime you request something, not getting it is
exceptional. Not sure how you can make an argument otherwise.
I would not expect a synchronous version of this method (were it to
exist) to have to use
On Wed, Oct 1, 2014 at 9:18 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Wed, Oct 1, 2014 at 3:14 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
Wait, what? Anytime you request something, not getting it is
exceptional. Not sure how you can make an argument otherwise.
I would not expect
On 01/10/14 14:21, Tab Atkins Jr. wrote:
On Wed, Oct 1, 2014 at 9:18 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Wed, Oct 1, 2014 at 3:14 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
Wait, what? Anytime you request something, not getting it is
exceptional. Not sure how you can make an
On Wed, Oct 1, 2014 at 3:21 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
And I wouldn't expect someone loading a FontFace synchronously to use
try/catch to deal with loading errors, either, because that's super
obnoxious. Failure, though, is a standard rejection reason - it maps
to the use
On Wed, Oct 1, 2014 at 9:34 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Wed, Oct 1, 2014 at 3:21 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
And I wouldn't expect someone loading a FontFace synchronously to use
try/catch to deal with loading errors, either, because that's super
From: whatwg [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Tab Atkins
Jr.
This is actually kinda terrible. Promises make it *really easy* to deal with
rejections *later*, letting you execute a bunch of code on the success path
and only at the end saying Oh, did something along the
On Wed, Oct 1, 2014 at 6:06 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Wed, Oct 1, 2014 at 2:56 PM, Peter Beverloo bever...@google.com wrote:
One argument I came across for overloading requestPermission is the
following:
Promise.all([ Notification.requestPermission(),
On Wed, Oct 1, 2014 at 11:44 AM, Domenic Denicola
dome...@domenicdenicola.com wrote:
From: whatwg [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Tab Atkins
Jr.
This is actually kinda terrible. Promises make it *really easy* to deal
with rejections *later*, letting you execute a
On Wed, Oct 1, 2014 at 11:52 AM, Jeffrey Yasskin jyass...@chromium.org wrote:
On Wed, Oct 1, 2014 at 6:06 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Wed, Oct 1, 2014 at 2:56 PM, Peter Beverloo bever...@google.com wrote:
One argument I came across for overloading requestPermission is the
On Wed, Oct 1, 2014 at 5:59 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
I've never heard this opinion explicitly expressed, and it has never
shown up in any API reviews of promise-using specs. It's directly
contrary to the way that existing non-promise async APIs are
constructed, and I
On Wed, Oct 1, 2014 at 1:02 PM, Tobie Langel tobie.lan...@gmail.com wrote:
On Wed, Oct 1, 2014 at 5:59 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
I've never heard this opinion explicitly expressed, and it has never
shown up in any API reviews of promise-using specs. It's directly
contrary
On Wed, Oct 1, 2014 at 7:22 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
Note that Python, for example, throws errors on dict keys not being
found (unless you specifically tell it a sentinel value to return
instead). Do you think that's terrible?
Sure. But JS doesn't.
On Oct 1, 2014, at 16:59, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Wed, Oct 1, 2014 at 11:44 AM, Domenic Denicola
dome...@domenicdenicola.com wrote:
From: whatwg [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Tab
Atkins Jr.
This is actually kinda terrible. Promises make
On Oct 1, 2014, at 18:22, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Wed, Oct 1, 2014 at 1:02 PM, Tobie Langel tobie.lan...@gmail.com wrote:
On Wed, Oct 1, 2014 at 5:59 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
I've never heard this opinion explicitly expressed, and it has never
Hi all,
I posted the following message to WebApps, but Anne van Kesteren suggested
that I instead post to WHATWG, and generalize my request to anything that
supports Fetch. When reading below, feel free to interpret
XMLHttpRequest in the broadest sense.
The proposal follows:
***
I would like
On Wed, Oct 1, 2014 at 10:53 AM, Domenic Denicola
dome...@domenicdenicola.com wrote:
On Oct 1, 2014, at 18:22, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Wed, Oct 1, 2014 at 1:02 PM, Tobie Langel tobie.lan...@gmail.com
wrote:
On Wed, Oct 1, 2014 at 5:59 PM, Tab Atkins Jr.
On 10/1/14, 1:59 PM, David Dorwin wrote:
Rejection also has the advantage of providing an exception, which can
provide information (reason and message) to differentiate between
potentially multiple causes. This is not possible when resolving with null.
Providing such information would likely
All,
FYI ... see below about priorities in XmlHttpRequest. Might be useful for
Cadmium (seems some browsers support something already).
In JS-ASE on NRDP, we are expressing priority through the model of
download tracks. Each request is prioritized relative to other requests
on the same download
For streaming video, where data is requested block-by-block, it would be
nice to be able to set priority proportional to the time until the
requested video block is needed for rendering. Or at least for relative
priorities between requests to reflect this. I think this means that either
priorities
0-7 priority is not sufficient. See previous discussion / proposal:
http://lists.w3.org/Archives/Public/public-whatwg-archive/2014Aug/0081.html
ig
On Wed, Oct 1, 2014 at 10:54 AM, Chad Austin caus...@gmail.com wrote:
Hi all,
I posted the following message to WebApps, but Anne van Kesteren
On Wed, Oct 1, 2014 at 11:02 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 10/1/14, 1:59 PM, David Dorwin wrote:
Rejection also has the advantage of providing an exception, which can
provide information (reason and message) to differentiate between
potentially multiple causes. This is not
Hi All,
Over the past few months all the browser vendors have moved towards
ignoring autocomplete=off with password fields. I understand the
rationale behind this, but in our software project this has lead to
the frustrating situation where we seem to have no good option to deal
with this and the
On Wed, Oct 1, 2014 at 9:19 PM, Dan Poltawski d...@moodle.com wrote:
To outline the situation in broad terms:
* We have shared secrets on the page which we protect against shoulder
surfing by using the password element with autocomplete=off
* The password managers are now all auto-filling
On Wed, Oct 1, 2014 at 8:30 PM, David Dorwin ddor...@chromium.org wrote:
I would specify that DOMException with the name NotSupportedError be
thrown. User agent implementations could provide more information in the
message. (There might be other non-exceptional failures that would use
On Wed, Oct 1, 2014 at 11:43 PM, Anne van Kesteren ann...@annevk.nl wrote:
Given async/await the only reasonable thing to do seems to me
to model them after functions and only use rejection for something
exceptional, but with the level of disagreement this has created in
several different
On 1 October 2014 22:30, Anne van Kesteren ann...@annevk.nl wrote:
Could you explain the situation in a bit more detail? Is the problem
that multiple users are behind the same computer? As it seems someone
is more likely to get my password by shoulder surfing if I type it
in while they watch
On Wed, Oct 1, 2014 at 4:11 PM, Dan Poltawski d...@moodle.com wrote:
The data in those fields are stored in plain text and shared between
multiple teachers (multiple accounts), so when another teacher comes
along - they could access it. There is a scale of severity of the data
in there - from
On Wed, Oct 1, 2014 at 4:17 PM, Peter Kasting pkast...@google.com wrote:
So, you're doing both of the following?
* Using a password field for (sometimes) things that aren't passwords
* Storing (potentially) sensitive data in the clear yourself, and sending
it (again, in the clear) to other
Firefox developer here (I was involved in our behavior change). Sorry
to hear that it's causing you trouble. Unfortunately this seems like a
pretty specific, uncommon use case, so we hadn't considered it. And we
probably aren't reasonably able to fix things for you without breaking
other more
On 2 October 2014 00:17, Peter Kasting pkast...@google.com wrote:
So, you're doing both of the following?
* Using a password field for (sometimes) things that aren't passwords
Right. Though it could be 'sensitive information' and needs obscuring,
so 'A text field that obscures data entry' seems
On Wed, 1 Oct 2014, Domenic Denicola wrote:
This sort of behavior makes promise rejection essentially worthless.
They are as worthless as exceptions.
Some exceptions _are_ worthless, as witnessed by the fact that nobody
ever tries to catch them. For example, TypeError.
This is why I've
On 2 October 2014 00:34, Gavin Sharp ga...@gavinsharp.com wrote:
The underlying use case seems to be obfuscating text in an input field
that isn't a password. From a spec perspective, a feature to opt-in to
obfuscation that isn't type=password could address this (e.g.
type=masked-text).
Yep,
On Wed, Oct 1, 2014 at 11:02 AM, Ilya Grigorik i...@igvita.com wrote:
On Wed, Oct 1, 2014 at 10:54 AM, Chad Austin caus...@gmail.com wrote:
I believe this proposal is very easy to implement: just plumb the priority
value through to the prioritizing network layer browsers already
implement.
On Wed, Oct 1, 2014 at 4:34 PM, Gavin Sharp ga...@gavinsharp.com wrote:
That browsers now automatically go fill in sensitive data (passwords)
into these password fields is the issue, because people might not
notice that happening and then submit the form.
OK, but how does that cycle get
On 2 October 2014 01:24, Peter Kasting pkast...@google.com wrote:
OK, but how does that cycle get started? I could be wrong, but I believe in
Chrome that we won't autofill your password from site X into a password
field on unrelated site Y. You have to have explicitly used that password
on
On Wed, Oct 1, 2014 at 6:12 PM, Dan Poltawski d...@moodle.com wrote:
Note a more traditional example of this which might affect more sites
is something like a 'create new user' form where the password would be
erroneously set to the password of the user who is creating the
accounts.
I know
On Wed, Oct 1, 2014 at 4:48 PM, Chad Austin caus...@gmail.com wrote:
Does HTTP 2.0's dependency graph + weights system allow traditional
priority semantics? That is, higher-priority resources would be serviced
before lower-priority resources, unless resource capacity remains available.
Yes,
On Wed, Oct 1, 2014 at 7:24 PM, Ilya Grigorik igrigo...@gmail.com wrote:
On Wed, Oct 1, 2014 at 4:48 PM, Chad Austin caus...@gmail.com wrote:
Does HTTP 2.0's dependency graph + weights system allow traditional
priority semantics? That is, higher-priority resources would be serviced
before
On Wed, Oct 1, 2014 at 7:59 PM, Chad Austin caus...@gmail.com wrote:
I don't see a way to set a priority value in there. The specific wording
is Streams can be prioritized by marking them as dependent on the,
completion of other streams.
I see that a client can specify the weight of a
Weight is actually not what I want. I want priority. They're different
concepts in that priority implies trumping and weight implies proportional
resource allocation.
That is, if I make 10 high-priority requests, 20 medium-priority requests,
and 30 low-priority requests, I don't want ANY of the
On Oct 1, 2014 4:34 PM, Gavin Sharp ga...@gavinsharp.com wrote:
Firefox developer here (I was involved in our behavior change). Sorry
to hear that it's causing you trouble. Unfortunately this seems like a
pretty specific, uncommon use case, so we hadn't considered it. And we
probably aren't
On Wed, Oct 1, 2014 at 8:39 PM, Chad Austin caus...@gmail.com wrote:
Weight is actually not what I want. I want priority. They're different
concepts in that priority implies trumping and weight implies proportional
resource allocation.
That is, if I make 10 high-priority requests, 20
53 matches
Mail list logo
