PLEASE NOTE: These forums are no longer utilized and are provided as an archive for informational purposes only. All support issues will be handled via email using our support ticket system. For more detailed information on this change, please see this blog post.

forms.css has tons of missing semicolons at the end of declarations

  1. Almost every declaration block is missing at least one...

    Thus when you try to style these in your own stylesheet it often doesn't work.

    Can we get an update please?

    Posted 11 years ago on Tuesday November 6, 2012 | Permalink
  2. The last attribute (or property:value pair) in a CSS selector doesn't require a semi-colon. It's optional. It's been left off on purpose. I don't know what you mean by "try to style these in your own stylesheet".. if you declare a new selector for an element properly there shouldn't be an issue.

    I'll be happy to consider a change in the future, but there's no reason the current forms.css file shouldn't work or actually NEEDS to be changed due to the format.

    Posted 11 years ago on Wednesday November 7, 2012 | Permalink
  3. Cool thanks for the update. I was not aware that the semicolon was not needed on the last element.

    That said, shouldn't the theme stylesheet take precedence over the plugin stylesheets? In addition, shouldn't a more specific css declaration take precedence as well?

    Posted 11 years ago on Wednesday November 7, 2012 | Permalink
  4. The forms are designed to inherit most of their styling (colors, font styles, borders, backgrounds, etc) from the parent theme so yes, for some things that would be true. For a generic form application like this, other things like margins, field widths, spacing and things like that have to be defined by the plugin so there is some kind of "out of the box" workable styling.

    If you don't like the default plugin styles there is also an option in the plugin settings to disable the CSS output. That pretty much gives you a blank canvas and you can style the forms any way you see fit.

    Sure, CSS specificity is always the way to go if you want to override a rule. More specific CSS selectors will take precedence. You can check out the CSS targeting examples listed on the page below for suggested ways to target and manipulate the different form elements.

    http://www.gravityhelp.com/documentation/page/CSS_Targeting_Samples

    Now, if you're having a specific issue that you can't seem to whip, we would be happy to work with you to figure it out. Just let us know.

    Posted 11 years ago on Wednesday November 7, 2012 | Permalink