-
Posts
-
Hi, I ran into a problem styling form fields.
Your CSS specifies the styling of fields by using the #top ID. (base.css – from line 186)
Since you use the #top ID, it is more targeted than using classes. This causes problems with plugins that generate forms, since they only add a class to their form fields. Their rules are thus overwritten by the enfold standard rules, since IDs take priority over classes.This is a real pain, since instead of allowing the plugins to use their own styling, I have to get that styling, and add it to my custom css file using !important.
I don’t even know why you need to use the #top ID with your CSS for forms, you don’t use it with any other elements.
Can you just remove #top from your stylesheet? Your rules would still have effect, but could easily be overwritten if needed.
Thanks,
TomHey Tom,
You don’t have to use the #top element to target anything, any element can be targeted without that. Do you have anything in specific we can look at? Also, I didn’t know that there is a hierarchy when it comes to ID’s and classes, do you have any documentation explaining that?
Best regards,
RikardHi,
Sample: If you look at the popovers that appear on this page, you’ll see that the email fields of the form are not formatted. With the browser’s developer tools, you can see that Enfold’s CSS is overwriting the form’s styling. It’s doing this because of what I explained in the original post, the #top ID is overwriting the class styling.
https://www.coinerie.com/hello1/ID and class hierarchy is basic CSS. Here is a page.
Best,
TomHi,
Actually if you ask the plugin creator how to load the styles of the form last, that would solve your issue.
It happens 1 out of 100, some plugins to have the same classes, or IDS.
When following Web Standards, that can be something that can happen, yes.Best regards,
BasilisWell Basilis the web is full of those specificity calculators and explanations about that:
https://css-tricks.com/specifics-on-css-specificity/see here a calculator: https://specificity.keegan.st/
Interesting thing: the :not pseudo class does not count on that.
@Basilis
Hi, I think you misunderstood.
The problem is CSS specificity. IDs are ranked higher than Classes, plain and simple. Since you have the #top ID set in your main CSS file for html forms, simple classes can’t be used to control those elements any more. Regardless of the order which they are loaded. IDs are more specific than classes.
All you would need to do is remove the #top selector from your CSS file, and that would resolve all plugin conflicts. I don’t see why you would need it anyhow, you don’t use it for any other html element, other than forms.
Do you understand the problem?
Best,
TomHi,
All you would need to do is remove the #top selector from your CSS file, and that would resolve all plugin conflicts. I don’t see why you would need it anyhow, you don’t use it for any other html element, other than forms.
I’m sorry but we can’t remove the selector because it is already declared in the theme’s css and js files. Removing the id will require major modification of the stylesheets and scripts. It is also use in the “scroll to top” button. What is the plugin that you’re using? You can do a “find and replace” in any IDE to prepend the #top selector before the form fields’ selector.
Best regards,
IsmaelHi, what I meant was removing the #top selector from just the styling part of forms in the base.css file. Not from your entire theme :-)
So in base.css from line 183:/* #Forms ================================================== */ #top form { margin-bottom: 20px; } #top fieldset { margin-bottom: 20px; } #top .input-text, #top input[type="text"], #top input[type="input"], #top input[type="password"], #top input[type="email"], #top input[type="number"], #top input[type="url"], #top input[type="tel"], #top input[type="search"], #top textarea, #top select { -webkit-appearance: none; border: 1px solid #e1e1e1; padding: 8px 6px; outline: none; font: 1em "HelveticaNeue", "Helvetica Neue", Helvetica, Arial, sans-serif; color: #777; margin: 0; width: 100%; display: block; margin-bottom: 20px; background: #fff; border-radius: 0px; } #top input[type="text"]:focus, #top input[type="password"]:focus, #top input[type="email"]:focus, #top input[type="number"]:focus, #top input[type="url"]:focus, #top input[type="tel"]:focus, #top input[type="search"]:focus, #top textarea:focus { box-shadow: 0px 0px 2px 0px rgba(0,0,0,0.2); color: #555; } #top textarea { min-height: 60px; line-height:1.5em;} #top label{ font-weight: bold; font-size: 0.92em; } #top legend { display: block; font-weight: normal; font-size: 1.2em; } #top select { width: 100%; } #top input[type="checkbox"] { display: inline; } #top label span, #top legend span { font-weight: normal; font-size: 13px; color: #444; } #top textarea{width:100%;} #top #wrap_all .valid .text_input, #top #wrap_all .valid .text_area, #top #wrap_all .valid .select{border:1px solid #9AA600;} /*#70A41B*/ #top #wrap_all .error .text_input, #top #wrap_all .error .text_area, #top #wrap_all .error .select{border:1px solid #DF653E;} #top #wrap_all .ajax_alert .text_input, #top #wrap_all .ajax_alert .text_area, #top #wrap_all .ajax_alert .select{border:1px solid #ffb628;} #top #wrap_all .valid .input_checkbox_label{color:#9AA600;} #top #wrap_all .error .input_checkbox_label{color:#DF653E;}Your styling would work exactly the same way without the #top selector, but would not conflict with plugins using classes to add styling to forms.
I know there are workarounds, but it just seems pointless to have to do something when wouldn’t be necessary.
Best,
Tom
- You must be logged in to reply to this topic.