[whatwg] A few hints on html5 - part 1

[Calogero Alex Baldacchino]

Let me suggest a few hints on html5 specs, maybe some hints will be 
minor or less important, maybe some others might be useful for a 
somewhat next version of these specifications. Let me also apologize if 
the following points have been yet discussed and I'm missing such 
discussions, or if I've misunderstood any part of the specs. -- this was 
a longer message, but the list bot refused it, thus I'm splitting it 
into a few messages (and thus the subject, part 1 etc.)

First, maybe the less relevant: in the "Script execution contexts" 
section a request is made for some couple of terms other than 
"with/without script". OK, let me suggest "scriptable/unscriptable" or 
"reachable/unreachable by script", for instance. Just a simple hint, no 
more.

The former suggests me a possible (partial) solution for the events 
section question about events handling for non active or "browsing 
context-less" documents: being script execution not allowed in such 
situations, we could state that any event exclusively thought for script 
interaction should never fire, unless any valid motivation arises to let 
the event fire and be dispatched to the corresponding handler(s), and in 
such a case the whole mechanism of deciding whether script execution 
must be allowed or not should be revisited. Otherwise, if any "script 
related" resources are thought to be kept "alive" in a somewhat "frozen" 
state (in example, in a previously active document, a connection buffer 
with last received, not yet elaborated content, the connection itself to 
be re-established, or its status), then any related event could fire and 
be frozen in a "pending" state, or just be "frozen" or "pending", 
meaning in a "before firing state", ready to fire (and be dispatched) as 
soon as the document enters a scriptable state (i.e. becomes active or 
gains a browser context).

Furthermore, the "event loop" and "task queue" definitions suggests me 
that a somewhat user agent could implement a sort of "all-in-one" 
mechanism to handle together (maybe for an improved interaction?) both 
implementation-related and script-related events, i.e. queueing together 
both types of event (or the related tasks), with a somewhat precedence 
rule between them, or even, in some cases, the very same event/task to 
be first handled by the underlying implementation, then passed 
(wrapped?) to the script specific mechanism (for instance, when a 
document, or an object inside a document, is fully loaded, a native 
"load" event is generated to increment/complete the document rendering 
and then it is wrapped and sent to any script related handler). In such 
a case, the specification could establish, for clearness sake, that only 
implementation related events must fire, if meaningful for the 
implementation in a "non-scriptable context" (an inactive or 
context-less document), while any script related event (even the same 
wrapped event, after the underlying elaboration) must either be 
discarded (it does not fire) or be frozen (if applicable) for a further 
possible resuming. Might such a clarification be helpful for such an 
(unrealistic? strange? possible?) implementation, in order to avoid or 
reduce confusion or possible side effects?

Anyway, such considerations might perhaps either be left to the user 
agent implementation, or be deferred to a next version of html5 specs...

For the "How do we allow non-JS event handlers?" concern, let me 
distinguish two different cases:

1) an event handler content attribute is set in the markup:
Let's assert it must conform to the ECMAScript FunctionBody production 
rules by default, unless another language is stated elsewhere as the 
default scripting language for the whole document or for a particular 
element.

As for the whole document, a meta tag could be used, such as '<meta 
http-equiv = "Content-Script-Type" content = 
"a_valid_scripting_mime_type" />' or the alike. If the declared 
mime-type is not supported, it could be defaulted to the ECMAScript one.

For the element by itself, an attribute could be added both to the 
markup and the DOM, either to describe a script language valid for all 
the script content attributes (i.e. 
'defaultscript="appropriate_mime-type"'), or to define a list of valid 
mime-types (i.e. 'acceptedscripts="first_mimetype;second_mimetype"'). In 
the latter case, for each parsed script content attribute, the first 
declared mime-type should constrain the production rules, or be skipped 
if not supported, using the next mime-type upon failure or after 
skipping an unsupported one; if all sequentially applied production 
rules fail, let a SYNTAX_ERR arise (or any other appropriate 
error/exception); if no mime type is supported, the default script 
language rules are applied (if not listed, that is, yet tried in the 
previous step), and if even this fails, let an appropriate 
error/exception (maybe the SYNTAX_ERR itself) arise. For the sake of a 
graceful degradation, the script content attribute whose production has 
failed could be set to the empty string, and any further elaboration 
continue normally, after the error had been notified to the user, if the 
case.

2) an event handler attribute and/or an event handler content attribute 
is set by a script routine:
Obviously, we are talking about a supported scripting language other 
than ECMAScript. If the attribute has not been set previously, the new 
code should be treated as a routine of the same language as the executed 
routine. It the attribute has been yet set by a script routine of the 
same language as the actual script, the operation should be allowed if 
the actual routine is allowed to modify the attribute (i.e. the same 
origin restriction is fulfilled), otherwise, if the "same language rule" 
is not matched or the modification is not allowed, an exception should 
arise.

On getting, a similar behaviour should be implemented: if getting is not 
allowed (i.e. the same origin restriction is violated) or the scripts' 
languages does not match, the operation is aborted, either with an 
exception (i.e. a security exception for the same origin violation) or 
returning null for the handler attribute and the empty string for the 
handler content attribute (maybe more suitable for a language mismatch, 
since a certain script interpreter/jit should be thought about as unable 
to understand other languages, at least at the moment - see below).

The "same language rule" on setting should be preferred to a more 
generic (and perhaps easier) "overwrite and remember what's the actual 
language" (that is, what interpreter must be called), because other 
script of the same origin and language could generate events and/or rely 
on the handler execution, or the execution of a subroutine of the 
handler accessible from the handler itself, so discarding and replacing 
the handler could interfere with such scripts in an unrecoverable manner.

A "cross-language event handler setting" should be allowed through out 
the addEventListener() and addEventListenerNS() methods, as far as each 
supported script language exposes a binding with the EventListener and 
the Event interfaces (and derived interfaces), or at least the handler 
is a routine which may be referenced and executed with an associated 
reference to an Event object understandable by the language; if the 
language presents a syntactical construct with the same semantic of the 
ECMAScript "this", and/or uses a semantics close together with the 
ECMAScript "scope chain", the same rules for the "this" and "scope 
chain" must apply, otherwise the EventTarget object and the Window 
object must be provided as visible in the scope of the event handler 
routine. Of course, such conditions are necessary in any case (not just 
for the addEventListener() and addEventListenerNS() methods), since are 
the minimal constraints needed to conform the idl and the visibility 
rules, and thus enabling event handling through a script language other 
than ECMAScript.

EventListeners of different languages could be taken apart in different 
lists, or listed together and marked in some way to be distinguished in 
respect to the proper language; in the latter case, the language 
identification of the listener should be left, at least in this version 
of the specifications, to the u.a. implementation, while in the former 
any mechanism could be implemented to treat the separated lists as a 
unique one (i.e. by remembering the insertion order to call the 
listeners the same way as they were added in the same list). In this 
context "cross-language event handler setting" should mean that the 
script "a" of the language "A" can register a listener routine of the 
same language "A" for an event on an EventTarget having at least another 
listener previously set by a script "b" of the language "B" for the same 
event, or a handler set as a handler content attribute, not that the 
script "a" can register a listener of the language "B". In other words, 
the "same language rule" on setting might be relaxed as far as the first 
registered handler (in particular, the handler attribute or the handler 
content attribute being set) is not discarded. Any handler set as a 
handler (content) attribute for an event of type "E" must be the first 
of the listeners list for the type "E".

Similarly to the setting of an event handler (content) attribute, the 
"same language rule" should apply also to the discarding of a previously 
registered handler through out the removeEventListener() and 
removeEventListenerNS() methods. Furthermore, if an attribute is defined 
to specify one or more allowed language(s) for an element's handler 
(content) attribute(s), setting such an attribute, when allowed, should 
set/modify the language attribute too (i.e. by adding a semicolon and 
the mime-type to the list, if not yet present). The same rule should 
apply to the event handler DOM attributes.

A future version of the specifications could investigate the opportunity 
and modalities to allow a full cross language scripting interaction, 
i.e. constraining any script interpreter/jit implementation to support 
mechanisms such as COM/CORBA or the alike, as far as the same origin 
restriction is fulfilled. In such a context, a script "a" of language 
"A" could be able to set/add an event handler of a different language 
"B", but a mechanism should be provided to let the EventTarget know what 
is the language of any registered listener. Such a mechanism can be 
either implementation specific, or explicated in the idl interfaces 
(i.e. adding an argument to the registration methods, or deriving the 
EventListener interface to add a property identifying the language). 
Anyway, the same language rule should apply on removing/replacing a 
listener. This rule by itself does not restrict the cross-language 
interaction, since a script "a" of language "A" having registered 
originally an event handler "EH" might expose a routine to unregister 
the previous handler and replace it with a valid alternative, and a 
script "b" of language "B" might be aware of such routine and use it to 
perform the listener replacing/removing - what matters is the call to 
the language "A" routine, which in turn calls the remove methods or sets 
an event handler (content) attribute, fulfilling the same language rule. 
What if the new, replacing listener is not of the original language? 
This could be possible as well: the replacing routine, after matching 
the same language and same origin rules, might be able to bypass the 
language constraint and set the proper handler in the desired language; 
however, such a bypass modality should be exposed in some way by the 
specifications.

Furthermore, either the actual or a future version of the specs could 
define a mechanism to constrain a group of handlers and/or a group of 
scripts of different languages as alternative, with a preference order, 
in the case one or more languages are not supported, i.e. by defining an 
EventListenerGroup interface to list a number of alternative listeners, 
associated with a language identification and a preference order, and/or 
by providing a ScriptGroup element, both in DOM and in markup, and 
adding a preference order attribute to the Script element. Such an 
attribute should just be ignored outside a script group, and, if unset 
for one or more element, should be defaulted to the lowest declared 
value or a default value identical for all the scripts in the script 
group, if none has a value set, so that all the alternative scripts with 
the same preference order value are selected on a "first fit" basis.

About the concern on a custom "click" dispatched at an element with 
default actions: what does "custom" stand for? If you mean a generic 
event generated by the script calling the createEvent() method, I think 
that the default actions should be triggered as if (i.e.) they were 
listeners registered at the end (or the beginning) of the listeners 
list, so that the preventDefault() method may be called by any 
registered listener to prevent default actions (the 
stopImmediatePropagation() method shouldn't block default actions): the 
script code generated the event, so the script code decides the sort of 
such event, the same way as any other "regular" (or expected) event: 
since there is no way to distinguish, at a script handler level, between 
a "regular" and a "generated" event, why should they be considered as 
different things in respect to any default action? If the programmer 
doesn't wish to prevent any default action for a certain event type, why 
should the implementation bypass such behaviour? In other words, the 
implementation should always treat any default action the same way for 
any event, despite of the event "origin", unless the specifications will 
provide a way to both distinguish the event "origin" without any 
workaround in the script (being the event handler just an asynchronous 
callback function possibly agnostic of whatever else is happening in the 
rest of the script execution) and to force the default actions to 
trigger (i.e. adding a forceDefault() method in the Event interface).

If the "custom click" is, instead, an event of type "click" (or whatever 
else type, enlarging the argumentation) created by calling createEvent() 
and passing the argument "CustomEvent", we could expect no default 
action is defined, unless the specs will define events in whatever 
namespace other than that for html, in which case the same behaviour 
should be matched, but relatively to any default action provided for the 
associated namespace; anyway, the event could be initialized with a 
detail attribute taking trace of its "origin", so that any handler could 
decide how to operate, but, since there is no way to force a default 
action, implementation should always avoid preventing default actions 
for script generated events. If the event is not associated to a 
namespace, and its type name clashes with a type name defined in the 
html namespace, the custom event initialization should resolve in an 
error condition.

Anyway, I understand that a special care could be needed if any default 
action is preceding a certain event in its "natural" generation, or if 
the event itself is "naturally" preceded and/or followed by other events 
which in turn has their own default actions. However, I don't expect 
this to be a great trouble: for instance, the specifications could 
establish it's up to the implementation to choose whether to generate 
the whole events sequence, with the associated default actions, or to 
abort, at any phase, the event propagation. The former choice could be 
suitable, i.e., for device generated-emulating "custom" events, and 
generally whenever the whole sequence and related actions might easily 
be rebuild from the "custom" event type and attributes: for each event 
and each element implicated in the three event flow phases, the 
dispatchEvent() implementation could be aware (either directly or 
through a callback) of the event default actions and of the expected 
preceding and following events, and could easily emulate a "natural" 
event flow (let's think about a custom click on a check-box). Otherwise, 
if the events sequence and flow rebuild were non-trivial and/or could 
lead to unpredictable/inconsistent behaviours, the event dispatch 
routine should abort and the event be discarded: this could be the case, 
for instance, of a "custom" mutation event referring to nodes which 
haven't been modified, or the case of a remote event from a source not 
handled by the RemotEventTarget (i.e. not added through the 
addEventSource() method, or yet removed), or a MessageEvent referring to 
ports which are not entangled (and cannot be entangled for any reason).

I'd also spend a few words about a custom context menu: a script could 
generate a somewhat container (i.e. a div) with several elements 
associated to some click handlers, and also exploit such handlers for 
"background" computation (that is, the handlers are also called, in some 
way, when the context menu is not shown). In such a scenario, three 
cases should be considered: if the menu, when not shown, is not a node 
of the active document, any click event should not be dispatched, 
according to the rule preventing events to fire in such situations, so 
the script should invoke directly the handler as needed; if the menu is 
part of the active document but is not shown, or its owner document is 
not fully active, any event and related default action strictly relying 
on the element visibility (i.e. an icon roll-over) should not fire, 
while preserving the custom event dispatch (that is, when trying to 
rebuild the whole events sequence expected if the click event were a 
"regular" event, any event and default actions strictly related to the 
visibility of an element should be ignored); if the custom event is a 
right click which would cause, if "regular", the context menu to show up 
on a visible and scriptable element, the menu must show up (that is, any 
event preceding and causing an element to show up, if not directly 
invoked, or directly invoked on an element whose parent or "related" 
node is not visible, should never trigger). Of course, this should apply 
to any sort of "menu" and in general to any document sub-tree whose 
visibility is determined by a script (I don't mean the UA implementation 
must take into account who sets an element visibility and how, but just 
what the actual "state" is).

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:
 CheBanca! La prima banca che ti dà gli interessi in anticipo.
* Fino al 4,70% sul Conto Deposito, zero spese e interessi subito. Aprilo!
 Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=7919&d=16-12