By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
459,268 Members | 1,262 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 459,268 IT Pros & Developers. It's quick & easy.

Accessing pseudo-classes through Javascript (Jscript)

P: n/a
Hello,

Is there a way to manipulate or at least read the pseudo-class of an
element ?

I know the style attribute can be accessed and gives the CSS properties
for a particular element. However, I can't seem to access the "hover"
properties.

example :

..class { color:#aaaaaa }
..class:hover {}

<div id="test" class="class"></div>

And then in an ideal world, I would like to do the following :

function()
{
element = $('test')
element.style.hover.color = #aaaaaa; <-------- this does not work
}

May 29 '06 #1
Share this Question
Share on Google+
37 Replies


P: n/a
pochartrand said the following on 5/29/2006 11:55 AM:
Hello,

Is there a way to manipulate or at least read the pseudo-class of an
element ?
Perhaps.
I know the style attribute can be accessed and gives the CSS properties
for a particular element. However, I can't seem to access the "hover"
properties.

example :

..class { color:#aaaaaa }
..class:hover {}

<div id="test" class="class"></div>

And then in an ideal world, I would like to do the following :

function()
{
element = $('test')


Please tell me you aren't using prototype.js as $( is a pretty good
indicator. If you are, all bets are off.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
May 29 '06 #2

P: n/a
Yes I use prototype.js

Is there a problem with that ?

May 29 '06 #3

P: n/a
pochartrand wrote:
Is there a way to manipulate or at least read the pseudo-class of an
element ?
Yes, there is.
I know the style attribute can be accessed and gives the CSS properties
for a particular element. However, I can't seem to access the "hover"
properties.

example :

.class { color:#aaaaaa }
.class:hover {}

<div id="test" class="class"></div>

And then in an ideal world, I would like to do the following :

function()
Since does not seem to be a FunctionExpression, the identifier is missing.
{
element = $('test')
Dump the Prototype junk, and do not rely on automatic semicolon insertion.
element.style.hover.color = #aaaaaa; <-------- this does not work


Of course it does not, as it is pure fantasy code.

1. It is syntactically incorrect. `#aaaaaa' is not an AssignmentExpression.
You should know already that CSS color values are represented by strings
in the DOM.

2. The proprietary `style' property of an element object refers to
its _inline_ style, not to a document stylesheet. That object
has properties corresponding to the possible inline style
properties (`style.color', for example), not to pseudo-classes.

IOW: you are trying to shoot at the wrong target with a broken bow.

You need to access the rule of the respective document stylesheet instead.
The first is that you find out which stylesheet applies. So you check out
the `className' property of the element object, and use
document.styleSheets to find the rule that corresponds to the pseudo-class.
Then you modify the `color' property of the object that represents this
rule.

Several examples for the retrieval and modification of stylesheet rules have
been posted before. Good luck.
PointedEars
--
Those who desire to give up freedom in order to gain security,
will not have, nor do they deserve, either one.
-- Benjamin Franklin
May 29 '06 #4

P: n/a
Thomas,

The code I posted is obviously syntactically incorrect and I didn't
think someone would actually care about it since my problem has nothing
to do with syntax. Same goes for the function without a proper name. As
prototype.js, I'm not using that for semi-automatic stuff.

I'm curious to know why you think prototype.js is junk btw.

The rest of your post was more interesting and maybe helpful though.

Thanks

May 29 '06 #5

P: n/a
pochartrand wrote:
The code I posted is obviously syntactically incorrect and I didn't
think someone would actually care about it since my problem has nothing
to do with syntax. Same goes for the function without a proper name.
You wrote about how it should be; I told you how it is.
Don't post anything that you don't want to be commented.
As prototype.js, I'm not using that for semi-automatic stuff. ^^^^^^^^^^^^^^^^^^^^
Whatever this means, Prototype's $() function alone is nonsense in and of
itself.

See the ECMAScript Language Specification (ECMA-262), Edition 3, subsection
7.6, and <URL:http://pointedears.de/scripts/test/whatami#inference>.
I'm curious to know why you think prototype.js is junk btw.


Google is your friend. [psf 6.1]

(It's not the first time that I [among others] comment on it.)
PointedEars
--
I hear, and I forget; I see, and I remember; I do, and I understand.
-- Chinese proverb
May 29 '06 #6

P: n/a
Thomas 'PointedEars' Lahn wrote:
Whatever this means, Prototype's $() function alone is nonsense in
and of itself.
Actually, I think it's pretty handy. I use my own version of $() in some
code.
See the ECMAScript Language Specification (ECMA-262), Edition 3,
subsection 7.6


"The dollar sign is intended for use only in mechanically generated code."

Just because something is _intended_ for one use doesn't mean it can't be
used for another. How code is generated has no relation to its validity or
functionality. Having a function named $ is perfectly valid. Nothing in the
specs says otherwise.

Innovation demands that things be used for purposes other than those for
which they were intended. :)
I'm curious to know why you think prototype.js is junk btw.

(It's not the first time that I [among others] comment on it.)


It needs to be a <FAQENTRY> by now. I intended to include an explanation of
why not to use it in my update of my best practices document.

--
Matt Kruse
http://www.JavascriptToolbox.com
http://www.AjaxToolbox.com
May 29 '06 #7

P: n/a
Matt Kruse wrote:
Thomas 'PointedEars' Lahn wrote:
Whatever this means, Prototype's $() function alone is
nonsense in and of itself.
Actually, I think it's pretty handy. I use my own version
of $() in some code.


Element reference retrieval by ID attribute is such a common requirement
that it makes perfect sense, when differing approaches must be used in
differing DOMs, to wrap the details up in a parameterised function call
and to extensively re-use that one function.
See the ECMAScript Language Specification (ECMA-262),
Edition 3, subsection 7.6


"The dollar sign is intended for use only in mechanically
generated code."

Just because something is _intended_ for one use doesn't
mean it can't be used for another. How code is generated
has no relation to its validity or functionality.


It might make a big difference to debugging and maintaining such code.
That is an area where contentions and 'best practices' make a
considerable contirbution.
Having a function named $ is perfectly
valid. Nothing in the specs says otherwise.
It is perfectly valid, but the specification defines a convention that
assigns particular meaning to Identifiers that start with $. It may be
possible/practical to disregard that convention but there are no
advantages in doing so. Equally short and obscure Identifiers are
available, including the underscore character.
Innovation demands that things be used for purposes
other than those for which they were intended. :)


Using a valid identifier is hardly an innovation, and neither is
disregarding a convention to no tangible benefit. There is no advantage
in using a $ to start an Identifier and the cost of doing so is that
knowledgeable javascript authors will have a natural expectation
disappointed.
I'm curious to know why you think prototype.js is
junk btw.

(It's not the first time that I [among others]
comment on it.)


It needs to be a <FAQENTRY> by now.

<snip>

It is certainly getting to be frequent, but what could be said?

Richard.
May 29 '06 #8

P: n/a
Richard Cornford said the following on 5/29/2006 6:48 PM:
Matt Kruse wrote:
Thomas 'PointedEars' Lahn wrote:
Whatever this means, Prototype's $() function alone is
nonsense in and of itself. Actually, I think it's pretty handy. I use my own version
of $() in some code.


Element reference retrieval by ID attribute is such a common requirement
that it makes perfect sense, when differing approaches must be used in
differing DOMs, to wrap the details up in a parameterised function call
and to extensively re-use that one function.


As JRS is so fond of saying, $( is less error prone than
document.getElementById( ever will be :) Although I don't care for the $
function name. Just seems perverse is all.
See the ECMAScript Language Specification (ECMA-262),
Edition 3, subsection 7.6

"The dollar sign is intended for use only in mechanically
generated code."

Just because something is _intended_ for one use doesn't
mean it can't be used for another. How code is generated
has no relation to its validity or functionality.


It might make a big difference to debugging and maintaining such code.


Whether a function is named $( or A( ? How?
That is an area where contentions and 'best practices' make a
considerable contirbution.


Absolutely.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
May 29 '06 #9

P: n/a
Richard Cornford wrote:
Matt Kruse wrote:
Thomas 'PointedEars' Lahn wrote:
Whatever this means, Prototype's $() function alone is
nonsense in and of itself.


Actually, I think it's pretty handy. I use my own version
of $() in some code.


Element reference retrieval by ID attribute is such a common requirement
that it makes perfect sense, when differing approaches must be used in
differing DOMs, to wrap the details up in a parameterised function call
and to extensively re-use that one function.


Count me in. But ignoring the inappropriate identifier (that I remember
you have commented on before, too), wrapping up details is exactly what
Prototype's $() does not. It does not even do a feature test for the sole
gEBI branch it supports.
I'm curious to know why you think prototype.js is
junk btw.
(It's not the first time that I [among others]
comment on it.)


It needs to be a <FAQENTRY> by now.

<snip>

It is certainly getting to be frequent, but what could be said?


I think some valid arguments have been collected in the meantime. I have
an idea of a "Using Prototype.js Considered Harmful" section on my Website,
and I might even take the time to dissect Prototype's code. (But no
promises, the next weeks are going to be very busy for me. It all depends
on how much free time will be left.)
PointedEars
--
But he had not that supreme gift of the artist, the knowledge of
when to stop.
-- Sherlock Holmes in Sir Arthur Conan Doyle's
"The Adventure of the Norwood Builder"
May 29 '06 #10

P: n/a
Richard Cornford wrote:
"The dollar sign is intended for use only in mechanically
generated code." It might make a big difference to debugging and maintaining such code.


In what way? I can't think of any common situations where it would matter.
Having a function named $ is perfectly
valid. Nothing in the specs says otherwise.

It is perfectly valid, but the specification defines a convention that
assigns particular meaning to Identifiers that start with $. It may be
possible/practical to disregard that convention but there are no
advantages in doing so.


I disagree. "Conventions" are not defined just by specs, but by actual
common use.
I would argue that $() being an "element lookup function" as a convention is
more known than the convention defined in the specs.
Equally short and obscure Identifiers are
available, including the underscore character.
_() is harder to read than $() :)

Currently, I've replaced $() with DOM.resolve() in my util.js, but I still
like the brevity of $(), and it does have a meaning that is understood to
many.
There is no
advantage in using a $ to start an Identifier and the cost of doing
so is that knowledgeable javascript authors will have a natural
expectation disappointed.


I think only the most extreme js authors would be familiar with the specs
enough to know what it says about $ in function/variable names. I would
propose that far more are familiar with prototype's $() functionality.
It needs to be a <FAQENTRY> by now.

It is certainly getting to be frequent, but what could be said?


Let's start a thread on well-reasoned arguments against prototype.js, and in
doing so I think some positive aspects should be pointed out as well. In
order to be considered fair and impartial, an analysis should be just that.
A short, concise list of 'cons' should suffice for the FAQ, or for my best
practices document (which is undergoing changes to be more in line with what
you and others might agree with as being best practices).

--
Matt Kruse
http://www.JavascriptToolbox.com
http://www.AjaxToolbox.com
May 30 '06 #11

P: n/a
Randy Webb wrote:
Richard Cornford said the following on 5/29/2006 6:48 PM:
Matt Kruse wrote:
Thomas 'PointedEars' Lahn wrote:
Whatever this means, Prototype's $() function alone is
nonsense in and of itself.
Actually, I think it's pretty handy. I use my own
version of $() in some code.
Element reference retrieval by ID attribute is such a
common requirement that it makes perfect sense, when
differing approaches must be used in differing DOMs,
to wrap the details up in a parameterised function call
and to extensively re-use that one function.


As JRS is so fond of saying, $( is less error prone than
document.getElementById( ever will be :) Although I don't
care for the $ function name. Just seems perverse is all.


On the assumption that fewer errors could be made writing the shorter
name? That may be true, but obviously any one character Identifier is as
short as '$', and spelling mistakes are not the only source of errors.
Errors in comprehension may be more problematic overall, and meaningful
Identifiers certainly do promote understanding. We are , after all,
talking about a global function that may be used anywhere rather than a
function local variable that only has to be understood within the
context of a dozen or so lines of code.
See the ECMAScript Language Specification (ECMA-262),
Edition 3, subsection 7.6
"The dollar sign is intended for use only in mechanically
generated code."

Just because something is _intended_ for one use doesn't
mean it can't be used for another. How code is generated
has no relation to its validity or functionality.


It might make a big difference to debugging and
maintaining such code.


Whether a function is named $( or A( ? How?


Suppose someone who knows javascript comes into a project and starts
looking at the code. He/She finds - A( .. ) - and goes looking through
the client-side code for a function named 'A' and finds it,
understanding what it does from the code found. Alternatively - $(
.... ) - is found, and knowing that it is conventional for Identifiers
beginning with '$' to be machine generated he/she has to start
wondering, and asking, about how, where and why this machine generated
Identifier is being generated, and the significance of that beyond its
manifestation.

If it never was being machine generated then all the extra time spent by
this individual finding that out, and the time of any of the others
asked about the issue, is a pure and unnecessary waste of resources.
(and the inverse of this situation, but with equivalent subsequent
expense, is experienced when real machine generated Identifiers are not
prefixed with '$').

Of course, if the function had a name that was more meaningful it may
not have been necessary for this individual to go and track down the
function definition on the first occasion they observed its use (or the
second and third times). Many conventions and 'best practices' reduce
ongoing costs.
That is an area where contentions and 'best practices' ^^^^^^^^^^^ make a considerable contirbution.


That "contentions" should have been 'conventions'.
Absolutely.


Richard.
May 30 '06 #12

P: n/a
Thomas 'PointedEars' Lahn wrote:
Richard Cornford wrote:

<snip>
It needs to be a <FA...RY> by now.

<snip>

It is certainly getting to be frequent, but what could
be said?


I think some valid arguments have been collected in the
meantime.

<snip>

The notion of picking on one particular library/toolset/script worries
me. The current apparent popularity of Protoytpe.js may just be an
aberration, and the next few months might show Yahoo's or someone else's
efforts replacing it as the thing that novices assume everyone
uses/knows.

There is a long standing request for an entry on code quality in general
(that is currently in early draft form), and although the discussion at
the time did not consider the '$' convention it certainly did cover most
of the other issues with Prototype.js.

Richard.

May 30 '06 #13

P: n/a
Matt Kruse wrote:
Richard Cornford wrote:
"The dollar sign is intended for use only in mechanically
generated code." It might make a big difference to debugging and maintaining
such code.


In what way? I can't think of any common situations where
it would matter.


You can only say that because actually machine generating Identifiers is
not that common in practice. You cannot reasonably deny that
disregarding conventions is not an aid to code maintenance in
programming in general.
Having a function named $ is perfectly
valid. Nothing in the specs says otherwise.

It is perfectly valid, but the specification defines a
convention that assigns particular meaning to Identifiers
that start with $. It may be possible/practical to disregard
that convention but there are no advantages in doing so.


I disagree. "Conventions" are not defined just by specs,
but by actual common use.


Conventions are certainly not something that you expect to find in
specs, but when one appears in that context the fact that is, as a
result, well known by individuals with a more than superficial interest
in the language suggests that it should be followed. Especially if there
is no really good reason for not following it, as in this case because
equally obscure and short alternative Identifiers are available.
I would argue that $() being an "element lookup function"
as a convention is more known than the convention defined
in the specs.
I have only ever seen one instance where that formulation was used, and
that should never have been create in the first place.
Equally short and obscure Identifiers are
available, including the underscore character.


_() is harder to read than $() :)


I don't see anything in it (particularly in a fixed with font). I would
not choose either in code that was intended to be maintained.
Currently, I've replaced $() with DOM.resolve()
"resolve" is still a bit non-specific for my taste.
in my util.js, but I still like the brevity of $(),
and it does have a meaning that is understood to many.
Yes, it means an arbitrary machine generated function in javascript.
There is no advantage in using a $ to start an Identifier
and the cost of doing so is that knowledgeable javascript
authors will have a natural expectation disappointed.


I think only the most extreme js authors would be familiar
with the specs enough to know what it says about $ in
function/variable names.


Or do you mean that only the most superficial javascript authors would
be unfamiliar with the specification? The convention has been repeatedly
mentioned here over the past 4 years to my certain knowledge.
I would propose that far more are familiar with
prototype's $() functionality.
More than what?

<snip> ..., or for my best practices document (which is undergoing
changes to be more in line with what you and others might
agree with as being best practices).


Does that mean you are going to attempt to justify the practices
recommend. That was my main criticism of your 'best practices' page,
because if you cannot write a convincing justification for a best
practice it may not be one.

Richard.
May 30 '06 #14

P: n/a
Richard Cornford wrote:
Conventions are certainly not something that you expect to find in
specs, but when one appears in that context the fact that is, as a
result, well known by individuals with a more than superficial
interest in the language suggests that it should be followed.
Especially if there is no really good reason for not following it, as
in this case because equally obscure and short alternative
Identifiers are available.
The fact that the decision is rather arbitrary is a good reason to not treat
it as a rule. Is there any logic behind saying that identifiers beginning
with $ should only be from generated code? Conventions such as class names /
namespaces beginning with a capital letter are common because they occur so
often. Machine-generated javascript is not all that common, and certainly
not to anyone at the level of using tools like prototype.
Currently, I've replaced $() with DOM.resolve()

"resolve" is still a bit non-specific for my taste.


Any other naming suggestion? I also considered "lookup" and DOM.$() ;)
Or do you mean that only the most superficial javascript authors would
be unfamiliar with the specification?
Not at all. Specifications are not often meant to be read by humans, but
rather as a reference for people writing implementations of the specs. There
are certainly some things to be learned from the ECMA Spec, but it seems
that the primary reason for being familiar with it is to be able to tell
others how stupid they are here in this group. I'm much less impressed by
someone who is very familiar with the specs than with someone who can do
something practical and useful with the working knowledge they have. People
who fit into both categories are rare! How many C, C++, Java, etc developers
do you know who have read the language specs cover to cover? Even very
skilled and experienced developers do not read the specs for the languages
and tools that they use unless they get really deep into it.
I would propose that far more are familiar with
prototype's $() functionality.

More than what?


More people are familiar with prototype's use of $() than the specs
convention for $ in identifiers.
(Based on unscientific observations of this group, support emails I receive,
and people I've worked with)
Does that mean you are going to attempt to justify the practices
recommend. That was my main criticism of your 'best practices' page,
because if you cannot write a convincing justification for a best
practice it may not be one.


Yes, I am going to write justifications and do general clean-up. For one,
I'm going to re-word the sections to be affirmative statements which
represent a best practice. Then I'll re-write some sections, add more
explanatory text, and add some new ones such as:
- Don't use html comments in script blocks
- Avoid cluttering the global namespace
- Avoid prototype.js
- Use 'var'
- Avoid 'sync' "Ajax" calls
- Use JSON

Any other suggestions you have would be greatly appreciated.

--
Matt Kruse
http://www.JavascriptToolbox.com
http://www.AjaxToolbox.com
May 30 '06 #15

P: n/a
Matt Kruse wrote:
Richard Cornford wrote:
Conventions are certainly not something that you expect to
find in specs, but when one appears in that context the
fact that is, as a result, well known by individuals with
a more than superficial interest in the language suggests
that it should be followed. Especially if there is no really
good reason for not following it, as in this case because
equally obscure and short alternative Identifiers are
available.
The fact that the decision is rather arbitrary is a good
reason to not treat it as a rule.


Of course it is arbitrary. Any character could have been used, although
attaching such significance to an alphabetical character obviously would
not have been a good idea.
Is there any logic behind saying that identifiers beginning
with $ should only be from generated code?
Is there any logic behind allowing '$' to be a leading character in an
Identifier at all? Why not '@', '# 'or '~'? It strikes me that '$' may
be in the set of characters allowed specifically in order to make it
available for that one specific use.
Conventions such as class names / namespaces beginning with
a capital letter are common because they occur so often.
Machine-generated javascript is not all that common,
The relative uncomments of machine generated Identifiers does not mean
that it is not useful to be able to indicate their status in a clear and
well known way.
and certainly not to anyone at the
level of using tools like prototype.
And it makes perfect space to let people who don't really know what they
are doing impose on ongoing maintenance expense on any code they are
involved with?
Currently, I've replaced $() with DOM.resolve()

"resolve" is still a bit non-specific for my taste.


Any other naming suggestion? ...


Something that states what the function actually does?
Or do you mean that only the most superficial javascript
authors would be unfamiliar with the specification?


Not at all. Specifications are not often meant to be read
by humans, but rather as a reference for people writing
implementations of the specs.
There are certainly some things to be learned from the ECMA
Spec, but it seems that the primary reason for being familiar
with it is to be able to tell others how stupid they are here
in this group.


You are a fool if you think that. ECMA 262 is the only source that
provides some very useful information. Where else are you going to find,
for example, a statement of which side of a comparison expression is
evaluated first, or a better statement of what it is that represents the
language core that can be expected to work in all implementations (so
stripped of the implementation specific extensions)?
I'm much less impressed by someone who is very familiar
with the specs than with someone who can do something
practical and useful with the working knowledge they have.
Javascript has always offered plenty of potential for doing things that
are "practical and useful" extremely badly. I cannot think of a single
individual whose javascript code I would want to go out of my way to
read who does not have some familiarity with the contents of ECMA 262.
Reading ECMA 262 may not be a panacea for good javascript authoring of
itself but (and certainly in the absence of a better source of the same
information) a familiarity with its content does promote a better
understanding of how javascript works. Which has very practical
consequnces.
People who fit into both
categories are rare!
People who know javascript well are rare.
How many C, C++, Java, etc developers do you
know who have read the language specs cover to
cover?
C, C++ and Java developers have good alternative sources for the level
of detail they need, Javascript does not. There are entire
implementations where the documentation consists of no more than stating
that they are ECMAScript implementations. Without knowing what
ECMAScript is how are you going to know what could be expected to work
in NetFront 4, for example?
Even very skilled and experienced developers do not read the
specs for the languages and tools that they use unless they
get really deep into it.


How many skilled developers have fallen into the trap of thinking that
javascript is block scoped like Java, or made assumptions about the
value of - this - and then been disappointed that javascript did not
work that way?
I would propose that far more are familiar with
prototype's $() functionality.

More than what?


More people are familiar with prototype's use of $() than
the specs convention for $ in identifiers. (Based on
unscientific observations of this group, support emails I
receive, and people I've worked with)

<snip>

If both groups are not that large then a personal sample is not going to
be representative.

There is no reason to allow the propagation of a mistake among people
who don't know any better get in the way of a well known, documented
convention that serves a more useful purpose, even if it is not needed
to do so very offten.

Richard.
May 30 '06 #16

P: n/a
Richard Cornford wrote:
Thomas 'PointedEars' Lahn wrote:
Richard Cornford wrote:
It needs to be a <FA...RY> by now.
It is certainly getting to be frequent, but what could be said? I think some valid arguments have been collected in the meantime.


The notion of picking on one particular library/toolset/script worries
me. The current apparent popularity of Protoytpe.js may just be an
aberration, and the next few months might show Yahoo's or someone else's
efforts replacing it as the thing that novices assume everyone
uses/knows.


The "Considered Harmful" document should be structured so that Prototype.js
works as an example to point out bad practices then, with anchors on each
section that discusses each one.
There is a long standing request for an entry on code quality in general
(that is currently in early draft form), and although the discussion at
the time did not consider the '$' convention it certainly did cover most
of the other issues with Prototype.js.


I still think Prototype.js would make up an especially good bad example
because of its popularity among the uninitiated.
PointedEars
--
Indiana Jones: The Name of God. Jehovah.
Professor Henry Jones: But in the Latin alphabet,
"Jehovah" begins with an "I".
Indiana Jones: J-...
May 30 '06 #17

P: n/a
Richard Cornford wrote:
Randy Webb wrote:
As JRS is so fond of saying, $( is less error prone than
document.getElementById( ever will be :) Although I don't
care for the $ function name. Just seems perverse is all.


On the assumption that fewer errors could be made writing the shorter
name? That may be true, but obviously any one character Identifier is as
short as '$', and spelling mistakes are not the only source of errors.
Errors in comprehension may be more problematic overall, and meaningful
Identifiers certainly do promote understanding. We are , after all,
talking about a global function that may be used anywhere rather than a
function local variable that only has to be understood within the
context of a dozen or so lines of code.


`$' is also frequently used as necessary prefix for variable access in
languages used server-side (e.g. PHP, Perl, [ba]sh). If a file would
contain both server-side code and client-side Prototype-based code (or
any code that introduces `$' as frequently used identifier), certainly
it would be confusing at first, and the code would be harder to maintain
then.
PointedEars
--
Alcohol and Math don't mix. So please don't drink and derive!
May 30 '06 #18

P: n/a
Thomas 'PointedEars' Lahn said the following on 5/30/2006 4:06 AM:
Richard Cornford wrote:
Randy Webb wrote:
As JRS is so fond of saying, $( is less error prone than
document.getElementById( ever will be :) Although I don't
care for the $ function name. Just seems perverse is all. On the assumption that fewer errors could be made writing the shorter
name? That may be true, but obviously any one character Identifier is as
short as '$', and spelling mistakes are not the only source of errors.
Errors in comprehension may be more problematic overall, and meaningful
Identifiers certainly do promote understanding. We are , after all,
talking about a global function that may be used anywhere rather than a
function local variable that only has to be understood within the
context of a dozen or so lines of code.


`$' is also frequently used as necessary prefix for variable access in
languages used server-side (e.g. PHP, Perl, [ba]sh).


That is irrelevant to whether it should be used in JS or not.
If a file would contain both server-side code and client-side Prototype-based
code (or any code that introduces `$' as frequently used identifier), certainly
it would be confusing at first, and the code would be harder to maintain
then.


Pure utter nonsense.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
May 30 '06 #19

P: n/a
"Richard Cornford" <Ri*****@litotes.demon.co.uk> writes:
Is there any logic behind allowing '$' to be a leading character in an
Identifier at all? Why not '@', '# 'or '~'? It strikes me that '$' may
be in the set of characters allowed specifically in order to make it
available for that one specific use.


I'm sure it was, just not for Javascript. Javascript surely inherited
the "$" from Java syntax (along with other baggage, like reserved words).
The Java Language Specification (first edition) says that "$" is
included for historical reasons, and should only be used in mechanically
generated code, or for accessing legacy systems.
<URL:http://java.sun.com/docs/books/jls/first_edition/html/3.doc.html#40625>

Personally, I don't mind using "$" as an identifier.

/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'
May 30 '06 #20

P: n/a
JRS: In article <h8******************************@comcast.com>, dated
Mon, 29 May 2006 18:58:49 remote, seen in news:comp.lang.javascript,
Randy Webb <Hi************@aol.com> posted :

As JRS is so fond of saying, $( is less error prone than
document.getElementById( ever will be :)


Justify that, if you can.

A local database search finds no occurrence of $( in my outgoing
mail/news since 2001-01-04 - and that one was not related to javascript.
The database contains virtually all of my outgoing messages.

--
John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 IE 4
<URL:http://www.jibbering.com/faq/> JL/RC: FAQ of news:comp.lang.javascript
<URL:http://www.merlyn.demon.co.uk/js-index.htm> jscr maths, dates, sources.
<URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.
May 31 '06 #21

P: n/a
Dr John Stockton said the following on 5/31/2006 12:48 PM:
JRS: In article <h8******************************@comcast.com>, dated
Mon, 29 May 2006 18:58:49 remote, seen in news:comp.lang.javascript,
Randy Webb <Hi************@aol.com> posted :
As JRS is so fond of saying, $( is less error prone than
document.getElementById( ever will be :)
Justify that, if you can.


Be pedantic if you must.
A local database search finds no occurrence of $( in my outgoing
mail/news since 2001-01-04 - and that one was not related to javascript.
The database contains virtually all of my outgoing messages.


Let me re-phrase it in a way that you won't be pedantic about it:

JRS is fond of using 1 and 2 character function names and defending that
practice by saying that it is less error prone to typos.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
May 31 '06 #22

P: n/a
VK
To OP:

The pseudo-selectors
:first-child
:first-letter
:first-line
:active
:hover
:link
:visited
are not available for scripting, at least not on IE. Potentially it is
possible to study linked stylesheets for rules and change corresponding
rules. It is /much/ easier though simply switch class name for
elements.

<OT>
"$ only for autogenerated code":- plain junk.
The whole sentence is indeed (as already pointed) taken from Java specs
where internal custom classes are stored in autogenerated files like
$Class1.class, $Class2.class etc. (when compiling the .java source). No
connection neither relevance to JavaScript.

In MS-DOS and (inheritedly) in Windows some service programs - very few
by now - start autoigenerated files with $ too. No connection neither
relevance to JavaScript.
From the other side in many programming languages $ sign is used as

variable type modifier (some old BASIC's) or simply as a marker of
variable. Say if you open any Perl program you'll be overwhelmed with
the amount of $'s because there it means any scalar thus not a function
pointer (&), object reference (*), array (@) or hash (%).

About the "weirdness" of single $ as identifier: that is exactly the
reason it was chosen. A widely used yet proprietary identifier has to
be short, memorizable and "unusual" so not lead to name conflicts - at
least not on every single step.

All this has no relevance to the quality of prototype.js as such.
</OT>

May 31 '06 #23

P: n/a
VK wrote:
<snip - usual nonsense>
"$ only for autogenerated code":- plain junk. <snip - more nonsense>

Thank you for endorsing the position that $ should only be used as an
initial character in a machine generated identifier.
All this has no relevance to the quality of prototype.js
as such.


How would you know?

Richard.
May 31 '06 #24

P: n/a
VK
<OT>
Richard Cornford wrote:
Thank you for endorsing the position that $ should only be used as an
initial character in a machine generated identifier.


Thank you for thinking of Perl programming as of a machine generated
process :-)
my $foo = "bar";
has to be typed by hand, including $ sign.

About "an initial character" - in some BASIC dialects (including the
British made Sinclair BASIC btw) $ denotes string value as opposed to
numeric value and placed as the end of identifier:
let a = 1;
let a$ = "foobar";

So the semantics of $ is similar to the symbol of rose: it has so many
meanings that it has no particular meaning whatsoever.
</OT>

Jun 1 '06 #25

P: n/a
VK wrote:
Richard Cornford wrote:
Thank you for endorsing the position that $ should only be used as an
initial character in a machine generated identifier.


Thank you for thinking of Perl programming ...

<snip>

Another demonstration of your talent for being spectacularly
irrelevant. This is a Javascript group, and we are talking about
javascript. Any special meaning that $ may have in other languages is
entirely their own business.

Richard.

Jun 1 '06 #26

P: n/a
VK wrote:
Richard Cornford wrote:
Thank you for endorsing the position that $ should only be used as an
initial character in a machine generated identifier.
Thank you for thinking of Perl programming as of a machine generated
process :-)
my $foo = "bar";
has to be typed by hand, including $ sign.


That is exactly the point. We are not talking about identifiers in Perl,
but about identifiers in ECMAScript implementations. Yet in Perl (and
other languages used server-side), `$' is a mandatory prefix of identifiers
for scalars, and every standalone $foo is considered a scalar reference
(read access). And server-side Perl can generate client-side
ECMAScript-conforming code. Now imagine what it would mean to escape each
and every `$' in that generated code in order to prevent it from being
understood by perl as a reference to a Perl scalar.
About "an initial character" - in some BASIC dialects (including the
British made Sinclair BASIC btw) $ denotes string value as opposed to
numeric value and placed as the end of identifier:
let a = 1;
let a$ = "foobar";

^
What part of "initial" is still unclear? And what meaning would have
BASIC (dialects; that introduced/endorsed the worst of all control
statements: GOTO) to contemporary programming?
PointedEars
--
Bill Gates isn't the devil -- Satan made sure hell
_worked_ before he opened it to the damned ...
Jun 1 '06 #27

P: n/a
VK wrote:
[...]
Thank you for thinking of Perl programming as of a machine generated
process :-)


Since we're <OT>-ing:
The official Perl term is "line noice with a mission", thank you.
http://en.wikipedia.org/wiki/Obfuscated_Perl_contest

--
Bart

Jun 1 '06 #28

P: n/a
Thomas 'PointedEars' Lahn asbergered:
my $foo = "bar";
has to be typed by hand, including $ sign.
That is exactly the point. We are not talking about identifiers in Perl,
but about identifiers in ECMAScript implementations. Yet in Perl (and
other languages used server-side), `$' is a mandatory prefix of identifiers
for scalars, and every standalone $foo is considered a scalar reference
(read access).


That is the general rule, yes. But one can easily use a pragma to
influence such things:
http://search.cpan.org/~abigail/vari....1/variable.pm
And server-side Perl can generate client-side
ECMAScript-conforming code.
Sure, as it can generate a T-shirt in a clothes factory or instruct a
plane how to fly.
Now imagine what it would mean to escape each
and every `$' in that generated code in order to prevent it from being
understood by perl as a reference to a Perl scalar.
If you're not familiar with Perl, this is a good remark indeed. It's a
simple mechanism though, called interpolation.

my $javascript = "alert('something')";

print qq{<html>
<body>
<script type="text/javascript">
$javascript
document.write('this is a \$-sign')
</script>
</body>
</html>
};

versus

print q{<html>
<body>
<script type="text/javascript">
document.write('this is a $-sign')
</script>
</body>
</html>
};
[...]


--
Bart

Jun 1 '06 #29

P: n/a
JRS: In article <nI******************************@comcast.com>, dated
Wed, 31 May 2006 15:15:06 remote, seen in news:comp.lang.javascript,
Randy Webb <Hi************@aol.com> posted :
Dr John Stockton said the following on 5/31/2006 12:48 PM:
JRS: In article <h8******************************@comcast.com>, dated
Mon, 29 May 2006 18:58:49 remote, seen in news:comp.lang.javascript,
Randy Webb <Hi************@aol.com> posted :
As JRS is so fond of saying, $( is less error prone than
document.getElementById( ever will be :)


Justify that, if you can.


Be pedantic if you must.
A local database search finds no occurrence of $( in my outgoing
mail/news since 2001-01-04 - and that one was not related to javascript.
The database contains virtually all of my outgoing messages.


Let me re-phrase it in a way that you won't be pedantic about it:

JRS is fond of using 1 and 2 character function names and defending that
practice by saying that it is less error prone to typos.


That's quite different; after you learn to read English, it will be time
to learn to write it - concisely and unambiguously, if you don't reject
that as unpatriotic.

I use single character function names in demonstration code, and maybe
for local functions; but I doubt whether you can find examples where I
have suggested that for wider use. But yes, two characters can be
sufficiently mnemonic for a common function ID.

--
John Stockton, Surrey, UK. ??*@merlyn.demon.co.uk Turnpike v4.00 MIME.
Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
Check boilerplate spelling -- error is a public sign of incompetence.
Never fully trust an article from a poster who gives no full real name.
Jun 1 '06 #30

P: n/a
Dr John Stockton said the following on 6/1/2006 7:14 AM:
JRS: In article <nI******************************@comcast.com>, dated
Wed, 31 May 2006 15:15:06 remote, seen in news:comp.lang.javascript,
Randy Webb <Hi************@aol.com> posted :
Dr John Stockton said the following on 5/31/2006 12:48 PM:
JRS: In article <h8******************************@comcast.com>, dated
Mon, 29 May 2006 18:58:49 remote, seen in news:comp.lang.javascript,
Randy Webb <Hi************@aol.com> posted :
As JRS is so fond of saying, $( is less error prone than
document.getElementById( ever will be :)
Justify that, if you can.

Be pedantic if you must.
A local database search finds no occurrence of $( in my outgoing
mail/news since 2001-01-04 - and that one was not related to javascript.
The database contains virtually all of my outgoing messages.

Let me re-phrase it in a way that you won't be pedantic about it:

JRS is fond of using 1 and 2 character function names and defending that
practice by saying that it is less error prone to typos.


That's quite different; after you learn to read English, it will be time
to learn to write it - concisely and unambiguously, if you don't reject
that as unpatriotic.


After you learn to read and understand what is written, maybe you can
attempt to preach to me about English. And while you are at it, you
might want to learn a little bit about the different dialects in use
around the World. I know, it is a stretch for you to even remotely
comprehend the implications of different dialects but I am sure you can
handle it.

While you are attempting to learn, you may want to learn the meaning of
a demonstrative example and try to understand the meaning of what people
say/write rather than continue with your pedantic behavior.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
Jun 1 '06 #31

P: n/a
In article <11**********************@i40g2000cwc.googlegroups .com>, VK
<sc**********@yahoo.com> writes

<snip>
<OT>
"$ only for autogenerated code":- plain junk.

<snip>

How do you feel about the opposite case where ECMA 262 allows something
but someone has grabbed it for their own use. Specifically, you're not
allowed to start a comment with
/**
nor with
//letter (i.e. no space after the //).

John
--
John Harris
Jun 1 '06 #32

P: n/a
John G Harris said the following on 6/1/2006 3:28 PM:
In article <11**********************@i40g2000cwc.googlegroups .com>, VK
<sc**********@yahoo.com> writes

<snip>
<OT>
"$ only for autogenerated code":- plain junk.

<snip>

How do you feel about the opposite case where ECMA 262 allows something
but someone has grabbed it for their own use.


Then nobody conforms to ECMA 262 and that means no browser/UA on the
planet is compliant. It just goes back to me saying that ECMA262 is a
good theory.....

But then it gets defended by saying that "The specs allow you to extend
this specification"

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
Jun 1 '06 #33

P: n/a
VK
John G Harris wrote:
How do you feel about the opposite case where ECMA 262 allows something
but someone has grabbed it for their own use. Specifically, you're not
allowed to start a comment with
/**
nor with
//letter (i.e. no space after the //).


Depends on who and why did grab it and how widely is it used.

Java-style comments for POD (your first example) is something to
respect as this notation is in use and there are programs for POD
parsing. "something to respect" means /should/ be respected, not /must/
be.

The second case is not known to me so I personally would disregard it -
unless instructed otherwise for a particular project.

As it was pointed numerous times by some people, c.l.j. cabbal could
write their own perfectly correct library and use instead of $ anything
else from underscore to \u-escaped Chinese hieroglyph. With good docs
and support it would be possibly much more popular than prototype.js
Instead they opted for explaining why libraries of any kind are bad as
such so they let other people to fulfill the demand. There are actions
and the consequences of these actions, so now they may end up by adding
extra check for (typeof $ == 'function') to make their code functional
anywhere outside of c.l.j. (if the things keep going in the same
direction with the same speed).

Jun 2 '06 #34

P: n/a
VK said the following on 6/2/2006 3:36 AM:
John G Harris wrote:
How do you feel about the opposite case where ECMA 262 allows something
but someone has grabbed it for their own use. Specifically, you're not
allowed to start a comment with
/**
nor with
//letter (i.e. no space after the //).
Depends on who and why did grab it and how widely is it used.


The first is the opening of a multi-line comment and the second is the
opening of a single line comment in JS.
Java-style comments for POD (your first example) is something to
respect as this notation is in use and there are programs for POD
parsing. "something to respect" means /should/ be respected, not /must/
be.
Whether it is Java-style, C++ style, or moon walking style is
irrelevant. It is a very established convention in Javascript.
The second case is not known to me so I personally would disregard it -
unless instructed otherwise for a particular project.
// single line comment.
// This construct is not known to you?
As it was pointed numerous times by some people, c.l.j. cabbal could
write their own perfectly correct library and use instead of $ anything
else from underscore to \u-escaped Chinese hieroglyph. With good docs
and support it would be possibly much more popular than prototype.js
Instead they opted for explaining why libraries of any kind are bad as
such so they let other people to fulfill the demand. There are actions
and the consequences of these actions, so now they may end up by adding
extra check for (typeof $ == 'function') to make their code functional
anywhere outside of c.l.j. (if the things keep going in the same
direction with the same speed).


What does anything in that paragraph have to do with anything about
single and multiple line comments that was asked about?

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
Jun 2 '06 #35

P: n/a
VK

Randy Webb wrote:
VK said the following on 6/2/2006 3:36 AM:
John G Harris wrote:
How do you feel about the opposite case where ECMA 262 allows something
but someone has grabbed it for their own use. Specifically, you're not
allowed to start a comment with
/**
nor with
//letter (i.e. no space after the //).


Depends on who and why did grab it and how widely is it used.


The first is the opening of a multi-line comment and the second is the
opening of a single line comment in JS.


Thanks for the enlightment :-), but you did not get the point: it was
asked about
/** (opening of a multi-line comment followed by asterix)
wich if used in Java-like POD generators to signal the parser that this
comment is to be parsed into POD segment (a piece of documentation).

As I said I did not know what does
//char (single line comment followed by a char w/o space)
mean but I presume some another convention for some other
parser/interpreter.

This is why relevant to the "$ sign identifier" discussion: the poster
asked my if I like if some construct/identifier/pretty-print, perfectly
legal for the given language, is taken/reserved by some 3rd party for
some specific use.

Jun 2 '06 #36

P: n/a
How do you guys feel about wasting your time on arguing wether or not
'$' should be used as a function name... or worse, how to start
comments...

Jun 14 '06 #37

P: n/a
In article <11**********************@h76g2000cwa.googlegroups .com>,
pochartrand <po*********@gmail.com> writes
How do you guys feel about wasting your time on arguing wether or not
'$' should be used as a function name... or worse, how to start
comments...


It's great!

It makes a change from job adverts.

It makes a change from troubles using prototype.js.

It makes a change from Date problems.
Does anyone know if Outlook Express still turns
//A
into
file://A
or has Microsoft stopped doing that?

John
--
John Harris
Jun 14 '06 #38

This discussion thread is closed

Replies have been disabled for this discussion.