zem_contact_reborn v4.5.0.0: contact mail form processing

philwareham · 2016-05-23 09:19:29

Bloke wrote #299206:

From memory, Phil argued (convincingly) to take all the automatic classes out.

You’re correct, I did!

Surely by its very nature, it’s not possible for a radio group to not be required, given that one of the options is always selected, thus always transmitted with the form?

Radio buttons can be completely unselected by default, although it’s considered best practice to have a default selected. This article sums it up quite well.

gomedia · 2016-05-23 12:36:33

Bloke wrote #299206:

If you want to use your own classes, you have to use the class attribute now to override them.

OK, I’ll live with it. For the record, this is how I’m now targeting a field called “mailing_list” in CSS:

input#mailing_list { ... }
label[for=mailing_list] { ... }

I’m not sure what effect setting required="0" should have on the HTML. Any thoughts anyone?

I need to be able to remove the required attribute, so that adi_contact can generate a custom error message. Please don’t kill that functionality! In HTML5, when a required attribute is set the browser seems to interfere with the normal POST action – i.e. it blocks the POST & prompts the user with a “Please fill out this field” tooltip instead.

I’ll add some docs about an upgrade path, though. Good call. And fix the bug you sent me via email, thanks for the report.

Great, no probs.

Bloke · 2016-05-23 12:52:13

gomedia wrote #299216:

I need to be able to remove the required attribute, so that adi_contact can generate a custom error message. Please don’t kill that functionality!

Okay, I’ll fix it up and leave it in.

Though I haven’t committed the code yet, that undefined index bug seems to be an oversight (lack of defensive coding) but the other one about the required attribute on the first group breaking all the others is a doozer. Thanks for finding that one, I’ll have to check there are no other combos that break in this way.

phiw13 · 2016-05-23 22:39:35

gomedia wrote #299216:

I need to be able to remove the required attribute

You should be able to set the novalidate attribute on the form. That will prevent browsers such as Firefox and Chrome of doing their automatic validation of required fields. See this MDN article.

Or perhaps ZCR could offer the option to add it ?

Edit: Added a ticket on github.

Last edited by phiw13 (2016-05-23 23:02:29)

gomedia · 2016-05-23 22:57:05

phiw13 wrote #299222:

You should be able to set the novalidate attribute on the form. That will prevent browsers such as Firefox and Chrome of doing their automatic validation of required fields. See this MDN article

Or perhaps ZCR could offer the option to add it ?

Thanks, that’s good to know. Yes, it would be a useful option for ZCR.

Bloke · 2016-05-23 22:58:49

Stupid bugs aside (of which there are currently two: a stray double quote when trying to set a radio checked, and the one Adi found where the plugin checks for a non-existent array key in zem_contact_group_validate and throws a wobbly) the logic to try and process multiple radio groups is mental.

It’s like:

If you haven’t specified required on the first item of a group, apply the currently in-force global required attribute (from the zem_contact tag).
If you have specified a required attribute, use that value for this radio element.
But if this is the first item in a new group and you’ve specified a required attribute, set the default required state for any subsequent radio tags with the same group name to that value.

I think I need to refactor the way it’s doing things in the zem_contact_radio tag because it’s way too complicated and I’m sure it’s checking too many things it doesn’t need to. Will try and figure it out this evening.

Bloke · 2016-05-23 23:06:11

phiw13 wrote #299222:

Or perhaps ZCR could offer the option to add [novalidate] ?

Sure. I can add that once I figure out if that attribute trumps any required attributes at the browser level, or if I have to add checks in the plugin to omit all required attributes if novalidate is in effect. The W3C is a bit vague on this point:

Specifies that the element represents a form that is not meant to be validated during form submission.

It doesn’t say whether validation is merely “check min/max bounds and such like” or whether it includes turning a blind eye towards required violations too. Presumably it’s browser-dependent, which could get sticky if we rely on it.

phiw13 · 2016-05-23 23:18:39

Bloke wrote #299225:

Sure. I can add that once I figure out if that attribute trumps any required attributes at the browser level, or if I have to add checks in the plugin to omit all required attributes if novalidate is in effect.

As far as I understand it, it indicates that the browser should not do its own internal validation (and thus prevent form submission). You still use the required attribute on the individual fields to flag the required fields.

IOW – it tells the browser: ‘don’t do any validation yourself, my script will take care of it’.

BTW for a fun thing with that automatic validation – using a ZCR form. In an Email field, type: t@t.tld. All (modern) browsers consider it valid… ZCR flags an error (correctly I think).

Bloke · 2016-05-23 23:31:23

phiw13 wrote #299226:

As far as I understand it, it indicates that the browser should not do its own internal validation (and thus prevent form submission). You still use the required attribute on the individual fields to flag the required fields.

OK, I’ll test it at some point. But does this mean it’s not much use for Adi if he wants a mechanism for the browser to butt out completely and stop nagging people to fill in fields? I recall someone else contacted me via email wanting the (v4.0.3.20) behaviour where the browser did no validation and, if a field was required, ZCR itself displayed this information in its ‘error’ box upon submission. The argument being that this behaviour is more consistent for end users, as it will always display an error box in a known place if there are any fields that violate anything.

Maybe using novalidate with varying values might be able to satisfy all these requirements. e.g.:

<txp:zem_contact novalidate="1"> : add HTML novalidate attribute to the form. Thus no validation checks are performed, but required fields are still checked browser-side and flagged.
<txp:zem_contact novalidate="2"> (or ‘all’ or something): add HTML novalidate attribute to the form and also globally remove all required attributes, irrespective of what you may have put in your individual ZCR tags, or the zem_contact tag itself, thus shutting off all browser-side interference.

Sounds a bit kludgy to effectively ignore an attribute you may have specified elsewhere in your form so I’m not sure if this is a great idea. If you want this behaviour, you might be better off doing:

<txp:zem_contact novalidate="1" required="0">

and just make sure you’ve taken off any required attributes in your individual ZCR form tags.

EDIT: Or perhaps I’ve read this all wrong. Maybe you still want to be able to enforce required fields, but not at the client. In which case, we need a mechanism to say “This field is required, but don’t stick the required attribute on the HTML tag, just check it at the server side on submission”. If so, how would you use plugin tag attributes to signal that to the plugin?

Any further thoughts on this issue, please raise them here and I’ll factor it into the plugin as best I can.

Last edited by Bloke (2016-05-23 23:37:45)

gomedia · 2016-05-24 00:02:38

Just done some experiments (admittedly in Firefox only) but novalidate on the form overrides both required on <input> tags and also data validation (e.g. dodgy email address format).

So, is your assertion “Thus no validation checks are performed, but required fields are still checked browser-side and flagged” correct?

phiw13 · 2016-05-24 00:04:32

I think you misunderstand, or you make it more complicate that it really is. And as far as I can tell, much of what the spec talks about is targeted at browser developers, not HMTL authors (aka you).

with <txp:zem_contact required="0">, the browser will not do any validation, as there are no required fields
with <txp:zem_contact required="1">. the browser will run its automatic validation, based on the browser understanding of a correct/valid value for that field – this is the current situation with ZCR.
<txp:zem_contact novalidate="1" required="1"> (meaning: novalidate="novalidate" aka true), the browser will not run its own validation of required fields, instead it will let the form script do the job. That is, it will not prevent form submission when the user presses the submit button, and thus will not display those error bubbles. Or rephrased: the presence of the novalidate attribute tells the browser to ignore it own internal mechanisms related to requiredfields. The script (ZCR) can still prevent form submission based on the required fields having an unexpected / invalid value.

Bullet point 3 is exactly what Adi wants to do: ”dear browser, don’t throw your own error messages, I’ll do it myself”

In the situation of the third point above, the required attribute is still useful for flagging the required fields: AT (screenreader) uses it, your script uses it to decide what fields it need to flag, etc.

Bloke · 2016-05-24 00:08:35

gomedia wrote #299228:

So, is your assertion “Thus no validation checks are performed, but required fields are still checked browser-side and flagged” correct?

Nope. Seems that novalidate turns off all client-side checks, including required.

So, to get this straight in my head: even though adding novalidate incapacitates the browser from checking required status and min/max constraints, etc, you still want all that validation to be done server side and display any errors in the error box that appears above the form? Just like it did in v4.0.3.20?

Textpattern CMS

Textpattern CMS support forum

#61 2016-05-23 09:19:29

Re: zem_contact_reborn v4.5.0.0: contact mail form processing

Bloke wrote #299206:

#62 2016-05-23 12:36:33

Re: zem_contact_reborn v4.5.0.0: contact mail form processing

Bloke wrote #299206:

#63 2016-05-23 12:52:13

Re: zem_contact_reborn v4.5.0.0: contact mail form processing

gomedia wrote #299216:

#64 2016-05-23 22:39:35

Re: zem_contact_reborn v4.5.0.0: contact mail form processing

gomedia wrote #299216:

#65 2016-05-23 22:57:05

Re: zem_contact_reborn v4.5.0.0: contact mail form processing

phiw13 wrote #299222:

#66 2016-05-23 22:58:49

Re: zem_contact_reborn v4.5.0.0: contact mail form processing

#67 2016-05-23 23:06:11

Re: zem_contact_reborn v4.5.0.0: contact mail form processing

phiw13 wrote #299222:

#68 2016-05-23 23:18:39

Re: zem_contact_reborn v4.5.0.0: contact mail form processing

Bloke wrote #299225:

#69 2016-05-23 23:31:23

Re: zem_contact_reborn v4.5.0.0: contact mail form processing

phiw13 wrote #299226:

#70 2016-05-24 00:02:38

Re: zem_contact_reborn v4.5.0.0: contact mail form processing

#71 2016-05-24 00:04:32

Re: zem_contact_reborn v4.5.0.0: contact mail form processing

#72 2016-05-24 00:08:35

Re: zem_contact_reborn v4.5.0.0: contact mail form processing

gomedia wrote #299228:

Board footer