CSS Hacks? « Gravity Support Forums

Gravity Support Forums » Plugin Support » Gravity Forms

wendy
Member

I was very excited to see the functionality of the Gforms plugin and plunked down the coin for the developer option, but after downloading and checking the CSS validation errors (there are several related to the very small sample form I created), I was a bit disappointed. How can I be certain that the CSS is "future" proof?
Here is the sample form:

http://www.mfai.zubird.com/contact-us/

Here are the CSS errors from the validator:

http://jigsaw.w3.org/css-validator/validator?profile=css3&warning=0&uri=http%3A%2F%2Fwww.mfai.zubird.com%2Fcontact-us%2F

There are a lot of parse errors and the validator apparently reads "\9" as "00009" in any line that has (the IE hack?)

Also, can you clarify what some of these hacks are doing? I have never seen some before. Is it common practice to put comments within the CSS brackets? I don't believe I've seen that either.

Here are a few lines that really look foreign to me:

{content:none; # /* for other browsers */} --- What is with the pound sign (#) and no additional semi-colon (;)?

{display:inline-block\9; margin: 2px 0 0 6px\9} --- I realize the backslashes are hacks for IE, any specific version or all of them? And what does this rule accomplish? My guess is that all browsers except for IE read and render what comes before the backslash (\) and that IE ignores it. Is this correct?

Thank you,

Wendy
P.S. Sorry if posted in the wrong area. I am definitely a noob in the forums.

Posted 13 years ago on Friday December 17, 2010 | Permalink
urmedia
Member
Heya Wendy -I'm not a dev for GF, I'm more a pain in their..you know. But...

Validators currently don't validate CSS 3 (most don't.) This is what a lot of those errors are. example:

-webkit-box-shadow
So they will always show up as an error. While not exactly "future proof" they are modern tags used for next generation web development and excepted by every browser out there except of the hated internet explorer and one other of insignificance I don't recall.

The '#' represents an ID selector. For example:
```
.class {display:none;}
#ID {display:inline}
```
While I'm not going to explain CSS rules and guides to you, that is what that is all about -a way to reference something. That's the basics of that..but there is more:

The # is a hack that makes non-IE browsers ignore the line

Now, the '\' is a bit different. It's basically like playing hide and seek with browsers.
```
width: 600px;
 w/idth: 600px;
```
Internet will recognize the first width, but ignore the second as it doesn't recognize anything with the '\'. IE is not a compliant browser with internet standards and likely never will be.

Compliant browsers will use the second width because it understands the '\'..but more then that, it appears second in the order of operations. CSS reads from top to bottom, remember.

Something to note, however, is that the backslash will never validate in your CSS.
Posted 13 years ago on Friday December 17, 2010 | Permalink
Kevin Flahaut
Administrator

This details a few of the browser specific styles/hacks.

http://www.webmonkey.com/2010/02/browser-specific_css_hacks/

If you're concerned about validating the CSS and "future proofing" it, you can go to the settings page and set the "Output CSS" option to No. Then you can copy the contents of the forms.css to your theme stylesheet and re-tool everything to your liking. If you do it that way though, you'll have to keep up with anything new that's added in subsequent versions.

Something you may want to take advantage of is adding a browser-specific body class to your theme then using CSS inheritance to add specific CSS rules for those browsers. Here's a tutorial that shows how to do that.

http://www.nathanrice.net/blog/browser-detection-and-the-body_class-function/

I wish that was part of the WordPress core as that would make it a lot easier targeting the different browsers and would keep the CSS a lot cleaner.

Posted 13 years ago on Friday December 17, 2010 | Permalink
wendy
Member

Thanks for your reply. I believe the reference to-webkit-box-shadowin my CSS is related to the CSS Pie I was recently playing around with and I am not concerned with that and I am aware there is some CSS 3 in there. I am only using it to test a few background rounded corner boxes, no big deal there if it breaks down the road. However, forms are a bit more important to get right. I guess what I would like to see is that they remove the hacks or find a more suitable way to target other browsers; ways that do not require hacks. I am not fond of the idea of re-doing my custom CSS every time a new version comes out as this defeats the purpose of the plugin. And besides, I paid for the solution. While I didn't expect it to be completely bug free, especially given it's newness, I did expect that it would be clean and valid code.

I found the articles interesting, especially about the global variables. I generally use conditional statements to target IE though. As for Gforms, I totally agree with the conclusion of the Webmonkey article which states in its conclusion "CSS hacks are just that — hacks. In general you should make every effort to avoid using them." I wonder if the developers at Gforms have done this??

I guess I will have to ponder whether I want to wait it out or find a different solution.

Thanks again.

Posted 13 years ago on Friday December 17, 2010 | Permalink
Kevin Flahaut
Administrator

I'm confused why you think invalid CSS is fine in some places and not in others. I think if you're going to be a stickler about it, then it should be consistent across the entire site.

Making sure that the forms work and layout properly are more important than strict CSS validation in my opinion. Of course we try to validate everything first, but still have had to introduce these hacks to overcome various rendering inconsistencies in the browsers.

CSS validation is simply a recommended standard and not a rule. Invalid CSS doesn't equate with broken CSS.

I would agree HTML validation is important because it's directly related to content. Screen readers or other accessibility devices rely on standardized, well-structured markup and content to work properly. CSS rules exist purely for visual formatting and layout. If the CSS formatting works as intended in as many browsers as possible, I think it's done it's job well no matter if it validates to the recommendation or not.

That said, if we can eventually find a way to validate the CSS fully and still have everything work properly in these browsers, be assured that we will.

Again, the whole "output CSS" option exists to put the developer in complete control of the form CSS formatting if they want. It's an advanced option, but as with any customizations, you have to maintain them. It's no different than customizing a WordPress theme, then having to update as new features are added or others are deprecated. If you don't want to do the extra work, then use the defaults.

Like I said before, if you really find it egregious, then you're free to "roll your own" stylesheet, format it and validate it as you wish.

Posted 13 years ago on Friday December 17, 2010 | Permalink
urmedia
Member

Something very important to keep in mind is that you are using a plugin tailored to the general populace. What you are expecting (from what I am interpreting your posts with) a custom solution specific to your needs.

The reality is that even the top plugins have to be 'worked in' to your development cycle and rarely fits snuggly right out of the box.

There are other wordpress form plugins available, many of which are free. I encourage you to try as many as you can and see if any are a 'perfect' fit for your website, or if you need to modify them to fit.

For example: I may well use GF just for the paypal add-on...yet I will still require making adjustments so it fits my needs. Is it still worth the cost (which is the bottom line question you need be asking) - I believe it is. The trick for me, however, is convincing my client to allow for the extra time required to make those adjustments while still justifying the costs.

My example is a real case. I've paid an insane amount of money over the years for Joomla plugins as well, and rarely do I get it perfect for my site out of the box. There is always something that needs to be changed.

Posted 13 years ago on Friday December 17, 2010 | Permalink
Kevin Flahaut
Administrator

@urmedia makes a good point. I didn't really address that in my previous reply, but it's a good one to make.

Gravity Forms is a generic form solution and as such has to work in lots of varied environments. We try to ensure that the forms work properly and format well in as many browsers, themes and setup scenarios as we can. Even so, it's not a custom solution and to get that kind of integration or personalization, you have to customize it to your specifications.

Not everyone has the same opinions about what is good markup, what needs to validate and many of our users are simply bloggers with no development experience who like that the forms are easy to install, get configured and work for them without a lot of fuss.

Posted 13 years ago on Friday December 17, 2010 | Permalink
wendy
Member
Wow, guys! I am not knocking the technology, just trying to make informed decisions here. I'm sorry if I am not articulating my concerns very well. Let's try this:
1. 1. I really LOVE the functionality of Gforms (especially that the data may be exported), but am concerned about how (or if) it will be maintained by the developers in the future. Gforms seems to be relatively new. I often times look at the plugins in terms of how long they have been around and if the devs are actively updating on a regular basis. Without much history, there is not much to go on. It would help to know if the project developers are committed for the long haul. I read some of the forums and I read the agreement and don't have a real good read on it yet.
2. 2. I can live with some "hacks" and invalid CSS if I understand fully what they are relating to and therefore can make an informed decision about whether or not they will have adverse affects for me or my clients. I was looking for someone to shed a bit of light on some of the CSS. So as not to use up a lot of time, I picked two specific items but in particular, this one:
  {content:none; # /* for other browsers */} The pound sign (#) in that line looks a little lonely (no closing semi-colon?). Getting reasonable answers behind the logic is good to hear from the developers. It helps build trust.
3. 3. Along with the Gforms, I am in the process of playing around with or testing other interesting technologies (as I often do-don't you?), hence the reason that the invalid "webkit" CSS is not a big deal to me right now. I intentionally pointed this out in my earlier post because I anticipated that one might think "well what the heck is with all that other invalid code in there, this chick must be nuts!" :) I did not think it necessary to point out exactly what I intended to do (or not) with other technology as this is a forum about Gforms, and I did not want to waste anyone's time with such matters.
Agian, I realize that you may have better things to do and I really appreciate you trying to help me figure this out. I am not trying to be cheeky, I just need some good answers that I can form intelligent decisions from. I have just stuck my big toe in thus far. I may also be interested in PayPal and MailChimp integration so you may be hearing from me even more, I hope you don't mind.
Posted 13 years ago on Sunday December 19, 2010 | Permalink