I wrote some user stories for RPs and IdPs with your comments in mind, and it
feels like I may have taken the initial cut of the API too far from HTTP
semantics:
https://github.com/SamPenrose/ua-augmented-auth/issues/9
It also feels like the API and stories need a second protocol, or at least
Interesting. I’ve noticed that setBaseAndExtent is used on gMail. Does it work
basically like a ‘setAnchorAndFocus’ would (Base/Anchor and Extent/Focus are
the same when set with this API, correct)?
From: Julie Parent [mailto:jpar...@google.com]
Sent: Wednesday, August 6, 2014 4:44 PM
To: Ben Pe
For what its worth, we plan to remove base and extent from Blink/Chromium (
https://code.google.com/p/chromium/issues/detail?id=230267). We've found
that developers do not understand the difference between focus/anchor and
base/extent, and since it is only supported by WebKit based browsers, it is
I don't understand the difference. setBaseAndExtent would then set all 4 of
these properties of selection? Do you have a definition to use for this?
From: Ryosuke Niwa [mailto:rn...@apple.com]
Sent: Wednesday, August 6, 2014 12:43 PM
To: James M. Greene
Cc: Ben Peters; public-webapps
Subject: Re:
Focus and anchor are different concepts from base and extent. While the former
always coincide with start and end, base and extent may be different from those
two.
In particular, when a user selects text by double clicking on a word, base and
extent stays at where the user had clicked while foc
> From: "Anne van Kesteren"
> On Wed, Aug 6, 2014 at 5:25 AM, Sam Penrose wrote:
> > Web apps suffer particularly due to non-http URIs and cookie segregation.
> > We would like feedback on the specific APIs suggested, as well as the
> > overall problem framing. Thank you for your consideration.
>
- Original Message -
> From: "Mike West"
> Hey Sam, this looks interesting indeed!
Thanks for the very helpful comments. My main takeaway is that I have failed to
communicate the use cases we are trying to solve. I really appreciate your
getting down into the weeds of my proposal; you
Hey Sam, this looks interesting indeed!
It's not clear to me how this proposal interacts with the credential
management proposal I sent out last week. Does the following more or less
describe the integration you're thinking about, or have I completely
misunderstood the proposal?
```
navigator.cre
This doesn't fully cover what setBaseAndExtent() does in WebKit/Blink: as
you pointed out yourself, it acts like extend(), which allows programmatic
creation of backwards selection by providing a focus (extent) that is
earlier in the document than the anchor (base). Your text doesn't cover the
back
On Wed, Aug 6, 2014 at 5:25 AM, Sam Penrose wrote:
> Web apps suffer particularly due to non-http URIs and cookie segregation. We
> would like feedback on the specific APIs suggested, as well as the overall
> problem framing. Thank you for your consideration.
One problem I have with OAuth or pe
Hi,
I am a mobile web developer and have some contributions to make regarding your
current draft specification for “Manifest for web application”.
My main feedback/concerns is that it is currently as inherently inflexible as
the cache manifest file, rendering it useless in many use cases:
Sp
We think that users could be well served by providing simple ways for user
agents and authentication protocols (specifically Oauth, we hope others) to
support each other:
https://github.com/SamPenrose/ua-augmented-auth
Web apps suffer particularly due to non-http URIs and cookie segregation.
12 matches
Mail list logo