- From: <richard.tibbett@orange-ftgroup.com>
- Date: Tue, 1 Dec 2009 16:15:11 +0100
- To: <robin@robineko.com>, <dom@w3.org>
- Cc: <public-device-apis@w3.org>
On 1st Dec 2009, at 14:03, Robin Berjon wrote: > > On Dec 1, 2009, at 13:40 , Dominique Hazael-Massieux wrote: > > Le mardi 01 décembre 2009 à 14:30 +0100, Robin Berjon a écrit : > >> With <input type=contact> the user gets a text field. Neither of > >> those is a really nice experience. > > > > But in both of the markup options, the <input type='foo'> > field could > > be conditionally added by the script based on detecting support for > > the API. > > Yes, I'm not saying that it's impossible, just that it's not > necessarily ideal - in other words, we should look at the > ramifications. > > Another option, which may just be crazy: > > <form enctype='something-magic-about-dap-contacts' onsubmit='foo()'> > <input type='text' name='given-name'/> > <input type='text' name='family-name'/> > <!-- other stuff --> > </form> > > On implementations that support this entry point, you'd get a > way of selecting contacts, triggered from the magic enctype. > On older implementations, you fall back to the form. > > I'm not saying it's a great way to go about it, just that > there may be other alternative markup-based entry points (and > that in some cases there won't be a good markup option). > So is it important to include a markup annex (whatever it actually looks like) in our specs before FPWD or should we just include a note in the draft that we are also looking in to additional options (as Robin suggested)? i.e. is it on the critical path RE: browser integration? Thanks, Richard
Received on Tuesday, 1 December 2009 15:15:49 UTC