0
222
ViewsAdding inline style to components
I am trying update some components in AEM to allow inline styles. For example I have a component by the name of Row-Dual Column and I am lost on how to allow inline style for this component. Row-Dual Column html consist of:
The code in text:
<table class="ac_dualColumn" border="0" cellpadding="0" cellspacing="0" style="border-collapse: collapse; width: 100% !important;">
<tr>
<td valign="top" id="ac-column-left-cell" class="ac-content-cell ac-column-cell" width="50%" style="width: 50%; padding-right: 10px;">
<div style="margin-bottom: 20px;">
<div data-sly-resource="${'parLeft' @ resourceType='mcm/campaign/components/parsys'}" data-sly-unwrap></div>
</div>
</td>
<td>
<td valign="top" id="ac-column-right-cell" class="ac-content-cell ac-column-cell" width="50%" style="width: 50%; padding-left: 10px;">
<div style="margin-bottom: 20px;">
<div data-sly-resource="${'parRight' @ resourceType='mcm/campaign/components/parsys'}" data-sly-unwrap></div>
</div>
</td>
</tr>
</table>
If this problem is too much to type I would love to communicate through phone or email. Thank You
2 answers
Answer question0
This is how I would approach it:
Case-1: If I only need certain styles authored
<div class="custom-inline-styles" style="width='${properties.width @context='styleToken'}'; display='${properties.display @context='styleToken'}'>
and so on..
Properties is how we access authored values in sightly.
Case-2: If I need the whole inline style authored
<div class="custom-inline-styles" style="${properties.inlineStyleString @context='styleString'}"
0
Can you provide more details about the component? Where would the style definitions come from? What does the jcr of the component dialog look like? As mentioned in an earlier answer, accessing the "inlineStyle" (or whatever it might be called) property of your component would look like this:
<div style="${properties.inlineStyle @ context='styleString'}">content content</div>
However, I would almost always advise against inline styles unless absolutely necessary. They setup a condition that is prone to conflicts, especially if non-technical authors are defining the styles added to the component. Instead, I would define a set of layout options in the component (eg, ./backgroundColor: 'background red, background blue, background green') that are associated with classNames you can apply to the markup and control with a CSS Stylesheet. That way you won't get accidental style overrides that require !important rules and plenty of headaches.
Component:
./backgroundColor -- granite/ui/components/coral/foundation/form/select
- items
- ./backgroundRed -- text: 'Background Red'; value: 'background-red'
- ./backgroundBlue -- text: 'Background Blue'; value: 'background-blue'
- ./backgroundGreen -- text: 'Background Green'; value: 'background-green'
HTL:
<div class="${properties.backgroundColor}">content content content</div>
CSS:
.background-red { background-color: red; }
.background-blue { background-color: blue; }
.background-green { background-color: green; }