kangax said:
Henry said:
[...]
When it was discusses it was suggested that - var global = this;
- was what people were using, and the use of alternative was
dismissed as something that nobody ever did in reality. Thus
removing the possibility did not represent any loss. The
ECMAScript committee are generally a bit short of actual browser
scripting experience.
Fair enough. I still think that as long as clients "helpfully"
provide access to certain elements (e.g. form controls or forms)
via property lookup of certain other elements (e.g. form or
document) it seems like a good idea to provide some way to
access (at least) global object.
(Until/unless there are alternative security models for scripts in
browsers) It is likely that there will always be ways of getting
references to the global object. Currently the committee are
discussing changing indirect - eval - use from potentially throwing an
exception (as in ES 3) to dong its code evaluation in the global
execution context. at which point:-
var evl = eval;
var global = evl('this');
- might, even if in a rather ugly way, provide the desired outcome.
Coupled with scope augmentation this looks quite nightmarish:
<form action="/" name="window" onclick="alert(window)"></form>
Considering that we might not be in control of name attribute
value,
Considering that is acceptable, but also remember that in the vast
majority of case/circumstances 'we' are in control of values of name
attributes. They are not things that come into existence on a random
basis, and even when machine generated they can be generated by known
and predictable rules.
what would be suggested to use in such case (besides getting
rid of whoever named a form in such way
)?
Issues with names/IDs (particularly the names of form controls) are
well known and long known. And these scope chain augmentation issues
are not that difficult to mitigate. For example, a naming convention
where names to be used in the DOM are always mixed case words with
initial capital letters would pretty much eliminate node name/object
property conflict issues (though only, when combined with a javascript
naming policy where such Identifiers would only be used for
constructor functions).
The places where the problem can be expected to be encountered are
where the deliberately technically ignorant/incompetent are employed
(that is, people who cannot or will not listen/learn) to write mark-up
(or mark-up generating server code), in which case the solution is get
a job somewhere else (as staying will become a nightmare very
quickly), or with legacy code that either nobody remaining understands
well enough to fix or that is third party and pre-complied.
In the case of the legacy code the problem is fixed (no new
problematic IDs or NAMEs will be introduced) and can be worked around
on a specific basis. (Unlike the case with the deliberately
incompetent developers, who may introduce new problems at any moment).
Granted, it's probably a problem for W3C to solve.
I don't see how they could. It has been the style of standardisation
(DOM and ECMAScript) to define a set of requirements to be met, but
most of the issues are consequences of what happens beyond/outside of
their specifications. It would be an unreasonable barrier to progress
to suggest that a UA should be 'this precise thing' and no more. Would
we have, for example, AJAX if UAs had been forbidden from ever
introducing XML HTTP request objects, but instead waiting until some
standards body decided such a thing would be a good idea? Look at
standards driven XHTML and the mess that has come out of that, where
many people think they are working with XHTML when they are really
just writing formally malformed HTML (a new flavour of tag soup) and
producing scripted documents that will just fall over in the event
that a browser ever attempt to interpret them as XHTML.
Even if ECMAScript was to provide a globally available `getGlobal`
function, nothing would stop current DOM implementations from
"shadowing" that identifier as well.
(Short of making it a property of the (soon to be ES 3.1 re-named)
Variable object)
I'm working on a simple html scanner to "catch" such occurrences
(as it could come in useful when working with legacy documents,
for example)
It could have precisely such a use, though in principle understanding
of the issues might make legacy documents that have such issues a
thing of the past. ;-)
Thanks. I wasn't aware of this.
Given some of the entries I have seen in books on the subject it
appears that you were a long way from being alone in that. But at
least you were open to finding out.
