How to avoid overwriting CSS styles in Widgets
When creating a widget with HTML content to add to a course homepage, there is the ability, when "Render in IFrame" is selected, to add all three kinds of CSS styles—inline, internal, and external.
However,
the internal and external styles do not behave as expected because they are not added to the <head> of the iframe, but rather a <div> within the <body> of the iframe. Moreover, because the widget container pulls in two stylesheets from D2L—namely `bsi.css` and `reset.css`—several styles that we define externally or internally do not appear as expected.
Is this expected behavior for iframe-style widgets? Is there an option for our internal and external styles to be defined in the <head> of the iframe to avoid being overwritten by the D2L styles?
Screenshots:
The first screenshot shows creating/editing a widget with a checkbox to “Render in IFrame”.
The second screenshot is an image of the pop up that is displayed when selecting “Customize Widget Style”. There are no options here to add/define CSS styles.
The third screenshot shows the browser inspector with a link highlighted. Note that styles from `bis.css` and `reset.css` are applied before, and therefore overwrite, the styles from our external stylesheet `catalyst.css`.
The fourth screenshot is a closeup of one problem because of the overwritten styles—a link in the :hover state has two underlines: one from D2L (`color: #004489; text-decoration: underline`) and one from our stylesheet (`border-bottom: 1px solid #006FBF`).
Edit: included the screenshots inline in this post rather than as attachments.
Answers
-
@Matthew.T.222 I've been able to use HTML/CSS in custom widgets just by copying and pasting the entire HTML code from our template pages and checking the Render in IFrame box. Everything has been working so far.
-
Hi @Jennifer.W.973!
HTML in general works in the custom widgets, and when checking "Render in IFrame" as I mentioned in my initial post, I'm able to use all three styles of CSS—inline, internal, and external. The issue that I'm describing is that internal and external styles do not appear to render in the order I would expect and are overwritten by two stylesheets from D2L—
bis.cssandreset.css. I expect this is because while the widget allows you to provide valid HTML (e.g.<!doctype html><html lang="en">when rendered, the styles provided in the
<head>…<head>tag are moved to a<div>tag that D2L creates, therefore not interpreting the styles as expected.To see an example of why this is a problem, screenshot 4 shows a link with two sets of styles added (ours and D2Ls) which results in two underlines. Normally (including in any HTML content pages), our CSS takes precedence over D2Ls, but in custom widgets they are not.
-
@Matthew.T.222 I see the div with class d2l-htmlblock that contains the entire HTML code for the widget. I'm not sure that there is a way to change the way widgets are rendered. You might just need to grab whatever code is taking precedence and add it to your own stylesheet with the necessary changes.
-
@Jennifer.W.973 Styles in our external stylesheets do come through, but because they are not included in the <head> it seems that D2L's stylesheets
bsi.cssorreset.cssare taking precedence. Screenshot 03 demonstrates this where we have defined aa:hoverstyle in ourcatalyst.cssstylesheet, but I have not found a way to ensure this takes precedence over thebsi.cssstyles that D2L injects.
-
I am so happy for this post! I had no idea we could use the HTML templates in widgets. Oh, happy day.😍
-
Hello @Matthew.T.222,
May I suggest you open a support case please, for us to further look into this issue.
Thank you,
Rusha
