com_connect - form and contact mailer

Bloke · 2020-06-02 12:15:56

I’ll fix the select/option thing somehow and look into replacing spaces and characters that might bork submission with just regular characters in the name attribute. Not sure whether utf-8 would be considered valid. I’d like to hope so, but it’d probably be up to the server or the HTML spec or something.

colak · 2020-06-02 13:56:40

I’m so sorry, I feel that I am spamming this thread today!

I am trying to limit what can be inserted in some text fields. ie.

<txp:com_connect_text type="number" label="percentage of..." required="1" class="" />

The issue with type="number" is that it does not accept decimals. ie commas or dots (depending on your local). Is there another way for this to be restricted to numbers and their decimals, and for people to use either a comma or a dot?

Bloke · 2020-06-02 14:07:30

colak wrote #323496:

The issue with type="number" is that it does not accept decimals. ie commas or dots (depending on your local).

Out of the box, the number field accepts integers, as per the HTML spec. You can use step to alter the granularity, e.g. step="0.1" or step="0.01" or even step="any" if you don’t care. min and max are also supported if you don’t want to permit anything above/below a certain value.

Also, by default, the field takes on the language of your site and uses its locale. So if you want to change it either for the entire form, or for a specific field, add lang="{lang-code}" at an appropriate point to make it more permissive.

For example, this permits comma or dot as separator by faking French as the field’s language:

<txp:com_connect_text type="number" label="percentage of..." step="any" lang="fr" required="1" class="" />

Last edited by Bloke (2020-06-02 14:09:41)

Bloke · 2020-06-02 14:53:35

colak wrote #323484:

validation when using com_connect_select and the options starting with a comma.

The crux of this issue seems to be that if you use an empty option, it must have a label to validate. Yours and Phiw13’s workarounds are good, but it’d be nice not to have to rely on them.

Couple of random thoughts on ways to solve this are:

New attribute

Introduce a new attribute like option_label or empty_label or something to the <txp:com_connect_select> tag. e.g. empty_label="Please choose"

If used, it would add an empty element to the start with the given label and a forced value="". You would have to then not use the leading comma in your options attribute (or we could silently ignore it if used in conjunction with this attribute).

Note this doesn’t help when the tag’s used as a container as the attribute would be ignored. I don’t like the idea of propagating this attribute forward so, if used, your container automatically has an empty option prepended. That’s fraught with complications and unexpected outcomes (like if you’re using <optgroup> or something in your container).

{empty} syntax

Introduce some syntax which means “This is an empty element”. For example wrapping it in braces: options="{Please select a character...}, Wolverine, Professor X, Mystique, Magneto".

It renders the label and would add value="" as above. This is neat but not very intuitive. Though an advantage is there’s no new attribute to confuse people.

The same braces syntax could be used in the <txp:option /> tag to label the first element as an empty entry.

There might be something else we can do yet, these are just initial thoughts. Anyone any feedback on these, or other ideas how to solve this?

Last edited by Bloke (2020-06-02 14:54:33)

colak · 2020-06-02 15:32:26

Bloke wrote #323497:

Out of the box, the number field accepts integers, as per the HTML spec. You can use step to alter the granularity, e.g. step="0.1" or step="0.01" or even step="any" if you don’t care. min and max are also supported if you don’t want to permit anything above/below a certain value.

<txp:com_connect_text type="number" label="percentage of..." step="any" lang="fr" required="1" class="" />...

This works!!!!

introduce some syntax which means “This is an empty element”. For example wrapping it in braces: options="{Please select a character...}, Wolverine, Professor X, Mystique, Magneto"

I like the idea and I noticed how much you favour braces for the plugins you work on:) It is straight forward and no new attributes will be needed.

phiw13 · 2020-06-02 23:02:11

Bloke wrote #323500:

Introduce some syntax which means “This is an empty element”. For example wrapping it in braces: options="{Please select a character...}, Wolverine, Professor X, Mystique, Magneto".

It renders the label and would add value="" as above. This is neat but not very intuitive. Though an advantage is there’s no new attribute to confuse people.

At first sight (early morning brain-electrons edition) this seems a reasonable option. The { } has some precedent, e.g. glz_custom_fields uses it to indicate the default in a set of radio buttons. I’ve seen it used elsewhere for a similar reason. So not a stretch to extend its use here.

phiw13 · 2020-06-02 23:08:53

colak wrote #323496:

<txp:com_connect_text type="number" label="percentage of..." required="1" class="" />...

The issue with type="number" is that it does not accept decimals. ie commas or dots (depending on your local). Is there another way for this to be restricted to numbers and their decimals, and for people to use either a comma or a dot?

You could consider using type=text instead, coupled to the inputmode="numeric" and pattern="your regular expression" attributes.

The UK Gov guidance now recommend this for flexibility and a host of accessibility reasons

Bloke · 2020-06-02 23:21:48

phiw13 wrote #323513:

You could consider using type=text instead, coupled to the inputmode="numeric" and pattern="your regular expression" attributes.

Sound advice. I can see why doing that is a good idea on three-and-a-bit of the government’s reasons. The rounding/exponential formatting is the biggest issue when dealing with giant numbers, otherwise hilarious things like this can happen. Scrolling with the mouse wheel too: definitely problematic in a lot of cases. The cryptic message that most browsers supply for violations is daft.

The only thing I’m not entirely sold on is the accessibility issue. Playing devil’s advocate, it seems the NVDA screen reader should be fixed to handle type="number" better. It’s been around long enough.

But even so, this is sensible advice that delivers a much better user experience… and com_connect supports it.

Last edited by Bloke (2020-06-02 23:24:34)

Bloke · 2020-06-02 23:31:31

Thanks for the feedback, men. I’ve committed the bracket syntax so please test it to see how you get on.

Incidentally, this next version is officially targeting 4.7.0 simply because of the way it handles Textpack language designators. Pre-4.7 Txp doesn’t understand the comma-separated language list in the Textpack. But other than that, the plugin should still work as far back as 4.5.0. Maybe earlier.

I’ve left the old opinionated designators in place in most cases, as 4.7.0 falls back gracefully. The only exception is English. Plugin upgrades should be fine on older versions of Txp, as they may not reinstall the Textpack anyway. But if you find it’s not behaving on older core tech, alter the #@language to remove the comma-separated list of language designators and it should work fine.

phiw13 · 2020-06-03 01:49:10

Bloke wrote #323514:

Sound advice. I can see why doing that is a good idea on three-and-a-bit of the government’s reasons. The rounding/exponential formatting is the biggest issue when dealing with giant numbers, otherwise hilarious things like this can happen. Scrolling with the mouse wheel too: definitely problematic in a lot of cases. The cryptic message that most browsers supply for violations is daft.

There are quite a few physical accessibility issues – you mention the scroll wheel thingie which does not happen with my trackpads and no mouse available, there is the size of the arrowed button (small small) and so on. keyboard access is reasonable as long as you just can type in that field. But if you don’t know what kind/type of numbers are acceptable, well…

The only thing I’m not entirely sold on is the accessibility issue. Playing devil’s advocate, it seems the NVDA screen reader should be fixed to handle type="number" better. It’s been around long enough

hmm, don’t tell that to the lady down the road who’s trying to update her application for disability support… (but NVDA should fix their issues, sure).

Thanks for the updated <select /> syntax, I’ll test later today.

colak · 2020-06-03 05:35:56

Bloke wrote #323515:

Thanks for the feedback, men. I’ve committed the bracket syntax so please test it to see how you get on.

That was quick! I’m trying to find the .zip.txt file.

phiw13 · 2020-06-03 06:06:52

colak wrote #323518:

That was quick! I’m trying to find the .zip.txt file.

You can download the .php file (head over to the “raw” mini tab) and on the TXP plugins panel choose the “upload plugin” widget.

–^–^–^–^–

Bloke, a first pass I get this, as attributes on the <txp:com_connect_option

<txp:com_connect_option class="" label="{Select one}" selected />

returns:

 <option selected value="">Select one</option>

I think I would expect:

<option selected value="" label="Select one"></option>

But what it currently returns appears to validate and the browsers (Safari and Firefox) handle it correctly.

Textpattern CMS

Textpattern CMS support forum

#217 2020-06-02 12:15:56

Re: com_connect - form and contact mailer

#218 2020-06-02 13:56:40

Re: com_connect - form and contact mailer

#219 2020-06-02 14:07:30

Re: com_connect - form and contact mailer

colak wrote #323496:

#220 2020-06-02 14:53:35

Re: com_connect - form and contact mailer

colak wrote #323484:

New attribute

{empty} syntax

#221 2020-06-02 15:32:26

Re: com_connect - form and contact mailer

Bloke wrote #323497:

#222 2020-06-02 23:02:11

Re: com_connect - form and contact mailer

Bloke wrote #323500:

#223 2020-06-02 23:08:53

Re: com_connect - form and contact mailer

colak wrote #323496:

#224 2020-06-02 23:21:48

Re: com_connect - form and contact mailer

phiw13 wrote #323513:

#225 2020-06-02 23:31:31

Re: com_connect - form and contact mailer

#226 2020-06-03 01:49:10

Re: com_connect - form and contact mailer

Bloke wrote #323514:

#227 2020-06-03 05:35:56

Re: com_connect - form and contact mailer

Bloke wrote #323515:

#228 2020-06-03 06:06:52

Re: com_connect - form and contact mailer

colak wrote #323518:

Board footer