Box model issue?

Collapse
This topic is closed.
X
X
Collapse
 
  • Page of 1
  • Time
  • Show
Clear All
new posts
Previous template Next
  • Robert Mark Bram
    #1

    Box model issue?

    Hi All!

    In the code below, I want to add a handler to a *row* (eventually so I can
    change the style of a row), but the event is being generated by the TD's it
    seems - in Opera and IE. Is there another way to assign a handler, making
    sure the event will come from the row and not a TD, or is this simply a box
    model issue I cannot work around by assigning new handlers?

    Any advice appreciated!

    Rob
    :)

    <html>
    <head>
    <title>Hover on Row Test</title>
    <script type="text/javascript">
    function addEventHandler (element, eventName, functionName) {
    if (element.attach Event) {
    element.attachE vent(eventName, functionName);
    }
    }
    function info(event) {
    infoElement = event.srcElemen t;
    alert (infoElement.no deName + " contains " + infoElement.inn erHTML);
    }
    </script>
    </head>
    <body>
    <table>
    <tr><td>cell 1</td><td>cell 2</td></tr>
    <tr><td>cell 1</td><td>cell 2</td></tr>
    <tr><td>cell 1</td><td>cell 2</td></tr>
    </table>
    <script type="text/javascript">
    elements = document.body.g etElementsByTag Name("tr");
    for(var index = 0; index < elements.length ; index++) {
    addEventHandler (elements[index], "onmouseove r", info);
    }
    </script>
    </body>
    </html>


    Tags: None
    • Michael Winter
      #2
      Re: Box model issue?

      Robert Mark Bram wrote:
      [color=blue]
      > [...] I want to add a handler to a *row* [...] but the event is
      > being generated by the TD's[/color]

      When an event is generated, it is /always/ targeted at the most deeply
      nested element. So, if you rollover a cell, the cell will be the
      target. To generate an event targeted at a row, the row itself (that
      is, the region outside of any cells) must be the deepest element involved.

      Once an event is generated, it will typically bubble-up to the root of
      the document (not all events bubble), activating listeners as it goes.
      [color=blue]
      > [...] in Opera and IE.[/color]

      In any user agent.
      [color=blue]
      > Is there another way to assign a handler, making sure the event
      > will come from the row and not a TD,[/color]

      No.
      [color=blue]
      > or is this simply a box model issue [...][/color]

      It has nothing to do with the box model. That affects layout. This is
      simply a standard behaviour of the event model.

      [snip]
      [color=blue]
      > element.attachE vent(eventName, functionName);[/color]

      Though the use of attachEvent does not, in itself, cause this issue
      (as I said, the behaviour is standard), /not/ using it will allow you
      to cope with the behaviour. You see, attachEvent is, in my opinion,
      broken. Instead of setting the this operator to something sensible -
      the element to which the listener is registered[1] - it is set to the
      global object which is entirely useless.

      If the IE event model provided a currentTarget equivalent (srcElement
      is equivalent to target), the deficiencies of attachEvent could be
      overlooked. However, this is not the case, so don't use it. If you
      need to manage multiple listeners on the same element, either use
      addEventListene r or code which emulates it with the on<event>
      properties. There have been several examples posted in this group's
      archives.
      [color=blue]
      > function info(event) {
      > infoElement = event.srcElemen t;
      > alert (infoElement.no deName + " contains "
      > + infoElement.inn erHTML);
      > }[/color]

      Once you've moved away from attachEvent, you can change the above to

      function info(e) {
      alert(this.node Name + ' contains ' + this.innerHTML) ;
      }

      Good luck,
      Mike


      [1] As you should know, this is what happens when an event listener is
      added via HTML intrinsic event attributes, on<event> properties,
      and the addEventListene r method. The fact that attachEvent doesn't
      follow this behaviour is the reason why I think it's broken.

      --
      Michael Winter
      Replace ".invalid" with ".uk" to reply by e-mail.

        Comment

        • Robert Mark Bram
          #3
          Event handling in the capturing phase for IE

          Hi All,

          Can anyone point me to an example of a 'home grown' way to introduce event
          handling in the capturing phase as opposed to the bubbling phase for IE?

          QuirksMode - for all your browser quirks
          http://www.quirksmode.org/index.html?/js/events_advanced.html


          Rob
          :)


            Comment

            • Tomasz Cenian
              #4
              Re: Event handling in the capturing phase for IE

              Robert Mark Bram napisa³(a):[color=blue]
              > Hi All,
              >
              > Can anyone point me to an example of a 'home grown' way to introduce event
              > handling in the capturing phase as opposed to the bubbling phase for IE?
              >[/color]

              Unless you implement your own javascript version for IE, its not possible.


              --
              tomasz cenian tcenian at wa dot home dot pl
              :::: :: : : http://cenian.boo.pl : : :: ::::

                Comment

                Previous template Next
                Working...