Stylesheet problem with generated nodes

Discussion in 'Javascript' started by jesdynf, Dec 15, 2006.

  1. jesdynf

    jesdynf Guest

    I'm having trouble applying a stylesheet to content I'm generating
    after the fact.

    Here's the sample code:

    <html>
    <head>
    <title>CSS/DOM Problem Example</title>
    <style type="text/css">
    ..historylinks {
    a:link { color: blue; text-decoration: none }
    a:active { color: red; text-decoration: none }
    a:visited { color: blue; text-decoration: none }
    a:hover { color: green; text-decoration: underline }
    }
    </style>
    <script type="text/javascript">
    function writeToHistory () {
    var hlist = document.getElementById("historyList");
    var li = document.createElement('li');
    var a = document.createElement('a');
    a.appendChild(document.createTextNode('Test!'));
    a.setAttribute("onClick", "alert(\"Alert!\");");
    a.setAttribute("class", "historylinks");
    li.appendChild(a);
    hlist.insertBefore(li,hlist.firstChild);
    }
    </script>
    </head>
    <body>
    <p>When you click this button, a new link appears at the top of the
    history list.
    Click on one of these links to perform an action.</p>
    <button onClick="writeToHistory();">Test</button>
    <ul id="historyList">
    <li>End of History</li>
    </ul>
    </body>
    </html>

    Mozilla reports that it doesn't understand the "a" declaration, and
    that might be a part of it, but as far as I can tell it's valid CSS. I
    tried assigning the style with both a.className and a.setAttribute;
    both generate valid HTML, but neither takes.

    (After /that/ I need to figure out why IE6 won't popup the Alert
    box...)

    I appreciate any help you offer.
     
    jesdynf, Dec 15, 2006
    #1
    1. Advertisements

  2. You can't nest CSS that way, you need e.g.
    .historylinks a:link { ... }
    .historylinks a:active { ... }
    .historylinks a:visited { ... }
    .historylinks a:hover { ... }
    Don't use setAttribute when scripting HTML documents, IE's
    implementation is much different from what the W3C DOM specifies and
    other browsers like Mozilla implement. Use element properties e.g.

    a.onclick = function () { alert("Alert!"); };

    and e.g.
    a.className = "historylinks";

    that works across user agents when scripting HTML.
     
    Martin Honnen, Dec 15, 2006
    #2
    1. Advertisements

  3. jesdynf

    VK Guest

    <html>
    <head>
    <title>Demo</title>
    <meta http-equiv="Content-Type"
    content="text/html; charset=iso-8859-1">
    <script type="text/javascript">
    function init() {
    var lnk = document.links[0];
    lnk.setAttribute('onclick', 'abrakadabra');
    window.alert(lnk.getAttribute('onclick'));
    // displays "abrakadabra"
    }
    window.onload = init;
    </script>
    </head>
    <body>
    <h1><a href="/">Demo</a></h1>
    </body>
    </html>

    How strange, setAttribute / getAttribute seem working just fine
    everywhere, including IE...

    Oh, got it! You meant to say: "Setting onclick attribute value in the
    relevant DOM Tree node is not always equal to setting onclick event
    handler in the element's scriptable DOM Interface".

    The question is then: why in the name would it be otherwise? It is true
    that some browsers do parse attrubute values and do update the
    interface thus they are making
    element.setAttribute('onclick', 'strValue');
    and
    element.onclick = myFunction;
    equal up to some extend (only "up to some extend" because DOM Tree and
    DOM Interface are too different to completely hide it).

    Such convenience "bridging" is neither directly prohibited nor required
    by the current specs. It means that there can be always UA's without
    such extension. One of such UA happens to take 85% or more of the
    current market share: thusly it is highly recommended for now do not
    use behavioral extension of setAttribute: use the standard interface
    scripting methods instead:

    a.onclick = myFunction;
    a.className = 'historylinks';
     
    VK, Dec 15, 2006
    #3
  4. Not altogether sound advice. IE /correctly/ refuses to set element
    properties that are described as "read-only" in the DOM, but does allow
    them to be set by setAttribute(). Firefox /incorrectly/ accepts the
    property setting.

    E.g.,

    var post = document.createElement("input");
    post.type = "submit";

    will incorrectly work under Firefox, but correctly fail under IE, whereas

    var post = document.createElement("input");
    post.setAttribute("type", "submit");

    will work everywhere.
     
    John W. Kennedy, Dec 15, 2006
    #4
  5. jesdynf

    Randy Webb Guest

    VK said the following on 12/15/2006 2:16 PM:
    <snip>

    Is there some reason you would put a request in the subject yet you have
    absolutely nothing in your post regarding any possible wording for an
    entry? If you want to request an entry, by all means do so. But don't
    imply in the subject that you want one and then not even mention it in
    the post.
     
    Randy Webb, Dec 16, 2006
    #5
  6. The current W3C DOM specification is W3C DOM Level 2 HTML
    <http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-62883744>
    it does not say that the type property (respectively type attribute in
    IDL terms) of HTMLInputElement objects is readonly. So using that sample
    above to claim a DOM implementation is incorrectly accepting changes to
    readonly properties is rubbish, that property is not readonly at all.
    Both IE/Win (tested with IE 6) and Mozilla/Firefox allow the above code
    without errors, that is creating a new input element object and setting
    its type property directly after that before the input element object is
    inserted into the document:

    See above test case, it does not make a difference in IE or Mozilla
    whether you use inputElement.type (or input['type']) or
    inputElement.setAttribute('type', '...'). The problem with IE's HTML DOM
    and setAttribute is that it pays attention to the case of attribute
    names and that it wants typed property values and not attribute strings:
    <http://msdn.microsoft.com/library/d...thor/dhtml/reference/methods/setattribute.asp>
    There it clearly says that the second argument is not (always) a string
    but rather a variant that can be a boolean, string or number. Then it
    has a third argument to indicate whether case should matter or not, by
    default it matters. In the W3C Core DOM the setAttribute method has two
    attributes that are always strings, and there is no third attribute.


    Where IE 6 refuses to set the type (but it refuses it with setAttribute
    as well as setting the type property) is when the input is already in
    the document:
    <http://home.arcor.de/martin.honnen/javascript/2006/12/test2006121602.html>


    So I think my advice is sound, in general and in particular for the
    example properties the original poster had, onclick and className.
     
    Martin Honnen, Dec 16, 2006
    #6
  7. jesdynf

    ASM Guest

    Martin Honnen a écrit :
    Yes that does any difference with my Firefox, but ...
    my IE (Mac) doesn't accept to set type attribute what you'll can try
    (the function breaks/stop from this point)
    nothing previously declared
     
    ASM, Dec 16, 2006
    #7
  8. jesdynf

    Randy Webb Guest

    ASM said the following on 12/16/2006 11:20 AM:
    IE on a Mac wouldn't be my choice of a browser to choose to use as a
    demo of whether something works or not.
     
    Randy Webb, Dec 16, 2006
    #8
  9. I don't know, Mac IE might be a very good choice for demonstrating
    something not working ;-)

    Richard.
     
    Richard Cornford, Dec 16, 2006
    #9
  10. jesdynf

    ASM Guest

    Richard Cornford a écrit :
    some things work better than with IE 6

    and ... you do what you want about info I can give ... :-(

    Now I can also talk about my NC4 :)
    (I doesn't more see functions with gEBI taking care if it can be used)
     
    ASM, Dec 16, 2006
    #10
  11. Dated late in 2000. IE6 (2001), as far as I can tell, implemented the
    DOM 1 specs, where HTMLInputElement.type _is_ readonly.
    Then that's a recent patch, because it was failing on an up-to-date IE6
    as recently as October (it cost me several hours of misery, IE6
    diagnostic facilities being as vile as they are).
    Hey, I never said IE doesn't suck.
    Let's just say the whole situation is a mess, no matter what approach
    you take.
     
    John W. Kennedy, Dec 16, 2006
    #11
  12. jesdynf

    Randy Webb Guest

    Richard Cornford said the following on 12/16/2006 12:26 PM:
    You have a very valid point.
     
    Randy Webb, Dec 16, 2006
    #12
    1. Advertisements

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 (here). After that, you can post your question and our members will help you out.