behavior:htmlarea (WYSIWYG editor) in h-smile core.

September 28, 2007

Filed under: HTML and CSS, HTMLayout, Sciter, Web Application Techologies — Andrew @ 12:48 pm

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

May 25, 2007

Filed under: HTMLayout, Philosophy, Sciter — Andrew @ 3:16 pm

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.
Graphin Demo

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

May 4, 2007

Filed under: HTML and CSS, HTMLayout, Sciter — Andrew @ 4:21 pm

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?



  1. 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.

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

  3. 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.

April 20, 2007

Filed under: HTML and CSS, HTMLayout, Sciter — Andrew @ 8:44 pm

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:  



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

  2. 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:



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


  2. 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.

HTMPrintMeasure or basics of HTML/CSS printing

March 31, 2007

Filed under: HTML and CSS, HTMLayout — Andrew @ 4:20 pm

PrintEx API of htmlayout has HTMPrintMeasure function with the following signature:

HPRESULT HTMPrintMeasure(HTMPRINT hPrint, HDC hdc,
            int scaledWidth,
            int viewportWidth,
            int viewportHeight,
            int* pOutNumberOfPages);

I would like to explain here meanings of its parameters as I am getting questions about printing and scaling pretty frequently.


First fact that we need to know: pixels in HTML and CSS are logical units and have nothing common with device pixels our HTML/CSS is rendered on.


By accident 1px in HTML normally mapped to one physical pixel on screen (but not always, sic!) and one "HTML pixel" on printer can be mapped to some rectangular area that covers multiple printer "pixels". Strictly speaking printers have no pixels.


Showing that more device pixels (dots)<br /> are needed to cover a 1px by 1px area on a high-resolution device than<br /> on a low-res one   [D]
(illustration taken from W3C CSS specification)


According to the specification, HTML pixels are logical units that are just fractions of real length units:

   1px (html,css) = 1in / 96

Thus pixel in HTML is very close by its nature to "point" – 1pt is 1/72nd of an inch.


And this is it about theory, back to our business – HTMPrintMeasure function and its parameters:



  • int scaledWidth

    - is a number of "HTML pixels" between left and right border of the page.

  • int viewportWidth

    - is a number of "printer physical pixels" or dots between left and right border of the page (a.k.a. physical page width).

  • int viewportHeight

    - is a number of "printer physical pixels" or dots between top and bottom border of the page (a.k.a. physical page height).

At this point of our "printing saga" we can ask the question "what are the correct values for these parameters?"


Let’s assume that we have given:



  1. printer that has 600 dpi (dots per inch) resolution.

  2. paper of the format "legal" – 8.5 by 11 inches.

Calculation then is pretty straightforward:

viewportWidth = 600 dpi * 8.5in = 5100 dots (or printer pixels if you wish)
viewportHeight = 600 dpi * 11in = 6600 dots.
scaledWidth = 8.5in * 96 (html px per inch) = 816

Therefore we have 816 "HTML pixels" on printing page of the legal/portrait format in horizontal direction.
This means that if you have <table width=800> or <img width=800> then they shall fit on such page in full (if printing margins were set to zero).


In reality things are a bit more complex – you need to take in account printing margins in calculations to get precise results. But this I hope will not be so difficult for people who knows, let’s say, C# programming language .

HTMLayout. Success story.

December 14, 2006

Filed under: HTMLayout, Philosophy — Andrew @ 10:09 pm

Here is a success story of one of our customers. Some goverment agency in some country.

Migrating from IE control to HTMLAYOUT

Problem

We have a suite of products deployed in multiple geographical locations to about 150 clients. The suite is implemented in Law Enforcement Agencies to leverage the use of technology in ensuring the safety of our communities. The product is taking advantage of HTML to render rich User Interface (UI) content. HTML and CSS provide flexibility in the implementation of the user interface, while being extremely user friendly. Most users are familiar with browsing the internet, thus comfortable with the concepts of ‘clicking’, ‘hyperlinks’, and basic control behaviors.

Our product is rendering its user interface through Microsoft Internet Explorer controls with Microsoft Visual Basic to handle events and data manipulation. With the advent of new versions of Internet Explorer, we are anticipating a multitude of problems in rendering the User Interface. The solution is to find a third party control capable of rendering the same HTML user interface while requiring a minimum of rewriting of the existing html code base.

Solution

Our user interface is a transformation of the data retrieved from the database into HTML by using XML/XSLT transformation. We have a variety of XSLT documents that render the user interface. By implementing HtmLayout into our legacy products, we are able to continue rendering the same UI while making a minimum of changes to the XSLT. Any discrepancy in the usability is minimum and unnoticed by our client base.

HtmLayout is straight forward in its implementation and provides a number of valuable advanced capabilities. Most of the standard HTML and CSS code is portable from IE to HtmLayout. With ‘Behaviors’, it is easy to link the HTML events to code in Visual Basic. Behaviors are also used to enhance the standard functionality of HtmLayout.

HtmLayout is bringing stability into the User Interface as it is not depending on Microsoft Internet Explorer model. HtmLayout ensures User Interface consistency throughout our products.

Why HtmLayout:
• Ease of use
• Ease of migration from IE
• Support standard HTML and CSS
• Minimum investment in conversion of HTML
• Implementation of custom ‘behaviors’
• No scripting (vbscript/javascript), fewer technologies involved = fewer defects
• Simplify pages, thus reducing risk of defects
• Robust handling of messages between HTML and VB
• Responsive support team

« Previous Page — Next Page »