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

Provide styling attribute to specify which HTML element will have the common styles classes added

    Details

      Description

      Extension of https://issues.liferay.com/browse/LPS-147783

      Since in the development of this previous story, the point 3 of the steps to perform was finally not included, this story aims to cover that point.

      In order to provide full flexibility for developers to decide where common styles will affect, we intend to create a "styling attribute" that will be used by fragment developers to indicate where the new classes that apply the common styles will be added. 
      The same way as "lfr-editable" indicates which fields are mapped, this new styling attribute will allow developers to indicate which HTML element is "stylable". 

      Requirements

      • have a new "data-lfr-styles" (or whatever we want to call it) attribute available, that can be added to the Fragment HTML, and when the fragment is generated, the automatically-generated classes to provide common styles are added right to the indicated HTML element in which the new attribute was inserted.
      • If a fragment does not contain this new data-lfr-styles attribute, the styling classes will be added to the surrounding div (just like it is done now).
      • Validate that a fragment CANNOT HAVE more than one styling attribute included.
      • (to Product team) Provide the appropriate documentation to developers, so that they can leverage this new capability
      • Refactor OOTB Fragments to add this attribute and gain consistency in styling.

       

      Design

      Not needed

      Acceptance Criteria

      • Given a fragment I am developing
      • when I add a "data-lfr-styles" attribute (or equivalent name) to any internal HTML element of the fragment, save the fragment and use it in a content page,
      • then the automatically generated classes to add common styles are generated where the attribute was inserted
      • Given a fragment I am developing
      • if there is no "data-lfr-styles" attribute (or equivalent name) present,
      • then the automatically generated classes to add common styles are generated in the outter div that surrounds the fragment.
      • Given a fragment I am developing, that already has a "data-lfr-styles" attribute present in any of the containing HTML elements
      • when I add a new "data-lfr-styles" attribute to another HTML element of the Fragment and try to save it,
      • then I receive an error message that says: "data-lfr-styles attribute can be used only once on the same 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?
      The Fragments creator cannot add a fragment with duplicated styles attribute HIGH Manual No Yes Yes
      When a new fragment has no styles attribute it is automatically-generated a div surrounding the fragment HIGH Manual No No Yes
      The Fragments creator can add a new fragment with a styles attribute HIGH Manual No Yes Yes
      View fragment styles are correctly displayed within a fragment that contains a value inside styles attribute HIGH Manual No No Yes

        Attachments

          Issue Links

            Activity

              People

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

                Dates

                Created:
                Updated:
                Resolved:

                  Packages

                  Version Package
                  Master