Require robust autocomplete field
Mark Smith
I'm looking for a way to implement an autocomplete field on some of my
forms.
I need both ajax support (for larger lists) and also a way to pass in
json arrays for smaller lists.
The best I have found so far is this one:
http://www.pengoworks.com/workshop/jquery/autocomplete.htm
(I know, jQuery - yuck!)
The problem with this one (and others) is that the rendering breaks
when any of the strings contain html entity encoded characters. This
is because the dropdown list is html, but the text box value is raw
text. Fixing the code myself to reconcile the two looks like it will
become very messy.
If anyone could recommend a way to do this properly. (Either a plugin
for an existing framework or a tried and tested pattern for
implementing autocomplete in pure JS would be greatly appreciated)
Thanks
Evertjan.
> Hi,
>
> I'm looking for a way to implement an autocomplete field on some of my
> forms.
>
> I need both ajax support (for larger lists) and also a way to pass in
> json arrays for smaller lists.
ajax and json are not parallel technologies,
json being just a way of defining stream content coding and
ajax being just a way to import these streams from the server
to an existing client page.
Perhaps you mean you want to have the smaller amounts of data hard coded
in your page?
> The best I have found so far is this one:
>
> http://www.pengoworks.com/workshop/jquery/autocomplete.htm
>
> (I know, jQuery - yuck!)
>
> The problem with this one (and others) is that the rendering breaks
> when any of the strings contain html entity encoded characters. This
> is because the dropdown list is html, but the text box value is raw
> text. Fixing the code myself to reconcile the two looks like it will
> become very messy.
You must have serverside controll over the stream,
so you can prepare the streams to your liking with serverside scripting.
> If anyone could recommend a way to do this properly. (Either a plugin
> for an existing framework or a tried and tested pattern for
> implementing autocomplete in pure JS would be greatly appreciated)
Methinks that, if you miss the skil to do it yourself, Mark,
hiring a professional would be the way to go.
--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)
Gregor Kofler
> Hi,
>
> I'm looking for a way to implement an autocomplete field on some of my
> forms.
>
> I need both ajax support (for larger lists) and also a way to pass in
> json arrays for smaller lists.
>
> The best I have found so far is this one:
>
> http://www.pengoworks.com/workshop/jquery/autocomplete.htm
Erm... The "AJAX" version doesn't do anything on my FF3.5
> (I know, jQuery - yuck!)
$input.keydown(...).focus(...).blur(...);
Nice.
> The problem with this one (and others) is that the rendering breaks
> when any of the strings contain html entity encoded characters. This
> is because the dropdown list is html, but the text box value is raw
> text.
Always use "raw" text and avoid innerHTML when creating the list.
Gregor
Eric Bednarz
> $input.keydown(...).focus(...).blur(...);
>
> Nice.
Chaining is not just nice, it is beautiful!
For example, I’ve seen this the other day:
<input
type="button"
value="Submit"
onclick="$('form').attr('action', $('form').attr('action')).submit();">
This clearly demonstrates how jQuery makes everyday’s tedious tasks much
simpler and quicker.
Gregor Kofler
Sheer magic - conciseness and readability form a holy alliance. In
addition your computer gets its daily exercise.
Gregor
Mark Smith
> Mark Smith wrote on 05 okt 2009 in comp.lang.javascript:
>
> > Hi,
>
> > I'm looking for a way to implement an autocomplete field on some of my
> > forms.
>
> > I need both ajax support (for larger lists) and also a way to pass in
> > json arrays for smaller lists.
>
> ajax and json are not parallel technologies,
> json being just a way of defining stream content coding and
> ajax being just a way to import these streams from the server
> to an existing client page.
>
> Perhaps you mean you want to have the smaller amounts of data hard coded
> in your page?
I know, for larger lists I want to deliver subsets based on a query.
(Either json, xml, raw text, I don't really mind.
For smaller lists it makes more sense to dump it all directly on the
page as json on page load....
> Methinks that, if you miss the skil to do it yourself, Mark,
> hiring a professional would be the way to go.
>
I don't lack the skill. Just didn't want to reinvent the wheel, seems
like a common requirement. Like I said if anyone had any pointers it
would be appreciated...
Thanks
Evertjan.
>> Methinks that, if you miss the skil to do it yourself, Mark,
>> hiring a professional would be the way to go.
>>
>
> I don't lack the skill. Just didn't want to reinvent the wheel, seems
> like a common requirement. Like I said if anyone had any pointers it
> would be appreciated...
Reinventing the wheel in programming is often simpler
than debugging the square wheels of others.
Looking at the methods of others however can be very helpful, I agree.
VK
> when any of the strings contain html entity encoded characters. This
> is because the dropdown list is html, but the text box value is raw
> text.
It is not completely correct. Not every HTML encoded entity "trash
out" the input but only < > & and and only if one
treats the input string as HTML code (using .innerHTML) From the point
of view of a running script any string is a Unicode sequence, so this
behavior is still a mystery, especially It might have something
to do with the code stability on .innerHTML assignments - just a
guess.
You may use innerText / textContent instead - in this case the string
reading goes as expected. Test case follows:
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=iso-8859-1">
<title>NoScript</title>
</head>
<body>
<h1 id="Sample">« » Θ …
ℑ ⇒ ' " < > & </h1>
<form action="" method="GET" onsubmit="return false;">
<input type="text" name="txt" size="30">
<input type="button" value="Test innerHTML"
onclick="
this.form.elements['txt'].value = document.getElementById
('Sample').innerHTML;
">
<input type="button" value="Test innerText"
onclick="
/*@cc_on
/*@if (@_jscript)
var IE = true;
@else @*/
var IE = false;
/*@end
@*/
this.form.elements['txt'].value = (IE)?
document.getElementById('Sample').innerText
:
document.getElementById('Sample').textContent;
">
</form>
</body>
</html>
Thomas 'PointedEars' Lahn
>> the rendering breaks when any of the strings contain html entity encoded
>> characters. This is because the dropdown list is html, but the text box
>> value is raw text.
>
> It is not completely correct. Not every HTML encoded entity "trash
> out" the input but only < > & and and only if one
> treats the input string as HTML code (using .innerHTML) [...]
Rubbish.
PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann
RobG
[...]
> <input type="button" value="Test innerText"
> onclick="
> /*@cc_on
> /*@if (@_jscript)
> var IE = true;
> @else @*/
> var IE = false;
> /*@end
> @*/
> this.form.elements['txt'].value = (IE)?
> document.getElementById('Sample').innerText
> :
> document.getElementById('Sample').textContent;
> ">
That is a spectacularly bad piece of code - there are many browsers
that aren't IE that implement innerText and not textContent.
A feature test using typeof offers far better cross-browser support:
var getText = (function() {
var el = document.createElement('p');
if (typeof el.textContent == 'string')
return function(el){return el.textContent;};
if (typeof el.innerText == 'string')
return function(el){return el.innerText;};
el = null;
})();
--
Rob
VK
> On Oct 6, 9:12 pm, VK <schools_r...@yahoo.com> wrote:
> [...]
>
> > <input type="button" value="Test innerText"
> > onclick="
> > /*@cc_on
> > /*@if (@_jscript)
> > var IE = true;
> > @else @*/
> > var IE = false;
> > /*@end
> > @*/
> > this.form.elements['txt'].value = (IE)?
> > document.getElementById('Sample').innerText
> > :
> > document.getElementById('Sample').textContent;
> > ">
>
> That is a spectacularly bad piece of code - there are many browsers
> that aren't IE that implement innerText and not textContent.
The current set of UAs I do care as of now is (listed by compatibility
priority, the top is the highest one):
Microsoft Internet Explorer 8.0 (X-UA-Compatible =6 =7 inclusive)
Mozilla Firefox 3.5
Safari 4.0
Google Chrome 3.0
Opera 10.0
Out of this list you have no guarantee of anything, including
document.createElement method. My principles are the same over years:
"unless you SAW it working in browser X.y under OS Y.z, it does NOT
work in browser X.y under OS Y.z". No amount of theoretical
considerations can override this simple truth.
VK
> > out" the input but only < > & and and only if one
> > treats the input string as HTML code (using .innerHTML) [...]
>
> Rubbish.
Do you have a counterexample?
Thomas 'PointedEars' Lahn
Do you have an example that proves it?
PointedEars
--
Use any version of Microsoft Frontpage to create your site.
(This won't prevent people from viewing your source, but no one
will want to steal it.)
-- from <http://www.vortex-webdesign.com/help/hidesource.htm> (404-comp.)
VK
wrote:
> VK wrote:
> >> > It is not completely correct. Not every HTML encoded entity "trash
> >> > out" the input but only < > & and and only if one
> >> > treats the input string as HTML code (using .innerHTML) [...]
>
> >> Rubbish.
>
> > Do you have a counterexample?
>
> Do you have an example that proves it?
?? The test is in my first post. Can you see it?
Peter May
What do you think about this solution that I was created some day?
function getInnerText(el){
var childs = el.childNodes;
var txt = "";
for (var i=0, len=childs.length; i<len; ++i){
if (childs[i].nodeType == 3) {
txt += childs[i].data;
} else if (childs[i].nodeType == 1){
txt += getInnerText(childs[i]);
}
}
return txt.replace(/\s+/g,' ');
}
--
Peter
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn wrote:
>> VK wrote:
>> >> > It is not completely correct. Not every HTML encoded entity "trash
>> >> > out" the input but only < > & and and only if one
>> >> > treats the input string as HTML code (using .innerHTML) [...]
>> >>
>> >> Rubbish.
>> > Do you have a counterexample?
>> Do you have an example that proves it?
>
> ?? The test is in my first post. Can you see it?
Do you mean that *invalid* *markup*?
VK
wrote:
> VK wrote:
> > Thomas 'PointedEars' Lahn wrote:
> >> VK wrote:
> >> >> > It is not completely correct. Not every HTML encoded entity "trash
> >> >> > out" the input but only < > & and and only if one
> >> >> > treats the input string as HTML code (using .innerHTML) [...]
>
> >> >> Rubbish.
> >> > Do you have a counterexample?
> >> Do you have an example that proves it?
>
> > ?? The test is in my first post. Can you see it?
>
> Do you mean that *invalid* *markup*?
Really? What HTML validator are you using? I am still on W3C one.
http://validator.w3.org/#validate_by_input
[past my HTML sample]
[press Check]
"This document was successfully checked as HTML5!"
It is irrelevant though to the issue. If you like HTML 4.01 or XHTML
better, simply insert the code from BODY to your own preferred test
page.
RobG
> On Oct 6, 5:24 pm, RobG <robg...@gmail.com> wrote:
> > On Oct 6, 9:12 pm, VK <schools_r...@yahoo.com> wrote:
> > [...]
>
> > > <input type="button" value="Test innerText"
> > > onclick="
> > > /*@cc_on
> > > /*@if (@_jscript)
> > > var IE = true;
> > > @else @*/
> > > var IE = false;
> > > /*@end
> > > @*/
> > > this.form.elements['txt'].value = (IE)?
> > > document.getElementById('Sample').innerText
> > > :
> > > document.getElementById('Sample').textContent;
> > > ">
>
> > That is a spectacularly bad piece of code - there are many browsers
> > that aren't IE that implement innerText and not textContent.
>
> The current set of UAs I do care as of now is (listed by compatibility
> priority, the top is the highest one):
It is very poor design to deliberately break functionality in browsers
that *you* don't care about when a funcionally equivalent alternative
is available that will work in nearly all browsers that support a
scriptable DOM.
> Microsoft Internet Explorer 8.0 (X-UA-Compatible =6 =7 inclusive)
> Mozilla Firefox 3.5
> Safari 4.0
> Google Chrome 3.0
> Opera 10.0
>
> Out of this list you have no guarantee of anything, including
> document.createElement method.
Perhaps you should join the jQuery development team, that seems to be
their list of browsers too. The following quote is apt:
"Much of the time it feels like the decision to limit
browser support to less than half a dozen popular desktop
web browsers was no more than the consequence of the person
who did it not knowing how to do anything else, that the
costs of the alternatives are being estimated by people who
could not produce them (so don't actually know what is
involved), and that the people who will have to live with
the financial fall-out of these decisions don't even realise
what has happened, and so never could have ratified those
decisions."
Richard Cornford
clj: Re-enable disabled form elements when user goes 'Back'
<URL: http://groups.google.com/group/comp.lang.javascript/msg/b2b3849ffad66853
>
--
Rob
RobG
Superb! I couldn't have done better myself! ;-)
"Obtaining the textNode from within multiple elements"
<URL: http://groups.google.com/group/comp.lang.javascript/msg/eb0aca4db4ec6d97
>
There is a discussion of innerText and Safari 2 in the thread below.
There are other issues with an innerText/textContent fork such as they
handle whitespace and returns differently. The above recursive method
can return different strings in different browsers too, it has
limitations.
"Need something like doc.getElementById().innerHTML..."
<URL: http://groups.google.com/group/comp.lang.javascript/browse_frm/thread/86fff95c403b8809/69a8714d71a2be24#69a8714d71a2be24
>
--
Rob
Garrett Smith
Can be much better with a simple property:
var TEXT_CONTENT = typeof documentElement.textContent === "string" ?
"textContent" : "innerText";
// usage:
alert(document.body.textContent);
The textContent property is DOM 3.
There are scriptable browsers that support neither textContent nor
innerText. For example, Blackberry browser.
It may be the case that the program can be designed differently so as to
avoid the problem of reading textContent/innerText, but to read the
"data" of a text node.
--
Garrett
comp.lang.javascript FAQ: http://jibbering.com/faq/
Peter
I knew that somewhere I saw that trick :P
> "Obtaining the textNode from within multiple elements"
> <URL: http://groups.google.com/group/comp.lang.javascript/msg/eb0aca4db4ec6d97
>
> There is a discussion of innerText and Safari 2 in the thread below.
> There are other issues with an innerText/textContent fork such as they
> handle whitespace and returns differently. The above recursive method
> can return different strings in different browsers too, it has
> limitations.
IMHO this recursiuve function is much better, than
innerText/textContent, but I can not imagine what restrictions may have
a solution.
Secondly, I'm sure at least that I collect the content by nodeType,
which should give me 100% sure that there is text. Hm, what limitations
could be for this solution?
--
Peter
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn wrote:
>> VK wrote:
>> > Thomas 'PointedEars' Lahn wrote:
>> >> VK wrote:
>> >> >> > It is not completely correct. Not every HTML encoded entity
>> >> >> > "trash out" the input but only < > & and and
>> >> >> > only if one treats the input string as HTML code (using
>> >> >> > .innerHTML) [...]
>> >> >>
>> >> >> Rubbish.
>> >> > Do you have a counterexample?
>> >> Do you have an example that proves it?
>> >
>> > ?? The test is in my first post. Can you see it?
>>
>> Do you mean that *invalid* *markup*?
>
> Really? What HTML validator are you using? I am still on W3C one.
>
> http://validator.w3.org/#validate_by_input
> [past my HTML sample]
> [press Check]
> "This document was successfully checked as HTML5!"
And now you should look at what the relevant `select' element says.
"HTML 5" is not even a Proposed Recommendation yet, let alone a Web
standard.
> It is irrelevant though to the issue. If you like HTML 4.01 or XHTML
> better, simply insert the code from BODY to your own preferred test
> page.
And test it where?
VK
>
> > Really? What HTML validator are you using? I am still on W3C one.
>
> >http://validator.w3.org/#validate_by_input
> > [past my HTML sample]
> > [press Check]
> > "This document was successfully checked as HTML5!"
>
> And now you should look at what the relevant `select' element says.
> "HTML 5" is not even a Proposed Recommendation yet, let alone a Web
> standard.
It is a valid markup by W3C Validator, period. Any "spiritually
conforming" validations based on a particular opinion of a group
memeber are completely out of any public interest. Yet again, if you
are interested in historical curiosities and artifacts, no one
prohibit you to use valid XHTML, HTML3 or HTML4.x in your own
projects. Just do not mix your personal preferences with the public
demand ;-)
> > It is irrelevant though to the issue. If you like HTML 4.01 or XHTML
> > better, simply insert the code from BODY to your own preferred test
> > page.
>
> And test it where?
If you don't know how and where to test a code snippet posted in this
newsgroup then what are you doing here?
VK
> that *you* don't care about when a funcionally equivalent alternative
> is available that will work in nearly all browsers that support a
> scriptable DOM.
The most poor design IMHO is to make some "abstractly robust" code and
claim it universally robust because it corresponds to such and such
programming principles. Well, it is an evangelistic matter with Mb of
posting made here over years, with Matt Kruse vainly trying to bring
some practical sense into the orthodoxy. I don't feel like taking his
place. I will never change the opinion of say Richard, he will never
change mine.
> > Microsoft Internet Explorer 8.0 (X-UA-Compatible =6 =7 inclusive)
> > Mozilla Firefox 3.5
> > Safari 4.0
> > Google Chrome 3.0
> > Opera 10.0
>
> > Out of this list you have no guarantee of anything, including
> > document.createElement method.
>
> Perhaps you should join the jQuery development team, that seems to be
> their list of browsers too.
And the EU as well :-) :
http://europa.eu/rapid/pressReleasesAction.do?reference=MEMO/09/439&format=HTML
http://arstechnica.com/microsoft/news/2009/07/eu-vista-xp-users-will-also-get-to-vote-ie-off-the-island.ars
- not talking about my US customers were say Opera being supported on
my own time expenses were possible because no one will give you a damn
penny extra to support an absolutely unknown browser.
Again: a browser is a commercial product, and the Web market is not
some sweet garden for badly made software or for market-impotent
company managers. One wants to be noticed by developers? Then get at
least 0.5% of usage share in recognized usage stats companies.
Cannot get 0.5% in years? Die, sucker, die and free the space for new
rivals.
"recognized usage stats companies are not counting right", "we have
other usage stats companies that are counting right", blah-blah-blah -
die, sucker, and die as a man, the crying corner is not here.
:-)
:-|
Thomas 'PointedEars' Lahn
>> >> Do you mean that *invalid* *markup*?
>>
>> > Really? What HTML validator are you using? I am still on W3C one.
>>
>> >http://validator.w3.org/#validate_by_input
>> > [past my HTML sample]
>> > [press Check]
>> > "This document was successfully checked as HTML5!"
>>
>> And now you should look at what the relevant `select' element says.
>> "HTML 5" is not even a Proposed Recommendation yet, let alone a Web
>> standard.
>
> It is a valid markup by W3C Validator, period.
No so. The validators at w3.org are known to provide validation of features
that are not even implemented. In particular, W3C HTML 5 is clearly marked
a Working Draft, and the Validator's `select' element labels its validation
"(experimental)".
If you have any doubts what "Working Draft" means with regard to W3C
Technical Reports, read the HTML 5 Working Draft's "Status of this
document" section.
>> > It is irrelevant though to the issue. If you like HTML 4.01 or XHTML
>> > better, simply insert the code from BODY to your own preferred test
>> > page.
>>
>> And test it where?
>
> If you don't know how and where to test a code snippet posted in this
> newsgroup then what are you doing here?
Red herring. You are the one claiming your code displays a certain behavior
in one or more runtime environments; you are the person who needs to tell
where exactly it displays that behavior, so that your observations can be
double-checked, and other environments than that which you tested can be
checked for the problem to see how grave a problem it is. Extraordinary
claims require extraordinary evidence, or they may be easily be written off
as nonsense (and, let's face it, which you are known to submit).
<http://www.catb.org/~esr/faqs/smart-questions.html#id382249>
I will not reply next time unless you have learned to pay proper attribution
to those who you quoted.
PointedEars
--
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
-- Richard Cornford, cljs, <f806at$ail$1$8300...@news.demon.co.uk>
Thomas 'PointedEars' Lahn
> RobG wrote:
>> A feature test using typeof offers far better cross-browser support:
>>
>> var getText = (function() {
>> var el = document.createElement('p');
>> if (typeof el.textContent == 'string')
>> return function(el){return el.textContent;};
>> if (typeof el.innerText == 'string')
>> return function(el){return el.innerText;};
>> el = null;
>> })();
>>
>
> Can be much better with a simple property:
>
> var TEXT_CONTENT = typeof documentElement.textContent === "string" ?
> "textContent" : "innerText";
That makes the assumption that if one object supports the `textContent'
property all other objects must also support it, and that if one object does
not support the `textContent' property no other object supports it. That is
hardly "better" in any sense of the word.
PointedEars
--
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee
Thomas 'PointedEars' Lahn
> RobG wrote:
>> A feature test using typeof offers far better cross-browser support:
>>
>> var getText = (function() {
>> var el = document.createElement('p');
>> if (typeof el.textContent == 'string')
>> return function(el){return el.textContent;};
>> if (typeof el.innerText == 'string')
>> return function(el){return el.innerText;};
>> el = null;
>> })();
>>
>
> Can be much better with a simple property:
>
> var TEXT_CONTENT = typeof documentElement.textContent === "string" ?
> "textContent" : "innerText";
That is based on the jump to the conclusion that if an object referred to by
`documentElement' supports the `textContent' property all other objects must
also support it, and that if this object does not support the `textContent'
property it and other objects must support the `innerText' property. That
is hardly "better" than the above in any sense of the word.
RobG
> > It is very poor design to deliberately break functionality in browsers
> > that *you* don't care about when a funcionally equivalent alternative
> > is available that will work in nearly all browsers that support a
> > scriptable DOM.
>
> The most poor design IMHO is to make some "abstractly robust" code and
> claim it universally robust because it corresponds to such and such
> programming principles.
Your criterion for "most poor design" (as bizarre and poorly stated as
it is) is not the issue. The point is that in an environment of a wide
variety of browsers you shouldn't go out of your way to write crap
code that is guaranteed to break in a good proportion of them.
> Well, it is an evangelistic matter with Mb of
> posting made here over years, with Matt Kruse vainly trying to bring
> some practical sense into the orthodoxy. I don't feel like taking his
> place.
Irrelevant crap. You will never be considered a Matt Kruse surrogate -
he at least has a clue about how to write javascript.
> I will never change the opinion of say Richard, he will never
> change mine.
I think that rates as name dropping. I will never change Barack
Obama's opinion on anything - does that make me sound important?
> > > Microsoft Internet Explorer 8.0 (X-UA-Compatible =6 =7 inclusive)
> > > Mozilla Firefox 3.5
> > > Safari 4.0
> > > Google Chrome 3.0
> > > Opera 10.0
>
> > > Out of this list you have no guarantee of anything, including
> > > document.createElement method.
>
> > Perhaps you should join the jQuery development team, that seems to be
> > their list of browsers too.
>
> And the EU as well :-) :http://europa.eu/rapid/pressReleasesAction.do?reference=MEMO/09/439&f...http://arstechnica.com/microsoft/news/2009/07/eu-vista-xp-users-will-...
If you think either of those articles offers any kind of endorsement
by the EU for your choice of supported browsers then your level of
English comprehension is approaching zero. From the second article:
"Upon closer inspection, Microsoft's browser ballot proposal for the
EU is much more drastic than one would expect. Users will choose from
up to 10 different browsers. And it won't be limited to Windows 7
users; the ballot screen will be pushed as an update to current
Windows XP and Windows Vista users. PC manufacturers will also have
the option of shipping one or more third-party browsers in place of
IE8."
The articles are about *Microsoft's* proposed system for letting users
chose a browser, they do not in any way establish a set of preferred
browsers. I imagine that the ones in the article are there purely as
examples, they are not a definitive collection. Secondly, OEMs can put
whatever browsers they want into the ballot system so users will have
a much greater choice of browser then the minimal list you proposed.
The articles are evidence *against* your proposal to support only a
limited group of browsers.
> - not talking about my US customers were say Opera being supported on
> my own time expenses were possible because no one will give you a damn
> penny extra to support an absolutely unknown browser.
More irrelevant drivel. You clearly don't understand the issue so I'm
not going to repeat it yet again.
> Again: a browser is a commercial product, and the Web market is not
> some sweet garden for badly made software
Then stop post badly written code.
> or for market-impotent
> company managers. One wants to be noticed by developers? Then get at
> least 0.5% of usage share in recognized usage stats companies.
>
> Cannot get 0.5% in years? Die, sucker, die and free the space for new
> rivals.
So where are your tests for Mobile Safari? Opera on game consoles?
Blackberry? Your advice is not worth the paper it's printed on.
> "recognized usage stats companies are not counting right", "we have
> other usage stats companies that are counting right", blah-blah-blah -
> die, sucker, and die as a man, the crying corner is not here.
Perhaps you should take your own advice.
--
Rob
VK
> code that is guaranteed to break in a good proportion of them.
Here it comes again... OK, just as a creative writing exercise, let's
give it another shoot to the sky.
1) Please define "a good proportion of browsers" in an approximate
numeric percentage value.
2) Please define an approximate numeric percentage value of browsers
where such code as
/*@cc_on
/*@if (@_jscript)
var IE = true;
@else @*/
var IE = false;
/*@end
@*/
this.form.elements['txt'].value = (IE)?
document.getElementById('Sample').innerText
:
document.getElementById('Sample').textContent;
will lead to an error. Please name that UA and its version.
[...]
> So where are your tests for Mobile Safari? Opera on game consoles?
> Blackberry?
? Obviously in the relevant UA in the relevant device, where else? I
actually like these as it gives me 20% price increase per mobile
environment.
David Mark
> On Oct 9, 4:01 am, RobG <robg...@gmail.com> wrote:
>
> > code that is guaranteed to break in a good proportion of them.
>
> Here it comes again... OK, just as a creative writing exercise, let's
> give it another shoot to the sky.
>
> 1) Please define "a good proportion of browsers" in an approximate
> numeric percentage value.
>
> 2) Please define an approximate numeric percentage value of browsers
> where such code as
>
> /*@cc_on
> /*@if (@_jscript)
> var IE = true;
> @else @*/
> var IE = false;
> /*@end
> @*/
> this.form.elements['txt'].value = (IE)?
> document.getElementById('Sample').innerText
> :
> document.getElementById('Sample').textContent;
>
> will lead to an error. Please name that UA and its version.
We're trying to have a civilization here, VK.
>
> [...]
>
> > So where are your tests for Mobile Safari? Opera on game consoles?
> > Blackberry?
>
> ? Obviously in the relevant UA in the relevant device, where else? I
> actually like these as it gives me 20% price increase per mobile
> environment.
Do you mind?
VK
> On Oct 9, 3:42 am, VK <schools_r...@yahoo.com> wrote:
>
>
>
> > On Oct 9, 4:01 am, RobG <robg...@gmail.com> wrote:
>
> > > code that is guaranteed to break in a good proportion of them.
>
> > Here it comes again... OK, just as a creative writing exercise, let's
> > give it another shoot to the sky.
>
> > 1) Please define "a good proportion of browsers" in an approximate
> > numeric percentage value.
>
> > 2) Please define an approximate numeric percentage value of browsers
> > where such code as
>
> > /*@cc_on
> > /*@if (@_jscript)
> > var IE = true;
> > @else @*/
> > var IE = false;
> > /*@end
> > @*/
> > this.form.elements['txt'].value = (IE)?
> > document.getElementById('Sample').innerText
> > :
> > document.getElementById('Sample').textContent;
>
> > will lead to an error. Please name that UA and its version.
>
> We're trying to have a civilization here, VK.
UA? version? usage stats per markets?
I am not interested in the abstract wording, clj is already sinking in
it, if not already sunk.
> > > So where are your tests for Mobile Safari? Opera on game consoles?
> > > Blackberry?
>
> > ? Obviously in the relevant UA in the relevant device, where else? I
> > actually like these as it gives me 20% price increase per mobile
> > environment.
>
> Do you mind?
See above.
RobG
> On Oct 9, 4:01 am, RobG <robg...@gmail.com> wrote:
>
> > code that is guaranteed to break in a good proportion of them.
>
> Here it comes again... OK, just as a creative writing exercise, let's
> give it another shoot to the sky.
It seems you've completely missed the point of my OP.
> 1) Please define "a good proportion of browsers" in an approximate
> numeric percentage value.
The code you originally posted will fail in any browser that is not IE
and doesn't support textContent. There are plenty of those, such as
Safari 2.
> 2) Please define an approximate numeric percentage value of browsers
> where such code as
>
> /*@cc_on
> /*@if (@_jscript)
> var IE = true;
> @else @*/
> var IE = false;
> /*@end
> @*/
> this.form.elements['txt'].value = (IE)?
> document.getElementById('Sample').innerText
> :
> document.getElementById('Sample').textContent;
>
> will lead to an error. Please name that UA and its version.
That is only half the issue. The problem is that having split browsers
into two categories - IE and others - the code in your OP assumes that
all non-IE browsers support the textContent property. That is a
demonstrably false assumption. The alternative is a feature test that
looks at support for textContent and innerText directly, clearly a
better strategy.
You are trying to push browser sniffing in a forum that wrote it off
as a flawed strategy many years ago.
>
> [...]
>
> > So where are your tests for Mobile Safari? Opera on game consoles?
> > Blackberry?
>
> ? Obviously in the relevant UA in the relevant device, where else? I
> actually like these as it gives me 20% price increase per mobile
> environment.
So that's your angle. Instead of writing robust code, you'd write
stuff that will break outside your supported list, then charge an
exorbitant fee to support some other browser.
--
Rob
VK
> It seems you've completely missed the point of my OP.
OK, I am ready to follow it over again.
> The code you originally posted will fail in any browser that is not IE
> and doesn't support textContent. There are plenty of those, such as
> Safari 2.
This is a false statement (I mean "plenty of those") and you know it.
The current amount of Safari 2.x users is equal to the current amount
of Netscape 4.x users thus so negligible that is not reflected by any
known market share stats service, so >0.01%
At the same time the current amount of IE6 users is bigger than the
amount of users of all versions of FF together (24%-25% per region).
The secret of this phenomenon is in the "netbook explosion" on the
market with Windows XP SP2 + IE6 preinstalled.
This is the old lasting silliness of clj we're going to say bye-bye:
create most stupid imaginary compatibility problems yet disregard some
most practical ones as soon as "pure feature detection" cannot handle
them.
Of course any stats numbers never prove anything to some clj regulars
as unreliable, easily spoofed, blah-blah-blah etc. but for other
readers some sample stats:
http://marketshare.hitslink.com/browser-market-share.aspx?qprid=0
http://marketshare.hitslink.com/browser-market-share.aspx?qprid=2
Used methodology:
http://marketshare.hitslink.com/
> You are trying to push browser sniffing in a forum that wrote it off
> as a flawed strategy many years ago.
It is a false statement as well. What was rightly wrote off is the
code branching based purely on User-Agent string examination. The rest
is a hoax just like "DIV layout", "semantical Web", XHTML and many
other things to forget and to move on. IMHO it is also a long lasting
hypocrisy when
/*@cc_on
/*@if (@_jscript)
var IE = true;
@else @*/
var IE = false;
/*@end
@*/
is really bad because we dare to name the browser we are detecting
while
if (window.ActiveXObject) { ... }
is good because we like not naming anything, just "any browser with
this feature"...
> > > So where are your tests for Mobile Safari? Opera on game consoles?
> > > Blackberry?
>
> > ? Obviously in the relevant UA in the relevant device, where else? I
> > actually like these as it gives me 20% price increase per mobile
> > environment.
>
> So that's your angle. Instead of writing robust code, you'd write
> stuff that will break outside your supported list, then charge an
> exorbitant fee to support some other browser.
No, and it is clear if you follow the modern Web trends. I am writing
code that tested to work for 99.9% of current environments - that
automatically includes the legacy systems holding up to 0.1% of the
market share.
If my customer needs to support an environment with 0.09%-0.01% of
market shares than it is obviously an individual custom adjustment for
an extra pay. It is natural to understand to both the vendor and the
customer. To make it clearer, a standard furniture set may cost you
$1000 but the same set separately made for your room dimensions and
shape may cost you as much as $5,000
Thomas 'PointedEars' Lahn
> On Oct 9, 5:42 pm, VK <schools_r...@yahoo.com> wrote:
>> 1) Please define "a good proportion of browsers" in an approximate
>> numeric percentage value.
>
> The code you originally posted will fail in any browser that is not IE
s/is not IE/does not support JScript's conditional compilation feature/
> and doesn't support textContent. There are plenty of those, such as
> Safari 2.
PointedEars
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16
David Mark
> RobG wrote:
> > It seems you've completely missed the point of my OP.
>
> OK, I am ready to follow it over again.
>
> > The code you originally posted will fail in any browser that is not IE
> > and doesn't support textContent. There are plenty of those, such as
> > Safari 2.
>
> This is a false statement (I mean "plenty of those") and you know it.
No, Safari 2 is just an example.
> The current amount of Safari 2.x users is equal to the current amount
> of Netscape 4.x users thus so negligible that is not reflected by any
> known market share stats service, so >0.01%
That's pure nonsense.
> At the same time the current amount of IE6 users is bigger than the
> amount of users of all versions of FF together (24%-25% per region).
> The secret of this phenomenon is in the "netbook explosion" on the
> market with Windows XP SP2 + IE6 preinstalled.
Who cares if IE6 outnumbers Safari 2?
> This is the old lasting silliness of clj we're going to say bye-bye:
> create most stupid imaginary compatibility problems yet disregard some
> most practical ones as soon as "pure feature detection" cannot handle
> them.
Like what? At least three people have told you how to detect the
proper property, in this very thread...
> Of course any stats numbers never prove anything to some clj regulars
> as unreliable, easily spoofed, blah-blah-blah etc. but for other
> readers some sample stats:
> http://marketshare.hitslink.com/browser-market-share.aspx?qprid=0
> http://marketshare.hitslink.com/browser-market-share.aspx?qprid=2
> Used methodology:
> http://marketshare.hitslink.com/
Worthless and irrelevant to your "argument". You've been shown how to
write the function to work in virtually anything (and without
resorting to conditional compilation).
>
> > You are trying to push browser sniffing in a forum that wrote it off
> > as a flawed strategy many years ago.
>
> It is a false statement as well. What was rightly wrote off is the
> code branching based purely on User-Agent string examination.
Good riddance to that (ten years later).
> The rest
> is a hoax just like "DIV layout", "semantical Web", XHTML and many
> other things to forget and to move on. IMHO it is also a long lasting
> hypocrisy when
Who is perpetuating these "hoaxes?" For one, nobody in here
recommends XHTML. There's really no such thing as a "DIV layout" and
if there were, it wouldn't be discussed in this group. Semantic
markup is not a hoax, nor is it discussed in this JS group.
>
> /*@cc_on
> /*@if (@_jscript)
> var IE = true;
> @else @*/
> var IE = false;
> /*@end
> @*/
>
> is really bad because we dare to name the browser we are detecting
> while
It's really bad because there is a much simpler (and far more
effective) alternative. It's been posted in this very thread.
>
> if (window.ActiveXObject) { ... }
>
> is good because we like not naming anything, just "any browser with
> this feature"...
No, if you read this group regularly, you'd know that's awful as well
(in general and especially for this case).
>
> > > > So where are your tests for Mobile Safari? Opera on game consoles?
> > > > Blackberry?
>
> > > ? Obviously in the relevant UA in the relevant device, where else? I
> > > actually like these as it gives me 20% price increase per mobile
> > > environment.
>
> > So that's your angle. Instead of writing robust code, you'd write
> > stuff that will break outside your supported list, then charge an
> > exorbitant fee to support some other browser.
>
> No, and it is clear if you follow the modern Web trends. I am writing
> code that tested to work for 99.9% of current environments - that
> automatically includes the legacy systems holding up to 0.1% of the
> market share.
Who conducted that study?
> If my customer needs to support an environment with 0.09%-0.01% of
> market shares than it is obviously an individual custom adjustment for
> an extra pay. It is natural to understand to both the vendor and the
> customer. To make it clearer, a standard furniture set may cost you
> $1000 but the same set separately made for your room dimensions and
> shape may cost you as much as $5,000
What you don't seem to grasp is that hacks, object inferences, browser
sniffs, etc. don't keep. Your clients will have to call VK in the
near future to twiddle with them. Oh, as noted, perhaps that is your
strategy.
VK
> > RobG wrote:
> > > The code you originally posted will fail in any browser that is not IE
> > > and doesn't support textContent. There are plenty of those, such as
> > > Safari 2.
>
> > This is a false statement (I mean "plenty of those") and you know it.
>
> No, Safari 2 is just an example.
I am still open for another more reasonable (>= 0.1% market share is a
must)
> > The current amount of Safari 2.x users is equal to the current amount
> > of Netscape 4.x users thus so negligible that is not reflected by any
> > known market share stats service, so >0.01%
>
> That's pure nonsense.
It is a proven fact. Though anyone is entitle to believe that there is
a world-wide conspiracy against comp.lang.javascript supported and
financed by all major statistical agencies across the globe.
> > At the same time the current amount of IE6 users is bigger than the
> > amount of users of all versions of FF together (24%-25% per region).
> > The secret of this phenomenon is in the "netbook explosion" on the
> > market with Windows XP SP2 + IE6 preinstalled.
>
> Who cares if IE6 outnumbers Safari 2?
the customers
> > This is the old lasting silliness of clj we're going to say bye-bye:
> > create most stupid imaginary compatibility problems yet disregard some
> > most practical ones as soon as "pure feature detection" cannot handle
> > them.
>
> Like what? At least three people have told you how to detect the
> proper property, in this very thread...
> > Of course any stats numbers never prove anything to some clj regulars
> > as unreliable, easily spoofed, blah-blah-blah etc. but for other
> > readers some sample stats:
> > http://marketshare.hitslink.com/browser-market-share.aspx?qprid=0
> > http://marketshare.hitslink.com/browser-market-share.aspx?qprid=2
> > Used methodology:
> > http://marketshare.hitslink.com/
>
> Worthless and irrelevant to your "argument".
> You've been shown how to
> write the function to work in virtually anything (and without
> resorting to conditional compilation).
I am using the bulletproof methods, others may use almost bulletproof
or easily spoofed but "ideologically proper" but I don't have this
luxury.
> > > You are trying to push browser sniffing in a forum that wrote it off
> > > as a flawed strategy many years ago.
>
> > It is a false statement as well. What was rightly wrote off is the
> > code branching based purely on User-Agent string examination.
>
> Good riddance to that (ten years later).
? Did I ever insisted in this group to use User-Agent string and only
it? Back in 1998 it was document.layers vs. document.all in my script.
The other question is that the right idea (detect particular UAs by
feature tests and not by navigator.userAgent) was brought in clj into
some crazy dogmatic overstatement. All this is IMHO.
[...] (nothing new)
> > I am writing
> > code that tested to work for 99.9% of current environments - that
> > automatically includes the legacy systems holding up to 0.1% of the
> > market share.
>
> Who conducted that study?
The members of the world-wide anti-c.l.j. conspiracy plot ;) , link to
one of them was provided
> > If my customer needs to support an environment with 0.09%-0.01% of
> > market shares than it is obviously an individual custom adjustment for
> > an extra pay. It is natural to understand to both the vendor and the
> > customer. To make it clearer, a standard furniture set may cost you
> > $1000 but the same set separately made for your room dimensions and
> > shape may cost you as much as $5,000
>
> What you don't seem to grasp is that hacks, object inferences, browser
> sniffs, etc. don't keep. Your clients will have to call VK in the
> near future to twiddle with them. Oh, as noted, perhaps that is your
> strategy.
My NN4+IE4,5 pop-up calendar written at summer 1998 still perfectly
working. Unfortunately I cannot provide the download link as my
anonymity at c.l.j. is part of my comfort. So you are free to decide
that I'm boasting.
David Mark
[snip]
>
> My NN4+IE4,5 pop-up calendar written at summer 1998 still perfectly
> working. Unfortunately I cannot provide the download link as my
> anonymity at c.l.j. is part of my comfort. So you are free to decide
> that I'm boasting.
Long-since decided. Thanks! :)
Garrett Smith
> Garrett Smith wrote:
>
>> RobG wrote:
>>> A feature test using typeof offers far better cross-browser support:
>>>
>>> var getText = (function() {
>>> var el = document.createElement('p');
>>> if (typeof el.textContent == 'string')
>>> return function(el){return el.textContent;};
>>> if (typeof el.innerText == 'string')
>>> return function(el){return el.innerText;};
>>> el = null;
>>> })();
>>>
>> Can be much better with a simple property:
>>
>> var TEXT_CONTENT = typeof documentElement.textContent === "string" ?
>> "textContent" : "innerText";
>
> That makes the assumption that if one object supports the `textContent'
> property all other objects must also support it, and that if one object does
> not support the `textContent' property no other object supports it. That is
> hardly "better" in any sense of the word.
>
It will work in Safari2, so that is better.
But certainly not better for Blackberry9000 (which supports neither).
Garrett Smith
> Garrett Smith wrote:
>
>> RobG wrote:
>>> A feature test using typeof offers far better cross-browser support:
>>>
>>> var getText = (function() {
>>> var el = document.createElement('p');
>>> if (typeof el.textContent == 'string')
>>> return function(el){return el.textContent;};
>>> if (typeof el.innerText == 'string')
>>> return function(el){return el.innerText;};
>>> el = null;
>>> })();
>>>
>> Can be much better with a simple property:
>>
>> var TEXT_CONTENT = typeof documentElement.textContent === "string" ?
>> "textContent" : "innerText";
>
> That is based on the jump to the conclusion that if an object referred to by
> `documentElement' supports the `textContent' property all other objects must
> also support it, and that if this object does not support the `textContent'
> property it and other objects must support the `innerText' property. That
> is hardly "better" than the above in any sense of the word.
>
I find that a fair inference to make that if one HTMLElement has a
"textContent" property, then most others will, too
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.
But this has gotten spectacularly off-track.
Garrett Smith
> Hi,
>
> I'm looking for a way to implement an autocomplete field on some of my
> forms.
>
> I need both ajax support (for larger lists) and also a way to pass in
> json arrays for smaller lists.
>
> The best I have found so far is this one:
>
> http://www.pengoworks.com/workshop/jquery/autocomplete.htm
>
> (I know, jQuery - yuck!)
>
Line 3:
var $input = $(input).attr("autocomplete", "off");
Where:
input.autocomplete = "off";
I know, boring. No dollar signs or chaining, but certainly much simpler.
> The problem with this one (and others) is that the rendering breaks
> when any of the strings contain html entity encoded characters. This
> is because the dropdown list is html, but the text box value is raw
> text. Fixing the code myself to reconcile the two looks like it will
> become very messy.
>
Help my understanding of that problem a bit:
Is the user typing "&" and the list has &?
That can't be; I must have misunderstood.
> If anyone could recommend a way to do this properly. (Either a plugin
> for an existing framework or a tried and tested pattern for
> implementing autocomplete in pure JS would be greatly appreciated)
>
Working out the details of the U/X is probably harder.
Mark Smith
> Mark Smith wrote:
> > Hi,
>
> > I'm looking for a way to implement an autocomplete field on some of my
> > forms.
>
> > I need both ajax support (for larger lists) and also a way to pass in
> > json arrays for smaller lists.
>
> > The best I have found so far is this one:
>
> >http://www.pengoworks.com/workshop/jquery/autocomplete.htm
>
> > (I know, jQuery - yuck!)
>
> Line 3:
> var $input = $(input).attr("autocomplete", "off");
>
> Where:
> input.autocomplete = "off";
>
> I know, boring. No dollar signs or chaining, but certainly much simpler.
>
> > The problem with this one (and others) is that the rendering breaks
> > when any of the strings contain html entity encoded characters. This
> > is because the dropdown list is html, but the text box value is raw
> > text. Fixing the code myself to reconcile the two looks like it will
> > become very messy.
>
> Help my understanding of that problem a bit:
> Is the user typing "&" and the list has &?
>
> That can't be; I must have misunderstood.
>
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.
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.
Thanks
Thomas 'PointedEars' Lahn
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
--
Danny Goodman's books are out of date and teach practices that are
positively harmful for cross-browser scripting.
-- Richard Cornford, cljs, <cife6q$253$1$8300...@news.demon.co.uk> (2004)
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.
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
> Garrett Smith wrote:
>
>> Thomas 'PointedEars' Lahn wrote:
>>> Garrett Smith wrote:
>>>> RobG wrote:
>>>>> A feature test using typeof offers far better cross-browser support:
>>>>>
>>>>> var getText = (function() {
>>>>> var el = document.createElement('p');
>>>>> if (typeof el.textContent == 'string')
>>>>> return function(el){return el.textContent;};
>>>>> if (typeof el.innerText == 'string')
>>>>> return function(el){return el.innerText;};
>>>>> el = null;
>>>>> })();
>>>>>
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.
>>>> Can be much better with a simple property:
>>>>
>>>> var TEXT_CONTENT = typeof documentElement.textContent === "string" ?
>>>> "textContent" : "innerText";
>>> That makes the assumption that if one object supports the `textContent'
>>> property all other objects must also support it, and that if one object
>>> does
>>> not support the `textContent' property no other object supports it. That
>>> is hardly "better" in any sense of the word.
>> 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").
>
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
> Thomas 'PointedEars' Lahn wrote:
> > Garrett Smith wrote:
>
> >> Thomas 'PointedEars' Lahn wrote:
> >>> Garrett Smith wrote:
> >>>> RobG wrote:
> >>>>> A feature test using typeof offers far better cross-browser support:
>
> >>>>> var getText = (function() {
> >>>>> var el = document.createElement('p');
> >>>>> if (typeof el.textContent == 'string')
> >>>>> return function(el){return el.textContent;};
> >>>>> if (typeof el.innerText == 'string')
> >>>>> return function(el){return el.innerText;};
> >>>>> el = null;
> >>>>> })();
>
> 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.
>
> >>>> Can be much better with a simple property:
>
> >>>> var TEXT_CONTENT = typeof documentElement.textContent === "string" ?
> >>>> "textContent" : "innerText";
> >>> That makes the assumption that if one object supports the `textContent'
> >>> property all other objects must also support it, and that if one object
> >>> does
> >>> not support the `textContent' property no other object supports it. That
> >>> is hardly "better" in any sense of the word.
> >> 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").
>
> 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".
--
Rob
RobG
[...]
> To be
> clear, Safari 2 supports innerHTML and not textContent.
Ooops... supports innerText and not textContent
--
Rob
Garrett Smith
> On Oct 13, 9:31 am, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
>> Thomas 'PointedEars' Lahn wrote:
>>> Garrett Smith wrote:
>>>> Thomas 'PointedEars' Lahn wrote:
>>>>> Garrett Smith wrote:
>>>>>> RobG wrote:
[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
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 & Son</DT>
<DD>x1</DD>
</DT>
or could use an HTML5 datalist element.
<datalist id="autocomplete-items">
<option value="x1">O'Neill & Son</option>
</datalist>
When the INPUT's value changes, then update the displayed options.
Thomas 'PointedEars' Lahn
Yes, sorry, I misread/misremembered <news:b0b86d5f-24d7-4625-
bb4d-850...@s21g2000prm.googlegroups.com>.
Thank you for your clarification. The Matrix has you!
PointedEars
--
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
-- Richard Cornford, cljs, <f806at$ail$1$8300...@news.demon.co.uk>
Thomas 'PointedEars' Lahn
> RobG wrote:
>> On Oct 13, 10:39 am, RobG <robg...@gmail.com> wrote:
>> [...]
>>> To be clear, Safari 2 supports innerHTML and not textContent.
>>
>> Ooops... supports innerText and not textContent
>
> Yes, sorry, I misread/misremembered <news:b0b86d5f-24d7-4625-
> bb4d-850...@s21g2000prm.googlegroups.com>.
>
> 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'.