Overwiew

We are going to re-develop RF components layouts.  And first point of  discussion are restrictions which we need to use for layout making. Only  after this we can get full picture of way of layout development.

Markups Restrictions

Which restrictions we need to use?

I can divide them into restrictions for components developers and  restrictions for components users:

Restrictions for components developers:

1) It is necessary to delete IE6 from list of supported browsers. We'll have  supported browsers:

• IE7 and higher
• FF3x and higher
• Safari 3.3 and higher
• Opera 9.6 and higher
• Chrome.

2) It is necessary to reject support of quirks mode (doctype) because "IE5  mode renders content as if it were displayed by Internet Explorer 7's quirks  mode, which is very similar to the way content was displayed in Internet  Explorer 5" (MSDN) and we'll not support IE6 and lower.

3) Earlier we had some problem with use of value of component hight (and  width) in percents. This question should be discussed separately for each  component. Generally these parameters should be deleted from component  attributes and can be used by means of styleclasses.

4) We need to reject use of selectors when developing the components, that  the user could use just a css classes for component restyling.

e.g. next css declarations should not be used in components css

.rich-component-header-cell > div{
...
}

5) It is necessary to shorten a length of prefixes of css classes names

RichFaces 4.0 Markups And Skinning: Semantic Markup Structure Restrictions that will be effected by a restricted semantic markup structure.

Restrictions for components users:

1) It is necessary to fix font size. This is necessary to use a DIV for  components layout because we need to have the equal hight in different  elements WITHOUT using a hight parameter (e.g. tabs). Now in tabs a table as  a layout, because next cells can have the same height without mathematic  script (it is very simple way). I've made example of problems with use of  multiline text and different contents heights in semantic layout without a  mathematics script for element hight calculation. In these cases for problem  solving we need to use 1 of 2 ways: first - we need to reject use to  different heights in different contents, second - user need to set heights  for each layout element (e.g. for tabs)(see attached file tabPanel_problem)

2) It is necessary to forbid use of text multiline (or use of arbitrary  contents) in components titles (e.g. panel header) and in tabs -  the same  situation as in previous case (see same attached file)

What will be in result?

As result of use of these restrictions we can get more simple and easy  semantic layouts and avoid the some earlier problems (e.g. in particular  problems with calculation of elements size).

@Ilya comment, So could we decide at component level(during planning concrete component features/design) what we prefer - to simplify markup for the component or to provide more deep customization (e.g. required by the community) for concrete component but has more complex layout/calculations or even drop semantic html principles?

Skinning

Parameters Set

     Results of the discussion with Lex:

• We still want add a few new ones for tables in order the tablesnot depends on panels color scheme. This dependence currently not allows to use tables in the panels without additional css definitions because of similar headers colors. And some projects where we saw tables in panels by design - used these css redefinitions. So new parameters proposed to be:
  • tableHeaderBackgroundColor
  • tableSubheaderBackgroundColor
• The reasons why we can't reduce number of parameters using calculations:
  • dark and light skins requires different calculation algorithms
  • smooth and inverse-coloured skins again requires different equations.

So we already tried to move this way but these reasons prevented us in the past from calculations usage. We just was not able to create some kind of skin when calculations was used.

• Why we can't remove specific skin parameters:
  • some skin parameters like tooltip color and calendar selected date color for example are unique for the components and not reused anywhere more. But these parameters should be changed with skin and we can't just move them to css.

Test of skinning (guide for testers)

For making a test of components skinning, you need to make next iteration:

1. It's necessary to prepare 2 test skins. Each parametre value of first skin must have negative value in second skin (for example red - green, blue - yellow, white - black)
2. Implement these skins in your test application
3. Open a testing component
4. Several times switch your skins and observe behavior of component elements colors - all visual elements of component must change their color (texts, borders, backgrounds)
5. If all elements will change their colors - then skinning was made correct. If any elements will save color - it's a BUG

Naming review

Open issue:

We talked about possible naming review. So we have to decide is this taks is a requirement and for which version. This task requires review all the components where some parameter applied. So the many effortsand time required for the task.