All < input > and < widget > elements (and their subparts) in the Sciter/HTMLayout are plain DOM elements with attached behaviors. This probably sounds not too much spectacular but, trust me, this, as a system, is extremely useful.
As a rule behavior as an entity is some class or collection of functions defining guess what? correct – behavior of DOM element – how it reacts on UI events. Main purpose of the behavior is to change state of the element while handling UI events. By changing state registers of the elements behaviors allow CSS engine to style them declaratively. So for example: li:expand > .details { display:block; transition:slide } will make items in your list expandable. You just need to define proper behavior for your list like ul { behavior:expandable-list; }. Image on the right is a screenshot of that expandable-list in action.
As I said before all built-in input elements in Sciter implemented as behaviors. While loading HTML document engine styles shape and behavior of elements by using Master style sheet.
By using cascading of styles you can redefine look-n-feel (literally) of all elements. As an example of why you would need this consider following task: there is no such thing as < button type='checkbox' >some caption here< /button> by defult in HTML. But you need it! Standard CHECKBOX in Windows for example has clickable caption erea. And your customers will expect such behavior. So in Sciter you will define button[type=”checkbox”] { behavior:checkbox; … } plus bunch of state styles and you will have checkbox button visually styled as a standard system one or as a product of cauchemar of your graphical designer. And by the way, you can change its style on the fly by changing, say, value of some attribute and use the value of such attribute in CSS selectors for such elements.