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
