[UA-EAI] WhatWG issue regarding <input type="email"> is open (#4562)

Sun Jun 7 14:27:30 UTC 2020

Couple of thoughts:

1. If you want stuff done, the quick way is to provide money (or  
guaranteed users by the million, because they equate to money). WHATWG  
think there are only 4 important browsers, so that limits your options  
somewhat. If you have the clout of a gov ernment department, a school  
system, or the like, maybe you can force something through, but most  
browser companies are pretty large, and dealing with a global market means  
they aren't keen on addressing things for one segment of one country. The  
alternative is to make the change in some critical service that uers need,  
patch it intrusively (like cookie authorisation maybe) for browsers that  
haven't got a native fix, and explain what is needed to clean that up.

Whether that is successful, or just rubs some powerful engineers the wrong  
way until they take a bloody-minded dislike to what you do and refuse to  
engage with the question again is hard to predict in advance.

2. John is right that accept EAI addresses in <input type="email"> won't  
prove that a system actually works with internationalised addresses so it  
may cause failures - and it is true that these may initially cause a lack  
of trust in the safety of using them. On the other hand, once the systems  
behind are updated, nothing further needs to be done - we don't need to  
change the code in every single website in the world...

On the other hand, if we introduce a new email type, the first requirement  
is to make it clear to users that it behaves differently (otherwise there  
is no reason for them to trust it anyway) which means a lot of  
coordination of user interface elements. This is something that has  
historically proven *amazingly* difficult. The signaling of Extended  
Validation security certificates is the only example that comes to mind of  
actual success this century, although I am sure there are others.

In addition, the only time it will work is when websites are changed - the  
entire underlying systems can be upgraded to work, but it would still be  
impossible to use just because the form itself isn't updated.

There is a principle that was used in designing HTML5 called the "priority  
of constituencies" that suggests you should try to concentrate the effort  
required on the smallest feasible group, who are also likely to be the  
best-qualified group to get it right. Where browser makers are a very  
small skilled group, site developers less so (the people who make the  
tools and many libraries that many site developers use are in between),  
and trying to change all end-users' behaviour is more or less a last  
resort (it can be done, but it's difficult).

Obviously there are no especially right answers here, beyond whatever  
works will be a good idea. It might be worth looking around the world of  
smaller or more geographically concentrated browsers - Vivaldi, Yandex,  
Baidu, Opera, Firefox, - or perhaps using the good relationship some  
governments have with e.g. Microsoft or Samsung to explore the  
possibilities. (And Microsoft and Mozilla are both represented on the  
WHATWG steering committee, for whatever that is worth... though the people  
you need to convince are more likely spec editors like Anne van Kesteren.

cheers

Chaals

On Sun, 07 Jun 2020 12:41:38 +1000, Mark W. Datysgeld  
<mark at governanceprimer.com> wrote:

> Following up on John, I got the same impression when discussing with  
> them last year's email acceptance research, from which our >key  
> suggestion was adding input type="eaimail".
>
> The question remains: what browser vendor would we be most likely to  
> convince and spend a lot of resources doing that? I still >stand by the  
> idea that, on the Web front, this ks the most valuable task we can  
> perform.
>
> Regards,
> --Mark W. Datysgeld from Governance Primer [www.markwd.website]
> In partnership with AR-TARC and the Brazilian Association of Software  
> Companies (ABES)
>
> On June 6, 2020 10:30:11 PM GMT-03:00, John Levine  
> <john.levine at standcore.com> wrote:
>>
>> In article <7b47fbe2-c8d2-bf78-a832-005abc067789 at jdlh.com> you write:
>>> EAI colleagues:
>>>
>>> Back on 26. May we talked about a FY21 goal of participating in the 
>>> WHATWG process to ask them to improve their spec for '<input 
>>> type="email">' in HTML, because it is limited to ASCII-only.
>>>
>>> Our friend John Levine had opened an issue about this back in April  
>>> 2019:
>>>
>>> Validating internationalized mail addresses in <input type="email">  
>>> #4562
>>> <https://github.com/whatwg/html/issues/4562>
>>> Opened 23 April, 2019.
>>>
>>> There is a little discussion there, and there could be more.
>>>
>>> This issue report refers back an ancestor in the previous bug database:
>>>
>>> Bug 15489 "forms: <input type=email> validation needs to be updated for 
>>> EAI".
>>> <https://www.w3.org/Bugs/Public/show_bug.cgi?id=15489>
>>> Opened 2012. Discussion in 2012-2018. Closed in 2019 when the old bug 
>>> tracker was closed down.
>>>
>>> I'm not proposing any specific action right now. I just want to get 
>>> these links to everyone for background reading and for situational 
>>> awareness.
>>
>> People in the know tell me that if one of the major browsers says they
>> will add <input type="eaimail">, then they'll add it to the spec.
>> Until then, no chance.
>>
>> Merely changing the existing <input type="email"> to allow EAI would
>> be a very poor idea because there is no way to tell in the browser
>> whether the web server and its MTA support EAI. A separate input field
>> type lets the web application designer accept EAI addresses if she
>> knows that the supporting software can handle it.
>>
>> R's,
>> John
>> -----
>> UA-EAI mailing list
>> UA-EAI at icann.org
>> https://mm.icann.org/mailman/listinfo/ua-eai
>> -----
>> By submitting your personal data, you consent to the processing of your  
>> personal data for purposes of subscribing to this mailing list  
>> accordance with the ICANN Privacy Policy  
>> (https://www.icann.org/privacy/policy) and the website Terms of Service  
>> (https://www.icann.org/privacy/tos). You can visit the Mailman link  
>> above to change your membership status or configuration, including  
>> unsubscribing, setting digest-style delivery or disabling delivery  
>> altogether (e.g., for a vacation), and so on.

-- 
Using Opera's mail client: http://www.opera.com/mail/