Sciter. Declarative behavior assignment by CSS: ‘prototype’ and ‘aspect’ properties

July 15, 2014

Filed under: HTML and CSS,Sciter,Script — Andrew @ 10:45 am

From the very beginning Sciter supported declarative scripting class assignment to DOM elements.

If you want all div.some-widget elements in your document to behave in some special way (be subclassed) then you will need:

1. in script to declare

class SomeWidget : Behavior {
  function attached() { ... } // called with 'this' set to the DOM element 
                              // being subclassed on DOM construction
  function detached() { ... }
  // ... SomeWidget specific methods here
}

2. and in CSS to declare

div.some-widget { behavior:SomeWidget; } 
/* or if SomeWidget id declared in other file: */
div.some-widget { SomeWidget url(some-widget.tis); }

After that all div elements having class=”some-widget” will have SomeWidget class assigned to them. I have explained this mechanism 8 years ago (time is passing, yes) here.

This works reliably and is quite convenient.

The only problem with behaviors/prototypes – at any given moment of time particular DOM element can have one and only one scripting class. JavaScript and TIScript do not support multiple inheritance.

Imagine that you have multiple functions in script aimed to configure some DOM element to serve some specific functionality.
In other words each of such functions adds its own aspect (partial functionality) to the element it is called on. Like:

function addClickHandlerFor(element) {
  // adds onClick handler defined by "click" element attribute in html
  element.on("click", function() { 
    var attrClick = element.attributes["click"];  
    element.eval(attrClick); // evaluate the expression
  });
}

You can have set of such functions configuring different aspects of elements/behaviors.

This works in principle but you will need to call such functions explicitly for all elements for which you will need such configurations. And don’t forget to call them it for content created dynamically (non-trivial task by itself).

Considered all these I have introduced new ‘aspect’ Sciter specific CSS property.

The aspect CSS property

It is declared as

  aspect: "function name" [ url(of-function-implementation-file) ];

Where "function name" is fully qualified name of the “aspect” function that is aimed to configure/setup some additional functionality on the element. And the url() is file name where it is defined.

Principles of aspect handling:

The “aspect” function is an ordinary tiscript function that gets called

  1. with this set to the DOM element satisfying the CSS rule.
  2. strictly once per life time of the DOM element.

And yet, the aspect CSS property uses non-standard inheritance – if the element has multiple matching rules with the aspect defined the used aspect is a list of all aspects. Thus if you have have these rules (example taken from the Plus engine):

[click] { aspect:"Plus.Click"; }
[dblclick] { aspect:"Plus.DblClick"; }

and the element defined in markup as

text

It will get two calls – Plus.Click() and Plus.DblClick() for it. As if you have the following in your CSS:

#clickable { aspect:"Plus.Click" "Plus.DblClick"; }

The aspect mechanism is actively used by Plus ( /samples/+plus/ ) and Lang ( /samples/+lang/ ) engines in Sciter SDK.
Plus provides declarative data binding facilities “a la” AngularJS and Lang is about i18n support.

Skeuomorphism vs flat in UI.

July 14, 2014

Filed under: Usability — Andrew @ 11:35 am

They say that skeuomorphism in UIs is bad but that flat thing that they came up with instead is actually even worse. Most of the time it gives no visual clue to the user.

There are two “Trim”s here:

BuddyTV

one is clickable button, another one is static label…

It is not a UI anymore – just a “find button” game.

More about the subject is here.

“Theory” of URLs for developers

July 9, 2014

Filed under: HTML and CSS,HTMLayout,Sciter,Web Application Techologies — Andrew @ 11:25 am

We are using URLs these days quite a lot, but not all of us understand what they actually are.

By this post I will try to explain their structure and how Sciter/HTMLayout deals with them.
Please note that this is sort of informal explanation and I am using term “URL” here while “URI” is more correct name for that entity strictly speaking.

URLs are made from these 5 major parts:

<scheme name> : [//] <resource identification > [ ? <query> ] [ # <fragment> ]

Where:

  • scheme name – is in principle any name token – name of the URL scheme. Some of names are well known: “file:”, “http:”, etc.
  • // part – if present, means that the following “resource identification” part uses hierarchical naming convention, with ‘/’ character as a delimiter.
  • resource identification – is either ‘/’ separated path name if ‘//’ is provided. Or it is some “flat” name.
  • query part is in principle meaningful only for dynamic client/server scenarios. It is an instruction to the server to provide that resources with those parameters.
  • fragment – is a name or ID of some sort that identifies some location or part inside the resource.

Consider that you have the same HTML test-file.html available from these three locations:

  1. file:///c:/test-folder/test-file.htm
  2. http://example.com/test-folder/test-file.htm
  3. res:test-file.htm

Let’s imagine that the document contains image with relative path:

  <html>
  <img src="image.png">
  </html>

Sciter, while loading the document, will resolve relative path name “image.png” to these:

  1. file:///c:/test-folder/image.png – as base URL is hierarchical one.
  2. http://example.com/test-folder/image.png – ditto.
  3. res:image.png – but here only resource schema is inherited as base URL uses “flat” naming convention.

In principle your Sciter application can use your own URL schema. You just need to decide will it be hierarchical or flat.

For example if you will call SciterLoadHtml(html, "app://module/main.htm"); then all relative links inside that document
will be resolved against app://module/ base name. So in your SCN_LOAD_DATA handler you will get: “app://module/images/img1.png”, “app://module/styles.css” and so on.

But if you plan to put all your files into resource section of your executable then you should use “flat” schema, like “res:”.

And the last note: if you use hierarchical URLs in SciterLoadHtml and SciterLoadFile calls then these urls must be absolute ones otherwise Sciter will not be able to resolve them reliably.

Sciter, <video> support

July 5, 2014

Filed under: HTML and CSS,Sciter,Web Application Techologies — Andrew @ 4:34 pm

Adding basic <video> support to Sciter.

The <video> element (behavior:video in fact) is rendered windowlessly as normal DOM element so can participate in animations, transforms and to have other DOM element rendered on it.

Here is a screenshot of Sciter made when it is playing video (standard 30 fps rate) under animation and transformation on semi-transparent background.

sciter video demo

DOM Inspector and “how to remove border from an input element”

June 21, 2014

Filed under: HTML and CSS,Sciter — Andrew @ 8:31 am

This how to remove border from input element is a popular question that I am getting time to time from new users.
And there are variations of it about dropdown select button, calendar cell, context menu and so on.

In this post I’d like to explain general method of solving such problems instead of answering “define the following …”

Each input element in Sciter is a plain DOM element or composition of plain DOM elements.

Input elements (and not only inputs) are getting their “primordial” styling by applying rules from Sciter’s internal “master.css” style sheet. To find out styles of particular DOM element start DOM inspector by clicking on its icon in Sciter.exe window.

To highlight needed DOM element click on it by mouse with CTRL+SHIFT keys pressed on keyboard. Or select the element in DOM tree in inspector’s window:

dom inspector

Inspector will show effective style rules applied to the element and also its final (used) styles.

As you see here that <input> element has no border at all. But it has
background-image: url(theme:edit-normal); background-repeat:stretch; instead – background image that is stretched to fill whole element’s area.

The theme:.... images are kind of virtual ones – their rendering is delegated to host OS UI theming services. Therefore background of this particular <input> element is drawn by host OS.

And finally here is the answer on “how to remove border from the input element”.

To suppress borders and any default background drawing declare the following:

 
input#my {
  border: none;  /* remove any border */
  background: none; /* remove any (default) background */
}

Sciter, SVG support

June 11, 2014

Filed under: Sciter — Andrew @ 5:02 pm

Adding SVG support to Sciter:

Sciter SVG demo rendering

Sciter SVG demo rendering

This time SVG implementation uses standard DOM model so can be accessed by TIScript Element interface and styled by CSS.

Same drawing on Mac OSX:
mac-osx-svg-tiger

« Previous PageNext Page »