Uploaded image for project: 'PUBLIC - Liferay Portal Community Edition'
  1. PUBLIC - Liferay Portal Community Edition
  2. LPS-147783

Refactor styles assignation to Fragments



      Improve - Refactor styles assignation to Fragments for more consistent styling

      Refinement Confluence: https://liferay.atlassian.net/l/c/pbzHkyMs


      Currently we are using HTML style tag (see this document) to add the common styles that are applied in the page editor to a Fragment. 

      In addition to this, this style tag is added to an automatically-created div inside which the Fragment is placed. This creates an issue with expectations since the styles that users expect to be editing in Common Styles do not correspond to the reality (e.g. button background color). Theabove-mntioend document shows examples of this inconsistency.

      Something similar was reported here: https://issues.liferay.com/browse/LPS-134157


      The main scopes for this story are two:

      • Find a way to insert two classes inside the Fragment's HTML:
        • class that is unique for each fragment in the fragments libraries. This class is used to provide default values for common styles.
        • class that is unique for each fragment that is dropped to a content page. This class is used to override default values of common styles with new values selected in the Page Editor, only for the fragment that is dropped already.
      • Be able to add styles to these two classes from the Page Editor using the common styles sidebar.
      • These two classes and the generated CSS must be ready to provide complete styling options for each viewport.
      • Review the hierarchy of styles of a given page to make sure that the styling is applied consistently (see document link below).

      List of Fragment requirements (mid-long term): https://docs.google.com/presentation/d/1efFCSbP3EKKfUNTIxIz1oMf-k_Fuwy-KuLITihepq8w/edit?usp=sharing

      The same document contains a proposal to "inject" classes for common styles in a specific part of a Fragment, instead of using the "outter div" to adopt common styles.

      In addition to these requirements, performance context and possible impact should be considered. Please see this for reference: https://issues.liferay.com/browse/PTR-1664



      Notes from Refinement meeting:

      Steps to perform

      1. Create a class associated to the fragment and move the current inline styles to that class
      2. Valitate that we are able to create and add these classes and CSS in the page head eventually.
      3. Process to create and render a new tag to insert the appropriate common style classes into a given fragment HTML


      What we are NOT facing in this epic:

      • Eliminate surrounding DIVs that are automatically created around a given fragment. 
      • the possibility to map two different HTML elements with common styles inside a given fragment.

      Test Scenarios

      Test Scenarios Test Strategy Kind of test Is it covered by FrontEnd ? (JS-Unit) Is it covered by BackEnd ? (unit or integration) Could it be covered by POSHI?
      View fragment styles are moved into style tag on different modes MEDIUM Manual Yes Yes Yes
      View fragment styles are moved into style tag under different viewports MEDIUM Manual Yes Yes Yes



          Issue Links



              david.gutierrez David Gutiérrez Mesa
              mateo.hermosin Mateo Hermosin
              Engineering Assignee:
              Victor Galan
              Recent user:
              Maria Muriel
              Participants of an Issue:
              Frontend Developer(s) Assigned:
              Victor Galan
              QA Engineer(s) Assigned:
              Oziel Souza
              0 Vote for this issue
              0 Start watching this issue




                  Version Package