Accessing pseudo-classes through Javascript (Jscript)

Discussion in 'Javascript' started by pochartrand, May 29, 2006.

  1. pochartrand

    pochartrand Guest

    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
    }
     
    pochartrand, May 29, 2006
    #1
    1. Advertising

  2. pochartrand

    Randy Webb Guest

    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/
     
    Randy Webb, May 29, 2006
    #2
    1. Advertising

  3. pochartrand

    pochartrand Guest

    Yes I use prototype.js

    Is there a problem with that ?
     
    pochartrand, May 29, 2006
    #3
  4. 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
     
    Thomas 'PointedEars' Lahn, May 29, 2006
    #4
  5. pochartrand

    pochartrand Guest

    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
     
    pochartrand, May 29, 2006
    #5
  6. 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
     
    Thomas 'PointedEars' Lahn, May 29, 2006
    #6
  7. pochartrand

    Matt Kruse Guest

    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
     
    Matt Kruse, May 29, 2006
    #7
  8. 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.
     
    Richard Cornford, May 29, 2006
    #8
  9. pochartrand

    Randy Webb Guest

    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/
     
    Randy Webb, May 29, 2006
    #9
  10. 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"
     
    Thomas 'PointedEars' Lahn, May 30, 2006
    #10
  11. pochartrand

    Matt Kruse Guest

    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
     
    Matt Kruse, May 30, 2006
    #11
  12. 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.
     
    Richard Cornford, May 30, 2006
    #12
  13. 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.
     
    Richard Cornford, May 30, 2006
    #13
  14. 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.
     
    Richard Cornford, May 30, 2006
    #14
  15. pochartrand

    Matt Kruse Guest

    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
     
    Matt Kruse, May 30, 2006
    #15
  16. 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.
     
    Richard Cornford, May 30, 2006
    #16
  17. 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-...
     
    Thomas 'PointedEars' Lahn, May 30, 2006
    #17
  18. 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!
     
    Thomas 'PointedEars' Lahn, May 30, 2006
    #18
  19. pochartrand

    Randy Webb Guest

    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/
     
    Randy Webb, May 30, 2006
    #19
  20. "Richard Cornford" <> 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 -
    DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
    'Faith without judgement merely degrades the spirit divine.'
     
    Lasse Reichstein Nielsen, May 30, 2006
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Jon Maz
    Replies:
    4
    Views:
    1,277
    Jon Maz
    Sep 9, 2004
  2. Maxwell2006
    Replies:
    5
    Views:
    2,399
    Steven Cheng[MSFT]
    Mar 7, 2006
  3. Kevin Frey
    Replies:
    0
    Views:
    411
    Kevin Frey
    Jul 28, 2006
  4. John Bentley
    Replies:
    14
    Views:
    354
    Jim Ley
    Feb 5, 2004
  5. VK
    Replies:
    4
    Views:
    356
    Thomas 'PointedEars' Lahn
    Jan 12, 2006
Loading...

Share This Page