W3C home > Mailing lists > Public > whatwg@whatwg.org > August 2011

[whatwg] Proposal for a web application descriptor

From: Cameron Heavon-Jones <cmhjones@gmail.com>
Date: Wed, 3 Aug 2011 12:24:47 +0100
Message-ID: <8C03DD9A-4526-48BB-8FA5-EF0DBFCA8EF6@gmail.com>

On 02/08/2011, at 11:50 PM, Ian Hickson wrote:
> On Wed, 27 Jul 2011, Cameron Heavon-Jones wrote:
>> 
>> The mapping of "tel" and "email" inputs to a contacts list is 
>> functional, not systematic. Might this be extended for some other 
>> inputs: date(*), url, search etc?
>> 
>> This functionality may be declared and defined through a new attribute, 
>> since autocomplete is already used, something like "autoassist"?
>> 
>> Maybe this would be able to over-ride the default "file" input behaviour 
>> of launching a popup in the case i just want to manually enter a 
>> file:///
> 
> I'm not sure I really understand what you are describing here.
> 

Registered as feature request with additional information:

http://www.w3.org/Bugs/Public/show_bug.cgi?id=13602

> 
>>> There are definite UX limitations to that approach - the content can't 
>>> provide visual hinting during the autocomplete, for example (it would 
>>> be nice if a photo gallery could trim down the set of photos from my 
>>> friends as I narrow in on the name).
>> 
>> This would seems to be ok as long as the contents remain sandboxed until 
>> selection is confirmed.
> 
> Assuming the photos are server-side, there's no way to do this without 
> giving the app essentially full read access to the contacts.

My assumption was that this was client-side. It makes no difference though, in the case of file selection through a modal dialog, the requesting page has no knowledge of if the file is coming from a local hard drive or networked resource, this is the power of the abstraction. It works the same for network-only resources.

> 
> 
>> It would be nice for a page\site\app to still be able to access a full 
>> contacts list if desired. Though it would seem to extend the integration 
>> into the full Contacts API which is of far larger scope.
> 
> There is definitely a question of whether there should be an API for this 
> specific case or if there are so many that we need a generic solution.
> 

Yes, i'm not pursuing a Contacts API however. It's too big in scope when there are simpler and more generic solutions for richer UIs, and which leave browser to distinguish themselves for aesthetics and user preferences.

> -- 
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


Thanks,
Cameron Jones
Received on Wednesday, 3 August 2011 04:24:47 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:35 UTC