ScIDE is a compact and handy source code editor with syntax highlighting (colorizing).

ScIDE is a system of HTML, CSS and scripting files that are running inside the Sciter. So ScIDE is so-called .scapp - Sciter application.

You can run ScIDE:

1. inside Sciter.exe player (part of main SDK distribution) or
2. as a separate application ScIDE.exe that is available as a separate install-by-unzip ScIDE distribution.
   ScIDE.exe is a simple bootstrap exe of Embeddable Sciter - sciter-x.dll. Its sources are in the SDK.
3. sciter-x.dll can be embedded in other applications so ScIDE or its parts may appear in other applications too.

ScIDE uses Scintilla editing engine wrapped as so called native behavior module. Sources of the behavior + slightly modified version of Scintilla are here.

ScIDE is lightweight and very fast despite of the fact that it uses scripting. Script is used as a glue sticking UI components together.

So far ScIDE knows about html, php, asp, css, js, tis, h/hpp and c/cpp files. These colorizing schemas are defined in /scapps/sciter.ide/scintilla/schemas/*.tis files and can be extended by script.

Visual style of the whole application is totally CSS driven so can be customized in different ways.

Lets say we have following markup:

<ul>
   <li>First</li>
   <li>Second (with <a href=#>hyperlink</a>)</li>
   <li>Third</li>
   <li>Fourth (with <a href=#>hyperlink</a> too)</li>
</ul>

and the styling task: all <li> that have <a> elements inside have yellow background.

If we would have hypothetic selector :with-child(selector) then we could write this as:

li:with-child(a:link) { background:yellow; }

Problem with this selector lies in its complexity - to compute such selectors you need to scan whole subtree of the element (<li> here). That is a task of complexity O(n). n here is a number of children of the element. Potentially it could be the whole DOM ( html:with-child(a:link) ).

And again that O(n) is not that bad if it happens only once but for the case:

html:with-child(a:hover) p { ... }

all <p> elements of the document should get new styles each time when some <a> in document will get :hover state. And that is really bad. Standard methods of optimizing such cases (e.g. caching) may not be acceptable as they may require significant amount of RAM and/or again CPU resources.

… back to the original task of styling "<li> that have <a> elements inside". It is still possible to solve it while keeping resource consumption at the same level.

Imagine that we would have some magic engine that will assign, say, attribute has-a-inside to such <li> elements. Then our task of styling <li>s will turn into simple rule that is known to be effective:

li[has-a-inside] { background:yellow; }

In real world scenarios people these days use JavaScript for that. Requires some programming but works reasonably well.

But our desire to do this solely by CSS as JS is not always available. Here is the method of how to accomplish this by CSSS! (so called active CSS) introduced in recent versions of h-smile core (htmlayout and the Sciter).

In CSSS! we need to create one helper rule that will create attribute has-a-inside for each <li> with <a> inside:

li
{
  assigned!: self.has-a-inside = self.$1( a[href] )? "true" # null;
}

This rule simply means:

When element li will get this style declaration first time (so when assigned!) this statement do:

1. assign "true" to the attribute has-a-inside if that li element (self) has at least one element inside matching the selector a[href].
2. or assign null to that attribute - so to remove it form the element.

The only rule left is the one that I’ve already mentioned:

li[has-a-inside]
{
  background:yellow;
}

Thus after loading such document all <li>s with hyperlinks will have yellow background. Done.

Of course it is not so abstractedly perfect if to compare with with-child(a[href]). E.g. our solution will not reflect dynamic DOM updates but that was the problem we were trying to solve anyway.

Nevertheless it will allow to solve the task in most of practical cases and will at least not make selectors matching implementation worse than it is now.

CSS (Cascading style sheets) has pretty extensive set of so called selectors. Example:

ul[type="1"] > li
{
  list-style-type: decimal;
}

Selector here means following: each li element that is immediate child of ul that has attribute type with the value "1" has that style.

Selectors and assosiated styles constitute static system of styles. And so they obey following rule (the law of CSS selectors):

At any given moment of time all elements in the DOM that satisfy set of selectors have correspondent styles applied.

Such static nature of CSS selectors establish some obvious (and not so) limitations on what could be done with selectors and what types of selectors CSS can support. For example:

• Selectors cannot use information defined by styles. Imagine hypothetical selector and style:

  div:visible { visibility:hidden; }
  

  Such pseudo-class always fails and so breaks the rule defined above. It is simply no such moment of time when the rule above is valid.

• Selectors can use only those features/characteristics of the DOM that can be evaluated at constant (or near) time. Otherwise observer will be able to catch moment of time when the rule will not be true.
• Consequence of this: selectors that require scan of number of elements of the DOM unknown upfront ( have complexity O(n) in other words ) are "persons non grata" in CSS.

There is nothing wrong in principle with O(n) complexity. At the end resolution of all styles of the DOM that has n number of elements is O(n). The problem arises when you use selectors that each has O(n) complexity. Total complexity in this case will be O(n*n) and that is the cause of troubles.  In case of frequent dynamic updates each such update may require re-computation of all styles of all elements so web page may easily become non-responsive - CPU will be busy resolving styles without doing any good to the user.

Imagine that we have selector like:

ul:not-exist(a:hover) {color:red;}

where :not-exist(…) is true when DOM does not contain element in brackets.

Computation of such pseudo-class is a task of complexity O(n) where n is a number of elements in the DOM.

No one of currently supported selectors in CSS selector module (http://www.w3.org/TR/css3-selectors/) have complexity of O(n). But there are selectors like :only-of-type pseudo-class that are "not good" as in some conditions their computation is as complex as O(n).

Next article will explain what could be done in CSS to overcome complexity problem and still be able to accomplish tasks like ul:not-exist(a:hover) {color:red;}

Some numbers if you wish:

Let’s assume that we have

1. DOM with 1000 elements and
2. single selector that has complexity  O(n) that requre 1 microsecond for computation.

Total time requred for the DOM to get its styles will be:

1000 * 1000 * 1μS = 1000000 μS = 1 S (one second)

Lets double number of elements in the DOM so we will get:

2000 * 2000 * 1μS = 4000000 μS = 4 S.

So by simply doubling number of elements we’ve increased time needed by four.

In real time scenario (on complex sites) it will easily make such sites too heavy to deal with.

Previous version of generators had design problem - it required some special stop value. That is the same kind of problem as with iterators in C++. In some cases it is not possible to choose such a value.

So is this new version:

// generator/continuation for C++
// author: Andrew Fedoniouk @ terrainformatica.com
// idea borrowed from: "coroutines in C" Simon Tatham,
//                     http://www.chiark.greenend.org.uk/~sgtatham/coroutines.html

  //++ coroutine, generator, continuation for C++

  struct _generator
  {
    int _line;
    _generator():_line(-1) {}
  };

  #define $generator(NAME) struct NAME : public _generator

  #define $emit(T) bool operator()(T& _rv) { \
                      if(_line < 0) { _line=0;}\
                      switch(_line) { case 0:;

  #define $stop  } _line = 0; return false; }

  #define $yield(V)     \
          do {\
              _line=__LINE__;\
              _rv = (V); return true; case __LINE__:;\
          } while (0)

  //-- coroutine, generator, continuation for C++

Implementation of typical iterator practically is the same an in previous version except of $stop is being used without any parameter now:

#include "generator.h"

$generator(descent)
{
   int i;
   $emit(int) // will emit int values. Start of body of the generator.
      for (i = 10; i > 0; i–)
         $yield(i); // a.k.a. yield in Python,
                      // returns next number in [1..10], reversed.
   $stop; // stop, end of sequence. End of body of the generator.
};

But its usage is a bit different and is close to JavaScript for(var in sequence) statement:

int main(int argc, char* argv[])
{
  descent gen;
  for(int n; gen(n);) // "get next" generator invocation
    printf("next number is %d\n", n);
  return 0;
}

And here is version of the generator that supports restart (recursive call) - needed for walking through tree alike (recursive) data structures. It uses allocations on the heap that I think is overkill for such constructions.

As we know iterators in C++ is a good but not perfect abstraction. Concept of foreach() (D, Python, Ruby, etc.) appears as more generic solution. At least foreach() does not require artificial iterator::end() to be defined for the collection.

Abstraction foreach() can be imagined as some function/object that is returning next value of collection/sequence each time it is getting invoked. Such functions are known as generators.

Here is my version of generator() for the C++. It is based on the bright idea of Simon Tatham - “coroutines in C“.

First of all sample, here is a declaration of our generator function in C++:

#include "generator.h"

generator(descent)
{
   int i;
   emit(int) // will emit int values. Start of body of the generator.
      for (i = 10; i > 0; i–)
         yield(i); // a.k.a. yield in Python - return next number in [1..10], reversed.
   stop(0); // stop, end of sequence. End of body of the generator.
};

Having declared such generator we can use it as:

int main(int argc, char* argv[])
{
  descent gen;
  do
    printf("next number is %d\n", gen());
  while (gen);
  return 0;
}

That is pretty simple and should be intuitively clear, no?

Here is full source of the generator.h file:

// generator/continuation for C++
// author: Andrew Fedoniouk @ terrainformatica.com
// idea borrowed from: "coroutines in C" Simon Tatham,
//                     http://www.chiark.greenend.org.uk/~sgtatham/coroutines.html

#ifndef __generator_h_
#define __generator_h_

struct _generator
{
  int _line;
  _generator():_line(-1) {}
  operator bool() const { return _line != 0; }
};

#define generator(NAME) struct NAME : public _generator

#define emit(T)     T operator()() { \
                     if(_line < 0) { _line=0;}\
                     switch(_line) { case 0:;

#define stop(V)     } _line = 0; return (V); }

#define yield(V)     \
        do {\
            _line=__LINE__;\
            return (V); case __LINE__:;\
        } while (0)

#endif // __generator_h_

Enjoy!

What is a difference between <input> and <widget> elements [in h-smile core]?

<input> is intrinsically display:inline-block element and <widget> is intrinsically display:block element.

So <input> can live only in some element that has display-model:inline-inside model, in other words in some text container like <p> (paragraph). So if you have markup as:

<div>
  Text: <input type=... />
</div>

engine is forced to wrap content of the div into anonymous text container block.(See: anonymous-block-level ).

In h-smile core that anonymous text container is not so anonymous - it is an element of type <text> (see menu: browse.exe -> Debug -> Element probe on). That <text> is just a <p> but without margins applied by default. You can style that <text> as any other element.

Concept of the Layout Parent Box

For inline-block elements Layout Parent Box is its line box (see: inline-formatting) so when you say height:100%% for inline-blocks their height will be set to the full height of line box.

For block elements Layout Parent Box is a content box of block’s parent (in normal flow). So in this markup:

<div style="height:200px; flow:vertical">
  <widget #first style=height:50%% />
  <widget #second style=height:50%% />
</div>

both widgets will each get 100px height (if no margins, paddings or borders were defined for the widgets).

Can markup parser be extended to support non-standard html elements?

Answer is “yes”.

Let’s say we want htmlayout to support element <checkbox>. We want such element 1) to contain only text (or other inline element) inside and 2) to behave exactly as <input type="checkbox">. To do so we need to define its model for the markup parser. The best place for this information is to put in the Master Style Sheet by using function HTMLayoutAppendMasterCSS().

Here is how such definition may look like:

checkbox {
  display: inline-block;        /* inline with outer text */
  display-model: inline-inside; /* contains only inlines */
  style-set: "std-checkbox";    /* all other visual and behavioral styles are
                                   derived from standard checkbox */
}

After such declaration parser will know how to parse such an element and how it shall be placed into the DOM.

Note: all custom elements shall be XML compatible in other words properly closed. So for this case our checkbox can appear only as <checkbox /> or <checkbox>some text</checkbox> in markup.

For an example of HTMLayoutAppendMasterCSS function use see htmlayoutsdk/wtl/browse/browse.cpp, function _tWinMain().

This article was prepared in Sciter/<richtext> editor.