Re: [whatwg] Proposal to add website-* meta extensions

2014-07-17 Thread Mounir Lamouri
On Wed, 16 Jul 2014, at 21:41, Arpita Bahuguna wrote:
 Hi Mounir,
 
 Agree! These meta extensions do appear to be an appropriate fit for the
 Web
 Manifest.
 However, am not sure how well the Manifest would be able to handle
 dynamically changing values for these extensions.
 
 Consider the use-case wherein, based on the location of the user,
 JavaScript
 changes the value of the website-number meta extension to give a more
 relevant contact phone number.
 As a meta extension, this is easily achievable.
 But would the content provider be able to change the values based on the
 location via Manifest? (do pardon my lack of knowledge in this area)

For the moment, the Web Manifest specification doesn't provide an API to
modify the Manifest after the page load. However, the server can provide
a different manifest depending on the user. It seems that serving
different manifest is probably what you should do here.

-- Mounir


Re: [whatwg] Proposal to add website-* meta extensions

2014-07-16 Thread Arpita Bahuguna
Hi Julian,

Thank-you for your views.

Are you suggesting that we instead introduce a new link relation (perhaps
contact) with tel:/mailto: types for specifying these parameters?

This would involve spec modification. Not sure how developers or browser
vendors take to it.

Was looking for a simpler solution that's quickly implementable.

Regards,
Arpita


On Tue, Jul 15, 2014 at 6:14 PM, Julian Reschke julian.resc...@gmx.de
wrote:

 On 2014-07-15 12:11, Arpita Bahuguna wrote:

 Hi,

 I would like to propose addition of the following three meta extensions:
 website-mail, website-number and website-address.

 Please find below a detailed description for each.

 --- x - x
 --- x --

 Overview:

 The website-mail meta extension defines a suggested e-mail ID, such as the
 customer support mail ID, specified by the vendor.

 The website-number meta extension defines a proposed phone number, such as
 the customer support number, specified by the vendor.

 The website-address meta extension defines a given address (or geolocation
 tag), such as the vendor's office address or billing address.



 UA's displaying a page containing any or all of these meta extensions
 could
 then make this information directly available for the user's perusal.



 Oft times visitors have to hunt through a vendor's site for obtaining the
 customer support mail ID, phone number etc. which is mostly hidden behind
 a
 not so prominently displayed Help or Contact Us link.

 Vendor's specifying their registered mail ID, phone number and/or their
 address via these meta extensions can thus expect supporting UA's to
 present
 this information to the user in an easily accessible format, either by way
 of a browser menu option (such as mail, call, map) or via the URL
 bar
 scheme handler or in another similar format.

 Selecting these menu options, if available, should launch the default mail
 application with the specified mail ID, the dialer application with the
 given contact number or, the default maps application loaded with the
 specified address/location tag respectively.

 No known existing meta extensions with a similar name/intention exist.

 Syntax:

 meta name=website-mail content=a...@xyz.com


 This should be a link relation, using by default a mailto:; URI.


  The content attribute for the website-mail meta extension can take any
 valid
 email ID.

 meta name=website-number content=+1-555-555-


 This should have a better name, and also be a link relation, using a
 tel: URI.

  The content attribute for the website-number meta extension can take any
 valid phone number.

 meta name=website-address content=Jane Doe, 5844 South Oak Street,
 Chicago, Illinois 60667 or

 meta name=website-address content=20.593684;78.96288

 The content attribute for the website-address meta extension can be any
 string or latitude and longitude separated by a semi-colon.

 Note:

 . In case multiple instances are found of the same meta extension,
 the last specified one should take precedence.
 ...


 In general, a single link to a URI having contact information seems to be
 much simpler to me...

 Best regards, Julian



Re: [whatwg] Proposal to add website-* meta extensions

2014-07-16 Thread Julian Reschke

On 2014-07-16 11:31, Arpita Bahuguna wrote:

Hi Julian,

Thank-you for your views.

Are you suggesting that we instead introduce a new link relation
(perhaps contact) with tel:/mailto: types for specifying these parameters?

This would involve spec modification. Not sure how developers or browser
vendors take to it.


Why would it involve a spec modification?


Was looking for a simpler solution that's quickly implementable.


Why is meta any simpler than link???



Re: [whatwg] Proposal to add website-* meta extensions

2014-07-16 Thread Arpita Bahuguna
Hi Julian,

Please find my comments inline:

-Original Message-
From: whatwg [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Julian 
Reschke
Sent: Wednesday, July 16, 2014 3:10 PM
To: Arpita Bahuguna
Cc: wha...@whatwg.org; Arpita Bahuguna
Subject: Re: [whatwg] Proposal to add website-* meta extensions

On 2014-07-16 11:31, Arpita Bahuguna wrote:
 Hi Julian,

 Thank-you for your views.

 Are you suggesting that we instead introduce a new link relation 
 (perhaps contact) with tel:/mailto: types for specifying these parameters?

 This would involve spec modification. Not sure how developers or 
 browser vendors take to it.

Why would it involve a spec modification?

Currently the link types defined by the specification are: 
http://www.whatwg.org/specs/web-apps/current-work/#linkTypes

Please correct me if I am wrong but I suspect introducing a new rel type would 
involve modifying the spec as well.
Adding new meta extensions however would not have any such overhead as far as I 
know. 


 Was looking for a simpler solution that's quickly implementable.

Why is meta any simpler than link???



Re: [whatwg] Proposal to add website-* meta extensions

2014-07-16 Thread Mounir Lamouri
On Tue, 15 Jul 2014, at 20:11, Arpita Bahuguna wrote:
 I would like to propose addition of the following three meta extensions:
 website-mail, website-number and website-address.

It seems that those meta extensions would be good candidates for the Web
Manifest: http://w3c.github.io/manifest/

-- Mounir


Re: [whatwg] Proposal to add website-* meta extensions

2014-07-16 Thread Julian Reschke

On 2014-07-16 12:01, Arpita Bahuguna wrote:

Hi Julian,

Please find my comments inline:

-Original Message-
From: whatwg [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Julian 
Reschke
Sent: Wednesday, July 16, 2014 3:10 PM
To: Arpita Bahuguna
Cc: wha...@whatwg.org; Arpita Bahuguna
Subject: Re: [whatwg] Proposal to add website-* meta extensions

On 2014-07-16 11:31, Arpita Bahuguna wrote:

Hi Julian,

Thank-you for your views.

Are you suggesting that we instead introduce a new link relation
(perhaps contact) with tel:/mailto: types for specifying these parameters?

This would involve spec modification. Not sure how developers or
browser vendors take to it.


Why would it involve a spec modification?

Currently the link types defined by the specification are: 
http://www.whatwg.org/specs/web-apps/current-work/#linkTypes

Please correct me if I am wrong but I suspect introducing a new rel type would 
involve modifying the spec as well.


No. There's a Wiki for it.


Adding new meta extensions however would not have any such overhead as far as I 
know.



Was looking for a simpler solution that's quickly implementable.


Why is meta any simpler than link???






Re: [whatwg] Proposal to add website-* meta extensions

2014-07-16 Thread Arpita Bahuguna
Hi Mounir,

Agree! These meta extensions do appear to be an appropriate fit for the Web
Manifest.
However, am not sure how well the Manifest would be able to handle
dynamically changing values for these extensions.

Consider the use-case wherein, based on the location of the user, JavaScript
changes the value of the website-number meta extension to give a more
relevant contact phone number.
As a meta extension, this is easily achievable.
But would the content provider be able to change the values based on the
location via Manifest? (do pardon my lack of knowledge in this area)

Would appreciate your thoughts on the same.

Regards,
Arpita

-Original Message-
From: Mounir Lamouri [mailto:mou...@lamouri.fr] 
Sent: Wednesday, July 16, 2014 3:32 PM
To: Arpita Bahuguna; wha...@whatwg.org
Subject: Re: [whatwg] Proposal to add website-* meta extensions

On Tue, 15 Jul 2014, at 20:11, Arpita Bahuguna wrote:
 I would like to propose addition of the following three meta extensions:
 website-mail, website-number and website-address.

It seems that those meta extensions would be good candidates for the Web
Manifest: http://w3c.github.io/manifest/

-- Mounir



Re: [whatwg] Proposal to add website-* meta extensions

2014-07-15 Thread Julian Reschke

On 2014-07-15 12:11, Arpita Bahuguna wrote:

Hi,

I would like to propose addition of the following three meta extensions:
website-mail, website-number and website-address.

Please find below a detailed description for each.

--- x - x
--- x --

Overview:

The website-mail meta extension defines a suggested e-mail ID, such as the
customer support mail ID, specified by the vendor.

The website-number meta extension defines a proposed phone number, such as
the customer support number, specified by the vendor.

The website-address meta extension defines a given address (or geolocation
tag), such as the vendor's office address or billing address.



UA's displaying a page containing any or all of these meta extensions could
then make this information directly available for the user's perusal.



Oft times visitors have to hunt through a vendor's site for obtaining the
customer support mail ID, phone number etc. which is mostly hidden behind a
not so prominently displayed Help or Contact Us link.

Vendor's specifying their registered mail ID, phone number and/or their
address via these meta extensions can thus expect supporting UA's to present
this information to the user in an easily accessible format, either by way
of a browser menu option (such as mail, call, map) or via the URL bar
scheme handler or in another similar format.

Selecting these menu options, if available, should launch the default mail
application with the specified mail ID, the dialer application with the
given contact number or, the default maps application loaded with the
specified address/location tag respectively.

No known existing meta extensions with a similar name/intention exist.

Syntax:

meta name=website-mail content=a...@xyz.com


This should be a link relation, using by default a mailto:; URI.


The content attribute for the website-mail meta extension can take any valid
email ID.

meta name=website-number content=+1-555-555-


This should have a better name, and also be a link relation, using a 
tel: URI.



The content attribute for the website-number meta extension can take any
valid phone number.

meta name=website-address content=Jane Doe, 5844 South Oak Street,
Chicago, Illinois 60667 or

meta name=website-address content=20.593684;78.96288

The content attribute for the website-address meta extension can be any
string or latitude and longitude separated by a semi-colon.

Note:

. In case multiple instances are found of the same meta extension,
the last specified one should take precedence.
...


In general, a single link to a URI having contact information seems to 
be much simpler to me...


Best regards, Julian