Дело в том, что там эти формы рассматривались, как хорошие примеры для других случаев. Ведь в каждой форме есть свои плюсы и минусы. Здесь совершенно другие заголовки и другие проблемы.
Насчет формы «бизнес-линча»: а как вы предлагаете измерить размер файла средствами JavaScript, без отправки его на сервер? Предлагаете пользователю подождать пару минут (и хорошо, если только пару), пока его файл отправляется в фоновом режиме, и только потом, получив с сервера данные о размере, разблокировать кнопку «отправить»?
Бизнес-линч не вполне обычный сервис. Со стороны студии это, скорее, жест доброй воли :-)
В любом другом случае правильно было бы не грубить пользователю приказом «Сделайте файл…», а самим программно уменьшить размер этого файла. Если качество работы сжимающего алгоритма вызывает сомнения, можно после сжатие отображать пользователю результат, с возможностью перезалить уже самостоятельно уменьшенный файл.
Когда в том или ином поле присутствует явное ограничение на набор возможных для ввода символов, например, только цифры или только латинские буквы, можно вообще запретить в этом поле ввод непринимаемых символов. При этом в момент ввода такого символа можно показывать балон с сообщением о том, что же все-таки можно вводить.
Плюс в том, что у нас в принципе не возникает ситуации, когда поле заполнено неверно.
Мне кажется, что заметка эта в основном полезна тем, что заставляет читателя самому задуматься над тем, что любым формам надо уделять больше внимания, чем кажется на первый взгляд, и самому подумать над тем, как придумать грамотную реализацию защиты формы от некорректных данных пользователя, при этом сделав это максимально удобно для конечного пользователя. Но сама тема в материале раскрыта, как мне кажется маловато. Было бы интересно посмотреть больше удачных и неудачных, по мнению автора, примеров решения этой проблемы.
Подача ошибок. Часть 3. Ошибки в формах.