----- Original Message -----
From: "Matthew Raymond" <[EMAIL PROTECTED]>
To: "Andrew Fedoniouk" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Sunday, June 25, 2006 8:39 PM
Subject: Re: [whatwg] Spellchecking proposal #2
Andrew Fedoniouk wrote:
Spellchecker looks like pure behavioral entity.
Behavior is generally handled exclusively by Javascript, but some
people have expressed that having to use script to enable spell checking
is highly undesirable.
Out of scope little bit:
There is at least one html/css engine where behavior as an entity has
nothing common with scripting.
I am speaking here about my http://www.terrainformatica.com/htmlayout/
It is strictly embeddable html/css engine (not a UA in common sense).
Hosting application provides set of "behaviors". Each behavior is
a set of event handlers wrapped as C++ class (or any other programming
language) . Such behaviors are part of application.
Behavior can be applied to any DOM element using
the 'behavior' CSS attribute. This schema has nothing common with
IE's behaviors, htc, COM, ActiveX, XPCOM, etc.
Moreover, all input elements in HTMLayout are just behaviors -
there are no such things as <input type=text> internally.
Default Master Style Sheet simply has following declaration:
input[type="text"] { behavior:edit; }
input is an ordinary DOM element as p, div, img, etc.
Behavior is what makes difference.
Here is Master Style Sheet I am using:
http://www.terrainformatica.com/htmlayout/master_ss.css.txt
This way application may declare that let's say <td> elements
in some table will behave as text edit input elements by simply
declaring #mytable td { behavior:edit; }
Main purpose of behaviors is to change state of the DOM elements
- their state flags (a.k.a pseudo classes in CSS) and attributes.
Builtin CSS engine does the rest.
Having all input elements defined as such behaviors plus
ability to combine them by CSS allows to build pretty
complex input elements by their composition.
For example behavior:select supports as standard <select>
functionality with fully styleable <option>s as also
hierarchical Tree View.
See: http://www.terrainformatica.com/htmlayout/images/selects2.jpg
Examples of other input elements are here:
http://www.terrainformatica.com/htmlayout/screenshots.whtm
SDK/include/behaviors also contains source code of
other useful behaviors.
So I would define this as:
<style>
#myeditor
{
white-space:pre; overflow: auto; ...
behavior: textarea spellchecker; /* textarea editor and
spellchecker
*/
}
</style>
In htmlayout engine each DOM element can have
multiple behaviors assigned, so following:
<textarea id="myeditor">...</textarea>
will behave as a text area editor with spellchecker using
style declaration above.
(in fact behavior:textarea and/or spechecker can be assigned to
any DOM element with display-role: block, (not only textarea)
but this is another story)
This looks a lot like an HTML Control (HTC), but it's incorrect if it
is. Remember that binding mechanisms like HTC and XBL are for binding
HTML/CSS/Javascript to elements, so any solution provided by those
mechanisms would have to have support in one of those languages.
As I mentioned before it is not HTC and has nothing common with
JavaScript.
In my interpretation behaviors are just named event handlers.
Speaking about let's say HTML/CSS v.5...
I am pretty sure that such behaviors can be formalized in some
specification and used in HTML and CSS in UAs of common use.
For example behavior:radio can be used for implementation
of tabs - tabular panels without introduction of new entities.
I mean that basic set of atomic behaviors
can cover (by their combination and reuse) almost all typical
cases implemented now only by scripts.
I am not sure did I manage to explain this idea clear enough?
Let me know if...
However, I suspect this is supposed to be a means of using canned
styles built into the browser. While this may be useful is some cases,
there is a danger that this could lead to people trying to reimplement
(X)HTML using CSS/XBL.
I am moving in quite opposite direction. I am pretty sure that
pure HTML and CSS already have potential powerful enough.
I know applications having quite sophisticated htmlayout based UI
built purely in declarative form using solely HTML, CSS, behaviors
and their composition.
Andrew Fedoniouk.
http://terrainformatica.com
