Skip to main content

I’m trying to develop a new front page for our Docebo implementation. Our design concept is similar to the one Docebo itself is using for its university.

We want the main body of the page to be divided into two columns.

  • On the left we’ll have a large “headline” and button leading to the course catalog for our flagship product. 
  • On the right, we’ll have a set of floating boxes which contain links to secondary offerings.

Our team has identified three options for implementing this layout. All of these involve using a Docebo widget page.  

The first two options involve using a CSS grid to position the elements. 

  • Option 1: In the composer, create a one-column row, and populate it with a single HTML widget. Use a three-column CSS grid to position the html elements on the screen. 
  • Option 2: In the composer, create a two-column row, and populate it with two HTML widgets. The widget in the left contains the main title and button, which are positioned vertically with CSS. The widget on the right contains the floating boxes, which are positioned with a two-column CSS grid.

The final option avoids using the CSS grid. 

  • Option 3: In the computer, create a two-column row. Place a single HTML widget in the left column, and place multiple HTML widgets in the right column. Use CSS to limit the width of widgets if we want to force multiple boxes to appear on the same “row.” 

What are the pros and cons of these approaches? My main concern is whether Docebo imposes any limits or restrictions on my ability to use a CSS grid on a widget page. Also, are we missing any approaches to accomplishing this? 

 

Thank you in advance. 

 

 

Personally I think your option 2 is the route I would go. This breaks up your styling into smaller pieces so you can troubleshoot easier if something isn’t behaving as you expect, and also if the CSS breaks from an update or another change down the road. You’ll have to do multiple widget ID call outs for box shadows, background color, etc. by using multiple but because there are some limitations to HTML behavior within the platform that option to me seems like the best balance.

I think @JennaM_BA has the right approach.

  • You will find that trying to apply a custom CSS grid can be challenging.
  • Two blocks is they way I would go about it.
  • If you have a choice about an embed from somewhere else, you may find that some of your options may go further.
    • with the caveat of it not being great for a mobile design approach.

 

 

I’m having trouble getting the html widget to accept the display:grid style. 

This is the html I’m pasting into the widget. 

<div style="display:grid; grid-template-columns: 1fr 1fr 1fr;grid-gap: 0.5em; border:1px solid">
        <div>value11</div><div>value12</div><div>value13</div>
        <div>value21</div><div>value22</div><div>value23</div>
</div>

This is what’s left after Docebo strips it when I click save. 

<div>
        <div>value11</div><div>value12</div><div>value13</div>
        <div>value21</div><div>value22</div><div>value23</div>

</div>

Any insight into why the style in the opening div tag are being stripped? 

You can put your HTML in the HTML widget, and your CSS in the “Configure Branding Look” - Custom Styles. When I tested the below it worked:

HTML:

<div class="grid-container">
  <div>value11</div><div>value12</div><div>value13</div>
  <div>value21</div><div>value22</div><div>value23</div>
</div>

CSS:

.grid-container {
  display: grid;
  grid-template-columns: 1fr 1fr 1fr;
  grid-gap: 0.5em;
  border: 1px solid;
}
 

I am by no means an expert at this so there may be other ways to go about it, and you’ll want to make sure your CSS doesn’t impact anywhere else in the platform which is a common testing step for those of us with a good amount of CSS implemented :)

@JennaM_BA - thanks for testing it. 

We rely on a lot of inline CSS on our pages because of anxiety about breaking things elsewhere on the site by using the “Configure Branding and Look” option. 

What does your testing process look like? I have to figure it would involve looking at every custom page in the implementation, right? 

@Lore Totally understand.

Generally I make sure to stay away from targeting anything that might be used elsewhere in the platform and use a custom class so I know it’s unique. Like “grid-containerx” and then in the css .grid-containerx for example. 

I don’t have a standardized testing process, I just try to be mindful of what it is that I’m targeting and then check those elements once I’ve implemented my custom code. So if I’m targeting a button, I’ll go check around the platform to see if any other buttons have been impacted. Same for containers, I’ll check the other widget containers and also some backend admin views to make sure Docebo’s native containers in any spots are not impacted. 

I also always keep versions of my code so I can easily roll it back if needed because I’ve certainly been surprised on what was impacted, especially when I first got started on customizing but after a few years I’m a bit more comfortable with it. 

There are some pretty stellar HTML/CSS folks in the community that might have additional suggestions!

I did end up implementing the grid via the “Configure Branding and Look” window per your approach @JennaM_BA. Thanks for your help!

Reply


Terms & ConditionsCookie settings