Kuali Rice Development
  1. Kuali Rice Development
  2. KULRICE-7469

UI Framework - CSS class hierarchy - support for multiple themes -cleanup

    Details

    • Similar issues:
      KULRICE-8879Themeing Support
      KULRICE-6754Document the UI Framework - Keyboard Support
      KULRICE-6840UIF Framework - Framework Improvements (Template Cleanup)
      KULRICE-7474CLONE - UIF Framework - Framework Improvements (Template Cleanup)
      KULRICE-6752UI Framework - Keyboard Support
      KULRICE-6753UI Framework - Keyboard Support
      KULRICE-6671UI Framework - Framework code improvements
      KULRICE-7477Lightbox - Div structure / CSS class support for lightbox
      KULRICE-6740Document the UI Framework - Modal Dialog (the back-end to support the Rich Lightbox, Question Framework)
      KULRICE-7300Document the UI Framework - Modal Dialog (the front-end to support the Rich Lightbox, Question Framework)
    • Epic Link:
    • Rice Module:
      KRAD
    • Application Requirement:
      KS
    • KAI Review Status:
      Not Required
    • KTI Review Status:
      Not Required

      Description

      1) Styles should be defined in the theme "branches", not in the bean/class' parent/base "root" that then applies across all themes. KRAD support for themes (and supply of at least 2 that applications can choose from/inherit) is important, demonstrating how easy it is for applications and institutions to customize through KRAD.

      For example, in 2.2, the KNS L&F has inherited various font and other visual treatments from the KS L&F specs, whereas in 2.0, these were at the theme level (respecting the KNS L&F choices). These should be corrected to use the KNS L&F or the KS L&F, as appropriate, depending on the selected theme.

      2) Both themes should use px for margins and padding, but not for fonts (use ems or % for fonts). There are several elements that have been changed in 2.2 to use px for fonts. These should be corrected (for example, in all headings for both themes).

      3) Both themes should include a fall-back list of font families for every element (there should be no element that lists only one font family. For example, list "Helvetica, Arial, sans-serif" or "Times New Roman, Georgia, serif" instead of "Helvetica" or "Times New Roman". Without a fall-back list, there can be problems with font size inheritance when people use some methods to enlarge font sizing.

      See attachment for example where we have only one font defined for H2s in the portal, whereas all the other UI text elements include a fall-back list.

        Issue Links

          Activity

          Hide
          Jessica Coltrin (Inactive) added a comment -

          moving non-blocker and non-critical m4 Jiras to 2.2-backlog

          Show
          Jessica Coltrin (Inactive) added a comment - moving non-blocker and non-critical m4 Jiras to 2.2-backlog
          Hide
          Tom Clark added a comment - - edited

          resolving this, based on completion of subtasks

          Show
          Tom Clark added a comment - - edited resolving this, based on completion of subtasks

            People

            • Assignee:
              Tom Clark
              Reporter:
              William Washington (Inactive)
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Structure Helper Panel