Jorge said:Hello,
What's the right thing to do in order to make it ~impossible to select
an element's text by clicking and dragging ?
kangax said:AFAIK, the following test works as well and avoids an element creation:
'MozUserSelect' in document.documentElement.style;
// `true` in Firefox 3.0.8
It's error-prone inference, though. `html' elements have no `style'
attribute to begin with, so their corresponding objects are not supposed to
have a `style' property.
Besides, haven't the two of you still not learned that the `in' operator for
feature-testing host objects (and other objects too, given its compatibility
matrix) is a bad idea in most cases?
typeof document.documentElement.style["MozUserSelect"] != "undefined"
David said:I assume you are referring to an old standard.
Not that there is a viable new one, but browsers have advanced since to
display the HTML element, [...]
so it is not a stretch to assume that browsers
released since the turn of the century have that property on the
documentElement (assuming they support it at all.)
Besides, haven't the two of you still not learned that the `in'
operator for feature-testing host objects (and other objects too, given
its compatibility matrix) is a bad idea in most cases?
typeof document.documentElement.style["MozUserSelect"] != "undefined"
Yes, but why not == 'string' ? And why the brackets?
kangax said:Good catch. Although, `document.body` (as an obvious alternative) might
not be available at the moment when test is performed (e.g. if a
containing SCRIPT element is itself contained within HEAD and BODY is
not yet parsed/created).
On a side note, do you know any clients which lack (or have a deficient)
`style` property on a `document.documentElement` object?
Besides, haven't the two of you still not learned that the `in' operator for
feature-testing host objects (and other objects too, given its compatibility
matrix) is a bad idea in most cases?
typeof document.documentElement.style["MozUserSelect"] != "undefined"
Feature testing varies. `isHostMethod`, as you know, actually compares
result of `typeof`, but if we are not interested in a particular
`typeof` value and only wish to know if a certain property exists, I
don't see what's wrong with `in`. It seems that - `typeof obj.foo !=
'undefined'` - can be replaced with - `'foo' in obj`.
If a property needs to be checked for callability, then `in` is not
enough, of course.
As far as compatibility, I see in your matrix, that `in` is supported by
JavaScript 1.4, JScript 5.0 and ECMAScript 3. Matrix also points out
that JScript 5.0 is implemented in IE5.0 and JavaScript 1.4 seems to
predate first versions of most of the JavaScript-based clients (such as
Firefox and SeaMonkey).
Isn't it reasonable to consider `in` safe for a
general web at this point in time (given how practically obsolete the
above mentioned versions of the browsers are)?
Is `in` inferior to `typeof` (besides compatibility) when one is not
interested in particular type of a property? And if so, why?
The archives have some discussion about that. The options include using
a combined approach of css and javascript.
.unselectable {
-moz-user-select: none;
-webkit-user-select: none;
}
if("unselectable" in el) {
el.unselectable = "on";
}
(...)
Thomas said:David said:I assume you are referring to an old standard.
The current standard, HTML 4.01 (and XHTML 1.x).
Not that there is a viable new one, but browsers have advanced since to
display the HTML element, [...]
Not really. And there is no good reason why document.body wouldn't suffice.
so it is not a stretch to assume that browsers
released since the turn of the century have that property on the
documentElement (assuming they support it at all.)
Whether it is a stretch or not, the assumption is unfounded. We've made
considerable progress (against considerable odds) with playing it safe on
host objects; now we don't want to fall back on the proof-by-example
fallacy, do we?
Yes, but why not == 'string' ? And why the brackets?Besides, haven't the two of you still not learned that the `in'
operator for feature-testing host objects (and other objects too, given
its compatibility matrix) is a bad idea in most cases?
typeof document.documentElement.style["MozUserSelect"] != "undefined"
Why, indeed. Just an old habit converting the `in' operation into something
less error-prone, I presume.
Good catch. Although, `document.body` (as an obvious alternative) might
not be available at the moment when test is performed (e.g. if a
containing SCRIPT element is itself contained within HEAD and BODY is
not yet parsed/created).
The current standard, HTML 4.01 (and XHTML 1.x).
Not that there is a viable new one, but browsers have advanced since to
display the HTML element, [...]
Not really. And there is no good reason why document.body wouldn't suffice.
Whether it is a stretch or not, the assumption is unfounded. We've made
considerable progress (against considerable odds) with playing it safe on
host objects; now we don't want to fall back on the proof-by-example
fallacy, do we?
Well, exactly. Whether an element object per se is created right from
the start or not is hardly relevant (and is probably implementation
dependent). It is availability of that element in a DOM that matters here..
I find scripts relying on `document.body` not as portable as those which
use alternative means (when possible, of course, and when a test doesn't
need to operate specifically on a BODY element itself). There's
`document.documentElement` and it's always trivial to create an element
yourself.
In this particular case, I'm thinking of something like:
var makeUnselectable = (function(){
function fnFalse() {
return false;
}
var selectProp, hasOnselectstart;
if (isHostMethod(document, 'createElement')) {
var el = document.createElement('div');
}
if (el && isHostMethod(el, 'setAttribute')) {
el.setAttribute('onselectstart', '');
hasOnselectstart = (typeof el.onselectstart == 'function');
if (el.style) {
var s = el.style;
selectProp = typeof s.MozUserSelect == 'string'
? 'MozUserSelect'
: typeof s.WebkitUserSelect == 'string'
? 'WebkitUserSelect'
: typeof s.KhtmlUserSelect == 'string'
? 'KhtmlUserSelect'
: '';
}
el = null;
}
if (hasOnselectstart) {
return function(el) {
el.onselectstart = fnFalse;
}
}
else if (selectProp) {
return function(el) {
if (el.style) {
el.style[selectProp] = 'none';
}
}
}
})();
I haven't tested it.
RobG said:Since head and body elements are mandatory in HTML documents, it is
likely that every document will be created with head and body elements
right from the start. However, that assumption is also likely to fail
in isolated cases since strictly the DOM shoudn't be presumed to be
ready for scripting until the load event occurs.
The window, document, document.documentElement properties are
immediately available for any a script that exists in a valid "normal"
page. The head element is also available, because the script is a
descendant of the head, the body, or a descendant of the body.
A script that expects document.body being the body element when it is
executed (global execution) places a constraint on that script: It must
be included in the body. Accessing document.body immediately can be
desirable in a feature test. The script that wants to access
document.body is limited to a few options.
1) include the script in the body
2) script uses onload to access document.body
3) script uses a "ready()" function to access body
4) script uses another node (not document.body)
5) script provides a function to access document.body later
Lets consider each option.
1) Pro:
Not including the scripts in the head also allows the script access to
document.body, without waiting for onload or "ready()" function.
<aside>
Aside from being able to access document.body, there is one other
consideration: Page load time and load order.
Many browsers will stop rendering content, won't download images or
other scripts until that script has loaded and executed.
If that script is moved all the way down, before the closing body tag,
the browser (any) will parse and render the body and continue to
download images without waiting for that script to load. The page will
load and render faster than if that script had been included in the head.
</aside>
con: Imposing the requirement of not including the script in the head
might not be a troublesome constraint for implementation code. However,
requiring low level code to exist in the body can cause inconvenience
when higher level code wants to use that low-level code, but that higher
level code wants to exist in the head (maybe to include a stylesheet but
avoid the visual effect of re-rendering (which can also impact
performance)). Requiring the low level code to have access to
document.body implies requiring the low level code to exist inside the
body, or requiring that that low-level code use onload or ready. That
means the high level code that depends on that file can't exist in the
head unless it also uses onload or the same "ready()" strategy that the
head used. That's a problem.
2) pro: simple and works in all browsers.
con: onload is slow, particularly if something is hanging.
3) pro: a ready function allows access to the document prior to onload.
con: A ready function, such as found on Dean Edwards site or in jQuery
relies on various nonstandard approaches. The reliable fallback to ready
is onload. If a ready function is used, it must be the same ready
function and that ready function therefore be included in the head.
4) use another node (not document.body)
This can work in some situations, but might be unsafe in other cases.
For example, a feature test that expects the browser to function in a
way that contradicts public w3c standards (such as by appending
elements) would be unsafe.
5) Low-level code provides a function that accesses document.body.
Con: requires redesigning the code in a way that might be more complex.
Con: The higher-level code does not have access the low-level method of
the body immediately. Must wait for onload or "ready()".
I can't think of a good reason to use an onload attribute in the body
tag, except maybe to match someone else's convention.
Why have some event handlers in html and some in the page-js file?
Consistency of behavior? No, that couldn't be it. Consistent
organization of code?
No, that isn't the case. Somebody prefers it that
way out of convention? Possibly, but I would question that convention.
You need to make sure you have a working setAttribute method first.
Ok. So, if `setAttribute` is broken, check that a value of a
corresponding event name property is not `undefined`?
Will be a string in IE < 8 (and IE8 in compatibility modes.)
Indeed. `typeof el.onselectstart != 'undefined'`, though, gives `true`
in at least IE7 and 8.
Might add "userSelect." Figure this will become at least a de facto
standard in the future.
Ok. Does it start with a lowercase `u`?
Are these mutually exclusive? I wouldn't treat them as such.
Good point.
You can lose this test. Won't get here unless the created DIV has a
style property. Of course, this assumes all elements that would be
passed to this function will have that property. Theoretically, this
could be an issue if an HTML element is passed (for example.) Seems a
good candidate for a footnote in the documentation.
That's what I had in mind - the fact that our dummy `HTMLDivElement` had
a style property doesn't quite guarantee that another element passed to
a function has it.
el.style[selectProp] = 'none';
}
}
}
})();
I haven't tested it.Not quite ready yet.
Thanks for corrections. Here's a modified version (if I understood all
of your points correctly):
var isEventSupported = (function(){
var isBuggy = false;
if (isHostMethod(document, 'createElement')) {
var el = document.createElement('div');
if (el && isHostMethod(el, 'setAttribute')) {
el.setAttribute('a', 'b');
isBuggy = (typeof el.a == 'b');
(...)
1) include the script in the body
2) script uses onload to access document.body
3) script uses a "ready()" function to access body
4) script uses another node (not document.body)
5) script provides a function to access document.body later
Lets consider each option.
(...)
See:
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.