Skip Navigation

[Résolu] Styling Bootstrap Elements

This is the technical support forum for Toolset - a suite of plugins for developing WordPress sites without writing PHP.

Everyone can read this forum, but only Toolset clients can post in it. Toolset support works 6 days per week, 19 hours per day.

Marqué : ,

This topic contains 6 réponses, has 2 voix.

Last updated by Brent Urbanski Il y a 3 années et 8 mois.

Assigned support staff: Nigel.

Auteur
Publications
#587842

Hello,

I'm having an issue with the css styling of bootstrap elements. When my web page starts to load, I see the bootstrap element's native styling for a second, then when the page has fully loaded, my styling is applied. I've tested adding the css to my View as well as my theme's style sheet, but I still catch a glimpse of the original bootstrap styling on page load. Is there a way to fix this?

#587963

Nigel
Supporter

Languages: Anglais (English ) Espagnol (Español )

Timezone: Europe/London (GMT+01:00)

Hi Brent

Can you clarify some things for me?

Your theme or Toolset is loading bootstrap.css, yes? (As per your settings at Toolset > Settings.)

And you are adding styles which overrule the Bootstrap styles is that correct?

Can you give me an example of a style you are adding to override Bootstrap, and a link to a page where I can see this happening?

Thanks

#588175
Screen Shot 2017-11-09 at 8.42.02 AM.png
Screen Shot 2017-11-09 at 8.43.28 AM.png

Hello Nigel,

Thanks for your help.

Within the Toolset > Settings I have selected bootstrap 3 which is included with the Beaver Builder theme I'm using. (see attached)

I've added an example of the "well" bootstrap element with css applied in the View. The css does change the well's corners from rounded to square, but I get a glimpse of rounded corners during page load. (see attached)

Unfortunately, I cannot share my dev site with you as I'm working locally. Is there anything else I can do help you troubleshoot the issue w/o direct access?

-Brent

#588270

Nigel
Supporter

Languages: Anglais (English ) Espagnol (Español )

Timezone: Europe/London (GMT+01:00)

Hi Brent

I set up a similar view with a well and modified the styling to see if I could reproduce the issue.

Initially I couldn't see the problem, but I'm working on a local server, so I simulated a slow network connection to have more time to witness the change, and, sure enough, I saw it.

The explanation is as follows (note I set Toolset to load Bootstrap because it doesn't come with the twentyseventeen theme I was testing with, but I'll come back to that):

The Bootstrap stylesheet is enqueued as normal and so is added as a stylesheet link to the page header along with the other stylesheets that are loaded.

Now, the custom CSS you added to the View is printed directly into the page markup, so you would think it would be effective immediately. But, if you inspect the page source you will note that the custom CSS rules are initially added as a DIV in the body. When building the page on the server, by the time the View shortcode is reached in the page content it is too late to add anything to the head. Adding CSS directly to the body is not HTML-compliant. So the slightly contrived solution is to add the CSS inside the DIV in the body, and then use some JavaScript to hoist these CSS rules into the head.

That doesn't happen until the relevant JavaScript file is loaded in the footer, which allows for a certain delay, albeit quite small, before the custom CSS rules are applied.

To prevent this you will need to add the CSS rules to a stylesheet which you then enqueue so that it is loaded in the head. It must still be loaded after Bootstrap, otherwise it wouldn't override it.

Which means enqueuing your stylesheet and specifying Bootstrap as a dependency, as described here: https://developer.wordpress.org/themes/basics/including-css-javascript/

I'm going to assume you can do that, but if you can't, let me know and I'll help.

You need to know the handle of the Bootstrap CSS file.

If Toolset were loading the bootstrap.css file it would be "toolset_bootstrap_styles", but if your theme is loading it you'll need to inspect how the theme enqueues it, or look at the page source. The handle is the link id, minus the "-css" suffix.

#588693
Screen Shot 2017-11-10 at 10.05.36 AM.png

Hello Nigel,

Thank you for your detailed response. It's greatly appreciated.

I'm somewhat familiar with enqueueing, but I could use your guidance, if possible.

Also, I'd like to note that in my page source I see that my child theme's style.css sheet is positioned right after my theme's bootstrap css file (see attachment). I've added the .well css to my child theme css file (it's also in the View), but I still see a lag in the applied styling.

#589042

Nigel
Supporter

Languages: Anglais (English ) Espagnol (Español )

Timezone: Europe/London (GMT+01:00)

Hi Brent

If you add it to your child theme's style.css file you can remove it from the View.

If that file is enqueued shortly after the Bootstrap CSS file then I'm surprised the delay is long enough for you to notice, but if so, I'm not sure there is much you can do about it.

For your styles to override Bootstrap they need to load after it, and there is only one other file which is enqueued between the two that might slow it down.

That file, with the handle 'fl-automator-skin-css', looks to me like it might be a Beaver theme custom CSS file (I don't have any debug info for your site) and you could try moving your custom styles there. Is there a section in the theme options or if you use the Customizr on the front-end to add custom CSS?

Try adding your styles there.

Load the page and double-check that they are included in that file. (In your browser dev tools you can examine the stylesheet. If using Chrome you'll find it under the Application tab, look in the Frames section for the Stylesheets.)

If it has been added to that file then you can remove it from elsewhere.

That's the soonest you can add the styles to override Bootstrap.

#589328

Hi Nigel,

Applying css to my theme's style sheet and removing it from the View appears to have fixed the issue.

Thank you for your help.

-Brent