danca
7/21/2015 10:08:00 AM
Il 07/19/2015 12:27 PM, Thomas 'PointedEars' Lahn ha scritto:
>
> See my correction. You can use the getElementsByName(â?¦) method for that; it
> is available on HTML document objects in implementations of W3C DOM Level 2
> HTML (since 2003) and HTML5.
>
> The getElementsByName(â?¦) method is not available on element objects (at
> least not in a standards-compliant way; implementations may vary); however,
> the getElementsByTagName(â?¦) method is, starting from IE/MSHTML 5.5 at the
> latest. That method can be called as element.getElementsByTagName("*"), and
> the resulting NodeList can be filtered, if you do not want to be tied to a
> specific â??tagNameâ? property value. If all else fails, the return value of
> document.getElementsByTagName("*") can be filtered.
>
> Higher Levels of the W3C DOM, implemented in recent Web layout engines,
> support other such methods that are more flexible, too:
> document.evaluate(â?¦) for XPath queries, and document.querySelector(â?¦) and
> document.querySelectorAll() for CSS queries.
>
>
> Also, you are reinventing the wheel. Several common libraries provide such
> a function, by using a query engine or otherwise. So I do not foresee many
> people being interested in your function.
OK, but I don't use any for now (apart the possibility I offer to have
the photo gallery managed via jQuery + fancybox - if one absolutely
wants that nice animation effect and is fine with the 100+ Kb of overhead).
>
> That said, I do not see why you would need this algorithm that finds an
> element by name in any context in the first place because there are more
> efficient built-in ones. The â??nameâ? attribute is only allowed for the
> following element types (cf. [1] and [2]):
>
> - â??aâ? elements:
....
Many thanks, this is a very useful summary (and I will add it to my
fragments of documentation i collect here and there). Very clear. But
IIUC, I would need different functions for different elements, and maybe
feature testing for getElementsByName...
>
> - form controls:
>
> There should not be form controls in an HTML document that are not part
> of a form. Only an ancestor â??formâ? element guarantees proper validation
> in HTML 5, and that this event works without client-side scripting
> everywhere. Controls of a specific form can be referred to by name
> with document.forms[â?¦].elements["â?¦"].
As I said previously, if you have:
<html>
....
<form name... method=POST action...>
<INPUT TYPE=TEXT NAME=aName VALUE="blah">
</form>
....
</html>
and then you replace the <INPUT> element :
<script>
....
// oldEl is the element, obtained via gEBI or whatever
newEl=document.createElement("input");
newEl.name="aName";
newEl.type="file";
oldEl.parentNode.replaceChild(newEl,oldEl);
console.log(document.forms[0].aName.);
....
</script>
IE 7 (and IE 8 in compatibility mode) both show a gracious bug. At the
time I made the test I wrote nodeFind(), that does not fail with any
known [by me] browser. IIRC there were cross-browsers problems with
getElementsByTagName at the time - not sure of that, anyway.
[apologize mode ON]
the fact is, I have to deal with my incomplete knowledge of different
implementations of ECMAscript, different Levels of W3C DOM, different
behaviour of different browsers and, in general, incomplete knowledge
/per se/ :-), and the difficulty to keep up with the browser's
evolution. Consequently, I try to avoid risks of cross-browsers
incompatibility (and right now a new class of problems seems to arise
with new devices such as smartphone, tablets and God knows what else:
adaptive web design for one...). I must choose: and "the better is enemy
of the good" (old italian proverb) has been proven to be a useful rule
of thumb for me. I sometimes feel like an illiterate trying to write a
poem, but I must do my best with the scarce resources I have (and this
is true for me as for everyone else - just "scarce" has a different
meaning).
JFC, here are some issues I remember I had to face in last years, apart
the previously described one:
- getElementsByName/getElementsByTagName not implemented
- mysterios bug in Opera in printing a frame
- bug in Opera in iframes readystate
- bug in IE about the test for the existence of a method in designmode
- bug in Firefox if trying to get a specific property of a window
- try... catch not implemented
- the old problem of knowing if a page is completely loaded and rendered
....and so on, I can't remember all of them. :-)
[apologize mode OFF]
>>
>> I know of that. But it is not an exercise. The scenario here is: a user
>> can post a message in a [kinda of] message system. Messages can have
>> attachments. If the author wants to edit the message he posted, he may
>> want to change the text or the attachment. So he has a button "change
>> attachment", and the input showing the name of the actual attachment
>> becomes a <file> to select another one and upload it. :-)
>
> (â??Exerciseâ? was not to be understood verbatim.) See my correction. There
> appears to be no point to use a read-only input[type="text"] element here if
> you want to support IE/MSHTML because you need to replace the element in any
> case.
? Not sure to understand. If the user only wants to change a description
in the form (that reflects the content of a record in a database), the
<submit> sends the form with no <file> control, so the CGI server side
only updates the record. If a <file> control is present the CGI takes a
different route, uploads the file, stores the file somewhere and writes
the address to the database etc.
>>>
>>> There is no â??javascriptâ?.
>>
>> ECMA, ok, ECMA.
>
> There is no ECMA (anymore). There are Ecma International, and the
> ECMAScript Language Specification (named for historical reasons). But what
> matters more than the name is the fact that this specification has several
> *different* implementations; several of them have â??JavaScriptâ? in their
> name.
I meant "ECMA" as string substitution of "java". I sould have written:
s/Java/ECMA/
>
> I do not know xbase. ECMAScript is a language of the C family, so you need
> to return a value from a function if you want to avoid an implicit return
> value. The implicit return value is the â??undefinedâ? value in ECMAScript
> implementations.
ACK. See also my answer to Scott Sauyet
Dan
--
"Everybody should pay taxes with a smile"
I tried, but they want money.