Miscellaneous
The Window interface open method accepts a "features" argument for
historical (and backward compatibility) reasons, which, as stated, has
no actual effect. I was considering the opportunity, instead, of
maintaining the old functionality as an alternative and redundant
implementation of the "make application state". That could work this
way: any browser feature set disabled in the features string is disabled
and not shown in the newly opened window, BUT, a somewhat element,
clearly being part of the browser application, is provided to let the
user enable any hidden feature (either altogether, or one by one), so to
reset the "normal" application condition; when a browser interface
component is hidden, any related key binding is "freed" from usual
capture, and redirected to the window active document, so that a "full
standalone" behaviour is transparently shown to the user (the "reset
element" should never be disabled), while when that component is
re-enabled its normal behaviour is re-established; if the application is
going full-screen the user is clearly advised about this and allowed to
block the operation (in the case the operation is allowed, the "reset
element" should become floating and maybe half-transparent -- I was
thinking on a possible, future 2D or even 3D web based game...).
-----
Current draft provides a few overloaded methods (like postMessage()
variants) differing for the number, type and order of their attributes.
A first concern could arise on the choice to overload functions in IDL
interfaces, since any of the possible supported/supportable script
language could not provide such a feature, making implementation more
difficult; however, this could be a minor concern, both since a script
with C-like syntax (as most are) usually let functions be overloaded,
one way or another, and because a different kind of language, not
providing such, could overcome the problem by defining methods with
slightly different names and binding them to the appropriate interface
(but this would lead maybe to a longer learning period and to possible,
successive even greater difficulties whether such names would clash with
future standard names). Maybe the parameters order and number could be
another concern, since a script language could (like JavaScript does)
allow functions overloading by varying the number of passed arguments,
without caring about arguments types, and leaving to the inner code any
checking and choice of what to do (that's closer to a C++ function
declaration with default arguments, than to a "full" overload); this is
not a real problem, but perhaps a little improvement in current specs
might result from changing the arguments order so that the arguments
list of an overloaded method's two variant, when compared, is equal for
the first 'x' arguments, where 'x' is the length of the shortest list,
since this could reduce the translation work the script engine must do
before calling the underlying implementation (i.e., it could be a
slightly easier casting of the arguments to their correspondent native
types, without any previous checking for the right type, before calling
the interface native implementation - the point is: a check is likely to
be done by the casting routine(s), so couldn't it be avoid before
casting?). Furthermore, any language missing the overload semantics
could expose just one method with the whole list of possible arguments,
corresponding to the idl declared method with the longer list, and I
think that defining idl methods with some care for arguments order would
be a neater choice.
-----
Current browsers provides facilities to parse xml code (either the
DOMParser object or a DOM Load and Save Parser). All fail with html "tag
soup", so if for any reason a somewhat string of html code must be
parsed to manipulate its DOM representation before taking any action, a
workaround must be found (i.e. calling
document.implementation.createHTMLDocument() and somehow inserting the
string into such fake document, then getting the DOM structure - this
could be quite unreliable too, as a parsing alternative, if any script
code in that string were executed). Since one of the goal of html 5
specifications is the definition of a standard parser, with a standard
parse error management, maybe the opportunity of exposing an
html-specific parser (skipping script execution) through the DOM might
be considered.
-----
Current draft states a script element set through the innerHTML property
is not executed at all, while it is when added by calling
document.write() (what about insertAdjacentHTML()?). However, I think
that allowing script execution in the former case would made of the
innerHTML property a truly live one, with some possible benefit: i.e. it
could be a way to insert new script elements into the document head
section from outside the head element (i.e. from an event listener on an
eventsource, to dynamically change a web application behaviour by
appending new markup to the head.innerHTML string). Of course this could
be problematic whether the newly inserted markup contained the same
script causing the innerHTML content to change (resulting in an endless
recursion); anyway that could be yet done by first checking for a
correspondence of the actually parsed markup into the newly set (perhaps
excluding the lastly executed script - and any following elements - for
double checking), so that the insertion would be similar to a
"beforeend" or "afterbegin" insertion through insertAdjacentHTML().
-----
The HTMLDocument interface presents several variants for the open
method, with very different "meaning" and purpose. Sincerely, I don't
think it's a very nice idea to expose functions with the very same name
but performing so much different operations on the same interface. I'd
consider as a better choice to divide and distribute them between the
HTMLDocument and the Window interfaces, removing any window related
open() method from the former, so to make immediately clear what contest
each method works on. If those methods were thought about as need for
backward compatibility purpose, maybe they cold be moved to a third
interface (called, i.e., HTMLBwdCompliantDocument), as well as any other
property thought for backward/cross-browsing compliance and/or being
deprecated, stating any object implementing the former interface must
also implement the latter. Maybe the same could be done with other
interfaces, to maintain a full compatibility with HTML 2 DOM (perhaps in
this case the "secondary" interface implementation could be not
mandatory). Such process could be suitable to deprecate any
method/attribute/interface before conclusively obsoleting it, in future
specifications.
-----
Let me come back to the non-JS scripts question. Let's assume that a
script engine exists for a somewhat script language "SL", is compatible
with the browser plug-in architecture and supports a technology such as
liveconnect to gain access to any DOM interface and give back
informations about the actual script context. Such engine could be
embedded into the document as an object descendant of the head element,
and a proper meta tag could bind the "SL" mime-type to that object: this
would be specially suitable for event handler content attributes, while
a script element could hold a proper set of attributes to recall a
specific engine (i.e. some attributes corresponding to a classid, a
codebase and a bypass mode, the latter specifying whether the plugged-in
script engine must be preferred to a native one, or not). Some special
restriction could be applied to such a script engine, such as running
separate processes for any independent script context, asking the user
for permission when a plug-in is required for scripting, requiring the
engine neither attempts to directly access the network (this would be
exclusive duty of the networking task source), nor to gain access to any
other running process or system library but what allowed for
communicating with the user agent or for proper execution, and
establishing a testing and certification mechanism (eventually optional)
to verify the fulfilment of such requirements (this might work very fine
if a standard plug-in architecture were defined and universally
adopted). So doing we'd have defined a pluggable script engine
architecture, which could be the base for a future cross language script
interaction architecture (providing the script contexts isolation is not
violated), or a part of a future, more complex and complete, COM/CORBA
(or the alike) based architecture.
-----
It's been reported that people are asking for non string messaging, but
a few constraints should be considered. First, no access is granted to
the network physical layer, so the API should take it as a black box and
make the most conservative choices, in order to keep communications as
reliable as possible: this leads to a need for a string serialization of
structured data, which could be done either at the DOM level or by the
networking task source. Furthermore, the message might be handled by a
piece of code written in a language other than the one generating it, so
a DOM level data serialization might be a good solution for both a
client-server and a cross-document messaging (thus the actual string
"nature" of a message content could be preserved), and consequently a
whole object serialization should be avoided for anything but DOM
elements, unless it is thought HTML 5 DOM must define a complete set of
interfaces for data structures which are neither document, nor browsing
strictly related (I don't feel to agree with such an idea, because that
could mean to put hands over a range of things which are in the scope of
a script language grammar and semantics, more than in the scope of a
DOM). This means, i.e., programmer should not assume an ECMAScript Array
object would carry on its prototype full range of properties and methods
(this should not happen at all, according to me).
However, I think a compromise can be found. Since most programmers, as
well as a part of current specifications (at least for event handling),
are somehow focused on ECMAScript capabilities, I'd consider a
JSON-style serialization, since that easily evaluates into an ECMAScript
object literal, holding properties labelled either by names or even
digits, and accessible as they were array items, so it could "emulate"
the basic structure of about any kind of data. For instance, a number
could be carried on as a field in its base-10 string representations,
while digit-labelled fields could represent an array, and any field with
a non-digit-only label could represent a value/name pair (accessible as
an associative array item - that is, something like 'array["label"]').
As far as every field contains a string (i.e. quoted data) or another
object literal (avoiding any function and variable reference, even
direct references to DOM elements), a somewhat "porting" to other
languages should be quite possible, since most should provide at least
the basic array semantic and a somewhat associative structure should be
realizable, while script languages usually provides the semantics of
runtime inferred types (other languages, with strong, compile-time
typization, like Java, should be capable to allow the creation of
maps/hashtables holding labelled items of any actual type through a
class hierarchy, or just taking everything as a string).
To avail of such a serialization, as a compromise for non-string
messaging through a string interface, HTML 5 should provide some
facilities, defining the serialization rules along with a few methods to
serialize/de-serialize and an interface capable to handle the
de-serialized object (to be binded to an array-like or
object-literal-like object in ECMAScript -- any method required by the
interface should be not enumerable), with no particular constraint for
the type of field values (or at least allowing strings), and a pair of
methods to get each item by name and by index, the latter perhaps only
working with digit-labelled items (to replicate the object literal and
array behaviour in ECMAScript), and describing the opportunity to access
any item as an array element, according to the language semantics and
syntax, in order to gain the largest possible behavioural uniformity
(another method, such as a "nextItem" could be considered to allow a
"label-agnostic" exploration in the manner of the ECMAScript "for in"
statement).
A special care would be needed for binary data. From an agnostic point
of view upon the network layer, a conservative approach would lead to a
base64 encoding, demanding to the networking task source the choice of a
different encoding if base64 weren't appropriate for a particular
communication protocol and network layout (thus, performing either a
transcoding or a "wrapping" - that is, re-encoding the base64 encoded
content so that it'll be decoded into base64 again). Once encoded in
base64, the binary data would be ready for insertion in a JSON-like
string as the content of a "binary-data" (or the alike labelled) field.
The implementation of the base64 decode algorithm should ensure the
original content is preserved without alterations (i.e., if the decoded
buffer were a string instead of a raw collection of bytes, a proper
charset should be used, to avoid any clash with charset reserved
bytes/byte-groups). Once a cross-language infrastructure were defined, a
different (and perhaps better) serialization could be defined, such to
grant the exchange of code along with data, thus enabling code migration
in a somewhat distributed computing or even agent-based environment.
OK, the lynching may start...
Regards, Alex
--
Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP
autenticato? GRATIS solo con Email.it http://www.email.it/f
Sponsor:
Tomb Raider anniversary. Gioca con Lara Croft sul tuo cellulare!
Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8273&d=16-12
