Unable to get element of frames through VBScript

name as a standard attribute

Errata for Range.insertNode

Hi,

I'm working on implementation of Range interface and create a test suite 
for this interface. By reading the Technical recommendation about 
Traversal and range Level 2, I identify a missing information.

Witch exception must be raise when the node given to insertNode function 
doesn't have any parent ?

    Patrik Dufresne

FORM successful submit element?

How to identify the submit button when a form was clicked?

The form below has three elements that can be used to submit the form.
If the form is submitted, it could be that one of the buttons would be
the cause, and, in that case, that button should be included in the
query string.

The browsers seem to have an internal mechanism for determining which
button is successful. Is the form's successful button exposed in the
DOM?

<form action="" id="theForm">
  <input name="text" value="blah">

  <input id="submit" name="submit" value="submit form here" type="submit">
  <input id="submit2" name="submit2" value="submit form there" type="submit">
  <input id="submit3" name="submit3" value="submit form elsewhere"
type="image" alt="[submit elsewhere]" src="missing.null">
</form>
<script>
document.getElementById('theForm').onsubmit = function(e) {
   alert(e.relatedTarget.type);
};
</script>

Opera: "image", et c.
IE8, FF3, Safari 3: Error

When the form is submitted, how to determine if and which submit input
was the cause?

Garrett

Design Fault: Document Object Model (DOM) Level 3 Events Specification

Hi,
in section "1.6.2. Mouse event types" is still a design fault:
  button of type unsigned short, readonly
    During mouse events caused by the depression or release of a mouse
    button, [...]

Problem:
If a mouse button depressed inside the document area but released
outside and mouse reenter the document area, there is no chance
to indicate, that no mouse button is depressed.

There is a common (failing) use case for drag & drop:
 - A drag action has been started inside the document area
   and the drag element is carry along the mouse pointer
 - Mouse pointer has been moved outside the document area
   and the drag element stand still on last mouse move/out position
 - Mouse button has been released
 - Mouse pointer has been moved inside the document area
   and the drag element still carry along the mouse pointer,
   although no mouse button depressed.

Solution:
 - button attribute should be updated during *ALL* mouse events
 - button attribute should be implemented as a bit mask (respectively
   for another attribute should be provide, to

I know, there are a lot of stalled discussions about this stuff.
Please keep in mind: A Web-Applications needs a well-performing
drag functionality, and currently only MS Internet Explorer provide it!

salute
Thomas

--
Thomas Fischer
Software Engineer

NOKIA Software & Services
Context, Advertising, and Emerging Markets

Re: Using DOM to replace media attribute in the link tag on page load

David Perrell wrote:
>  IE > 6 won't run on pre-XP Windows and there are clearly many who
>  feel no need to upgrade their OpSys or change its default UA.

The primary point of the CC‐based approach is to work around this issue.

David Perrell wrote:
>  Meanwhile, there are millions of web pages with script typed as
>  "text/javascript". UA acceptance of "text/javascript" won't be going
>  away any time soon.

I didn’t dispute this. I simply noted that the mentioned MIME type is 
deprecated.

David Perrell wrote:
>  IMHO, conditional mime types are a bit premature.

I’m curious as to what criteria should be used to determine when the 
time is “mature” in your view. The older MIME types text/javascript and 
text/ecmascript are essentially deprecated per RFC4329 (or “obsolete” as 
that RFC, unfortunately, puts it); RFC4329 is already on the IANA MIME 
Media Types list. The question is: “Can you start using the new MIME 
types here and now without significantly hurting anything?” The answer 
may vary depending upon your goals; in my case and, probably, most 
people’s cases (where they have enough control over their code to use 
CCs), the answer is “Yes.”.

David Perrell wrote:
>  If you're presenting plain HTML then it should be safe to use the
>  <script> tag without a type declaration.

I agree. However, it is “safe” to do quite a number of things that are 
not technically correct per specification(s), not conforming, invalid, 
or poor practice.

In this case, omission of the |type| attribute makes the document 
invalid (and non‐conforming?) and keeping it doesn’t hurt anything. I 
prefer to write documents that are valid and conforming since I believe 
that doing so is good form and, naturally, suggest that others do the 
same (as I did here).

Anyway, I don’t see how this even matters unless you’re suggesting that 
nimblehost should drop the attribute entirely.

David Perrell wrote:
>  However obsolete, "text/javascript" is currently the most-supported
>  content type for javascript and was probably a wise choice.

I’ve recognized the support levels for the various MIME types and my 
CC‐based approach takes this into account. (*/javascript can be 
substituted for */ecmascript in the example code that I previously 
presented, if preferred.) If you need to support browsers that don’t 
support the new application/* MIME types and/or the CC‐based solution 
doesn’t work for you (e.g., the problematic browsers are not WIE), then, 
by all means, use the text/javascript MIME type.

As a side note, I disagree with the term “obsolete” which means 
“useless” (clearly, text/javascript has not entered the realm of being 
useless); I prefer use of the term “deprecated” (“disfavored”).

David Perrell wrote:
>  I read an IE8 blog complaint: IE8b1 doesn't support the new mime
>  types. Perhaps that will change before final release.

That’s both interesting and unfortunate.

— Patrick Garies

Invoking a subroutine while DOM parsing

Using DOM to replace media attribute in the link tag on page load

I've found no references online that address this particular challenge, so I
hope the DOM experts here can point out the mistakes in my code. The
original html I am trying to replace looks like this:

<link rel="stylesheet" type="text/css" media="screen"
href="rw_common/themes/nhmobile/css/screenwidth/variable.css" />

I'd like to change the media attribute to "all" when the page loads so that
it looks like this instead:

<link rel="stylesheet" type="text/css" media="all"
href="rw_common/themes/nhmobile/css/screenwidth/variable.css" />

The code I've come up with is as follows:

<script type="text/javascript">
	var mediaType = document.getElementsByTagName("link");
	for(x=0; x<mediaType.length; x++) {
		mediaType.item(x).setAttribute("media", "all");
	}
</script>

Using firebug to check the current tree of nodes shows that the media
attribute remains unchanged. I'm at a loss at how to fix this problem. Any
and all help is greatly appreciated.

Best regards,
Jonathan
--

-- 
View this message in context: http://www.nabble.com/Using-DOM-to-replace-media-attribute-in-the-link-tag-on-page-load-tp18531235p18531235.html
Sent from the w3.org - www-dom mailing list archive at Nabble.com.

Change Event, Bubbling and IE8

This is a compliance issue with Internet Explorer.

If a change event can bubble, what can it bubble up to?

Will it be possible to observe a bubbled change on a FORM?

http://www.w3.org/TR/DOM-Level-2-Events/events.html

| change
|    The change event occurs when a control loses the input
| focus and its value has been modified since gaining focus.
| This event is valid for INPUT, SELECT, and TEXTAREA. element.
|
|        * Bubbles: Yes
|        * Cancelable: No
|        * Context Info: None

Internet Explorer 8 still does not support EventTarget, however, it
does support bubbling.

The result below from Safari3 and Firefox3 are that the change and
submit events bubble and alerts are shown.

IE8: No alert shown.

=============================================================================

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>
<head>
<title> Change </title>
</head>

<body>

<h1>Form Dirty?</h1>

<form id='big'>

  <fieldset id="ff"><legend>legend</legend>
  <select name='big'>
    <option>one</option>
    <option>two</option>
  </select>

  <textarea name="a">foo</textarea>
  <label>
    <input type="radio" name="df"/>radio
  </label>
    <input type="radio" name="df"/>radio
  <input type="checkbox"/>
  <input type='text'/>
  <input type="password"/>
  <input type="submit" value="go"/>
</fieldset>

</form>

<script>
  var big = document.getElementById('big');

  if(big.addEventListener) {
    big.addEventListener("change", getTimeStamp, true);
    big.attachEvent("submit", getTimeStamp, true);
  } else if(big.attachEvent) {
    big.attachEvent("onchange",  getTimeStamp, true);
    window.attachEvent("submit", getTimeStamp, true);
  }
  function getTimeStamp(e){
      alert(e.timeStamp);
  }
</script>

</body>
</html>
=============================================================================

If MSIE is not going to implement DOM Events, what should be the
expected behavior of MSIE?

Garrett

Regarding Entity Reference Nodes

FYI: minor typographical error in DOM Level 3 Validation

The following erratum was added:
[[
val-1. 2008-06-09. [minor typographical error]. The nodeValidity and
validateDocument methods

        The value VAL_NS_WF appears twice in the table describing all
        possible validation outcomes. The second appearance should be
        ignored.
]]
http://www.w3.org/2004/01/DOM-Level-3-errata#val-1

Regards,

Philippe