Re: [whatwg] A mechanism to improve form autofill
On Fri, Aug 3, 2012 at 5:31 AM, Aryeh Gregor a...@aryeh.name wrote: On Thu, Aug 2, 2012 at 9:42 PM, Ian Hickson i...@hixie.ch wrote: On Thu, 26 Jul 2012, Smylers wrote: Ian Hickson writes: Also, I do not understand why we have credit cards types. Is anyone willing to have his credit cards information saved locally? Sure, why not? I am too, but I can understand why people who share their computer (and user accounts) with others wouldn't want their card numbers saving. That's a UA configuration issue, presumably. (Similar to saving passwords.) In fact, Chrome already autodetects credit card numbers for autofill (presumably based on a heuristic) and has a special dialog for whether to remember them, similar to the password-remembering dialog. At chrome://chrome/settings/autofill, there are fields for both addresses and credit card numbers. This is documented here: https://support.google.com/chrome/bin/answer.py?hl=enanswer=142893p=settings_autofill IIRC, one option when it asks you to remember credit cards is don't ever remember credit card numbers -- although I'm not sure, since I think I picked it and thus haven't seen the dialog in a long time. :) In practice the credit card portion of Chrome Autofill is not very useful since most (hand-wavy) sites that contain credit card fields in forms use autocomplete=off, which Chrome respects. There is a third-party Chrome extension which removes autocomplete=off to solve this issue. James
Re: [whatwg] Proposal: Deprecate registerProtocolHandler/registerContentHandler via Web Intents
Thanks for your feedback, Bjartur. On Tue, Feb 21, 2012 at 9:30 AM, Bjartur Thorlacius svartma...@gmail.comwrote: Þann mið 15.feb 2012 23:39, skrifaði James Hawkins: * If |scheme| is specified, |action| *should* (must?) be ignored. Why would you forbid distinguishing between actions on URIs? Postal and retrieval of mail, for example, are quite distinct actions. As are modification and retrieval of documents. I'm not sure if the proposal was explicit enough, but for the RPH-esque functionality in Web Intents, we activate WI in the same circumstances RPH is activated, which is when links are activated in a page. Can you elucidate how the scenarios you listed could be handled? Note these scenarios are above and beyond RPH, but we're not trying to make the API self-limiting. Thanks, James
Re: [whatwg] Proposal: Deprecate registerProtocolHandler/registerContentHandler via Web Intents
On Tue, Feb 21, 2012 at 11:31 AM, Bjartur Thorlacius svartma...@gmail.com wrote: Þann þri 21.feb 2012 18:44, skrifaði James Hawkins: I'm not sure if the proposal was explicit enough, but for the RPH-esque functionality in Web Intents, we activate WI in the same circumstances RPH is activated, which is when links are activated in a page. Can you elucidate how the scenarios you listed could be handled? Note these scenarios are above and beyond RPH, but we're not trying to make the API self-limiting. Windows Explorer (the file manager) does for example offer users to edit images upon right-click. I worry that if URI scheme handlers need not only take care of fetching but also of presentation, other actions than view will be unnecessarily hard to implement. Thus I figure retrieval and presentation must be separated. (view (fetch uniform:resource/locator)) or (edit (fetch uniform:resource/locator)) instead of (fetch-and-view uniform:resource/locator) Is this use case not fully handled by the UA specifying the appropriate action when building the intent, e.g., the user right-clicks on an image in a page and the UA constructs context menu items for edit/share/etc. action?
Re: [whatwg] Web Intents with System-Wide Sharing Features
Definitely, though I'd limit it to a MAY recommendation. James On Mon, Feb 20, 2012 at 9:08 PM, Rodger Combs rodger.co...@gmail.com wrote: Mac OSX 10.8 (Mountain Lion), along with most mobile operating systems, has a system-wide sharing functionality. Could the Web Intents API add a SHOULD or MAY clause for adding web intents to the system-wide share sheet or similar functionality, rather than just on the web? It fits with a few other parts of the HTML5 spec that move towards OS integration (e.g. notifications, which would fit well with Android/iOS/OSX10.8's built-in notification centers).
[whatwg] Proposal: Deprecate registerProtocolHandler/registerContentHandler via Web Intents
We, the designers of the Web Intents draft API, have always seen Web
Intents as a superset of the functionality provided by
registerProtocolHandler (RPH) and registerContentHandler (RCH). To
follow this to the logical conclusion, we should be able to provide
functionally equivalent counterparts to RPH/RCH in Web Intents. This
proposal provides a means of deprecating RPH/RCH, replacing this
functionality with equivalent functionality from Web Intents.
For reference RPH/RCH are documented at [1]. The current draft of the
Web Intents API is at [2].
registerProtocolHandler
===
The registerProtocolHandler() method allows Web sites to register
themselves as possible handlers for particular schemes.
void registerProtocolHandler(DOMString scheme, DOMString url, DOMString title);
We propose the addition of a 'scheme' attribute to the Web Intents
service registration to handle this use case.
intent scheme=mailto
* |scheme| is the same as specified for RPH.
* If |scheme| is specified, |action| *should* (must?) be ignored.
Thus, with this proposal, when the user clicks a mailto:; link, the
UA will internally create a new intent containing the scheme and the
URL parameters as the data in the payload. This payload will be
delivered to the service the user picks. Note we’re considering
specifying the UA may optionally decode the parameters into the
|extras| object.
Given the following anchor on mypage.com:
a href=mailto:m...@mypage.com?bcc=supp...@mypage.comsubject=testing;
the UA will deliver the following payload to the selected service:
{
type: “text/plain”,
scheme: “mailto”,
data: “mailto:m...@mypage.com?bcc=supp...@mypage.comsubject=testing”,
extras: {
bcc: “supp...@mypage.com”,
subject: “testing” }
}
Open question: should we use the same whitelist of schemes used by RPH?
registerContentHandler
===
The registerContentHandler() method allows Web sites to register
themselves as possible handlers for content in a particular MIME type.
void registerContentHandler(DOMString mimeType, DOMString url,
DOMString title);
We propose modifying the relationship between the |action| and |type|
attributes to specify that if |action| is not specified and |type| is
specified, the action is implicitly 'view' and the service must be
shown in the picker when the UA encounters content of matching MIME
type.
intent type=image/png
The above registration would register the service to handle content of
MIME type image/png.
When the UA loads a resource of type image/png, it sends the type
and content to the service in the payload.
{
data: pngImageContent,
type: “image/png”
}
isProtocolHandlerRegistered / isContentHandlerRegistered
=
There are serious fingerprinting issues with these methods, and when
contemplating analogous methods for Web Intents, we thought long and
hard about the fingerprinting issue.
As spec'ed a site could call registerProtocolHandler('web+uniqueID',
...) where uniqueID is unique to a user. The site could then call
isProtocolHandlerRegistered with that matching 'web+uniqueID' to
verify who the user is.
One of the use cases for these methods is to allow a client site the
ability to show alternative UI for protocols/content that are not
capable of being handled by any service. Web Intents also requires a
solution for this use case, as showing an empty picker* is a
non-starter.
* The picker refers to the UI in the UA that shows registered services
for a given intent, allowing the user to pick which service to
activate.
Instead of creating analogous functionality of these methods for Web
Intents, we decided to tackle the problem state of an empty picker.
The proposed solution is to allow a client site to suggest a service
(URL) that is displayed by the UA in the picker. The
|suggestedService| parameter is optional.
startActivity(..., suggestedService);
In addition declarative registration removes the need to fashion
registration as:
if (!isProtocolHandlerRegistered(x))
registerProtocolHandler(x);
The work of maintaining that state is displaced to the UA.
unregisterProtocolHandler / unregisterContentHandler
===
The analogous functionality for these methods in Web Intents already
exists and is the same as the removal of any type of service: remove
the declarative registration from the content, and the UA will
unregister the service as a handler.
[1]
http://www.whatwg.org/specs/web-apps/current-work/multipage/timers.html#custom-handlers
[2] http://dvcs.w3.org/hg/web-intents/raw-file/tip/spec/Overview.html
Thanks,
James
Re: [whatwg] Proposal: intent tag for Web Intents API
On Thu, Dec 8, 2011 at 12:43 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 6 Dec 2011, James Hawkins wrote: One of the critical pieces of the API is a declarative registration which allows sites to declare which intents they may be registered for. The current draft of the API calls for a new HTML tag, intent, the attributes of which describe the service registration: [...] Separate from the issue of what precisely the element should look like, I wonder if you could expand on the precise use case for the element. In particular, I'm interested in whether this use case might also apply to some of the register*Handler() methods we have now. Ideally, it would be good to have the current protocol and content type handlers and the Web Intent stuff all use a coherent and consistent API. Absolutely, we're very keen on providing RPH/RCH functionality via Web Intents. Let me start with the use case for the intent element, then I'll get to R*H. *** Use cases *** The intent element serves as a declaration of functionality of a web app. For example, Twitter exposes share functionality, Picnik exposes editing functionality, Dropbox exposes pick/save functionality, etc. Once the user accepts these registrations (gives permission), the UA can connect a client requesting a given set of functionality to the service that previously exposed that functionality. The fact that the element is declarative is a win wrt sites that may wish to crawl the web to index which web app handles which functionality. See www.openintents.org/en/intentstable for an example of this for Android Intents. *** RPH/RCH *** registerProtocolHandler gives services a way to imperatively expose functionality that is to specific to protocols. Web Intents will handle this use case by adding a scheme/URL pattern attribute to the intent registration. Android Intents exposes scheme/URL pattern filtering as well, so this addition moves Web Intents that much closer to its model API. navigator.registerProtocolHandler(mailto, https://www.example.com/?uri=%s;, Mail Service); becomes intent scheme=mailto title=Mail Service Click here to install our Mail Service application! /intent registerContentHandler allows services to imperatively expose functionality that is specific to content types. Web Intents will provide this use case by special-casing the intent element when no action is provided for a particular MIME type. navigator.registerContentHandler(image/png, http://www.example.com/?foo=%s;, My Image Viewer); becomes intent type=image/png title=My Image Viewer Click here to install our Image Viewer application! /intent Of course the fallback content is optional and determined by the service, but we believe it's a great way to expose fallback functionality via installable extensions/apps/whatnot. *** Advantages *** Client-side handling. For R*H, ?foo=%s normally requires server side processing. With Web Intents, this data is passed completely client-side on the intent object. Wildcard matching. R*H does not allow wildcard matching, where as Web Intents would allow a service to register for image/* in one succinct registration. Thanks, James
[whatwg] Proposal: intent tag for Web Intents API
*** Overview ***
The W3C Web Intents Task Force is working on the Web Intents API at
public-web-inte...@w3.org: see the bottom of this email for details.
Web Intents is a web platform API that provides client-side service
discovery and inter-application communication. Services register to
handle high-level actions (e.g., share, edit, pick), while clients
invoke an intent (action + type + data). For example twitter.com may
allow the user to register the site as a provider of the 'share'
action.
One of the critical pieces of the API is a declarative registration
which allows sites to declare which intents they may be registered
for. The current draft of the API calls for a new HTML tag, intent,
the attributes of which describe the service registration:
!ENTITY % Disposition {window|inline}
!ELEMENT INTENT - O EMPTY -- a Web Intents registration -
!ATTLIST INTENT
action %URI; #REQUIRED -- URI specifying action --
type%ContentTypes; #IMPLIED -- advisory content types --
href%URI; #IMPLIED -- URI for linked resource --
title %i18n; #IMPLIED -- service title --
disposition %Disposition window-- where the service is created --
We settled on the intent tag after reviewing several alternatives
(see below). The intent tag offers the greatest ease-of-use for
developers, and the ability to crawl/index sites that support Intents.
One of the cool things about the declarative syntax is that it allows
one to create sites (like http://www.openintents.org/en/intentstable)
which serve as a database of services that support intents. We're
currently adding a section on webintents.org that allows the developer
of a service to be add his service to the registry by entering the
service URL, which we then crawl and index the intents.
One could also imagine exposing intent services using search engine technology.
*** Proposal ***
Add the intent tag to the HTML spec.
*** Alternatives ***
Imperative DOM registration: registerIntentHandler(...).
Pros:
* Analogous to registerProtocolHandler, registerContentHandler.
* Doesn't require addition to the HTML spec.
Cons:
* Not declarative, not as easy to index.
* Timing requirements unclear (Is the registration removed if a
service does not call registerIntentHandler() on the next visit? If so
how long does the UA need to wait to 'be sure'?)
* Heavier footprint in the DOM API.
* Less self-documenting code:
registerIntentHandler('webintents.org/share',
'text/uri-list',
'handler.html',
'My Sharer',
'inline');
intent action=webintents.org
type=text/uri-list
href=handler.html
title=My Sharer
disposition=inline
/intent
link rel=intents:
Pros:
* Declarative.
Cons:
* link rel has become a dumping ground for these type of usages.
* Need to modify HTML spec to add appropriate attributes.
CRX-less Web Apps
(http://code.google.com/intl/en-US/chrome/apps/docs/no_crx.html):
Pros:
* Declarative.
Cons:
* Not standardized.
* Requires extra level of indirection.
*** API Status ***
Within the W3C the Webapps WG is rechartering to include Web Intents
as a joint-deliverable with the DAP WG (which already had Intents in
its charter). Discussion is taking place about the API at
public-web-inte...@w3.org.
The draft API is current hosted at [1], though I'm working feverishly
to convert this into a W3C-style draft format.
[1]
https://sites.google.com/a/chromium.org/dev/developers/design-documents/webintentsapi
Our use cases, JavaScript shim, and example pages are hosted at
http://webintents.org.
Thanks,
James Hawkins
Re: [whatwg] Proposal: intent tag for Web Intents API
To clarify, my use of the word 'we' below is we the designers of the
API, not the participants of the Web Intents TF.
As stated in the 'API Status' section below, discussions about Web
Intents are ongoing in the TF. In addition, note that nothing is
finalized in the Web Intents API as of yet.
Since the registration aspect of the current draft of the API requires
the addition of a new tag, I decided to hold that discussion on the
appropriate ML, namely this ML.
Thanks,
James
On Tue, Dec 6, 2011 at 10:00 AM, James Hawkins jhawk...@google.com wrote:
*** Overview ***
The W3C Web Intents Task Force is working on the Web Intents API at
public-web-inte...@w3.org: see the bottom of this email for details.
Web Intents is a web platform API that provides client-side service
discovery and inter-application communication. Services register to
handle high-level actions (e.g., share, edit, pick), while clients
invoke an intent (action + type + data). For example twitter.com may
allow the user to register the site as a provider of the 'share'
action.
One of the critical pieces of the API is a declarative registration
which allows sites to declare which intents they may be registered
for. The current draft of the API calls for a new HTML tag, intent,
the attributes of which describe the service registration:
!ENTITY % Disposition {window|inline}
!ELEMENT INTENT - O EMPTY -- a Web Intents registration -
!ATTLIST INTENT
action %URI; #REQUIRED -- URI specifying action --
type %ContentTypes; #IMPLIED -- advisory content types --
href %URI; #IMPLIED -- URI for linked resource --
title %i18n; #IMPLIED -- service title --
disposition %Disposition window -- where the service is created --
We settled on the intent tag after reviewing several alternatives
(see below). The intent tag offers the greatest ease-of-use for
developers, and the ability to crawl/index sites that support Intents.
One of the cool things about the declarative syntax is that it allows
one to create sites (like http://www.openintents.org/en/intentstable)
which serve as a database of services that support intents. We're
currently adding a section on webintents.org that allows the developer
of a service to be add his service to the registry by entering the
service URL, which we then crawl and index the intents.
One could also imagine exposing intent services using search engine
technology.
*** Proposal ***
Add the intent tag to the HTML spec.
*** Alternatives ***
Imperative DOM registration: registerIntentHandler(...).
Pros:
* Analogous to registerProtocolHandler, registerContentHandler.
* Doesn't require addition to the HTML spec.
Cons:
* Not declarative, not as easy to index.
* Timing requirements unclear (Is the registration removed if a
service does not call registerIntentHandler() on the next visit? If so
how long does the UA need to wait to 'be sure'?)
* Heavier footprint in the DOM API.
* Less self-documenting code:
registerIntentHandler('webintents.org/share',
'text/uri-list',
'handler.html',
'My Sharer',
'inline');
intent action=webintents.org
type=text/uri-list
href=handler.html
title=My Sharer
disposition=inline
/intent
link rel=intents:
Pros:
* Declarative.
Cons:
* link rel has become a dumping ground for these type of usages.
* Need to modify HTML spec to add appropriate attributes.
CRX-less Web Apps
(http://code.google.com/intl/en-US/chrome/apps/docs/no_crx.html):
Pros:
* Declarative.
Cons:
* Not standardized.
* Requires extra level of indirection.
*** API Status ***
Within the W3C the Webapps WG is rechartering to include Web Intents
as a joint-deliverable with the DAP WG (which already had Intents in
its charter). Discussion is taking place about the API at
public-web-inte...@w3.org.
The draft API is current hosted at [1], though I'm working feverishly
to convert this into a W3C-style draft format.
[1]
https://sites.google.com/a/chromium.org/dev/developers/design-documents/webintentsapi
Our use cases, JavaScript shim, and example pages are hosted at
http://webintents.org.
Thanks,
James Hawkins
Re: [whatwg] Proposal: intent tag for Web Intents API
On Tue, Dec 6, 2011 at 1:08 PM, James Graham jgra...@opera.com wrote: On Tue, 6 Dec 2011, Anne van Kesteren wrote: Especially changing the way head is parsed is hairy. Every new element we introduce there will cause a body to be implied before it in down-level clients. That's very problematic. Yes, I consider adding new elements to head to be very very bad for this reason. Breaking DOM consistency between supporting and non-supporting browsers can cause adding an intent to cause unrelated breakage (e.g. by changing document.body.firstChild). Originally we envisioned using a self-closing tag placed in head for the intent tag; however, we're now leaning towards not using self-closing and having the tag be placed in the body with fallback content, e.g., to install an extension to provide similar functionality. intent action=webintents.org/share Click here to install our extension that implements sharing! /intent What are your thoughts on this route? James
Re: [whatwg] Proposal: intent tag for Web Intents API
On Tue, Dec 6, 2011 at 1:16 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Tue, Dec 6, 2011 at 1:14 PM, James Hawkins jhawk...@google.com wrote: Originally we envisioned using a self-closing tag placed in head for the intent tag; however, we're now leaning towards not using self-closing and having the tag be placed in the body with fallback content, e.g., to install an extension to provide similar functionality. intent action=webintents.org/share Click here to install our extension that implements sharing! /intent What are your thoughts on this route? So, when the intent tag is supported, it's not displayed at all, and instead solely handled by the browser? This seems okay to me. Correct.
