[whatwg] A few hints on html5 - part 4

[Calogero Alex Baldacchino]

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