Aesthetically scripting.

Say you have some html document that has some elements with assigned IDs. I would like to find better notation for functions – event handlers in TIScript.

For example we have following html fragment:

<button id="foo">Click me!</button>

and we know that such button can generate onClick event (whatever it means).

There are multiple possible ways of how to do this in JavaScript. First of all standard way (that uses function $() – get element by selector)

  $("#foo").onClick = function() { ... }

This means: assign anonymous function (handler) to onClick property (event name) so system will call back that function when event will happen.

Internet Explorer (JScript) allows to do the same definition as:

  function foo::onClick() { ... }
  // or probably this way:
  function foo.onClick() { ... }
  // and in VBScipt
  sub foo_onClick() ... end sub

This is possible in IE because all elements that have IDs are seen as variables of global name space. That approach has some limitations: IDs in HTML can contain characters that are not valid in variable names, e.g. ‘-‘ in #foo-bar.

Sciter/TIScript has symbols that allowed to use ‘-‘ and all other characters allowed in IDs (html/xml):

  // for element with id="foo"
  function self#foo.onClick() { ... }
  // for element with id="foo-bar"
  function self#foo-bar.onClick() { ... }

self#foo-bar is a syntax sugar – equivalent of self["#foo-bar"]
Syntax is a bit “noisy” but works. Other variants that I’ve considered:

  function onClick of self#foo (...) { ... }

  when onClick on self#foo-bar  (...) { ... }

and other variations. I don’t really know what is better… Any ideas?

behavior:htmlarea (WYSIWYG editor) in h-smile core.

My initial idea was to implement behavior:htmlarea (WYSIWYG editor) as editing behavior that manipulates elements in existing DOM tree. This approach is not working for many reasons.

Main reason is following:

In presence of CSS the same rendering result (pixels in the view) can be achieved in many ways – by using various CSS attributes. (Think about spacing between paragraphs – they can be done as margins or as paddings or as trivial <br>s.)

WYSIWYG editing behavior is aimed to solve task that is somehow opposite to rendering : to change DOM structure by using current view (what user sees).

So current CSS and DOM that are good for rendering prevent good WYSIWYG implementation. I have never seen any editor based on contenteditable=”true” in browsers that I can consider as a good WYSIWYG editor. It is just impossible because of such same-DOM/multiple-ways-of-rendering-by-CSS.

Perfect WYSIWYG assumes that you can change DOM structure by using solely toolbar and keyboard – without any knowledge about underlying CSS. But current state of CSS makes perfect WYSIWYG almost impossible. Some CSS attributes and abstractions are extremely hard to present to non-css-educated user.

Solution that I am working on now:

behavior:htmlarea will be based on my blocknote editing engine.
Blocknote editing engine is using so called “flat DOM” – linear sequence of paragraphs and tables. I am just adding there limited support for CSS so htmlarea will use separate CSS file for content representation:

<htmlarea content-markup=html|wiki content-style="editing.css" />

That editing.css is a linear set of style rules that use simple tags and class selectors:

  strong { font-weight: bold; }
  strong.very { font-weight: bold; color:red; }

No other type of selectors will be allowed. Reason is simple: “predictable WYSIWYG”.
Think about following selector:

  div.some > p { margin-top:40px; } 

and user editing text with it. ENTER will cause the paragraph to be split into two:


That will create margin-top:40px; spacing between them. ENTER in other paragraphs (not in div.some) will create produce different spacing. There is no way for the user to explain why here it is 40px and there it is 10px or so.

That is why HTML WYSIWYG content editing widget, I think, shall use not-exactly-html DOM and CSS.