Require robust autocomplete field

[Thomas 'PointedEars' Lahn]

It will work in Safari2, so that is better.
But certainly not better for Blackberry9000 (which supports neither).

You are not making sense. As Safari 2 purportedly does not support either
`textContent' or `innerText', either none of both approaches would work
there or both of them would "work" there (depending on the definition of
"work").


PointedEars

 

[Thomas 'PointedEars' Lahn]

I find that a fair inference to make that if one HTMLElement has a
"textContent" property, then most others will, too
NAK

An implementation that has neither innerText nor textContent poses a
problem.

That's Blackberry9000. Blackberry9000 has innerHTML and Text node, so
another approach using those can work.

Thanks for that.

But this has gotten spectacularly off-track.

Off-track maybe, but fortunately not off-topic. This is how Usenet works.


PointedEars

 

[VK]

The list contains an item such as "'O'Neill & Son'" (In order
to appear correctly in the rendered dropdown).

When selected and placed in the text box, it should appear as "O'Neill
& Son', however it doesn't all the ugly encoding is displayed to the
user.

Hacking it to decode makes jquery think the input is invalid, as the
selection must appear in the original list...

The way I see it there are 3 options:

1: Hack the jquery library to make the comparison callbacks to
decode / encode between the 2 formats on the fly. (Not sure if it's
possible to do reliably and with tidy code. The whole point of using a
library was to avoid this kind of minefield.)

2: Hack the jquery library to use 2 lists, "HTML" and "TEXT"
formatted. (Same problems as option 1)

3: Ditch the library and do it manually... Hence this post. Any
examples out there of this problem being solved right? It seems like a
common problem, yet the only examples out there use half baked
libraries that only kind of work some of the time.

The reason of you current troubles is not clear. In my very first
answer it was explained in details the root of the problem, per-
browser specifics, demo page to verify all statements made and the
actual workaround. It was later suggested that might be some browsers
not implementing any modern DOM methods yet fully implementing node
traversal. It was also suggested that there might be some valuable
customers with JavaScript support but without any features atop DOM 0
at all. If it makes you worried than use some more check-filled
function like

function getNormalizedContent(elm) {
if (typeof elm.textContent != 'undefined') {
return elm.textContent;
}
else if (typeof elm.innerText != 'undefined') {
return elm.innerText;
}
else if (typeof elm.childNodes != 'undefined') {
return elm.childNodes.nodeValue;
}
else {
// return whatever you like
}
}

Such (or alternate) function could be defined after the 3rd library
load and used in the callback procedure on user selecting an option in
the custom select object. To fix the callback action in this way is a
trivia with some JavaScript knowledge either for jQuery or
Prototype.js or any other library you are using.

 

[VK]

  return elm.childNodes.nodeValue;

return elm.childNodes[0].nodeValue // of course

 

[Garrett Smith]

THe above function returns a function or undefined.

In browser that supports neither textContent nor innerText,
getText is going to have the value |undefined| and getText() will
result in TypeError.

You are not making sense. As Safari 2 purportedly does not support either
`textContent' or `innerText', either none of both approaches would work
there or both of them would "work" there (depending on the definition of
"work").

There seems to be some miscommunication here.

You stated that Safari 2 does not support either "textContent" or
"innerText". The property that Safari 2 does not support is
"textContent". "innerText" works in Safari 2+ (and Chrome and Opera).

The approach I posted is better in that it gets the code working in
Safari 2. It is not much better for Blackberry9000, though at least it
does not result in TypeError from calling getText() where getText has
value |undefined|.

The Blackberry simulators are free for download. 9500 is touch-screen,
so clicks map to "touch" actions (no copying of Apples patented
"TouchEvent" (which is one of the worst, latest API I've seen).
http://na.blackberry.com/eng/developers/resources/simulators.jsp

RIM also offers an Eclipse plugin with a debugger for Blackberry.

 

[RobG]

THe above function returns a function or undefined.

In browser that supports neither textContent nor innerText,
getText is going to have the value |undefined| and getText() will
result in TypeError.

Yes, a further branch is need for such browsers using a recursive
traversal of child nodes. I should have included it but it's been
posted in the thread anyway.

There seems to be some miscommunication here.

You stated that Safari 2 does not support either "textContent" or
"innerText". The property that Safari 2 does not support is
"textContent". "innerText" works in Safari 2+ (and Chrome and Opera).

Where "you" is PE. Yes, I think he missunderstood my post. To be
clear, Safari 2 supports innerHTML and not textContent. Later versions
support textContent, I don't know at which version that support was
added and I don't care. I have a robust getTextContent function that
works every where it's used.

The same logic applies to finding more browsers where VK's sniffing
code fails - I don't really care, I know of one case where it will
fail and, having implemented a suitable feature test, don't care about
others unless they start failing that test.

I note that VK relented, but had to change the test to use 'undefined'
rather than string. As Christopher Hitchens would say, "I suppose
that's progress - of a sort".

 

[RobG]

To be
clear, Safari 2 supports innerHTML and not textContent.

Ooops... supports innerText and not textContent

 

[Garrett Smith]

[feature test for getTextContent]

The same logic applies to finding more browsers where VK's sniffing
code fails - I don't really care, I know of one case where it will
fail and, having implemented a suitable feature test, don't care about
others unless they start failing that test.

Right, or if there is a case where textContent is not doing what is
expected of it.

Bottom line is the sniffing is unrelated to the problem of getting text
content from an element.

 

[Garrett Smith]

Thanks for getting back OT.

The list contains an item such as "'O'Neill & Son'" (In order
to appear correctly in the rendered dropdown).

When selected and placed in the text box, it should appear as "O'Neill
& Son', however it doesn't all the ugly encoding is displayed to the
user.

Seriously, that should not break like that. Are you sure that it does
that? I've not looked into the source code (beyond the first few lines).

If so, I am sorry you got sucked into that one.

Hacking it to decode makes jquery think the input is invalid, as the
selection must appear in the original list...

The way I see it there are 3 options:

1: Hack the jquery library to make the comparison callbacks to
decode / encode between the 2 formats on the fly. (Not sure if it's
possible to do reliably and with tidy code. The whole point of using a
library was to avoid this kind of minefield.)

2: Hack the jquery library to use 2 lists, "HTML" and "TEXT"
formatted. (Same problems as option 1)

3: Ditch the library and do it manually... Hence this post. Any
examples out there of this problem being solved right? It seems like a
common problem, yet the only examples out there use half baked
libraries that only kind of work some of the time.

You'll need to write some code, somewhere along the way. Sounds like the
jQuery widget needs to be redesigned in a way to allow for "O'Neill &"
to be an option to the user, and represented correctly in HTML.

The other posters were on the right track with the textContent/innerText
issue.

Does the value that is displayed to the user the same value that you
want to send to the server?

for example, you might show "O'Neill & Son" (as O'Neill & Son)
to the user, but send a value to the server that is associated with that
value (e.g. "1"). That way, the server side program does not have to
deal with the value of "O'Neill & Son", but can have the value it wants
for that.

Does the list need to be populated with data from the server
/dynamically/, as the user types?

The representation of the list of labelText/value could be done with a
DL, where the DT is displayed and the DL holds the value:

<DT id="autocomplete-items">
<DT>O'Neill &amp; Son</DT>
<DD>x1</DD>
</DT>

or could use an HTML5 datalist element.

<datalist id="autocomplete-items">
<option value="x1">O'Neill &amp; Son</option>
</datalist>

When the INPUT's value changes, then update the displayed options.

 

[Thomas 'PointedEars' Lahn]

Ooops... supports innerText and not textContent

Yes, sorry, I misread/misremembered <[email protected]>.

Thank you for your clarification. The Matrix has you!


PointedEars

 

[Thomas 'PointedEars' Lahn]

Yes, sorry, I misread/misremembered <[email protected]>.

Thank you for your clarification. The Matrix has you!

JFTR: (Standalone) Safari 2.0.4 (for Mac OS X 10.4) supports `innerHTML',
too. But I could confirm this way that it does support `innerText', and
does not support `textContent'.


PointedEars