Danny
Member
Can you build in a toggle for this? Like the CSS one. Or if not a toggle then a filter or something?
Many of our clients insist on XHTML 1.0 Strict code and this is invalid XHTML. Right now the only course of action is to edit the plugin source or not update it past 1.3.11 (but this isn't really a viable solution).
cbg
Member
I upgraded without testing our production website to Gravity Forms v 1.3.12 from v 1.3.11 and now our website styles are broken. I was encouraged to do this upgrade by the statement "We highly recommend you keep your Gravity Forms installs up to date using the Automatic Upgrade".
At least Gravity Forms should have provided a warning about the potential problems caused by new html 5 tags.
Also I want to mention that the behavior differs between browsers; when the page is not xhtml valid each browser produces a slightly different result.
Are there any guidelines on how to deal with the new html 5 tags when Gravity Forms is upgraded? Is there an option to support a rollback to a previous version?
I would appreciate if Gravity Forms provides a solution for the problems introduced by this upgrade.
@cbg please post a link to your form page so we can take a look at it.
@cbg
We are discussing the possibility of making the HTML 5 fields an optional setting.
If you would like to rollback to 1.3.11, you can download it from http://www.gravityhelp.com/downloads/ and replace your current version with it.
Alex, I noticed the older releases are no longer on that page.
Also, I had the same experience with HTML 5 field types in the latest release. Some of my pages no longer validate. For example:
http://www.ilharley.com/about-us/service/service-appointment/
It doesn't hurt anything visually that I can see, it's just no longer valid XHTML. I'd rather not have the field types since I'm not using HTML5 than have invalid XHTML.
Actually, the older versions have been removed from the download page. If you are having issues and need to roll back to an older version for some reason, just send us a note using the contact form and we'll send you the file.
@cbg Carl sent me your URL and I've looked at your form page in multiple browsers and so far the only thing I see is that your submit button text is not being displayed.
In digging a little deeper, I found this is because of a rule in your custom.css file on line 176 where you've declared a negative value for the text-indent and not as a result of any Gravity Forms changes in the last version.
I also didn't see any browser differences or discrepancies on the fields with the new HTML 5 attributes - email, phone, etc. The button itself has no HTML 5 attributes and would be unrelated to this issue.
If you can be more specific about what browser or browsers your seeing discrepancies in and exactly what they are (margins, etc) I'll be happy to look a bit further. So far, I simply can't replicate the issues you've reported.
cbg
Member
Thanks for investigating the issue.
The pages with forms are:
http://www.canopyoutdoor.com.au/
http://www.canopyoutdoor.com.au/contact-us/
http://www.canopyoutdoor.com.au/email-a-friend/
The problem also manifests if the user enters bad data and the from validation fails. The styles displayed with error messages do not work properly anymore.
I did a mistake and I upgraded Gravity Forms directly in production using the automatic upgrade.
My question is: are there any differences between Gravity Forms database schema v 1.3.11 and v 1.3.12? To restore v 1.3.11 is just a matter to replace the files and leave the database alone?
I still can't replicate your issues. I've tested across multiple browsers and so far, no dice. I'm seeing normal validation and validation error styling being displayed.
What specific browsers/platform are you having problems with?
There weren't any database schema changes for version 1.3.12 but if you're planning on running WordPress version 3.0, you're going to need the newest version of Gravity Forms. If you're not upgrading your WordPress install for a while, you should be able to roll back to the earlier version without any issues.
cbg
Member
Thanks for feedback. Our developer went and fixed the styles to work with the new html 5 tags.
However I would appreciate if you could help us fix a more subtle issue.
I you use Chrome 5.0 and you go to
http://canopyoutdoor.biz/ (user / password: stage / stage)
and click the Submit on "EMAIL A CONSULTANT" form you can see the error message caused by form validation. This site uses Gravity Forms 1.3.11.
If you go to
http://www.canopyoutdoor.com.au/
and click the Submit on "EMAIL A CONSULTANT" form the error message is not displayed.
This happens with Chrome only (I tested with IE and Firefox and it works).
I would appreciate if you have a look and provide feedback.
Otherwise the other forms work correctly.
I checked this out in multiple browsers again, Chrome 4.1.249 on Windows, Chrome 5.0.375.55 on Mac - error message displayed fine for me everywhere.
I'm glad the other forms are working for you now, but I'm personally not convinced that the HTML 5 field attributes had anything to do with any styling issues. It would be great if you could post whatever "fix" your developer came up with so we can have a look.
cbg
Member
Thanks for investigating.
I tested with Chrome 4.1.249.1064 on Windows and it works. However it does not work with Chrome 5.0.375.55 beta on Windows.
Please note that it works on staging (http://canopyoutdoor.biz/ user / password: stage / stage) with Gravity Forms 1.3.11 and Chrome 5.0.375.55 beta on Windows.
It could be a problem with Chrome 5.x on Windows; however it works with Gravity Forms .1.311.
I will talk to our developer about providing feedback on what he did to fix the problem.
Okay, thanks so much for the extra information. Anything else you can tell us will be valuable in testing future versions.
Another data point.
On Windows XP with Chrome 5.0.375.55 beta
When I go to this page and submit with no data:
http://www.canopyoutdoor.com.au/
I do not get the validation error messages. The cursor just jumps to the email field.
When I go to this site:
http://canopyoutdoor.biz/
The validation error messages show up as expected.
With Firefox 3.6.3, I get the validation error messages as expected on both sites. There are a bunch of JavaScript errors on both sites, when checking in Firefox, but I am not sure if any of them are related to this problem. I counted something like 26 scripts, including the inline JavaScript.
In Google Chrome, this page does not even seem to be POSTing:
http://www.canopyoutdoor.com.au/
when you click submit. On the .biz page, you get a "waiting for" when it posts back to the server, then you get the validation error message. At .com.au, that does not happen, but the cursor jumps to the email field right away.
One other weird thing: if you F5 to refresh in Chrome, you get the warning about duplicate form submission on the .biz site, but not the .com.au site. That makes me believe the POST was not submitted.
So, I can confirm what cbg is saying here.
Danny
Member
Kevin, I'm the developer. The styling issues came from 2 things:
1.) HTML 5 input types
2.) Thesis specific fixes (some are rather questionable to be honest, 5% !important width on checkboxes?)
We often use input[type="text"] in CSS, since this was changed to type email and type tel the styling was lost. In addition the Thesis fixes now took precedence over custom styling as almost every div in the chain up to the form was defined in the stylesheet (this is really unnecessary and forces us to do the same).
Example of Thesis specific CSS:
#content_box .post_box .format_text ul.gfield_radio li input
What would be enough:
.format_text input[type="radio"]
.format_text .gform_wrapper input
.format_text .gfield_radio inputWhat we used previously:
.custom .format_text .gform_wrapper input[type="radio"]
What we have to use now:
.custom #content_box .post_box .format_text ul.gfield_radio li input
Danny
Member
Back to the original request - please build in a switch to turn these on or off. We have many clients that simply request XHTML 1.0 Strict validation and this breaks it.
HTML 5 is great but it is pretty unnecessary here for most people (and most people will use some sort of XHTML doctype which will throw validation errors with them).
Danny, we appreciate the extra information.
I can see there are a few places where the Thesis specific styles can still be tweaked on my end. I actually intended to change the "5%" to "auto" in this last release but missed it. These were added to help solve some of the most common Thesis form styling issues that resulted from some "questionable" theme CSS, most notably applying a blanket 45% width to all inputs. They work well with a default implementation of Thesis, but of course with other custom styles, it's hard to predict.
With the huge variety themes out there, we can aim for the middle ground and hopefully the forms work fine with very little tweaking. One size really doesn't fit all so sometimes it does take a bit more work to get everything just so.
The option to completely turn off the default forms CSS exists too, so it's easy to completely restyle the forms to your liking without the influence of any other stylesheets.
As far as the input types, the majority of the themes I've seen don't use the type attribute for input styling at all so the styling issue wouldn't affect most. It's not that the HTML 5 fields actually break anything, just related to the choice of CSS selectors.
Moving forward, we will be changing the HTML 5 fields to an optional setting in the next release so this won't be an issue.
Thanks again.
@illinoisharley thanks for doing the extra legwork and sharing the results. I'm installing the beta version of Chrome for Windows and will give it a run.
As you mentioned, there are a lot of scripts on this site. With the inconsistencies, I'd bet there is some kind of conflict there but we'll check it out and see.
UPDATE:
I installed Google Chrome beta 5.0.375.55 on Windows XP and the sidebar form on http://www.canopyoutdoor.com.au/ worked just fine for me. Again, I can't replicate the problem.
The error style didn't display because it appears like the default styles aren't being enqueued properly and/or there is some kind of styling conflict.
