gmane.comp.web.dom.general

Re: FORM successful submit element?

Garrett Smith — 2008-08-10T22:25:26

On 8/10/08, João Eiras gmail.com> wrote: It's straying off topic. Somewhat interesting bug, though. Thanks for the informative reply, BTW. Huh? Yes, I've seen this and much worse. A RequestDispatcher on the server is the right alternative. WRT WF2.0, I should wait and see before continuing with more feedback. I don't want to waste my efforts. BTW, have you considered using inline-style response? It can make the discussion much easier to follow. http://en.wikipedia.org/wiki/Posting_style#Inline_replying Garrett

Re: FORM successful submit element?

João Eiras — 2008-08-10T21:26:11

How is that toString issue related with your original message? Anyway, if you really want to blame someone, join the whatwg mailing lists and contribute to the WF2 specification. Currently websites resort to javascript hacks to redirect a form submit to different urls. Useless I know. On , Garrett Smith gmail.com> wrote:

Re: FORM successful submit element?

Garrett Smith — 2008-08-10T17:59:19

On 8/10/08, João Eiras gmail.com> wrote: Really? I guess the only use case for that would be submitting to different domains. Taking that successful submit param on the server, all that is needed is a simple RequestDispatcher. WF2/HTML5 - Too many new features while there are things in HTML that still don't work in IE or Webkit. Opera needs to get some basicthings in order before implementing these new things. For example: javascript:try{ alert(document.forms[0].elements); } catch(ex) { alert(ex); } Opera: Error: Object doesn't implement [[Call]]. Because Opera tries to call the 'toString' property off of the 'elements' object. It should not do this, but should have an internal method that safely converts the HTMLCollection to a string. Garrett

Re: FORM successful submit element?

João Eiras — 2008-08-10T16:56:37

Hi. Opera probably gives the info you want because Opera supports WebForms 2, and in web forms you can have several submit buttons with different actions. It seems the other browsers have this behavior undefined. On , Garrett Smith gmail.com> wrote:

Re: FORM successful submit element?

Garrett Smith — 2008-08-07T06:32:49

On Mon, Aug 4, 2008 at 12:46 PM, Boris Zbarsky mit.edu> wrote: Thank you, Boris. That is what I thought. In serializing a FORM, I don't usually need to get the input that was clicked, but for completeness, it should be present. If this successful submit element were to be exposed, it would have to be through an event, I think. I'll probably want to take this over to the html5 list, but the idea is to get a form data as an object or string. form.onsubmit = function(e) { if(event.getBinaryString) { // Get Serialized Data. alert(event.getBinaryString()); } }; Garrett

Re: FORM successful submit element?

Boris Zbarsky — 2008-08-04T19:46:55

Garrett Smith wrote: No, it is not. -Boris

FORM successful submit element?

Garrett Smith — 2008-08-04T05:33:33

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? Opera: "image", et c. IE8, FF3, Safari 3: Error When the form is submitted, how to determine if and which submit input was t

RE: RFC4288 script media types (was: Using DOM to replace media attribute...)

David Perrell — 2008-07-29T21:31:03

Patrick Garies: | I also know of no cases where this is strictly required for “functional | compliance” (whatever that is). I simply said that the MIME type is | deprecated (i.e., discouraged). I don't agree the media types should be referred to as "deprecated." The meaning of "obsolete" in this context is in RFC4288 (which obsoleted 2048): '...media types that are no longer believed appropriate for use can be declared OBSOLETE by a change to their "intended use" field'. Obsolete can mean "outmoded," which is reasonable. RFC4329 is not an 'Internet standard', and - unlike HTML - doesn't need an interim period of deprecation (when UAs SHOULD continue to support something) prior to obsolescence. 'Functional compliance': where functionality depends on compliance (e.g. at some point security or versioning benefits might depend on full compliance). You're striving for syntactical compliance; there currently appears to be no functional difference. | There are functional differences for application/ecmasc

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

Patrick Garies — 2008-07-29T10:11:47

David Perrell wrote: I also know of no cases where this is strictly required for “functional compliance” (whatever that is). I simply said that the MIME type is deprecated (i.e., discouraged). (This issue is sort of like using quoted attributes versus unquoted in HTML; the latter is generally seen as poor practice, but still acceptable. There’s little practical effect with regard to either approach. The difference, in this case, is formal deprecation (for whatever that’s worth to you).) David Perrell wrote: There are functional differences for application/ecmascript assuming that the script is in its own file, at least (e.g., the version parameter). I haven’t tested whether current browsers that support the new application/* types actually adhere to the RFC in this regard though. David Perrell wrote: I didn’t say that you need to go change all of your existing Web pages. Presumably, that’s why the text/* types were registered. David Perrell wrote: At the same time, there was

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

David Perrell — 2008-07-29T02:12:23

Patrick Garies: | The first criterion is effectively saying “never”; So long as there's no functional compliance issue, that may be so. At the moment, I know of no spec I need to validate against that requires the new mime types. | I’m not quite sure what you mean by “partially” or “doesn't address | current conditions”. If, by those, your message is that something | shouldn’t be used until it can be freely used in all commonly used | browsers (i.e., “doesn't address current conditions”) and that | workarounds (i.e., “partial” adherence to RFC4329 due to the IE | workaround) mean that a solution shouldn’t be used, I simply have to | disagree. I have no qualms about conditionally using something that has a visual or functional effect, but I see no purpose in conditionally providing two different content descriptions when one will suffice. Obsoleting of text/javascript does not imply we must immediately change all our web pages. Text/javascript wasn't registered until RFC4

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

Patrick Garies — 2008-07-27T20:41:00

David Perrell wrote: The first criterion is effectively saying “never”; I don’t expect text/javascript to go anywhere even if the application/* media types become popularly used simply due to backward compatibility concerns. I don’t expect the latter to happen for years, particularly if Internet Explorer 8 or later end up not supporting RFC4329. David Perrell wrote: I’m not quite sure what you mean by “partially” or “doesn't address current conditions”. If, by those, your message is that something shouldn’t be used until it can be freely used in all commonly used browsers (i.e., “doesn't address current conditions”) and that workarounds (i.e., “partial” adherence to RFC4329 due to the IE workaround) mean that a solution shouldn’t be used, I simply have to disagree. Working around lack of browser support and/or being unable to fully support a standard until support improves or an alternative is offered is nothing new on the Web. (Of course, I realize that that la

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

David Perrell — 2008-07-26T05:37:22

Patrick Garies: | 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) My criteria is: when there are UAs that no longer accept script type as "text/javascript" OR when there are no longer UAs in common use that do not recognize the RFC4329-sanctioned script types. You ask if you can use the new MIME types without hurting anything while I ask "Why should I change what works to *partially* satisfy a specification that doesn't address current conditions?" That doesn't mean one of us is wrong (CCs aren't evil!), but I don't think assuming that all future versions of IE will support "text/ecmascript" is good idea. I would AT LEAST wait until a conforming version of IE is released and limit the IE-specifics to lesser versions. David Perrell

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

Thomas Fischer — 2008-07-24T13:50:13

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

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

Patrick Garies — 2008-07-24T06:31:40

David Perrell wrote: The primary point of the CC‐based approach is to work around this issue. David Perrell wrote: I didn’t dispute this. I simply noted that the mentioned MIME type is deprecated. David Perrell wrote: 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: 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 po

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

David Perrell — 2008-07-23T23:34:17

Patrick Garies wrote: | I said “up to version 7”, so that includes version 7 itself too. The way | that I implement it is by use of conditional comments: 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. 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. IMHO, conditional mime types are a bit premature. If you're presenting plain HTML then it should be safe to use the | Alternatively, the following works if you want to combine embedded scripts (with tracks for WIE and non‐WIE browsers): | | Admittedly, this is extra work for something that seems to be mostly cosmetic. Hopefully, WIE8 will support the two new MIME types so that the messiness above can eventually be done away with. (I’m not willing to test pre‐release software on this computer to find out if this issue is fixed in WIE 8 Beta 1 though.) — Patrick Garies

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

nimblehost — 2008-07-22T16:27:26

Thanks for your help Patrick - I'm a complete newbie when it comes to javascript and DOM, but you and David have helped get me on the right track here. I've gotten this to work - the problem was in my implementation. Thanks again, both of you. Jonathan Patrick Garies wrote:

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

David Perrell — 2008-07-22T14:48:07

Patrick Garies: | The original code was correct. |mediaType[x]| (not |mediaType.item[x]|) | is an ECMAScript alternative. ... | That would be |getElementById| (with a lowercase “d”). My apologies, thanks for the correction. I had tested before I wrote that, and it initially appeared that Jonathan's code didn't work, while mediaType[x] and getElementById("linkid") without the loop did work. But when I tested thusly: media type was changed in FF 3.01, Opera 9.51, and IE 5.01. | * The MIME type text/javascript is deprecated in favor of the MIME types | application/javascript and application/ecmascript. Unfortunately, | neither are supported in Windows Internet Explorer up to version 7. I'm still seeing a lot of pre-XP Windows

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

Patrick Garies — 2008-07-22T09:50:01

Patrick Garies wrote: I forgot: ditto for |setAttributeNS| versus |setAttribute|. — Patrick Garies

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

Patrick Garies — 2008-07-22T09:46:33