...

The effects of this are not too bad: using the per-component classes (see below) you can more easily address styling of html tags used in the components and reset them only where needed. In addition DomUI mostly uses the styleless div and span tags, and just adds styling by giving those a class where needed.

Browser support and tweaks

Image Added

In those times of yore we had browsers and Internet Explorer. The latter was, well, evil. Supporting IE versions below 8 was, well, what Hell probably looks like. Luckily a lot has changed: while IE is still a royal pain in the backside (you won't believe the trouble it has with the simplest stuff still) its rendering, at least, has become way better.

Now if only they would not LIE about the css styles in the developer tools....

For IE we try to do our best to make it work with the jokes implanted in the actual browser versions. We do not usually spend time getting something to work in the IE7 emulation mode in IE 11 or nonsense like that. The best way to get things to Just Work is actually to write them on Chrome or Firefox, and once they are working to try to see what IE makes of it. The other way is more problematic, usually.

Supporting old browsers (well, IE) is just too much work. So we focus on current browsers (meaning those that were current a year ago) to create style sheets, and we remove stuff in style sheets that were needed for Netscape 1.1.

If tweaks are needed please try to use feature discovery, and try not to depend on browser identification.

Older versions of the DomUI style sheets allowed embedded "preprocessing" Javascript, and knew about the browser version they were rendered for. This allowed per-browser version tweaks by conditionally including css. The SCSS version of the sheets do not support this and do not know the browser type.

One fragment per component

...

Shared styles should normally only be used for small things, because sharing too much means that it becomes hard to change components using that style.

Using CSS selectors for the "parts" of a component

More complex components can consists of multiple html tags. For instance the DataTable component contains a table, a tbody, tr's, td's and more. The "root" of the component, as said, must have the CSS base class name which for DataTable is "ui-dt".

A common mistake is to now address the parts in the DataTable with selectors like:

.ui-dt td {...

This finds the td's in the DataTable allright. But the problem is: it also finds all td's of tables that are INSIDE a DataTable cell!

So a style that is supposed to work for a cell of the DataTable only now also applies for something inside such a cell. That is a bad idea.

So the rule is: use only class names in selectors, do not use tags.

Layout rules

One of the biggest design flaws in the earlier DomUI style sheets have to do with layout. So in the new style sheets we attempt to do better, by defining stricter rules. The disadvantage of the new rules are that sometimes more css is needed to style a page, or that extra "layout" components are needed to get something to look good. But the advantage should be less odd layout cases and easier CSS.

Two basic types of components

For the purpose of the discussion we divide the components in two big "groups" related to their layout:

• The "inline" component group. These components use limited width, and often occur together with other components in some "inline" way. Good examples of inline components are Text<T>, LookupInput, CheckBox, ComboLookup and all.
• The "panel" component group. These usually contain other components and show as a block. They can either be complex components like DataTable and Tree, or they can be Panels or Headers.

Inline component rules

Component structure

Inline components should, by default, all behave as an inline-block. So by default it should be possible to place inline components one after another.

All inline components must have a single Node that contains all of the component. This is important because it allows the parts of the component to be addressed relative to its container, so that alignment rules can be applied. So a proper component would be:

<div class='ui-myc'>
  <input type='email' size='12'>
  <button class='ui-myc-btn'><span class='fa-icon' /></button>
</div>

while a bad, bad one (hello DateInput) would be:

<div class='ui-myc'>
  <input type='email' size='12'>
</div>
<button class='ui-myc-btn'><span class='fa-icon' /></button>

The latter was used in some older DomUI components- and styling them is also called the seventh circle of Hell.

Inline component layout

By default an inline component should not have any padding around it. So adding two inline components after each other should show with those components touching each other! It is the responsibility of the container to place components in such a way that groups of components "look nice".

The reason for this rule is that having paddings around the components makes it hard to construct other components from existing ones.

Take the following example:

Say that the SmallButton itself came with 5px padding all around it. The Text<T> component also has this. But a common "supercomponent" is to combine a Text with one or more small buttons, and for that it is customary to have the buttons touching the Text control and each other:

[IMAGE HERE]

To get this done the new component now has to "undo" the styles of the components, then add its own. That is error prone.

This rule also means that adding "naked" components together, without help, will look like shit. This btw has always been the case, but it was just a different kind of the smelly stuff.

Forms

Input components are normally used inside forms. A form in DomUI is not a component but is built by a FormBuilder, a special class which helps with creating a nice layout for a form. The result of a FormBuilder is a set of Nodes with special styles that together with the components should force them to look nice.