Autocomplete and styling of the controls

[Gabriel Petrovay]

Hi,

There are some undocumented restrictions and issues regarding the autocomplete feature in the places library.

Styling:

How to provide class styling to the input fields? This is because the autocomplete code gives the input fields new class name: "pac-input-default". So, if the input had an initial class this is thrown away. What are some best practices to style such autocomplete-input-fields?

Hidden text input fields:

If a text input fields is hidden: (the input is in a div that has the "display: none" style), the autocomplete code does not work anymore. If you look into the debug console you see that all the classes and elements are added but the completion proposals don't show up anymore.

Focus issues:

And one more question. How can one get rid of the default text/change the default text: "Enter a location". This raises a problem is the focus is moved in the input field from code with jQuery. The default text is not deleted.

Regards.

Gabriel

[Gabriel Petrovay]

Some more issues with the autocomplete feature:

- since the proposal div is absolutely positioned, the resizing of the window keeps the div in place while the input field changes its position. (I know this is not a very common behavior of the user: resizing the browser during completion proposals)

- the problem with the hidden text input fields is that the proposal div is rendered with a width of 0px and therefore not seen by the user. Moreover, because of the hidden input field also the position is messed-up, (top: 0px; left: 0px;), this being probably what it gets from the not visible input field.

[Gabriel Petrovay]

And, is it safe to handle classes generated but such an API?

For example I want to remove the pac-input-default class myself. Can I repy on such a name or is this error-prone since the names can change anytime?

Regards,

Gabriel

[Chris Broadfoot]

Comments inline.

On Mon, Jun 6, 2011 at 9:58 AM, Gabriel Petrovay <gabipe...@gmail.com> wrote:

Styling:

How to provide class styling to the input fields? This is because the autocomplete code gives the input fields new class name: "pac-input-default". So, if the input had an initial class this is thrown away. What are some best practices to style such autocomplete-input-fields?

Sounds like a bug! Sorry about that. I've filed this internally.

For now, I suggest re-using our class to style your autocomplete fields. If you need more granular control, you could use the HTML id attribute, or wrap the <input> in a <div>.

 

Hidden text input fields:

If a text input fields is hidden: (the input is in a div that has the "display: none" style), the autocomplete code does not work anymore. If you look into the debug console you see that all the classes and elements are added but the completion proposals don't show up anymore.

This sounds about right to me. Are you trying to show the suggestions without the textbox?

 

Focus issues:

And one more question. How can one get rid of the default text/change the default text: "Enter a location". This raises a problem is the focus is moved in the input field from code with jQuery. The default text is not deleted.

This is another thing I've filed with the team, we should probably be using the "placeholder" attribute here.

Some more issues with the autocomplete feature:
- since the proposal div is absolutely positioned, the resizing of the window keeps the div in place while the input field changes its position. (I know this is not a very common behavior of the user: resizing the browser during completion proposals)
- the problem with the hidden text input fields is that the proposal div is rendered with a width of 0px and therefore not seen by the user. Moreover, because of the hidden input field also the position is messed-up, (top: 0px; left: 0px;), this being probably what it gets from the not visible input field.

This is probably because a hidden input has no width. Again, why are you hiding the input? This is not an intended use case.

 

And, is it safe to handle classes generated but such an API?
For example I want to remove the pac-input-default class myself. Can I repy on such a name or is this error-prone since the names can change anytime?

Probably not. The names can change any time. Although I suggested re-using it earlier in this mail, this should probably be a temporary measure until the bug is fixed.

Chris 

--
http://twitter.com/broady

[Gabriel Petrovay]

Thanks Chris for the answers. See inline.

On Mon, Jun 6, 2011 at 3:06 AM, Chris Broadfoot <cb...@google.com> wrote:

Comments inline.

On Mon, Jun 6, 2011 at 9:58 AM, Gabriel Petrovay <gabipe...@gmail.com> wrote:

Styling:

How to provide class styling to the input fields? This is because the autocomplete code gives the input fields new class name: "pac-input-default". So, if the input had an initial class this is thrown away. What are some best practices to style such autocomplete-input-fields?

Sounds like a bug! Sorry about that. I've filed this internally.

For now, I suggest re-using our class to style your autocomplete fields. If you need more granular control, you could use the HTML id attribute, or wrap the <input> in a <div>.

That is exactly what I did to hack around it. .wrapperDiv input { ... } to simulate class-like behavior. And the id to give a style to it only for that element.

 

Hidden text input fields:

If a text input fields is hidden: (the input is in a div that has the "display: none" style), the autocomplete code does not work anymore. If you look into the debug console you see that all the classes and elements are added but the completion proposals don't show up anymore.

This sounds about right to me. Are you trying to show the suggestions without the textbox?

Nope. The input field shows up either on request or if needed (geolocation not supported).

 

 

Focus issues:

And one more question. How can one get rid of the default text/change the default text: "Enter a location". This raises a problem is the focus is moved in the input field from code with jQuery. The default text is not deleted.

This is another thing I've filed with the team, we should probably be using the "placeholder" attribute here.

You can test it with jQuery using:

addAutocompleteHandlers(); // which does the autocomplete api initialization

$("#autocompleteInput").focus(); // => "Enter a location" is not deleted

$("#autocompleteInput").val(""); // => "Enter a location" is not deleted either

Some more issues with the autocomplete feature:
- since the proposal div is absolutely positioned, the resizing of the window keeps the div in place while the input field changes its position. (I know this is not a very common behavior of the user: resizing the browser during completion proposals)
- the problem with the hidden text input fields is that the proposal div is rendered with a width of 0px and therefore not seen by the user. Moreover, because of the hidden input field also the position is messed-up, (top: 0px; left: 0px;), this being probably what it gets from the not visible input field.

This is probably because a hidden input has no width. Again, why are you hiding the input? This is not an intended use case.

As the field is displayed lazily, the google.maps.places.Autocomplete was called $(document).ready() to install the necessary handlers. such that when the autocomplete input needs to be displayed, no more logic is necessary.

Of course there are many dirsy workarrounds like using divs over the input field that hide the input field or a wrapper div with "overflow: hidden", etc. But I'd rather see a even nicer API.

 

 

 

And, is it safe to handle classes generated but such an API?
For example I want to remove the pac-input-default class myself. Can I repy on such a name or is this error-prone since the names can change anytime?

Probably not. The names can change any time. Although I suggested re-using it earlier in this mail, this should probably be a temporary measure until the bug is fixed.

Chris 

--
http://twitter.com/broady

--
You received this message because you are subscribed to the Google Groups "Google Maps JavaScript API v3" group.

To post to this group, send email to google-map...@googlegroups.com.
To unsubscribe from this group, send email to google-maps-js-a...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-maps-js-api-v3?hl=en.

--
MSc Gabriel Petrovay
Mobile: +41(0)787978034
www.28msec.com

[Gabriel Petrovay]

And a few more things on usability:

- an Enter or Tab selection. I know that both are already used in form submission and navigation respectively. But it would be nice to let the user choose what key he wants in the constructor.

- once the user chooses something, this should be considered "chosen" and the proposal div should not be displayed again if the user navigates back and forth the controls, unless he changes again the text in the autocomplete field.

And one more test and proposal for the focus thing:

- try autocomplete on an input with the autofocus attribute. "Enter a location" should not be displayed. The options arguments in the Autocomplete contructor should say something like:

var options = {

  emtyText: "Enter a location";

}

This for at least two reasons:

1. internationalization (correct me if I-'m wrong and this is handled by an option in the maps API URL already, but not sure if that fits all needs)

2. letting users write their own text, and possibly empty if someone writes the text outside the field

Regards,

Gabriel

[en4ce]

good topic, i had / have the same problems with this, it would be nice
if the styles you gave to the input box just stay´s the same

On 6 Jun., 13:05, Gabriel Petrovay <gabipetro...@gmail.com> wrote:
> Thanks Chris for the answers. See inline.
>
>
>
>
>
>
>
>
>
> On Mon, Jun 6, 2011 at 3:06 AM, Chris Broadfoot <c...@google.com> wrote:
> > Comments inline.
>

[Miles]

I completely agree that the user of the API should be able to supply
the default text for the input box. Specifying it via the options
parameter would be great. Or perhaps the google API could respect what
I've set for the value attribute on my input element?

Another point of quirkiness I've noticed:

In my webapp, if the user clicks outside of the autocomplete text box
before selecting a location from the drop down, I need the text box to
clear out instead of leaving the text as is. I've tried clearing the
textbox manually via onchange and onblur events, but the somehow the
autocomplete logic magically repopulates it right after it clears.

Regards,

Miles

[Clem]

Same issues !


Sincerely,
Clement.

[en4ce]

bug report anyone ?

[Gabriel Petrovay]

I did not file any of the bugs.

Chris (from Google) mentioned that he already files some internally. So, Chris, are there any that we still have to file?

Thanks!

PS: In the meanwhile I do a lot of dirty tricks: enabling auto completion only from the 2 character (enabling it on keypress when the input field is empty still has some issues) Anyway this is much better because you might not need completion always and only on demand. Moreover, for 1 character is most probably irrelevant. And this way the showing of the control is decoupled from auto completion.

bug report anyone ?

--
You received this message because you are subscribed to the Google Groups "Google Maps JavaScript API v3" group.
To post to this group, send email to google-map...@googlegroups.com.
To unsubscribe from this group, send email to google-maps-js-a...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-maps-js-api-v3?hl=en.

[Chris Broadfoot]

On Thu, Jun 16, 2011 at 5:29 AM, Gabriel Petrovay <gabipe...@gmail.com> wrote:

Chris (from Google) mentioned that he already files some internally. So, Chris, are there any that we still have to file?

Sure, please file them externally if you want to be notified of any related changes (we'll update the external issue when it gets fixed)

Chris

--

http://twitter.com/broady