INPUT, WIDGET and custom elements in h-smile core

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.

4 Replies to “INPUT, WIDGET and custom elements in h-smile core”

  1. Thanks for detailed description.
    One question about custom elements:
    Can I add styles in css file (not in HTMLayoutAppendMasterCSS)?
    Why HTMLayoutAppendMasterCSS is preferable?

    Thanks.

  2. In general: custom elements, as a feature, de facto, changes input language of the HTML parser so it is better if that input language definition will be available upfront – before parsing html(extended).

    Think about this: styles can be loaded asynchronously so at the moment of HTML parsing information about custom element may not be available.

    Resume: Technically you can define custom elements in local style sheet but there is no guaranty that parser will be able to use them properly. If you loading document (and its styles) from local source then loading is synchronous so, yes, you can define custom elements in local style sheets.

  3. Exempli gratia, I register custom element type using HTMLayoutDeclareElementType and set ELEMENT_MODEL (before parsing document). Is it enough information for parser? Is parser needed something else?

    I see two disadvantages of HTMLayoutAppendMasterCSS:
    1. Styles are splitting in css and cpp code, and
    2. Project must be recompiled after (cpp) styles changing.

  4. HTMLayoutDeclareElementType is enough but it allows you to define only model of the element.
    Usually you need to define model and default rendering style. Up to your needs to be short.

Comments are closed.