Accessing pseudo-classes through Javascript (Jscript)

P

pochartrand

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
}
 
R

Randy Webb

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.
 
T

Thomas 'PointedEars' Lahn

pochartrand said:
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
 
P

pochartrand

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
 
T

Thomas 'PointedEars' Lahn

pochartrand said:
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 said:
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
 
M

Matt Kruse

Thomas said:
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.
 
R

Richard Cornford

Matt said:
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.
"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.
 
R

Randy Webb

Richard Cornford said the following on 5/29/2006 6:48 PM:
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.
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.
 
T

Thomas 'PointedEars' Lahn

Richard said:
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
 
M

Matt Kruse

Richard said:
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.
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 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).
 
R

Richard Cornford

Randy said:
Richard Cornford said the following on 5/29/2006 6:48 PM:

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.
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 "contentions" should have been 'conventions'.
Absolutely.

Richard.
 
R

Richard Cornford

Thomas said:
Richard Cornford wrote:

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.
 
R

Richard Cornford

Matt said:
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.
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.
_() 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.
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?

..., 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.
 
M

Matt Kruse

Richard said:
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.
"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.
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.
 
R

Richard Cornford

Matt said:
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?
Any other naming suggestion? ...

Something that states what the function actually does?
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?
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.
 
T

Thomas 'PointedEars' Lahn

Richard said:
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
 
T

Thomas 'PointedEars' Lahn

Richard said:
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
 
R

Randy Webb

Thomas 'PointedEars' Lahn said the following on 5/30/2006 4:06 AM:
Richard said:
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.
 
L

Lasse Reichstein Nielsen

Richard Cornford said:
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
 

Ask a Question

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.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top