better autocompletion?
Hi there! I have a problem with autocompletion for selecting a node by title. This is a very noce methid to find a node, but the problem is that it is ambiguous. There might be several nodes by the same name. You can try to make it less ambiguous by adding the author's name and or the date, but only the node ID will do away with ambiguity. The problem is that the UI does not look really nice. I've thought about a way to transfer more information in the request, but this is problematic. After all an autcompletion field is just a textfield. Also, we need to keep non-JS browsers in mind and if I essentially require CSV data in the textfield this is a usability nightmare for these people. To process CSV data for select fields is also not much fun and error prone. Now, the following idea won't help non-JS browsers at all, but it will be helpful for JS-browsers. The idea is to store all the information about the selection made by the user in a session variable. You can already assign the available selections to a session variable after populating the array of matches. What is required is to make this information contain only the actual selected value. To this end the JS would need to run the autocompletion function one more time after the user has moved out of the select field. My questions are: 1) Is this possible? 2) Does anybody else consider this a good idea? Cheers, Gerhard
Hmmm. I can't yet understand what you are trying to do. Please give a use case. I'll add that autocomplete can certainly return full HTML for each match so we could show a profile picture along with each matching user if we desired. I saw this on some site and it looked terrific IMO. It seems that other modules have also tacked this problem when author has to identify a 'related node' in a form. One module (relativity?) adds a link (for current user only) to all nodes which reads 'use this node for x' when you are searching for a related node. It also offers a 'cancel searching' link. The destination on each link takes you back to its form after some processing has occurred. Might be an option in your case. On 4/18/06 6:43 AM, "Gerhard Killesreiter" <gerhard@killesreiter.de> wrote:
Hi there!
I have a problem with autocompletion for selecting a node by title.
This is a very noce methid to find a node, but the problem is that it is ambiguous. There might be several nodes by the same name. You can try to make it less ambiguous by adding the author's name and or the date, but only the node ID will do away with ambiguity. The problem is that the UI does not look really nice.
I've thought about a way to transfer more information in the request, but this is problematic. After all an autcompletion field is just a textfield. Also, we need to keep non-JS browsers in mind and if I essentially require CSV data in the textfield this is a usability nightmare for these people. To process CSV data for select fields is also not much fun and error prone.
Now, the following idea won't help non-JS browsers at all, but it will be helpful for JS-browsers. The idea is to store all the information about the selection made by the user in a session variable.
You can already assign the available selections to a session variable after populating the array of matches. What is required is to make this information contain only the actual selected value. To this end the JS would need to run the autocompletion function one more time after the user has moved out of the select field.
My questions are:
1) Is this possible? 2) Does anybody else consider this a good idea?
Cheers, Gerhard
On 18 Apr 2006, at 2:14 PM, Moshe Weitzman wrote:
It seems that other modules have also tacked this problem when author has to identify a 'related node' in a form. One module (relativity?) adds a link (for current user only) to all nodes which reads 'use this node for x' when you are searching for a related node. It also offers a 'cancel searching' link. The destination on each link takes you back to its form after some processing has occurred. Might be an option in your case.
My idea for the UI is similar, but have a 'currently selected' list of nodes. Which automatically includes the last x nodes you have created. And an itunes like filtering form for finding other nodes to select. -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
Moshe Weitzman wrote:
Hmmm. I can't yet understand what you are trying to do. Please give a use case.
The use case is in comment_mover module. Among other things it adds a "move" tab to nodes. If you click that tab you get a form which has a single autocompletion field. There you can select another node by title to which you the can assign the first node as a comment. This is usefull for any mail processing module where mails might come in out of order. In this case the second mail would be processed first and made its own node since no parent can be found (the parent still being in the queue). So you can use comment mover to fix this.
I'll add that autocomplete can certainly return full HTML for each match so we could show a profile picture along with each matching user if we desired. I saw this on some site and it looked terrific IMO.
Yeah, but as always I am after functionality not eye candy. :p
It seems that other modules have also tacked this problem when author has to identify a 'related node' in a form. One module (relativity?) adds a link (for current user only) to all nodes which reads 'use this node for x' when you are searching for a related node. It also offers a 'cancel searching' link. The destination on each link takes you back to its form after some processing has occurred. Might be an option in your case.
Not really, if you image a lively discussion forum. Cheers, Gerhard
The use case is in comment_mover module. For this case, I propose you add a dropdown with the most recent 200 forum topic titles. Each option has a title and a (nid) at the end. Also offer an 'Other' textfield where admin has to enter a nid just in case the desired destination is not recent. Put some integer validator on that textfield.
Op dinsdag 18 april 2006 12:43, schreef Gerhard Killesreiter:
Hi there!
I have a problem with autocompletion for selecting a node by title.
This is a very noce methid to find a node, but the problem is that it is ambiguous. There might be several nodes by the same name. You can try to make it less ambiguous by adding the author's name and or the date, but only the node ID will do away with ambiguity. The problem is that the UI does not look really nice.
I ran into this problem when I needed node-selection (as in: choose the parent) for clipper.module Back then , I designed and thought of another widget for this, one that I never (obviously ;) ) made into real code... However, I just made my notes and the mockup into a post @ webschuur.com: http://www.webschuur.com/node/576 Hope it explains itself there. Bèr -- PGP ber@webschuur.com http://www.webschuur.com/sites/webschuur.com/files/ber_webschuur.asc PGP berkessels@gmx.net http://www.webschuur.com/sites/webschuur.com/files/ber_gmx.asc Hoe het naviatie blok te verbergen: http://help.sympal.nl/hoe_het_naviatie_blok_te_verbergen
Gerhard Killesreiter wrote:
Hi there!
I have a problem with autocompletion for selecting a node by title.
This is a very noce methid to find a node, but the problem is that it is ambiguous. There might be several nodes by the same name. You can try to make it less ambiguous by adding the author's name and or the date, but only the node ID will do away with ambiguity. The problem is that the UI does not look really nice.
Well, you can alter the displayed description without changing the node id on the other side of the match set. How about amending the autocomplete results to (eg) Title (Author, Date) | nid ? -- ------------------------------------------- John Handelaar E john@handelaar.org T +353 21 427 9033 M +353 85 748 3790 http://handelaar.org ------------------------------------------- Work in progress: http://dev.vocalvoter.com -------------------------------------------
Hi, I'd suggest something similar to what Gmail currently has in it's mail views: The subject is on the left, and then the begin of the mail follows immediately in a greyish color. At the right hand, it is cut of and the time is displayed. For those of you who don't use Gmail, I attached an image. Of course, one could also make a node span over two lines - The first line holds the title, taxonomy terms and so on and the second line below the first words of the node's content. Konstantin
Op dinsdag 18 april 2006 16:33, schreef John Handelaar:
How about amending the autocomplete results to (eg)
Title (Author, Date) | nid
?
AFAIK it was Dries who said 'we should never use nids or other database specific keys in our frontend'. Even if this were not his exact words, that is still very true. Imagine Gmail forcing you to remember a mid (mail id) for each mail you receive. Or itunes allowing you only to 'add a song by inserting its unique sid in this textfield' . Not an option. Key ids are for the database and the code, not for humans. Bèr -- PGP ber@webschuur.com http://www.webschuur.com/sites/webschuur.com/files/ber_webschuur.asc PGP berkessels@gmx.net http://www.webschuur.com/sites/webschuur.com/files/ber_gmx.asc Hoe het naviatie blok te verbergen: http://help.sympal.nl/hoe_het_naviatie_blok_te_verbergen
Bèr Kessels wrote:
Op dinsdag 18 april 2006 16:33, schreef John Handelaar:
How about amending the autocomplete results to (eg)
Title (Author, Date) | nid
?
AFAIK it was Dries who said 'we should never use nids or other database specific keys in our frontend'.
You misunderstand. The nid part is the field value for autocomplete. -- ------------------------------------------- John Handelaar E john@handelaar.org T +353 21 427 9033 M +353 85 748 3790 http://handelaar.org ------------------------------------------- Work in progress: http://dev.vocalvoter.com -------------------------------------------
John Handelaar wrote:
Bèr Kessels wrote:
Op dinsdag 18 april 2006 16:33, schreef John Handelaar:
How about amending the autocomplete results to (eg)
Title (Author, Date) | nid
?
AFAIK it was Dries who said 'we should never use nids or other database specific keys in our frontend'.
You misunderstand. The nid part is the field value for autocomplete.
But then you have the nid value there in the form, instead of the text, which sounds ok, until you answer a phone call while entering, and forget what you were up to, and wonder what 23897 actually stands for again. What I am/was after was a way to do autocomplete matching and display, but store the nid. This would require a hidden field in addition to the visible field. The hidden field is set when a match is made/clicked, and the visible field shows the "human" representation. On submit, the "human" representation is discarded, and the db stores the nid. In my case it was for stock pricing lookup. I've worked around this unsing an autocomplete match that is a built string containing the unique stock id (which is ok to show people as they will get to know the common ones), as well as the description, separated in a fixed manner I can explode() later on. When the form is submitted, the save function explodes the values, and uses them to lookup the actual nid. The problem is if someone changes the code before saving, or perhaps the title of the node before saving, it may no longer match, causing a revalidation sequence. Storing the nid would always be correct, but the javascript autocomplete needs to be smarter to be able to do that. Simon
Simon Lindsay wrote:
John Handelaar wrote:
Bèr Kessels wrote:
Op dinsdag 18 april 2006 16:33, schreef John Handelaar:
How about amending the autocomplete results to (eg)
Title (Author, Date) | nid
?
AFAIK it was Dries who said 'we should never use nids or other database specific keys in our frontend'.
You misunderstand. The nid part is the field value for autocomplete.
But then you have the nid value there in the form, instead of the text, which sounds ok, until you answer a phone call while entering, and forget what you were up to, and wonder what 23897 actually stands for again.
ARGH Can people who haven't actually developed autocompleting forms now *STOP* talking? The nid value wouldn't appear in the UI. But it *MUST* be the field value and therefore it must be sent. You make a request. It's returned in two parts, value and description. I mentioned 'nid' as the VALUE. Then I clarified what I meant. Now it won't bloody go away. -- ------------------------------------------- John Handelaar E john@handelaar.org T +353 21 427 9033 M +353 85 748 3790 http://handelaar.org ------------------------------------------- Work in progress: http://dev.vocalvoter.com -------------------------------------------
John Handelaar wrote:
Simon Lindsay wrote:
John Handelaar wrote:
Bèr Kessels wrote:
Op dinsdag 18 april 2006 16:33, schreef John Handelaar:
How about amending the autocomplete results to (eg)
Title (Author, Date) | nid
?
AFAIK it was Dries who said 'we should never use nids or other database specific keys in our frontend'.
You misunderstand. The nid part is the field value for autocomplete.
But then you have the nid value there in the form, instead of the text, which sounds ok, until you answer a phone call while entering, and forget what you were up to, and wonder what 23897 actually stands for again.
ARGH
Can people who haven't actually developed autocompleting forms now *STOP* talking?
That is unnesssarily rude even for my rather relaxed attitude when it comes to being rude.
The nid value wouldn't appear in the UI.
Well, it does for me. The key of the selected item will appear in the UI as soon as I have selected an item. At least this is the current bahaviour with the ajax module for 4.6. Did this improve in the version in CVS?
But it *MUST* be the field value and therefore it must be sent.
To be sent it has to appear in the field or not? Cheers, Gerhard
Op woensdag 19 april 2006 16:50, schreef Gerhard Killesreiter:
But it *MUST* be the field value and therefore it must be sent.
To be sent it has to appear in the field or not?
Indeed. Drupal sends only the string. Nothing more nothing less. So if you wnat the NID to be sent, you will have to make it appear in the interface. At least in the current system. And I developed autofills, so am I entiteled to my share of ranting now too? Bèr
Bèr Kessels wrote:
Op woensdag 19 april 2006 16:50, schreef Gerhard Killesreiter:
But it *MUST* be the field value and therefore it must be sent.
To be sent it has to appear in the field or not?
Indeed. Drupal sends only the string. Nothing more nothing less. So if you wnat the NID to be sent, you will have to make it appear in the interface. At least in the current system.
And I developed autofills, so am I entiteled to my share of ranting now too?
Bèr
I believe this is why the topic is 'better autocompletion'. Not about how it works now, but how he feels it should work.
Bèr Kessels wrote:
Op dinsdag 18 april 2006 16:33, schreef John Handelaar:
How about amending the autocomplete results to (eg)
Title (Author, Date) | nid
?
AFAIK it was Dries who said 'we should never use nids or other database specific keys in our frontend'.
Even if this were not his exact words, that is still very true.
Steven suggested to use urls instead. These are things the user already sees and they are unique. Cheers, Gerhard
Hi, I'm not sure if this will be the right tool for the job in comment_mover, but you should have a look at the activeselect module (http://drupal.org/node/49976), which lets you link select boxes hierarchically using AJAX. I don't really see how you can use a hierarchy of select lists for comment moving, however, since nodes in Drupal are not guaranteed to fall within any sort of classification - by default they just exist in a 'big swimming pool'. Perhaps you could use activeselect to browse hierarchically, first by type, then by node, then by comment? (Assuming that you want users to be able to move comments beneath specific other comments in a node, rather than just 'moving them to a new node'). This would work, since every node has one type (officially - excluding cases like event module), and since every comment belongs in one node, and is potentially the child of one other comment. For the case of duplicate node titles, my advice is to not worry about this, since it's too uncommon a use case to warrant making the interface more complex. Cheers, Jaza. On 4/18/06, Gerhard Killesreiter <gerhard@killesreiter.de> wrote:
Hi there!
I have a problem with autocompletion for selecting a node by title.
This is a very noce methid to find a node, but the problem is that it is ambiguous. There might be several nodes by the same name. You can try to make it less ambiguous by adding the author's name and or the date, but only the node ID will do away with ambiguity. The problem is that the UI does not look really nice.
I've thought about a way to transfer more information in the request, but this is problematic. After all an autcompletion field is just a textfield. Also, we need to keep non-JS browsers in mind and if I essentially require CSV data in the textfield this is a usability nightmare for these people. To process CSV data for select fields is also not much fun and error prone.
Now, the following idea won't help non-JS browsers at all, but it will be helpful for JS-browsers. The idea is to store all the information about the selection made by the user in a session variable.
You can already assign the available selections to a session variable after populating the array of matches. What is required is to make this information contain only the actual selected value. To this end the JS would need to run the autocompletion function one more time after the user has moved out of the select field.
My questions are:
1) Is this possible? 2) Does anybody else consider this a good idea?
Cheers, Gerhard
Jeremy Epstein wrote:
Hi,
I'm not sure if this will be the right tool for the job in comment_mover, but you should have a look at the activeselect module (http://drupal.org/node/49976), which lets you link select boxes hierarchically using AJAX. I don't really see how you can use a hierarchy of select lists for comment moving, however, since nodes in Drupal are not guaranteed to fall within any sort of classification - by default they just exist in a 'big swimming pool'.
Perhaps you could use activeselect to browse hierarchically, first by type, then by node, then by comment? (Assuming that you want users to be able to move comments beneath specific other comments in a node, rather than just 'moving them to a new node'). This would work, since every node has one type (officially - excluding cases like event module), and since every comment belongs in one node, and is potentially the child of one other comment.
Activeselect seems to be a solution, unfortunately I need one for 4.6, too.
For the case of duplicate node titles, my advice is to not worry about this, since it's too uncommon a use case to warrant making the interface more complex.
Well, comment_mover also moves comments and if these comments actually are imported from a mailign list using mailhandler/listhandler or og2list, I think there will be a lot of comments with duplicate titles. Cheers, Gerhard
killes: I got it. Requires no forms changes at all. First, some boards call this operation 'prune' and 'graft'. Prune is removing a comment branch and graft is attaching it elsewhere. This borrows from plants the language of gardening plants. You add three links to comment_mover_links(). First, you add a link called 'prune' on every comment for priveleged people. When admin clicks that, all 'prune' disappear and in their place two new links: 'graft' and 'cancel prune'. When user clicks a graft link, you now have source and target and can move accordingly. 'cancel' just sets it so that the 'prune' links show up again. If you don't like this language, you could use other. I like its organicness :)
Op woensdag 19 april 2006 15:46, schreef Moshe Weitzman:
If you don't like this language, you could use other. I like its organicness
This method is how MusicBrainz does its (rather new) relationship interface too. It is interesting, but quite a horror when you are trying to add a relationship with more tabs open. Just be aware of this, when developing the sessions that contain the pruned comments/nodes. It is a very interesting concept, especially because you use the statelessness. Bèr
Bèr Kessels wrote:
Op woensdag 19 april 2006 15:46, schreef Moshe Weitzman:
If you don't like this language, you could use other. I like its organicness
This method is how MusicBrainz does its (rather new) relationship interface too. It is interesting, but quite a horror when you are trying to add a relationship with more tabs open. Just be aware of this, when developing the sessions that contain the pruned comments/nodes.
It is a very interesting concept, especially because you use the statelessness.
I was thinking about multiple tabs and I think that they are actually a requirement in this case or at least not harmful. Use case: 1 misplaced comment (with children) Task: Move it to another node. Procedure: Mark comment as "being in the process of grafting" by clicking link. Clicking sets a session variable and a redirects to the same page. This page will display the message. Now you can go to any other node and attach the comment there. It does not matter if you do this in the same or another tab. You only need to make sure, the tab has been loaded after you clicked on "prune". Cheers, Gerhard
On Wed, 2006-04-19 at 17:20 +0200, Gerhard Killesreiter wrote:
Bèr Kessels wrote:
Op woensdag 19 april 2006 15:46, schreef Moshe Weitzman:
If you don't like this language, you could use other. I like its organicness
This method is how MusicBrainz does its (rather new) relationship interface too. It is interesting, but quite a horror when you are trying to add a relationship with more tabs open. Just be aware of this, when developing the sessions that contain the pruned comments/nodes.
It is a very interesting concept, especially because you use the statelessness.
I was thinking about multiple tabs and I think that they are actually a requirement in this case or at least not harmful.
Use case: 1 misplaced comment (with children)
Task: Move it to another node.
Procedure: Mark comment as "being in the process of grafting" by clicking link. Clicking sets a session variable and a redirects to the same page. This page will display the message. Now you can go to any other node and attach the comment there. It does not matter if you do this in the same or another tab. You only need to make sure, the tab has been loaded after you clicked on "prune".
Cheers, Gerhard
Or you could always implement a clipboard like a approach, where you select a few items for pruning. They're tossed in a clipboard, then you can have a select for the graft, which will give you a shorter listto deal with.
Darrel O'Pry wrote:
On Wed, 2006-04-19 at 17:20 +0200, Gerhard Killesreiter wrote:
Bèr Kessels wrote:
Op woensdag 19 april 2006 15:46, schreef Moshe Weitzman:
If you don't like this language, you could use other. I like its organicness
This method is how MusicBrainz does its (rather new) relationship interface too. It is interesting, but quite a horror when you are trying to add a relationship with more tabs open. Just be aware of this, when developing the sessions that contain the pruned comments/nodes.
It is a very interesting concept, especially because you use the statelessness.
I was thinking about multiple tabs and I think that they are actually a requirement in this case or at least not harmful.
Use case: 1 misplaced comment (with children)
Task: Move it to another node.
Procedure: Mark comment as "being in the process of grafting" by clicking link. Clicking sets a session variable and a redirects to the same page. This page will display the message. Now you can go to any other node and attach the comment there. It does not matter if you do this in the same or another tab. You only need to make sure, the tab has been loaded after you clicked on "prune".
Cheers, Gerhard
Or you could always implement a clipboard like a approach, where you select a few items for pruning. They're tossed in a clipboard, then you can have a select for the graft, which will give you a shorter listto deal with.
Also an interesting idea. I am not sure how the usage pattern for comment_mover will be. Your idea woudl be usefull if I were to move a lot of comments in one session. I think that the usage pattern will rather be to move one comment/thread at a time. Cheers, Gerhard
On Wed, 2006-04-19 at 17:36 +0200, Gerhard Killesreiter wrote:
Darrel O'Pry wrote:
On Wed, 2006-04-19 at 17:20 +0200, Gerhard Killesreiter wrote:
Bèr Kessels wrote:
Op woensdag 19 april 2006 15:46, schreef Moshe Weitzman:
If you don't like this language, you could use other. I like its organicness
This method is how MusicBrainz does its (rather new) relationship interface too. It is interesting, but quite a horror when you are trying to add a relationship with more tabs open. Just be aware of this, when developing the sessions that contain the pruned comments/nodes.
It is a very interesting concept, especially because you use the statelessness.
I was thinking about multiple tabs and I think that they are actually a requirement in this case or at least not harmful.
Use case: 1 misplaced comment (with children)
Task: Move it to another node.
Procedure: Mark comment as "being in the process of grafting" by clicking link. Clicking sets a session variable and a redirects to the same page. This page will display the message. Now you can go to any other node and attach the comment there. It does not matter if you do this in the same or another tab. You only need to make sure, the tab has been loaded after you clicked on "prune".
Cheers, Gerhard
Or you could always implement a clipboard like a approach, where you select a few items for pruning. They're tossed in a clipboard, then you can have a select for the graft, which will give you a shorter listto deal with.
Also an interesting idea. I am not sure how the usage pattern for comment_mover will be. Your idea woudl be usefull if I were to move a lot of comments in one session. I think that the usage pattern will rather be to move one comment/thread at a time.
Cheers, Gerhard
Sounds more likely that you'd do one at a time... unless you come across a thread that needs moving while looking for that stinking node you wanted to move that last comment thread to...
Moshe Weitzman wrote:
killes: I got it. Requires no forms changes at all.
First, some boards call this operation 'prune' and 'graft'. Prune is removing a comment branch and graft is attaching it elsewhere. This borrows from plants the language of gardening plants.
I know that language. :)
You add three links to comment_mover_links(). First, you add a link called 'prune' on every comment for priveleged people. When admin clicks that, all 'prune' disappear and in their place two new links: 'graft' and 'cancel prune'. When user clicks a graft link, you now have source and target and can move accordingly. 'cancel' just sets it so that the 'prune' links show up again.
That is a nice idea! It will work for moving comments to other comments in the same post and even elsewhere. It would even work for demoting posts to comments. I'd only need a form for making nodes from comments and that would be an easy one.
If you don't like this language, you could use other. I like its organicness :)
I think I will keep it. Cheers, Gerhard
Page not found.
I'm not sure if this will be the right tool for the job in comment_mover, but you should have a look at the activeselect module (http://drupal.org/node/49976),
(http://drupal.org/node/49976), Page not found.
Get an email client that understands boundary delimiters. Try: http://drupal.org/node/49976 -- Morbus Iff ( you are nothing without your robot car, NOTHING! ) Culture: http://www.disobey.com/ and http://www.gamegrene.com/ O'Reilly Author, Weblog, Cook: http://www.oreillynet.com/pub/au/779 icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus
"Morbus Iff" wrote: (To someone...he didn't provide attribution...maybe it was his email client.)
(http://drupal.org/node/49976), Page not found.
Get an email client that understands boundary delimiters. Try:
Even though you were not replying to me, my email client is perfectly capable of handling URLs, yet Jeremy's original is also displayed incorrectly for me, with the final ")" being made part of the URL. "Boundary delimiters" isn't specific, and you know it. Fences are boundary delimiters. Shall my email client handle picket fences, chain link fences, brick walls? What you should be doing is reminding the OP, Jeremy, of how to include a URL with a recognized standard __url delimiter__, which is < and > "Jeremy Epstein" wrote:
I'm not sure if this will be the right tool for the job in comment_mover, but you should have a look at the activeselect module (http://drupal.org/node/49976), which
And maybe should have said (<his url>) if he wanted to provide for email transmission. -- Gary P.S. Looks like your javascript is using 'overlib.js'. That's a great little package.
We have to argue about this publically?
Get an email client that understands boundary delimiters. Try:
Even though you were not replying to me, my email client is perfectly capable of handling URLs, yet Jeremy's original is also displayed incorrectly for me, with the final ")" being made part of the URL.
Then I say the same to you. It doesn't take a leap of faith for an email client to a) ignore ending punction of a URL (such as a period or comma), b) treat the previous and last character of a URL as erroneous, if they're of the same pair type. My email client (Thunderbird), displayed the () enclosed URL properly.
What you should be doing is reminding the OP, Jeremy, of how to include a URL with a recognized standard __url delimiter__, which is < and >
I will heartily agree that <> is quite commonly used. I will need to be convinced that it is any more important than other delimiter, or that its popularity is a strong enough argument for using it alone. In RFC 2396, we see the following, which indicates the standard of exactly the amount of plausible delimiters (and, yes, I will concede that () is not one of them): The angle-bracket "<" and ">" and double-quote (") characters are excluded because they are often used as the delimiters around URI in text documents and protocol fields. ... delims = "<" | ">" | "#" | "%" | <"> Other characters are excluded because gateways and other transport agents are known to sometimes modify such characters, or they are used as delimiters. unwise = "{" | "}" | "|" | "\" | "^" | "[" | "]" | "`" Further down in Appendix E, we see the side you're arguing, but nothing purely indicated that <> is the only url delimiter available (emphasis on "variety of ways"): In practice, URI are delimited in a variety of ways, but usually within double-quotes "http://test.com/", angle brackets <http://test.com/>, or just using whitespace. ... Using <> angle brackets around each URI is especially recommended as a delimiting style for URI that contain whitespace. For robustness, software that accepts user-typed URI should attempt to recognize and strip both delimiters and embedded whitespace. The last paragraph, however, is unclear on whether "delimiters" refers to the previously quoted text (of <>#%", of which I would suggest it doesn't refer to, due to the URI fragment issue).
Looks like your javascript is using 'overlib.js'. That's a great little package.
You are incorrect. It's not using overlib, and I explicitly did not want to use overlib because: * It's old and bloated. * It does lots of trickery for browsers that I have no intentions of supporting anymore (ancient Netscapes, IEs, etc., etc.). * All styling is done through function parameters, not CSS. -- Morbus Iff ( you are nothing without your robot car, NOTHING! ) Culture: http://www.disobey.com/ and http://www.gamegrene.com/ O'Reilly Author, Weblog, Cook: http://www.oreillynet.com/pub/au/779 icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus
You are incorrect. It's not using overlib, and I explicitly did not want to use overlib because:
Gah - my apologies, Gary. I erroneously presumed you had been talking about my tooltip junk, not the activeselect. -- Morbus Iff ( you are nothing without your robot car, NOTHING! ) Culture: http://www.disobey.com/ and http://www.gamegrene.com/ O'Reilly Author, Weblog, Cook: http://www.oreillynet.com/pub/au/779 icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus
On 4/20/06, Morbus Iff <morbus@disobey.com> wrote:
You are incorrect. It's not using overlib, and I explicitly did not want to use overlib because:
Gah - my apologies, Gary. I erroneously presumed you had been talking about my tooltip junk, not the activeselect.
I hope that Gary wasn't talking about activeselect, because it most certainly does not use overlib! I've never heard of overlib before in my life. Activesleect is heavily based on the Drupal core autocomplete library, and as such, all it depends on is drupal.js (which we can all agree is neither old nor bloated :-p). @Gary, Morbus: thanks for the tip, in the future I will enclose my URI's within an RFC 2396 recommended delimiter (of my choice!). I assumed that all mail clients recognise parentheses as delimiters - I've never encountered one that doesn't. Also, I can't believe that this silly technicality caused such a stir! Cheers, Jaza.
participants (13)
-
Adrian Rossouw -
Ana Willem -
Bèr Kessels -
Darrel O'Pry -
Earl Miles -
Gary (Lists) -
Gerhard Killesreiter -
Jeremy Epstein -
John Handelaar -
Konstantin Käfer -
Morbus Iff -
Moshe Weitzman -
Simon Lindsay