HTMLayout – Page 2 – Terra Informatica Software

Aero, Windows V/7

In the middle of adding Windows Aero DWM support to HTMLayout and Sciter:

This is standard sample htmlayoutsdk/html_samples/border-radius/rounded-tabs.htm from the SDK

Seems like I need to add “aero” as an additional value to CSS @media selector in order to support such screens. This document is using simple html { background-color:transparent; } declaration to make it transparent.

And w7aero sample application is calling this function

void ExtendFrameIntoClient(HWND hwnd)
{
   // Negative margins have special meaning to DwmExtendFrameIntoClientArea.
   // Negative margins create the "sheet of glass" effect, where the client area
   //  is rendered as a solid surface with no window border.
   MARGINS margins = {-1};
   HRESULT hr = S_OK;
   // Extend frame across entire window.
   hr = DwmExtendFrameIntoClientArea(hwnd,&margins);
   assert (SUCCEEDED(hr)); hr;
}

Pretty easy I would say…

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.

Built-in Drag and Drop support in h-smile core

As far as I understand there are two distinct drag-n-drop mechanisms:

Global drag-n-drop when objects are dragged from one window/application on desktop to another. In most cases this is very close to clipboard cut-n-paste but with some additional visualization.
Window local drag-n-drop when objects are dragged inside single window/form. For example some shopping cart implementation.

I have added support of latter one to the h-smile core – local drag-n-drop of DOM elements. Details are here.

Consider following task:

For these two select elements:

<select id="source" size="5">
  <option>First<</option>  
  <option>Second<</option>  
  <option>Third<</option>  
</select>
<select id="destination" size="5"></select>

we would like to provide ability to drag <option> elements from #source element to the #destination. In case of htmlayout or the Sciter (both are based on h-smile core) it is enough to write following:

   select#source > option
   {
      dragging: only-move; /* we can only move options out here*/ 
   }
   select#destination
   {
      accept-drag: selector( select#source > option ); 
                  /* we accept only options from select#source*/ 
      drop: append; 
                 /* order of items is not relevant, 
                     always append dropped option */
   }

and this is it – our users now are able to drag items from first <select> to second.

But what about one of main principles of good UI design – “discoverability”? User should have a visual clue while dragging: where and when he/she can drop dragged item. Following additional pseudo-classes will help us in this tasks:

   option:moving /* moving (dragging ) option */
   {
      background:blue; color:white;
      opacity:0.5;
   }
   select:drop-target /* active drop target element(s) */
   {
      background: yellow; 
      /* after D&D operation was started all active drop-targets 
          will be highlighted by yellow color */ 
   }
   select:drag-over /* drop target element under the dragged item.*/
   {
      outline: 1px solid green; 
      /* green outline to show that at current mouse position  
          dragged element can be dropped in this particular drop-target */ 
   }

And that is all we need to enable drag-n-drop in our application.

Oh, forgot to add: what if we need to drag options in both directions – from #destination back to the #source? The same simple idea:

   select#destination > option
   {
      dragging: only-move;  
   }
   select#source
   {
      accept-drag: selector( select#destination > option ); 
      drop: append; 
   }

And one small piece left: drop:recycle will declare element it is applied to (drop-target) as a “black hole” – all items dropped here will be deleted.

How I would do that Start Page.

Two days ago I have downloaded and installed new Microsoft Visual C++ 2008 Express.

First thing that you see when you start its IDE is the Start Page (close to what you see on the right). I was intrigued how this view is made. That clearly have look and feel of a web page. Some portions of data are coming from Internet.

So I took the Spy++ application and pointed it on the view. It was a surprise for me to discover that this view is made of separate windows in old VB style. It is made of 40 (forty) child windows. That is not so good to be honest:

too resource greedy, e.g. without this view IDE takes 10 Mb less of memory;
and as you might expect scales badly on high DPI settings, see example of actual rendering:

VS on Large DPI

Thus I’ve decided to reproduce this screen in HTMLayout. Here are steps of how I’ve made it.

1. Images

For this particular view we need 4 ( and only four ) images:

– header background;
background of the body section;
background and borders of informational panel;
– background of panel’s caption.

(I took these images from screenshot I made from Microsoft Visual Studio window. These images are probably copyrighted. In any case my respect to their authors.)

Ok, back to business…

2. HTML

Structure of HTML for such a view is simple:

<body>
  <div .header />
  <div #sidebar >
    <div .panel #recent-projects><caption>Recent projects</caption>
      <ul><include src="content/list-of-projects.htm" /></ul>
      <table>
        <tr><td>Open:</td><td href="#">Project...</td></tr>
         <tr><td>Create:</td><td href="#">Project...</td></tr>
      </table>
    </div>
    <div .panel #getting-started><caption>Getting started</caption>
      <ul><include src="content/getting-started.htm" /></ul>
    </div>
    <div .panel #headlines><caption>Headlines</caption>
      <dl><include src="content/headlines.htm" /></dl>
    </div>
  </div>
  <div .panel #msdn-news>
    <caption>MSDN: Recent news</caption>
    <dl><include src="content/msdn-recent-news.htm" /></dl>
    <p style="text-align:right;"><a href="#">More news...</a></p>
  </div>
</body>

Nothing spectacular so far I would say.

Note:

Markup above is HTMLayout specific: 1) <div .panel > is a short form of <div class=”panel” > and
<div #recent-projects > is <div id=”recent-projects” > and you can use both forms. And 2) <include src=”content/list-of-projects.htm” /> is so called client side include instruction – it allows to assemble final HTML from different source files. This include makes sense here as while parsing engine will generate HLN_LOAD_DATA notifications for each inclusion. These portions are dynamic so handling this notification we can generate HTML content fragments we need. That is close to the CGI idea.

3. Styles

Final piece left – styles. That is really simple as HTMLayout supports expandable backgrounds.
If you have read document under the link above then you should get the idea of this fragment. It defines styles for our panel and its caption:

    div.panel
    {
      background-image: url(images/panel-back.png);
      background-repeat: expand; 
      background-position: 14px 14px 14px 14px; 
          // top right bottom left offsets/margins
      padding: 0 10px 10px 10px;
      margin-bottom:20px;
    }

    div.panel > caption
    {
      background-image: url(images/panel-caption-back.png);
      background-repeat: expand stretch-left stretch-middle stretch-right; 
      background-position: 3px 3px 3px 3px; 
         // top right bottom left offsets/margins
      padding:6px 6px;
      color:white;
      font-weight:bold;
      position:relative;
      top:-0.7em;
      margin-bottom:-0.6em;
    }

Other styles are also simple as these two above.

To see this mock-up alive you can download demo browser.exe with samples and run /bin/browse.exe. Click open button and find /html_samples/MSVS-start-page/start-page.htm. This is it.

4. Epilogue

It took me one hour to design this sample (from the set of existing images).

Loaded document consumes 5 (five) times less resources than original solution.

And HTMLayout is free. For Microsoft Visual Studio Team (respect!) too 🙂

Talks about HTMLayout

Here is a translation of the interview in Russian I gave to Alexander Sergeev from the HumanoIT.

Alexander Sergeev(AS) says:

My long time dream – to write a shareware program and sell it through the Internet: cash out, Brazil, Maldives, Tokyo, beaches, skiing, casinos… ahhh. This summer I almost brought it to reality… all thanks to one wonderful graphical engine. I’ll tell you right away – I didn’t finish my program yet (simple lack of time), but the summer has not gone wasted – now I know, WHAT interfaces can be developed on the desktop. For us (in HumanoIT Group) this knowledge is equivalent to its weight in gold, since we don’t develop interfaces for the web only.

HTMLayout is currently the only embeddable HTML/CSS engine of this type.

Here are a couple of interfaces based on the HTMLayout engine:

Nobody can tell us about HTMLayout better than its author. Hence, I present to you an interview with Andrew Fedoniouk, the author of this wonderful graphical engine.

Part 1: Ponderings about Web 2.0

What do you think about Web 2.0: what is the essence of Web 2.0 for you as a user? As a programmer?

Andrew Fedoniouk(AF): First of all, nobody knows for sure what Web 2.0 is 🙂 It’s a set of technologies and solutions at the level of a "hack" – this I will tell you. For myself, I classify Web 2.0 as a set of technologies which supports Occasionally Connected Web Applications.

Please clarify what you mean by Occasionally Connected Web Applications?

It’s an application, which has a built-in capability of working offline. I.e. Web 2.0 is more about desktop applications, than about the actual web. It’s about using web on the desktop and vice versa – giving web applications a desktop-like feeling.

Name some main differences between today’s desktop applications and Web 2.0 applications?

Storage of data. Actually – this is the age old difference between client-server and desktop applications. Web 2.0 tries to bring the "comfort" of desktop to the web.

What do you think the main differences in UI between the two are? (let’s leave HTMLayout out of the picture for now)

Inductive UI versus Productive UI. Traditionally, Web applications are ossasionally used applications. I.e. web application’s UI must be self-descriptive: any user off the street should be able to do what he needs to, without reading any docs.
Let’s take Norton Antivirus and Norton Internet Security as examples. These are applications of a "big red button" – rarely accessed (by UI), so their UI must be intuitive. This is one of the reasons Symantec uses HTMLayout in their products.

Another example is a media player application. That kind of applications are built around "Play" button. I cannot imagine anyone reading manual of, say, WinAmp.

What do you see as inductive UI? Wizards, oriented to perform user tasks?

Yes, inductive UI is a paradigm of "steps" (a wizard) – enter some data, press submit, move to the next step.

AS (Alexander Sergeev): By the way, Don Norman introduced a concept called affordance – analogous to being self-descriptive. For example, scissors – it’s obvious that the fingers go into the holes 🙂

AF (Andrew Fedoniouk): Sure.

And what do you mean by productive UI?

Inductive UI is Web 1.0. Web 2.0 – is (among other things) an attemp to make productive UI available in the web. Productive UI refers to applications used every day. A characteristic feature of such applications is an attempt to minimize the amount of efforts to achieve a desired result. Shortcuts, for example, are an obvious attribute of a productive UI. Toolbars, among other things, are as well.
But this distinction between Inductive and Productive UIs is becoming less clear. The complexity of applications is growing, so even such apps as MS Word use wizards and ribbon.

If we go down to the level of controls and widgets – what do you see as the main difference between desktop and Web 2.0 applications?

Widgets are also approaching a common denominator. Web 2.0 widget kits are striving to recreate the desktop, while desktop kits are going in the direction of compound web alike widgets.

Please name three main technologies, which you think are the basis of Web 2.0 applications? Desktop applications?

AJAX (as a lightweight way of sending messages between the UI and the data model – a classic feature of desktop applications)

HTML/CSS as a technology for gluing together the pieces into a final UI. There is actually a lot behind this. PHP/ASP/etc technologies as a way of putting together the UI. This is what the desktop didn’t have.

Finally, scripting and HTML event propagation schema, as a way of connecting different elements between each other. In fact, this was not present in the desktop UI (typed languages).

AS: You forgot about DOM.

AF: Yes, DOM is a whole different aspect.

AS: We see Web 2.0 eye to eye from the technical perspective. For me, Web 2.0 is get, parse & display: get the data (from the server), parse/process the data and display it. Get is ajax, parse is DHTML (HTML + DOM + Javascript), display is CSS. I think that it is thanks to these technologies that we now can create rich user experience in Web 2.0 applications.

AF: Technically, if we dig deeper, this all falls under the paradigm of CGI. This is the basis of generating UI in server-terminal type systems. Terminals are just becoming more resource rich.

AS: Yes, the last point sums up the need for usability and user-orientated UI’s 🙂

What do you think web applications lack, even disregarding web-duality?

Starting from afar, there are 2 types of Internet users: "readers" and "writers". For readers, Web 1.0 is quite sufficient, and so are the current browsers. The second group – "writers" – are the people who need a different:

model of security

usage model (occasionally connected)

capability for interaction between desktops objects and browser objects

For example, Gmail is great at everything (as that Exchange Web Client – web client of “big” Outlook), except for the fact that it’s not a desktop application 🙂 I want to be able to download email and read it when I have free time, while disconnected. This is an example #2.

The simple action "save as" in any word processor or email client. In fact, the browser disallows writing anything on the client due to security concerns. This is the right way for the "reader" use case.

About #3, let’s use the clipboard as an example. I want to insert an image I just drew in Xara into a blog entry and it’s not possible. I need some other client ( UA user agent) to accomplish that.

Part 2: HTMLayout Engine

Tell me a little about the HTMLayout library. What is it for?

HTMLayout is a unique (in its own right) embeddable html/css engine. Embeddability is the focal point here.

All operations which concern security, for example load remote resource, go through the host (notification and callback). Hence, the host application is in charge of the security policy. This is the main problem while embedding Gecko and Trident (IE, IWebBrowse).

The CSS feature set is extended in HTMLayout to support 2D layout – the HTML/CSS model in the web is an endless tape, having a fixed width only. HTML and CSS 2.1 lack a method to perform vertical alignment.

All widgets are made from DOM elements – i.e. their components are styled through CSS. For example, combobox is a DOM element and the button in it (show popup) is also a DOM element. This button can have it’s own style (think of UI themes), and additional behavior associated with it as well.

Behaviors – as a way of setting behaviors per se for conglomerates of DOM elements (aka controls). Behavior changes the state of DOM elements, while CSS displays it all.

Sinking/bubbling event propagation schema, as a simple and effective way to deal with events.

Support for OS themes – as a way to respect user preferences.

So, roughly speaking, HTMLayout is a web browser, which a Windows programmer can embed into his or her program, and base its UI on DHTML?

You can say that. If roughly 🙂

As far as I know, people in Motorola use it exactly like that. They made a specialized browser based on HTMLayout that communicates with http server.

C++ and C# is used instead of Javascript to display and process widgets (aka controls)?

Yes, the language of the host application is used to describe actions. I know about various bindings of HTMLayout in C++, C#, Ruby, Lua, Python, etc.. Imagine that you had a way to, say, extend some HTML/CSS engine with various UI elements needed for your applications (<input>, <widget>, etc). I suspect that you won’t need JS in 95% of the cases if you have the required component set.

There have always been resizing issues in Windows applications based on MFC/WTL – you had to manually adjust the size of the controls. On the web, I have never seen a "rubber" application, which would have automatically (upon browser window resize) adjusting control size (inputs, combo boxes, etc). Is this problem resolved in HTMLayout? What features are available in the library to simplify the resizing procedure.

There are two problems about resize.
The first – implementing a rubber layout – it is in HTMLayout already by the nature of HTML and CSS. I think this kind of flexibility is not available in any other UI toolkit.
The second – "congruent UI scaling" – is not that much of a problem in my eyes. "Automatic resize of controls when the browser window is resized" – this can be done in HTMLayout, if that’s what you need. However, users usually make the window bigger to increase the working area, rather than to increase, for example, the font size.

An example from a different area. Symantec NIS (Norton Internet Security) has support for high contrast mode. It’s done simply with CSS by using different media types (normal screen and high-contrast screen settings are really different media types):
@media screen { … css declarations… }
@media high-contrast { … css declarations… }

Therefore it is no need to reprogram the host application to support accessibility.

Regarding components in HTMLayout. As far as I understand, on the web, I am working not with the control itself but rather with the control’s HTML-snippet. In HTMLayout, I can create the control beforehand, name and change it at the execution stage, depending on the current event and data?

You can write in CSS:
input[ type=”something” ] { behavior: some-behavior; }
and in HTML to use it as:
<input type=”something” />

The host application should provide a behavior implementation which can do pretty much anything. For example, it could create an embedded DOM tree and handle the events it generates. The same behaviour can be used by different style schemas, creating visually different control elements.

In essence, all input elements in HTMLayout are made this way. They are simply a set of behaviors which are assigned to different DOM elements through the master CSS style sheet.

Embeddable behaviors can be reused:
<span class=myradio name=n1 /> <span class=myradio name=n1 /> <span class=myradio name=n1 />
+ css:
span.myradio { behavior: radio; }
span.myradio:checked { background-image:….; }

Furthermore, it’s possible to glue together complex structures from simple blocks.

AS: I.e. in such a case, when the user clicks a radio button, the background image could appear.

AF: Yes.

AS: Besides, instead of outputting a simple radio button, I can show anything? (can’t think of an example of what else I could output 🙂 )

AF: Tabs, as UI control elements, are pretty much a set of radio buttons (bookmarks) augmented with a binding mechanism to the visibility panel set. I.e. it is sufficient to write a behavior, which upon receiving a BUTTON_CLICK notification from such a radio button, could set the :cuurent state flag of some corresponding div panel.

All that remains to be done is a bit of CSS:
div.tab-panel { display:none; }
div.tab-panel:current { display:block; }

There aren’t that many behavior patters like that in real applications. I.e. creating something complicated from something simple. The CSS code is used as glue, binding together state and appearance into a single entity.

AS: Thanks for the detailed example! Originally, I mistakenly thought that instead of behavior:radio; I could write behavior:"something" and instead of the radio button we would get "something" in the span. Instead, it seems that we are changing object properties here.

AF: Yes, the main purpose of behavior is changing state attributes of DOM elements in response to user actions. In the behavior::attach() handler, it’s possible to create or change the DOM structure of the element (or its surrounding), if required.

AS: So, behavior allows to manage the contol’s state.

Please provide an example of applications which use HTMLayout?

Off the top of my head – Symantec (Norton Antivirus, Norton IS, Norton 360). All games from Alawar have a "game console", which uses HTMLayout:

Part 3: UI evolution tendencies

What do you think some of the current developing tendencies for UI on the desktop?

Software vendors are striving to switch to a service model – i.e. the user paying regularly for a service, rather than once. UI’s are very different from each other. On one hand, we have typical desktop productive utilities. On the other, we have the aforementioned big red button applications. I wouldn’t try and pick out the mainstream. This is counter-productive, since I believe there is no one fit all solution here.

What if we look at the progress in the area of controls and tools for UI development? Is there progress? Do you see any tendencies here?

I see both technical and stylistic tendencies:

Stylistic – "pictographic UI’s" and "hyperlinking"

Technologic – declaraitive UI – the unfulfillable dream of all humanity

Back when I was still coding, I created interfaces with the help of Visual Studio’s resource editor. It took me a very long time. Even today, the interface UI developer should keep in mind the complexity of the task he is giving to the UI programmer.

From a developer’s perspective, I think none of the technologies offers a noticeable improvement in the time taken to develop the bare interface without any data behind it. VB(6) allowed you to quickly throw some forms together in the editor. However, that’s where it stops. How do you create a form within another, handle events in complex structures, etc.

IMHO, the web is far more advanced in this respect – the interface is almost completely separated from the business logic with the help of templates and templators. On the desktop, as far as I know, everything is much less cheesy.

Yes, there are also tendencies – UI generation from templates, CSS as an entity (stylization of existing DOM – seperation of semantic(data,code) and style). VB and MFC simply are not made for stylizing elements and combining simple elements into complex structures.

AS: Yes, it’s not so easy to change the interface styles in VB and MFC. You have to go through all properties and change the styles in each of them. In addition, in MFC you have recompile the project as well. To develop your own control, you need to study the ActiveX/COM technologies.

For me, HTMLayout is a significant step forward in separating the UI from the application’s business logic. The interface’s designer can quickly create a prototype in something like Axure (meant for web apps). Then, he or she can write the HTML code as a template for the programmer, who can add behaviors, variables, and other stuff into this template.

In my opinoin, HTMLayout does and excellent job of integrating the advantages of both desktop and web technologies.

AF: I think so. In addition, some properties of UI components cannot be changed at all in VB and MFC. HTMLayout interace provides a whole different level of control.

Rubber layout, for example. Fixed layout format is the exact offender which prevents scalable UI’s. Controls in Windows dialogs are usually fixed dead in their tracks. Set 120dpi on the screen and it’s over – the UI is unreadable even in some Microsoft applications.

Behind the layout flexibility of a rubber interface lies accessibility – not all users can use the UI with the default 96dpi.

HTMLayout ideology helps large scale development of software – the UI and logic become loosely coupled. Hence, the separation into teams of UI designers and stylists, and backend logic programmers becomes much easier.

Parts 4 and 5

I think it’s reasonable to leave these parts for the next article – too many letters, even for this blog. 🙂

What will be in the next article:

SW and web application aesthetics

MS Expression, XAML, Aurora

Animation in HTMLayout

Designing

I am designing <richtext> behavior for htmlayout/sciter… So far I like the way it allows to edit the text.

There are interesting usability problems bubble up sometimes… Let’s say you have following document:

<body>
  <pre>
     ....
  </pre>
  <table>
     ....
  </table>
</body>

And now imagine that you need to insert some text (paragraph) between the table and that pre block. Or insert paragraph (<p>) at the beginning of the document – before the <pre>…

I do not know any WYSIWYG HTML editor that allow to handle such operations.

So I have invented “horizontal caret” that marks start-block-position. Enter key in that position causes new paragraph to be inserted.

Here is an example of such caret – blinking black bar in top-left corner of the pre element:

richtext, horizontal caret

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:

<div.some>
      <p>first</p>
      <p></p>
  </div>

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.

Graphin engine

I have started Graphin.dll project – portable and compact graphics engine based on AGG (agg2d in particular).

Graphin url is code.google.com/p/graphin

API mimics Graphics and Image objects but in plain C. In principle this is close to the <canvas> from WHAT WG .

Graphin.dll includes also pnglib/zlib and jpeglib with the ability to load and save image object to/from byte vectors (and so mm files) as png/jpeg.

Intention is to have graphics engine that is portable and simple to use. With Graphin it should be possible to reproduce <canvas> functionality
in any language/environment.

There is nothing spectacular yet there but structure is established and couple of methods like graphics_rectangle, graphics_line, etc are written.

Graphin is based on agg 2.4 and contains that agg2d thing written by Maxim Schemanarev .

agg2d class was ported by Jerry Evans from agg 2.3 and contains fixes made by Maxim, myself and Pavel Korzh.

New members of the project are very welcome.

I am planing to use Graphin as graphics backend of multiplatform versions of htmlayout and sciter.

Update: here is a screenshot of Graphin Demo project.

CSS extensions in h-smile engine. Part II. Flex units.

Flex length units are "weights" used in distribution of free space along some direction.

Example of the document with flex units:

<html>
<head>
  <style>
  div.outer
  {
    border:red 2px dashed;
    width:400px;
    height:250px;
  }
  div.inner 
  { 
    margin-left:30%%; width:50%; margin-right:70%%; 
    height:100%%;
    background:gold; border:brown 4px solid; 
  }
  </style>  
<head>
<body>

  <div class="outer">
    <div class="inner"></div>
  </div>
  
</body>
</html>

This document will be rendered in h-smile engine as:

As you see left and right margins of div.inner are distributed as 30:70 and they span whole free space left from width:50% and borders of the div.inner.

Key point here is distribution of free space. Computation of flex units happens as a last phase of layout algorithm – when container’s dimensions are known and all non-flex lengths were computed. Space left from fixed lengths will be distributed among elements and parts given in flexes.

Here is another example that demonstrates weighted distribution of heights:

<html>
<head>
  <style>
  div.outer
  {
    border:red 2px dashed;
    width:400px;
    height:250px;
  }
  div.inner1 
  { 
    height:1*;
    margin:4px;
    background:gold; border:brown 4px solid; 
  }
  div.inner2 
  { 
    height:2*;
    margin:4px;
    background:lightblue; border:navy 4px solid; 
  }
  </style>  
<head>
<body>
  <div class="outer">
    <div class="inner1"></div>
    Some text in between.
    <div class="inner2"></div>
  </div>
</body>
</html>

And its rendering:

As we see here heights of div.inner1 and div.inner2 are distributed using given 1:2 ratio (1* and 2*).

Notation of flex units

There are two equivalent forms of flex length notation: N%% and N*. These two forms are different by multiplier: 1* is exactly 100%%.

Computation details

If sum of flexes in the space that needs to be distributed is less than 100%% then some free space (remainder) will be left undistributed. If sum is equal or more than 100%% then all flex values are used as weights in distribution so all free space will be “covered by flexes”.

Nothing new under the sun

Idea of flex units for CSS was taken from HTML 4.0 relative length units . Flex units in N* notation are used there as values of cells dimensions. ( I do not know any html rendering engine that has this part of standard implemented though ).

XUL specification has also concept of flexes. Flexibility of widths (?) or heights(?) of elements in container is defined by the flex attribute.

Why flex’es are so good?

Flex units allows to position elements with respect of other content on the page. For example if user will change base font size of the document then dimensions given in flexes will be recalculated accordingly. In principle design based on flex units will produce layout that is more stable to changes of platform dependent things – font sizes and types, screen sizes. etc.

Flex units allows to position elements staying in static layout mode – without need of position:relative, absolute.

Flex units significantly reduce need of use of tables or JavaScript code for layout purposes.

CSS extensions in h-smile engine. Part I. Style sets.

Style set is a named set of style declarations – it is a system of selectors and style definitions that are applied as the whole.

Style sets are declared by using @set at-rule:

@set my-table

{

  td { color:blue }

  td.highlighted { color:red }

}

Assignment of style set to elements is made by using style-set attribute:

table#my

{

  style-set: "my-table";

}

After this declaration <table> element with id="my" will get system of styles defined by the set. In this particular case all cells ( <td>s ) will have blue color and all cells of class "highlighted" will have color red.

If somewhere later in your CSS you will have definition:

table#my {  style-set: none; }

then it will drop definitions from the set my-table all together. In other words style-set is a switch of style sets.

:root

Element that has style set applied serves role of the root for selectors defined in the set. :root pseudo class being used in style set definition matches the element this set is applied to.

Specificity of selectors in sets.

Specificity of selectors inside style set is calculated by using standard CSS algorithm.

In presence of style sets an element is getting its style in two stages:

by applying all style rules and attributes without style set – as usual.

if element gets some value of the style-set attribute then the element gets all matching style from the style set.

So styles inside style set are of larger importance/weight than ordinary styles.

Motivation

Style sets mechanism solves two principal problems of CSS:

They allow to define local and independent style systems for elements in the same DOM tree without need of using <frames>.

Style sets allow to reduce computational complexity of style resolution. In classic CSS all style rules that used by the document are placed in the single ordered table. Task of finding list of matching selectors for the element has computational complexity near O(n), where n is a number of rules in the table. And style resolution of the whole DOM tree is O(n * m * d) task. Where m is a number of DOM elements and d is an average depth of the tree. Style sets allow to reduce significantly n multiplier in this formula.

Style sets are actively used in so called Master Style Sheet of the h-smile engine. Master Style Sheet defines default rendering and behaviors of intrinsic input elements and components. See link above for more details.