[whatwg] Spellchecking proposal #2

[Andrew Fedoniouk]

----- Original Message ----- 
From: "Matthew Raymond" <mattraymond at earthlink.net>
To: "Andrew Fedoniouk" <news at terrainformatica.com>
Cc: <whatwg at whatwg.org>
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