Saikat,

You are unfortunately facing a known issue with IE11 and flex layout - While flex layouts are the recommended type of layouts when building a new application, it works on all the modern browsers but has a couple of limitations in IE11.

IE11 has some issue rendering correctly flex layout when there is a <table> tag somewhere in your DOM that is parent of your flex layout. see https://github.com/philipwalton/flexbugs/issues/179.

There are 2 typical ways that you can have the 'table' tag and you can easily fix them by following the steps below:

1/ The harness container is adding a table tag

Your harness is likely using a custom header or the old default format - this configuration usually introduced a table tag at the top of your harness. A new option called 'No Markup' was added as a container format for the container. Open your harness rule, open the property panel for the container and select the 'no markup' format. This settings will get rid of any extra markup that was created by the harness

2/ The action area is adding a table tag

If your layout is inside the case area of a flow, it is possible that you are using an old action area - check if your perform harness is using the pyCaseActionArea and if the section includes pzActionAreaContent – The section pzActionAreaContent uses a free form layout that generates a table markup. 

To fix the issue, override pyCaseActionArea in your application, remove the section include pzActionAreaContent and include directly the FlowAction_HTMLSimple.

If you build a new application in Pega 7.2.2 based on UI-Kit 8, the pyCaseActionArea and all the harnesses have been upgraded with these 2 changes. If you are upgrading an older application and want to take advantage of flex layouts, you need to make sure that your DOM does not have any lingering 'table' tags.

Hope it helps !

Nikhil,

The data model of the skin rule form is very similar to the earlier implementation and uses some of the same object classes like Embed-Skin-Font used in the old branding wizard but the skin rule form is now a full fledge assembled rule form and you no longer have access to the actual data model like most of the other rule forms. An HTML rule like the BrandingWorkformTemplate was difficult to maintain and was too much tightly coupled to the data model making it difficult to change and improve the model from release to release.

While you have no longer access to individual properties, we are adding the capabilities in the upcoming release to refer to mixin settings directly in your override CSS file similar to some well known pre/post CSS processors like SASS or LESS. The benefit is that you can define and manage all your colors, text settings and others using the skin rule and then retrieve the value directly in the override CSS. This feature should reduce some of the maintenance related to override CSS files.

As far as your other questions are concerned:

1/ Extending flex support to the skin rule is something that we are thinking about but is challenging to expose as a set of settings so that any developers can understand and leverage them. flex-direction is actually what is set when you switch between an inline vs inline-grid dynamic layout. flex-grow is better applied to the cell of the dynamic layout. In all recent Pega apps that I have worked on, I have taken advantage of flex using override CSS files. You can for example define this very simple helper class called 'pz-flex-grow-1' that you can set on the ReadOnly/ReadWrite style of a control to make it take all the available space 

.pz-flex-grow-1 {
  flex:1;
}

2/ Currently the skin generates CSS for both inline-block and flex box so that you can mix the 2 types of dynamic layouts in your application. Once most of the applications are using flex box layouts, we will certainly offer an option in the skin to only generate the CSS for flex layout - That will reduce the amount of CSS generated. Due to IE11 limitations (see above), there is still some workaround needed when upgrading all the layouts to flex.

We are also thinking about providing more tools in the skin to refactor your existing sections. The tool could allow you to rename a format for example or convert your layouts from inline-grid to flex. There is actually an activity currently available in Pega 7.2.2 that allows you to upgrade all the sections in a ruleset and version to flex automatically - the activity is called 'pzFindSections' and you can pass the activity name 'pzConvertInlineBlockToFlex' as parameter. This activity was used to upgrade all the sections in ui-kit 8 to use flex box layouts.

3/ A typical difference between a mobile and desktop app is that the font size is larger on mobile and the size of the control have an increased height. This is not something that can be configured in the skin rule form right now. The recommendation is to implement these changes using override CSS - the pyEndUSer skin in UI-Kit as a file called py-responsive-overrides that implements some of this functionality - I recommend to review this file and add an additional CSS file attached to your skin to add on to this default implementation

4/ when building a new application,I would recommended including the latest version of ui-kit in your stack and have a skin that inherits from pyEndUser. You should not override the CSS files included in pyEndUser in your own application otherwise it will make it difficult to upgrade. All the strategic applications are upgrading to the latest version of ui-kit on every release and it is usually a relatively easy process. If you already have an application running on an older version of UI-Kit, you should be able to upgrade to a more recent version of Pega 7 while keeping the same version of  UI-Kit. Upgrading to a new version of ui-kit does not guarantee backward compatibility. This is why ui-kit is always incremented as a major version: we want to provide the best user experience when creating a new application with each release and as such the CSS files and design can be very different from one UI-Kit version to the other.

If you want to specialize the portal to look different on a mobile device vs a tablet vs desktop, you can circumstance the portal harness. In the example below, you can render a specific portal for a mobile device. You can also use a different property based on the user agent using pxRequestor.pyUserAgent

This is a good option if the design of the portal is very different between mobile vs desktop (adaptive design). Since you can only have one type of screen layout format like header/left/main, this approach works if your screen layout type is of different type for each circumstanced harness

If you want something that is more configurable, with potentially a different height depending on the mobile device device width and length, the best approach is to include an override CSS file in your skin to handle the height changes using something like this:

/* change height of the header for iPhone 6 to 100px */
@media only screen and (max-device-width: 667px)  and (-webkit-device-pixel-ratio: 2) {

  html.iOS .screen-layout > .screen-layout-region-header {
     height:100px;
  }   
  html.iOS .screen-layout > .screen-layout-region-main-middle {
     top:100px;
  }   
}

by default, there are top level classes in the html tag to identify a phone/tablet vs desktop and the operating system (iOS vs android) 

The UI Gallery is using a different skin - if you open the harness pyGalleryPage, you will see that it includes an additional CSS file called workform_pyuigalleryskin. This was done so that the look and feel of the UI Gallery is not dependent of your application skin. A lot of developers like using the UI gallery as a starting point; the best practice is to open one of the section example and copy the layout that you want to use directly into your application.

The other option is to use a feature that is not very well known: In your skin, click on the 'Actions' button and select Launch -> UI Gallery Preview. It will use your skin to preview the ui gallery. You can preview any portal or harness using your selected skin in this actions menu

In this example, I have modified the color of the strong button in pyEndUser. The UI gallery reflects the new settings.

Don't hesitate to share your feedback on how we could improve the ui gallery and make it even more useful for all developers.

Pradeep,

from the screenshot, it seems that you are trying to add an underline under the input field, similar to some of the Google material design. There is a good tutorial on how to achieve similar effect (and much more) using css3 in the following document: https://scotch.io/tutorials/google-material-design-input-boxes-in-css3

Without using custom controls and staying as much as possible in the model, I would use an helper class on the input field that you want to style:

1/ add the helper class 'input-underline' in the RO/RW class of your input control

2/ add the following helper class definition in an override CSS file attached to your skin:

.input-underline > .content-inner > .field-item {
  position:relative;
}
.input-underline > .content-inner > .field-item > span > input {
  border:none;
}
.input-underline > .content-inner > .field-item > span:after {
  content:'';
  height:2px;
  width:100%;
  bottom:-4px;
  left:0;
  position:absolute;
  background: #5264AE;
}

your input field will look like this

the trick is to use the span tag that wraps the input tag and position a relative element using the pseudo element :after to generate the bottom highlight

Hope it helps.