setSelectionRange and friends

[Thomas 'PointedEars' Lahn]

But those are XUL.

Do you consider that an argument against using them? Gecko uses XUL for
rendering widgets, so there is no problem there. And yet, those properties
have evidently been implemented in UAs not based on Gecko. As for another
example, `innerHTML' has been MSHTML. Has this stopped anyone?

Why not use the objects I recommended? They work in virtually every
modern browser (except IE of course.) ISTM that XUL objects are a
hard way to go here.

The properties are there for the purpose that they have been designed for,
regardless of their origin. To use Range objects instead is the hard way.


PointedEars

 

[David Mark]

Do you consider that an argument against using them?  Gecko uses XUL for
rendering widgets, so there is no problem there.

For now. Assuming it isn't buggy, which I can't vouch for.

And yet, those properties
have evidently been implemented in UAs not based on Gecko.

Yes, surprised to hear they are in Safari.

As for another
example, `innerHTML' has been MSHTML.  Has this stopped anyone?

No. But you miss the point. There is a more standard alternative
that I *know* works. That's what I recommend.

The properties are there for the purpose that they have been designed for,
regardless of their origin.  To use Range objects instead is the hard way.

How do you figure that? Write a quick wrapper and use it forever (in
virtually any modern browser.)

 

[Tim Streater]

No, all books published on the subject to date are more or less junk.

Can you justify this conclusion? Otherwise I shall consider it rubbish.

That's why there is some debate going on about whether the FAQ should
list any at all at the moment.


Goodman doesn't know what he is talking about, and so does Flanagan.

You mean nothing useful or correct in something like 2500 pages of text?

Nonsense.

In your apparently foolish opinion.

What does that mean?

A good text book gives you, in addition to mere reference information,
examples, comment, analysis, and answers to the questions anyone would
have after reading a reference. You may be able to deduce all of
geometry from the definition of a point, but I can't.

Trim your quotes to the relevant minimum, please.

No.

 

[Thomas 'PointedEars' Lahn]

For now.

XUL isn't going away on Gecko, and Gecko isn't going away on Mozillas
anytime soon, and they won't break existing GRE-based applications by
removing those properties.

Assuming it isn't buggy, which I can't vouch for.

It has worked fine in several Web editors, including that of MediaWiki (you
may have heard about it -- Wikipedia is based on it), for years.

No. But you miss the point. There is a more standard alternative
that I *know* works. That's what I recommend.

You really should explore the alternatives. It takes two *assignments* to
select text in a form control using .selectionStart and .selectionEnd. It
takes at least three *calls* to do it with Range objects. Guess why other
vendors (they are in WebCore because they are in KHTML) decided to implement
Gecko's .selection* properties.

How do you figure that?

How do I figure that they *are* there? Well, that they are *there*.

Write a quick wrapper and use it forever (in virtually any modern browser.)

However, that wrapper needs not, and in the case of form controls should
not, use Range objects only.


PointedEars

 

[Thomas 'PointedEars' Lahn]

No, all books published on the subject to date are more or less junk.

Can you justify this conclusion? [...]

Yes. Read the archives, there is plenty of evidence.

You mean nothing useful or correct in something like 2500 pages of text?

What matters is what the signal/noise ratio is. From what I have seen from
them quoted and posted here, it is at about the same low level as yours.

In your apparently foolish opinion.


A good text book gives you, in addition to mere reference information,
examples, comment, analysis, and answers to the questions anyone would
have after reading a reference. You may be able to deduce all of
geometry from the definition of a point, but I can't.

Apparently you don't know MDC and other reference sites out there.
Apparently you haven't read the FAQ which links to it. Obviously,
not apparently, *you* are the fool.

No.

*PLONK*


PointedEars

 

[David Mark]

XUL isn't going away on Gecko, and Gecko isn't going away on Mozillas
anytime soon, and they won't break existing GRE-based applications by
removing those properties.

We are do for some major changes in this industry. But regardless,
there is a precedent for Gecko removing XUL methods from the DOM, even
those in widespread use. See getBoxObjectFor. Last I checked, it
wasn't gone, but deprecated and pending deletion.

It has worked fine in several Web editors, including that of MediaWiki (you
may have heard about it -- Wikipedia is based on it), for years.

I didn't say it wouldn't work fine (if properly feature tested.) I'm
sure they don't use it exclusively; in fact, they must have at least
three branches, where only two are needed.

You really should explore the alternatives.

Maybe I will, but I will always regard XUL with skepticism when it
comes to cross-browser solutions. And I certainly won't recommend it
until I have more information.

It takes two *assignments* to
select text in a form control using .selectionStart and .selectionEnd.
It
takes at least three *calls* to do it with Range objects.  Guess why other
vendors (they are in WebCore because they are in KHTML) decided to implement
Gecko's .selection* properties.

Who cares? You only have to write the wrapper once. And I am even
less trusting of an imitation XUL method. Would you trust
document.all in Gecko?

How do I figure that they *are* there?  Well, that they are *there*.
Thanks.


However, that wrapper needs not, and in the case of form controls should
not, use Range objects only.

That's your opinion and I can't say I agree with it.

 

[Thomas 'PointedEars' Lahn]

We are do for some major changes in this industry. But regardless,
there is a precedent for Gecko removing XUL methods from the DOM, even
those in widespread use. See getBoxObjectFor. Last I checked, it
wasn't gone, but deprecated and pending deletion.

I see no argument here against using the properties when and if they are
there. Besides, has getBoxObjectFor() even been implemented elsewhere?
Looks like a collection of fallacious arguments.

I didn't say it wouldn't work fine (if properly feature tested.)

You implied that it may be buggy; I provided evidence to the contrary.

I'm sure they don't use it exclusively; in fact, they must have at least
three branches, where only two are needed.

Maybe so, but again an irrelevant argument (if an argument at all).

Who cares?

The people who want to write efficient code, which by definition should
include you from now on as you reported working on a supposedly widely used
general-purpose library (Dojo).

You only have to write the wrapper once.

Your repeated "write the wrapper only once" argument is void. One may have
to call the wrapper more than once, and then its efficiency matters very much.

And I am even less trusting of an imitation XUL method.

I was not talking about the setSelectionRange() method.

Would you trust document.all in Gecko?

Irrelevant argument.

That's your opinion and I can't say I agree with it.

Your problem, your loss.


PointedEars

 

[David Mark]

I see no argument here against using the properties when and if they are
there.

I'd look again.

Besides, has getBoxObjectFor() even been implemented elsewhere?

What difference would that make?

Looks like a collection of fallacious arguments.

I'd expect nothing less from you.

You implied that it may be buggy; I provided evidence to the contrary.

It certainly could be buggy. God knows gBOF was. The point is that I
can't recommend something that I haven't used. Perhaps you can.

Maybe so, but again an irrelevant argument (if an argument at all).



The people who want to write efficient code, which by definition should
include you from now on as you reported working on a supposedly widely used
general-purpose library (Dojo).


Your repeated "write the wrapper only once" argument is void.
Dammit!

 One may have
to call the wrapper more than once, and then its efficiency matters very much.

That's the first time you've mentioned efficiency here. As with
everything else, I can only comment on the efficiency of the objects
that I have used. You know this leads nowhere.

I was not talking about the setSelectionRange() method.


Irrelevant argument.

I don't think so.

Your problem, your loss.

My splitting headache. Can we agree to disagree here, yes?

 

[Thomas 'PointedEars' Lahn]

I'd look again.

I'd read again if I were you.

What difference would that make?

If no, there would be another red herring. If yes, we have an attempt at
proof by example. Since both arguments are fallacious, it would not matter
for the outcome of this discussion, of course, but it would be interesting
anyway.

It certainly could be buggy. God knows gBOF was. The point is that I
can't recommend something that I haven't used. Perhaps you can.

I have used the properties I have been referring to.

That's the first time you've mentioned efficiency here.

You are mistaken.

As with everything else, I can only comment on the efficiency of the objects
that I have used.

That is a pity. One would have assumed you would know that calls are
usually more expensive than assignments, given the same back-end action.

You know this leads nowhere.

It could lead to your starting to make an educated hypothesis.

My splitting headache. Can we agree to disagree here, yes?

If it was only you, yes. But if you are working on Dojo you should consider
the bigger picture, and I could not condone that course of action then.


PointedEars

 

[David Mark]

I'd read again if I were you.



If no, there would be another red herring.  If yes, we have an attempt at
proof by example.  Since both arguments are fallacious, it would not matter
for the outcome of this discussion, of course, but it would be interesting
anyway.



I have used the properties I have been referring to.

Okay. I'll look at them, whenever. Not a priority for me right now.

You are mistaken.

Am I? I fielded no questions about it. Regardless, you have my
answer.

That is a pity.  One would have assumed you would know that calls are
usually more expensive than assignments, given the same back-end action.

Of course I know that. As with anything to do with host objects,
there are no guarantees. I just refuse to go out on a limb like
that. Do as you must.

It could lead to your starting to make an educated hypothesis.

Um, I have my own thoughts about what *I* might do. What do you want,
a written report? It's not coming.

If it was only you, yes.  But if you are working on Dojo you should consider

Well, there's no if there. And I'll get to the text selection
stuff when I get to it. Just so happens it isn't today, so I am not
particularly interested in this subject.

the bigger picture, and I could not condone that course of action then.

I'm taking it under consideration. When the time comes, I'll do what
I think is valid, weighing feedback from the other contributors and
interested parties.

 

[Timo Reitz]

The universality of Range objects would make them candidates for less
performance than the specialized properties. It is not logical not to use
the latter when they are available.

Is it (less performance) really relevant? If not, I would prefer shorter
code to a little optimization.

 

[Thomas 'PointedEars' Lahn]

Is it (less performance) really relevant?

Of course it is. You want your Web application more responsive, not less,
and less memory-consuming, not more, don't you?

If not, I would prefer shorter code to a little optimization.

The beauty of it is that you can have both with the .selection* properties.
As I said, two assignments (or one call) compared to at least three calls.


PointedEars

 

[David Mark]

Of course it is.  You want your Web application more responsive, not less,
and less memory-consuming, not more, don't you?


The beauty of it is that you can have both with the .selection* properties.
 As I said, two assignments (or one call) compared to at least three calls.

That's just not true. Even for the OP, unless he is running just the
latest Safari and Gecko. Three branches vs. two. Less complexity
often trumps gains in efficiency.

And I can tell you that the less esoteric host methods involved, the
better. That rule holds for most browser scripting tasks.

 

[Thomas 'PointedEars' Lahn]

That's just not true. Even for the OP, unless he is running just the
latest Safari and Gecko. Three branches vs. two.

Why three branches? Which DOM does not support .selectionStart and
..selectionEnd but Range objects *instead*?

Less complexity often trumps gains in efficiency.

The complexity of the Range approach is undoubtedly greater than that of the
..selection* approach.

And I can tell you that the less esoteric host methods involved, the
better. That rule holds for most browser scripting tasks.

With my suggestion (that many others have already implemented), no host
method is involved at all. With Range objects at least three host methods
are involved.


PointedEars

 

[David Mark]

Why three branches?  Which DOM does not support .selectionStart and
.selectionEnd but Range objects *instead*?

So, it is you contention that all of these *XUL* properties are in
every browser that features the standard selection and range objects?
If so, you might have a point.

The complexity of the Range approach is undoubtedly greater than that of the
.selection* approach.

No kidding. The complexity I referred to was the extra branch.

With my suggestion (that many others have already implemented), no host
method is involved at all.  With Range objects at least three host methods
are involved.

You know what I meant. Esoteric properties are just as shaky. The
less the better.

 

[Garrett Smith]

Tim Streater wrote:

[...]

These seem to work in Safari 4 beta and FF3 (both Mac), but I'm
concerned they might be deprecated or not be best suited for my needs -
or that they might be part of a useful and well supported set that for
some reason I'm going to have to discover one item at a time.

Comments/suggestions welcome.

Also implemented in Opera 9 (possibly earlier).

It would be very helpful to have a test for them to see where they work,
and where they are buggy. I don't have one. Anyone else have an example?
Post up and include results from browsers.

If a property is found to be buggy, it would require a capability check
to work around that behavior. If that is too cumbersome, another
approach could be used.

Also related, .selection* is part of HTML 5 WD[1].

Garrett

[1]http://www.whatwg.org/specs/web-app...diting.html#dom-textarea/input-selectionstart