Re: [whatwg] URN or protocol attribute

2010-06-03 Thread Brett Zamir

On 3/11/2010 10:44 AM, Brett Zamir wrote:

On 3/11/2010 10:31 AM, Ian Hickson wrote:

I would recommend following a pattern somewhat like the Web's initial
development: create a proof of concept, and convince people that it's 
what
they want. That's the best way to get a feature adopted. This is 
described

in more detail in the FAQ:


http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F 



Ok, fair enough. I think I'll try that as a browser extension snip


Just as a follow-up, I have now made a Firefox extension which supports 
two attributes on a/: uris and alternateURIs, whereby the former 
takes precedence over href, and the latter are accessible only by 
right-clicking links (though potentially discoverable by custom styling 
of such links (automatable by the extension)).


My thought is that sites which have the following goals may be 
particularly interested:


1) Those wishing to maintain objectivity and refrain from endorsing 
specific sites, e.g., governments, news institutions, scholars, or sites 
like Wikipedia. Even for a site's internal links, use of alternateURIs 
could offer convenience (e.g., Wikipedia would no doubt wish to continue 
to use href to refer to its own ISBN page by default, but could use the 
alternateURIs attribute to allow right-clicks on the link to activate 
the URN link which in turn activates their chosen default handler, e.g., 
Amazon, Google Books, etc.). The same could be done for music, etc.
2) giving full user choice as to how to view the data (especially useful 
for information of common and particular interest to the site viewers, 
e.g., links to the Bible in a religious forum)
3) those wishing to try out new protocols of whatever type (not only 
URNs), such as chatting protocols, whether installed via web or browser 
extension, as the proposed markup gives them a convenient fall-back to 
href, so they don't have to have dead links for those whose browsers 
do not support the protocol.


https://addons.mozilla.org/en-US/firefox/addon/162154/

Brett



Re: [whatwg] URN or protocol attribute

2010-06-03 Thread Brett Zamir

On 6/4/2010 12:59 PM, Brett Zamir wrote:

On 3/11/2010 10:44 AM, Brett Zamir wrote:

On 3/11/2010 10:31 AM, Ian Hickson wrote:

I would recommend following a pattern somewhat like the Web's initial
development: create a proof of concept, and convince people that 
it's what
they want. That's the best way to get a feature adopted. This is 
described

in more detail in the FAQ:


http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F 



Ok, fair enough. I think I'll try that as a browser extension snip


Just as a follow-up, I have now made a Firefox extension which 
supports two attributes on a/: uris and alternateURIs, whereby 
the former takes precedence over href, and the latter are accessible 
only by right-clicking links (though potentially discoverable by 
custom styling of such links (automatable by the extension)).


My thought is that sites which have the following goals may be 
particularly interested:


1) Those wishing to maintain objectivity and refrain from endorsing 
specific sites, e.g., governments, news institutions, scholars, or 
sites like Wikipedia. Even for a site's internal links, use of 
alternateURIs could offer convenience (e.g., Wikipedia would no 
doubt wish to continue to use href to refer to its own ISBN page by 
default, but could use the alternateURIs attribute to allow 
right-clicks on the link to activate the URN link which in turn 
activates their chosen default handler, e.g., Amazon, Google Books, 
etc.). The same could be done for music, etc.
2) giving full user choice as to how to view the data (especially 
useful for information of common and particular interest to the site 
viewers, e.g., links to the Bible in a religious forum)
3) those wishing to try out new protocols of whatever type (not only 
URNs), such as chatting protocols, whether installed via web or 
browser extension, as the proposed markup gives them a convenient 
fall-back to href, so they don't have to have dead links for those 
whose browsers do not support the protocol.


https://addons.mozilla.org/en-US/firefox/addon/162154/


Just to elaborate a little bit further, one possible future addition 
which could further enhance this experience would be to design a 
protocol (and corresponding markup-detection mechanism), say created: 
or wiki: which would first check via HEAD request whether the page 
were created or not, and then style the link accordingly and possibly 
alter the URL to lead directly to the editing or alternatively, it could 
make HEAD requests to try out a sequence of URLs, e.g., checking whether 
Citizendium had an article, and if not, creating a link to the Wikipedia 
article if present. While this could be done potentially via the server 
(e.g., this extension for Mediawiki: 
http://www.mediawiki.org/wiki/Extension:BADI_Pages_Created_Links ), I 
believe allowing client-side markup to do it would facilitate use of 
this potential more widely, allowing wikis or open-forums to link with 
one another in a way which prevents wasted visits by their users.


Although URNs could also be used (as supported already potentially in 
the above extension) to try to find encyclopedic articles (e.g., 
urn:name:pizza), or better yet, through a new protocol which could 
suggest intended uses of the information (e.g., 
find:urn:name:pizza?category=order, find:urn:name:pizza?category=define, 
etc.) and thereby avoiding hard-coding information, the created: 
suggestion above could give authors more control than they have now if 
they did want to suggest a particular path-way.


Brett



Re: [whatwg] URN or protocol attribute

2010-03-10 Thread Ian Hickson
On Mon, 8 Feb 2010, Brett Zamir wrote:
 
 Internet Explorer has an attribute on anchor elements for URNs:
 http://msdn.microsoft.com/en-us/library/ms534710%28VS.85%29.aspx
 
 This has not caught on in other browsers, though I believe it could be a very
 powerful feature once the feature was supported with a UI that handled URNs
 (as with adding support for custom protocols).
 
 Imagine, for example, to take a link like:
 
 a href=http://www.amazon.com/...(shortened)
 urn=isbn:9210020251United Nations charter/a
 
 The default behavior would simply follow the link, but if a user agent 
 supported the @urn attribute, and if the browser (or browser add-ons) 
 had registered support for that URN namespace identifier (here isbn), 
 it could, for example, open a dialog to ask which handler to use (or 
 whether to always use it), it could ask or otherwise allow in 
 preferences an HTML page (with wildcards) where the attribute's content 
 could be passed, or it could give the option whenever the user 
 right-clicked to choose which handler they wanted to use for a given 
 link.

Does this match IE's behaviour with the urn= attribute?


Historically, browsers that have wanted to offer dedicated services for 
specific features, e.g. the iPhone handling map views using a dedicated 
Maps application, have done so by simply overriding parts of the URL 
space, e.g. in that case detecting when a page is on the Google Maps site 
and parsing the URL locally instead of sending it to the remote site.

Is there really a need for a more dedicated mechanism? It's not clear that 
there is much pent-up demand for this.

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


Re: [whatwg] URN or protocol attribute

2010-03-10 Thread Brett Zamir

On 3/11/2010 9:19 AM, Ian Hickson wrote:

On Mon, 8 Feb 2010, Brett Zamir wrote:
   

Internet Explorer has an attribute on anchor elements for URNs:
http://msdn.microsoft.com/en-us/library/ms534710%28VS.85%29.aspx

This has not caught on in other browsers, though I believe it could be a very
powerful feature once the feature was supported with a UI that handled URNs
(as with adding support for custom protocols).

Imagine, for example, to take a link like:

a href=http://www.amazon.com/...(shortened)
urn=isbn:9210020251United Nations charter/a

The default behavior would simply follow the link, but if a user agent
supported the @urn attribute, and if the browser (or browser add-ons)
had registered support for that URN namespace identifier (here isbn),
it could, for example, open a dialog to ask which handler to use (or
whether to always use it), it could ask or otherwise allow in
preferences an HTML page (with wildcards) where the attribute's content
could be passed, or it could give the option whenever the user
right-clicked to choose which handler they wanted to use for a given
link.
 

Does this match IE's behaviour with the urn= attribute?

   
No, to my knowledge, there is no special behavior in IE with regard to 
how it is used. I was really more listing it as a precedent, since I was 
more in favor of a more general purpose defaultProtocol attribute 
which could not only allow URNs but other protocols to be tried before 
defaulting to a regular href link.



Historically, browsers that have wanted to offer dedicated services for
specific features, e.g. the iPhone handling map views using a dedicated
Maps application, have done so by simply overriding parts of the URL
space, e.g. in that case detecting when a page is on the Google Maps site
and parsing the URL locally instead of sending it to the remote site.

   
The problem with this is that it is not an approach which can likely be 
taken by browser extensions nor be offered to websites which wish to 
register themselves as handlers. And URNs by definition are not specific 
to any site.

Is there really a need for a more dedicated mechanism? It's not clear that
there is much pent-up demand for this.
   


There wasn't a lot of pent up demand for the web itself either (why 
would people or companies want to link to other people's sites?); if 
people aren't able to use a feature or know of the concept, they might 
not think of asking for it. I think that as with my earlier suggestion 
on shared databases or storage, I think people are just not accustomed 
to thinking that the web can be used in a way which collaborates between 
sites (more than mere links), since the first idea that pops into 
people's minds is how they can put their own site up. That doesn't mean 
they wouldn't like to work with other sites or offer a feature that 
would have normal fallback behavior in browsers that didn't support it.


If people can see a need for registering protocol handlers, the 
defaultProtocol attribute is I think the best way to make it work.  
Why would someone want to experiment in using a protocol (including 
urn:), say ISBN:, if the interface will only say to their users, This 
browser does not recognize that protocol/namespace ID. The 
defaultProtocol attribute would give a chance for the protocol/URN NID 
to be checked for support, but if not working could default to visiting 
the href target. Wouldn't that be a useful feature? Few will 
experiment with a href=urn:isbn:../a as it is just a dead link 
for browsers that don't support the protocol, but I'm sure many sites 
would be willing to allow a defaultProtocol=urn:isbn:... 
href=http://books...;.../a as it doesn't hurt to add one extra 
attribute, even if say browsers are slow at supporting the attribute.


The web is not only about companies that want to make money and shuffle 
people in the direction they want. There are also sites (including 
companies without a stake in certain content) who want to offer more 
choice to their users (e.g., Wikipedia, governments, individuals, etc.). 
And no doubt any company wouldn't mind being able to register themselves 
in a way where they could offer themselves to users visiting those more 
neutral sites (e.g., Amazon registering itself for links leading to ISBN 
links at other sites). It simply offers more choice to users...


Brett



Re: [whatwg] URN or protocol attribute

2010-03-10 Thread Ian Hickson
On Thu, 11 Mar 2010, Brett Zamir wrote:
 
  Is there really a need for a more dedicated mechanism? It's not clear 
  that there is much pent-up demand for this.
 
 There wasn't a lot of pent up demand for the web itself either (why 
 would people or companies want to link to other people's sites?); if 
 people aren't able to use a feature or know of the concept, they might 
 not think of asking for it.

That's true, but we only have so many resources, so we have to prioritise. 
Things that have pent-up demand are typically more important. :-)

I would recommend following a pattern somewhat like the Web's initial 
development: create a proof of concept, and convince people that it's what 
they want. That's the best way to get a feature adopted. This is described 
in more detail in the FAQ:

   
http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F

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


Re: [whatwg] URN or protocol attribute

2010-03-10 Thread Brett Zamir

On 3/11/2010 10:31 AM, Ian Hickson wrote:

On Thu, 11 Mar 2010, Brett Zamir wrote:
   

Is there really a need for a more dedicated mechanism? It's not clear
that there is much pent-up demand for this.
   

There wasn't a lot of pent up demand for the web itself either (why
would people or companies want to link to other people's sites?); if
people aren't able to use a feature or know of the concept, they might
not think of asking for it.
 

That's true, but we only have so many resources, so we have to prioritise.
Things that have pent-up demand are typically more important. :-)

I would recommend following a pattern somewhat like the Web's initial
development: create a proof of concept, and convince people that it's what
they want. That's the best way to get a feature adopted. This is described
in more detail in the FAQ:


http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F
   


Ok, fair enough. I think I'll try that as a browser extension, as well 
as possibly the other idea of a shared database API which I think has 
the potential to become an even more powerful feature (e.g., a local 
calendar to which any site could offer to add events and be viewed on 
the web or in a browser extension)... But there still may be some things 
(like an official auxiliary world language!) which can only show their 
real benefits (and potential demand) when implemented across the board...


Brett



Re: [whatwg] URN or protocol attribute

2010-02-10 Thread Simon Pieters
On Wed, 10 Feb 2010 08:55:56 +0100, Martin Atkins  
m...@degeneration.co.uk wrote:




Brett Zamir wrote:

Hi,
 Internet Explorer has an attribute on anchor elements for URNs:  
http://msdn.microsoft.com/en-us/library/ms534710%28VS.85%29.aspx



Internet Explorer supports a non-standard attribute on the A element  
called urn, which accepts an URN identifying some resource.


It is described in detail here:
http://msdn.microsoft.com/en-us/library/ms534710(VS.85).aspx

It is not apparent that this attribute causes any behavior in the  
browser itself. It is possible that this is exposed to browser  
extensions in some way to allow them to overload the behavior of a link  
which identifies a particular class of resource.


It does not seem that this attribute has achieved wide author adoption  
nor wide application support.


IE's .urn attribute is present on *all* elements, and is part of IE's  
namespaces. It's the equivalent of DOM's .namespaceURI.


--
Simon Pieters
Opera Software


Re: [whatwg] URN or protocol attribute

2010-02-10 Thread Thomas Broyer
On Wed, Feb 10, 2010 at 1:36 PM, Simon Pieters wrote:
 On Wed, 10 Feb 2010 08:55:56 +0100, Martin Atkins wrote:


 Brett Zamir wrote:

 Hi,
  Internet Explorer has an attribute on anchor elements for URNs:
 http://msdn.microsoft.com/en-us/library/ms534710%28VS.85%29.aspx


 Internet Explorer supports a non-standard attribute on the A element
 called urn, which accepts an URN identifying some resource.

 It is described in detail here:
 http://msdn.microsoft.com/en-us/library/ms534710(VS.85).aspx
[...]

 IE's .urn attribute is present on *all* elements, and is part of IE's
 namespaces. It's the equivalent of DOM's .namespaceURI.

Simon, you're confusing .urn with .tagUrn:
http://msdn.microsoft.com/en-us/library/ms534658(VS.85).aspx

-- 
Thomas Broyer
/tɔ.ma.bʁwa.je/


Re: [whatwg] URN or protocol attribute

2010-02-10 Thread Brett Zamir

On 2/10/2010 3:55 PM, Martin Atkins wrote:


Brett Zamir wrote:

Hi,

Internet Explorer has an attribute on anchor elements for URNs: 
http://msdn.microsoft.com/en-us/library/ms534710%28VS.85%29.aspx


This has not caught on in other browsers, though I believe it could 
be a very powerful feature once the feature was supported with a UI 
that handled URNs (as with adding support for custom protocols).


Imagine, for example, to take a link like:

a href=http://www.amazon.com/...(shortened) 
urn=isbn:9210020251United Nations charter/a



[snip details]

I like what this proposal achieves, but I'm not sure it's the right 
solution.


Here's an attempt at stating what problem you're trying to solve 
without any specific implementation: (please correct me if I 
misunderstood)


 * Provide a means to link to or operate on a particular artifact 
without necessarily requiring that the artifact be retrieved from a 
specific location.


 * Provide graceful fallback to user-agents which do not have any 
specialized handling for a particular artifact.



Yes, exactly.
This is different to simply linking to a different URL scheme (for 
example, linking a mailto: URL in order to begin an email message 
without knowing the user's preferred email provider) because it 
provides a fallback behavior for situations where there is no handler 
available for a particular artifact.


Yes. But note also that it would be possible to have the @protocol 
attribute be, for example, be used for already frequent protocols like 
mailto:, and the @href be http: . Or, to use a URN, the protocol could 
be urn:isbn:... and the @href could be http, etc.


Since 'href' also links to a protocol, it might be more clear for the 
proposed attribute to be called something like @defaultProtocol.



== Example Use-cases ==

 * View a particular book, movie or other such product without 
favoring a particular vendor.


 * View a map of the location for particular address or directions to 
that address without favoring a particular maps provider.


 * View a Spanish translation of some web document without favoring a 
particular translation provider.


 * Share a link/photo/etc with friends without favoring a particular 
publishing platform. (i.e. generalizing the Tweet This, Share on 
Facebook, class of links)




Yes. This would of course depend on the protocols existing. For example, 
XMPP as an open protocol, might work for your last examples if those 
services were actually using XMPP. And your other examples would also be 
excellent use cases.



== Prior Art ==

=== Android OS Intents ===

The Android OS has a mechanism called Intents[1] which allow one 
application to describe an operation it needs have performed without 
nominating a particular other application to perform it.


Intents are described in detail here:
http://developer.android.com/guide/topics/intents/intents-filters.html

An intent that does not identify a particular application consists of 
the following properties:


 * Action: a verb describing what needs to be done. For example, 
view, edit, choose, share, call.
 * Object: the URI of a particular thing that the action is to be done 
to. This is not specified for actions that apply only to a class of 
object, such as choose.
 * Object Type: the MIME type of the Object, or if no particular 
Object is selected a concrete MIME type or wildcard MIME type (e.g. 
image/*) describing the class of object that the action relates to.


A process called Intent Resolution is used to translate an abstract 
intent like the above into an explicit intent which nominates a 
particular handler.


Often when applications use intents a UI is displayed which allows a 
user to choose one of several available applications that can perform 
the action. For example, the built-in photo gallery application 
provides a Share command on a photo. By default, this can be handled 
by application such as the email client and the MMS application, but 
other applications can declare their support for intents of this type 
thus allowing plug-in functionality such as sharing a photo on Facebook.




That's an interesting consideration.

I think some behaviors should be necessarily limited with links (as they 
are in HTTP disallowing a link to make a POST or PUT request or upload a 
form (without JavaScript at least))--so that, e.g., spam links don't 
cause users to accidentally do things they didn't want to do. So 
side-effects should probably not occur (like share at least), unless 
it was merely, as in your use cases with Twitter/Facebook to lead to a 
UI control confirming that you wanted to share.


Unlike URNs, a regular protocol could already handle the use cases you 
mention, and perhaps the Intents mechanism could itself be made into a 
protocol: e.g.,:


android:intents;action=CALL;data=tel:123-555-1212

Being that experimentation here is fairly early on, and being that there 
may be too many types of fundamental actions/data/etc. to agree 

Re: [whatwg] URN or protocol attribute

2010-02-09 Thread Martin Atkins


Brett Zamir wrote:

Hi,

Internet Explorer has an attribute on anchor elements for URNs: 
http://msdn.microsoft.com/en-us/library/ms534710%28VS.85%29.aspx


This has not caught on in other browsers, though I believe it could be a 
very powerful feature once the feature was supported with a UI that 
handled URNs (as with adding support for custom protocols).


Imagine, for example, to take a link like:

a href=http://www.amazon.com/...(shortened) 
urn=isbn:9210020251United Nations charter/a



[snip details]

I like what this proposal achieves, but I'm not sure it's the right 
solution.


Here's an attempt at stating what problem you're trying to solve without 
any specific implementation: (please correct me if I misunderstood)


 * Provide a means to link to or operate on a particular artifact 
without necessarily requiring that the artifact be retrieved from a 
specific location.


 * Provide graceful fallback to user-agents which do not have any 
specialized handling for a particular artifact.


This is different to simply linking to a different URL scheme (for 
example, linking a mailto: URL in order to begin an email message 
without knowing the user's preferred email provider) because it provides 
a fallback behavior for situations where there is no handler available 
for a particular artifact.


== Example Use-cases ==

 * View a particular book, movie or other such product without favoring 
a particular vendor.


 * View a map of the location for particular address or directions to 
that address without favoring a particular maps provider.


 * View a Spanish translation of some web document without favoring a 
particular translation provider.


 * Share a link/photo/etc with friends without favoring a particular 
publishing platform. (i.e. generalizing the Tweet This, Share on 
Facebook, class of links)


== Prior Art ==

=== Android OS Intents ===

The Android OS has a mechanism called Intents[1] which allow one 
application to describe an operation it needs have performed without 
nominating a particular other application to perform it.


Intents are described in detail here:
http://developer.android.com/guide/topics/intents/intents-filters.html

An intent that does not identify a particular application consists of 
the following properties:


 * Action: a verb describing what needs to be done. For example, 
view, edit, choose, share, call.
 * Object: the URI of a particular thing that the action is to be done 
to. This is not specified for actions that apply only to a class of 
object, such as choose.
 * Object Type: the MIME type of the Object, or if no particular Object 
is selected a concrete MIME type or wildcard MIME type (e.g. image/*) 
describing the class of object that the action relates to.


A process called Intent Resolution is used to translate an abstract 
intent like the above into an explicit intent which nominates a 
particular handler.


Often when applications use intents a UI is displayed which allows a 
user to choose one of several available applications that can perform 
the action. For example, the built-in photo gallery application provides 
a Share command on a photo. By default, this can be handled by 
application such as the email client and the MMS application, but other 
applications can declare their support for intents of this type thus 
allowing plug-in functionality such as sharing a photo on Facebook.


=== Internet Explorer urn Attribute ===

Internet Explorer supports a non-standard attribute on the A element 
called urn, which accepts an URN identifying some resource.


It is described in detail here:
http://msdn.microsoft.com/en-us/library/ms534710(VS.85).aspx

It is not apparent that this attribute causes any behavior in the 
browser itself. It is possible that this is exposed to browser 
extensions in some way to allow them to overload the behavior of a link 
which identifies a particular class of resource.


It does not seem that this attribute has achieved wide author adoption 
nor wide application support.


---

Please reply with any other use cases and prior art you have.

I'm particularly interested to see whether Android's (verb, object) 
tuple is actually required or whether the single object as afforded by 
your proposal -- and by the existing design of registering handlers for 
particular URL schemes and MIME types -- is sufficient for the use-cases 
at hand.





[whatwg] URN or protocol attribute

2010-02-08 Thread Brett Zamir

Hi,

Internet Explorer has an attribute on anchor elements for URNs: 
http://msdn.microsoft.com/en-us/library/ms534710%28VS.85%29.aspx


This has not caught on in other browsers, though I believe it could be a 
very powerful feature once the feature was supported with a UI that 
handled URNs (as with adding support for custom protocols).


Imagine, for example, to take a link like:

a href=http://www.amazon.com/...(shortened) 
urn=isbn:9210020251United Nations charter/a


The default behavior would simply follow the link, but if a user agent 
supported the @urn attribute, and if the browser (or browser add-ons) 
had registered support for that URN namespace identifier (here isbn), 
it could, for example, open a dialog to ask which handler to use (or 
whether to always use it), it could ask or otherwise allow in 
preferences an HTML page (with wildcards) where the attribute's content 
could be passed, or it could give the option whenever the user 
right-clicked to choose which handler they wanted to use for a given link.


Likewise, a link like:

a href=http://en.wikipedia.org/wiki/United_Nations_Charter; 
urn=wikipedia:United_Nations_CharterUnited Nations charter/a


...could alternatively be opened in the corresponding Encyclopedia 
Britannica (or Amazon, etc.) page (assuming wikipedia could be 
accepted as a URN namespace, thus unburdening the IANA from coming to 
consensus on the web community's many and ever-expanding names). Users 
would be free to follow the content in the data viewer they wished to 
use, while sites would be free to avoid committing too strongly to any 
particular handler implementation (i.e., the website they specify is 
only a default).


Although software has been made to handle URNs within @href (see, for 
example, https://addons.mozilla.org/en-US/firefox/addon/1940 ), it is 
really a lot to ask for website creators to support a protocol without 
being certain of support (or at least a JavaScript fall-back which could 
test for support). With this proposal, there is no real down-side to 
content creators, users, etc. (nor, given the simplicity of this 
proposal, even really, it would seem to me, to specification editors!), 
to adding an extra attribute (which need have no precise behavior 
associated with it).


Actually, maybe even a protocol attribute would be in order to give a 
similar alternative between a default website and a generic protocol 
handler (and maybe the urn: protocol could be subsumed into this even 
more general attribute).


So, my suggestion is to add to a/ a @urn or, even better, a @protocol 
attribute (since the latter is more comprehensive and also already has a 
formal API for JavaScript registration of handlers). If some browsers 
are not keen on supporting it, maybe there could be a simple test to 
check for support, since it is not strictly necessary, but could 
unobtrusively offer more choice to users.


best wishes,
Brett