Hello and welcome to our community! Is this your first visit?
Register
Enjoy an ad free experience by logging in. Not a member yet? Register.
Results 1 to 8 of 8
  1. #1
    Regular Coder
    Join Date
    Aug 2005
    Posts
    282
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Properties vs Attributes ??

    I can't seem to find any great documentation out there to clearly layout when a property should be set, vice the setAttribute method??

    Surely,

    Code:
    element.onclick = function() {} // for event handlers
    but where is the "best practices" for any other properties/attributes collections?
    M$ seems to publish them as being fully synonymous, however, that is not the full truth...

    Code:
    element.innerHTML = "some string";
    element.setAttribute("innerHTML", "some string");
    granted the first line would probably get a broader browser base, but what will be more future-proof?

    more hazy, would be such properties as "value, type, name" etc..
    any thoughts greatly appreciated.

  • #2
    Master Coder
    Join Date
    Feb 2003
    Location
    UmeŚ, Sweden
    Posts
    5,575
    Thanks
    0
    Thanked 83 Times in 74 Posts
    Well, here's the best practices BASED ON CURRENT BROWSERS. These are not the best practices from a DOM point of view, but from a compatibility point of view:
    • If it's an event handler, you should attach it to onevent property of the element node in the form of a function reference or literal. This has maximum compatibility. However, the W3C DOM Events and iew proprietary event attachment functions are good replacements if you need to do the event handling without disrupting any other code that might also handle events on the page. You need to be aware of some technical difficulties of each approach though.
    • If it's a change of the class or id of an element, or for that matter any HTML attribute, you should use the respective HTML DOM property of the element node (className, id etc.) for compatibility with iew.
    • If you're changing styles, simple style changes may be done by using the CSS2 DOM properties of the style property of the element node. A larger style change may be better served by writing it into a style rule for a class and simply changing the className of the element node to include or exclude that class. Making big style changes in the form of string assignments to the style property of the element node is generally a worse idea.
    Last edited by liorean; 02-18-2006 at 05:32 AM.
    liorean <[lio@wg]>
    Articles: RegEx evolt wsabstract , Named Arguments
    Useful Threads: JavaScript Docs & Refs, FAQ - HTML & CSS Docs, FAQ - XML Doc & Refs
    Moz: JavaScript DOM Interfaces MSDN: JScript DHTML KDE: KJS KHTML Opera: Standards

  • #3
    Kor
    Kor is offline
    Red Devil Mod Kor's Avatar
    Join Date
    Apr 2003
    Location
    Bucharest, ROMANIA
    Posts
    8,478
    Thanks
    58
    Thanked 379 Times in 375 Posts
    If I am allowed, I would like to add two more things:
    Quote Originally Posted by KC-Luck
    element.setAttribute("innerHTML", "some string");
    innerHTML is an IE only method. Anyway, when it is used in it's "active" way, it is a method, not an attribute. The way the above code is, you may expect that the element shoud have a HTML attribute called innerHTML

    <tag innerHTML="some string">

    Which, obviousely it is not true.

    Quote Originally Posted by liorean
    Making big style changes in the form of string assignments to the style property of the element node is generally a worse idea.
    Hm... But when need to modify only a single attribute at a time, to build a new classe each time for each of the possibilities looks not a bright ideea as well. You should deal with a huge bunch of classes, so that the same mess could occure, or even worst...
    KOR
    Offshore programming
    -*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

  • #4
    Master Coder
    Join Date
    Feb 2003
    Location
    UmeŚ, Sweden
    Posts
    5,575
    Thanks
    0
    Thanked 83 Times in 74 Posts
    Quote Originally Posted by Kor
    Hm... But when need to modify only a single attribute at a time, to build a new classe each time for each of the possibilities looks not a bright ideea as well. You should deal with a huge bunch of classes, so that the same mess could occure, or even worst...
    Well, obviously that only works if you know what possible states your elements may be at at the time of writing the style sheets. What I meant was that it's better to change one class than to change the style property at runtime if you already knew what styles should be added to the class at the creation of the page.

    If you're doing runtime things such as colour cycling, changing looks at runtime based on user input (not on any preset number of choices that you knew before hand), using drag and drop or other dynamic positioning etc. then obviously the style rule and class change method is not the best choice. But the majority of uses of writes to the style attribute wheere you change more than one style property you know at the time of creation what the possible values can be, and then creating hte style rule when you create the style sheet is a better idea.
    liorean <[lio@wg]>
    Articles: RegEx evolt wsabstract , Named Arguments
    Useful Threads: JavaScript Docs & Refs, FAQ - HTML & CSS Docs, FAQ - XML Doc & Refs
    Moz: JavaScript DOM Interfaces MSDN: JScript DHTML KDE: KJS KHTML Opera: Standards

  • #5
    Master Coder felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, Australia
    Posts
    6,642
    Thanks
    0
    Thanked 649 Times in 639 Posts
    innerHTML is not part of the standards but that method is supported by all of the major browsers including Firefox, Opera, Safari, Konqueror, Mozilla, and Netscape.
    Stephen
    Learn Modern JavaScript - http://javascriptexample.net/
    Helping others to solve their computer problem at http://www.felgall.com/

    Don't forget to start your JavaScript code with "use strict"; which makes it easier to find errors in your code.

  • #6
    Regular Coder
    Join Date
    Aug 2005
    Posts
    282
    Thanks
    0
    Thanked 0 Times in 0 Posts
    This is getting out of hand??
    the best examples would be

    Code:
    element.setAttribute("name", "radio1");
    element.setAttribute("value", "blah blah");
    element.setAttribute("id", "input-1");
    etc?
    yes, if given that the document is sent via application/xml+xhtml yes setAttribute would be the better choice??
    or, would setting each of the above attributes by direct property assignment be sufficient?

    Code:
    element.id = "input-1"; ....

  • #7
    Kor
    Kor is offline
    Red Devil Mod Kor's Avatar
    Join Date
    Apr 2003
    Location
    Bucharest, ROMANIA
    Posts
    8,478
    Thanks
    58
    Thanked 379 Times in 375 Posts
    The main ideea i that W3C tries, wiselly, to separate methods from attributes. In classical javascript the attaching of an attribute have a dual action, a passive one (returning the value of an attribute):

    var myValue = object.attribute

    and, in the same syntax, an active action (setting a value to an attribute)

    object.attribute = myValue;

    DOM tryes to separate them, and bring in front the methods, to avoid any possible coding confusion:

    var myValue=object.getAttribute('attribute');
    object.setAttribute('attribute','myValue');
    KOR
    Offshore programming
    -*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

  • #8
    Master Coder
    Join Date
    Feb 2003
    Location
    UmeŚ, Sweden
    Posts
    5,575
    Thanks
    0
    Thanked 83 Times in 74 Posts
    I believe the REAL reason the W3C chose to use methods is that it fits better with Java and similar systems.

    However, I would say the best practice is to use the property accessors whenever they exist, but ONLY for those cases that are actually defined.


    There's a problem here in that we have several technologies that are interacting, and the interaction is not always defined in any specification. Attributes are just strings. Let me give you an example: An event handler specified as an attribute might be JavaScript code, but from the DOM point of view it's just a string and has exactly NOTHING to do with the actual event handler, which is a pure JavaScript/DOM thing. That's why the event handler attributes are not directly mapped to the corresponding properties.

    This creates an inconsistency between the mapping of attribute to properties, and many people don't realise that. You simply cannot set a non-string value as an attribute value, and you simply cannot set a non-function as an event handler.
    liorean <[lio@wg]>
    Articles: RegEx evolt wsabstract , Named Arguments
    Useful Threads: JavaScript Docs & Refs, FAQ - HTML & CSS Docs, FAQ - XML Doc & Refs
    Moz: JavaScript DOM Interfaces MSDN: JScript DHTML KDE: KJS KHTML Opera: Standards


  •  

    Posting Permissions

    • You may not post new threads
    • You may not post replies
    • You may not post attachments
    • You may not edit your posts
    •