weixin_40001048
weixin_40001048
2021-01-02 03:09

Constraint validation limits

I was elaborating a polyfill for what I consider a missing feature in form validation (you can find it, along with the related proposal, in my repositories) and I found out a limitation regarding how custom validity is defined. The current mechanism of defining an error based on its error message, while efficient sometimes, makes it quite difficult for scripts defining different custom errors to interact with each other. In my case, for example, I chose to check whether the custom error message matches mine in order to remove it when the user fixes the mistake, so that the custom error is not removed if another one occurs. I think this could be done in a better way using the element.validity property: - allow authors to define new validity error properties, as my script does with validity.groupMissing: authors will have to let these properties return true in conditions defined by the script. - make sure element.validity.valid returns true only if all other validity errors (either native or custom) return false - let invalid event depend directly on element.validity. Currently browsers implement a sort of internal API to do that, so if I define it another way without also using element.setCustomValidity, the event is not fired. - let errorMessage be writable, so that once the event is fired (according to element.validity) the message can be produced on-the-fly without having to reset it when user intervenes. - of course customError should be left as-is, both for compatibility with current situation and for enabling easier cases.

Of course this could be done in a different way but I suppose it wouldn't be compatible with current API: customError could return an object, whose properties are defined by separate instances of setCustomValidity. element.setCustomValidity('groupMissing', 'error message for groupMissing') This way different error messages can be identified and removed, and customError is true only if all the custom error messages correspond to empty strings (it would be interesting how these messages can be returned, though, and there would be issues about what element.errorMessage should return).

Could it be done spec-side? Or does it depend on how vendors interpret the specification?

该提问来源于开源项目:w3c/html

  • 点赞
  • 写回答
  • 关注问题
  • 收藏
  • 复制链接分享
  • 邀请回答

5条回答

  • weixin_40001048 weixin_40001048 4月前

    AlternativeRequired is indeed the polyfill I mentioned. In that case I check that the custom error message string #is one of those generated by my own script, before unsetting it. This way, if other custom errors are generated, they do not conflict.

    making it easier for two different scripts to run over the same form, potentially providing two types of validation on the same form element

    Yes, that's exactly my issue. Different custom errors are difficult to distinguish, as they all rely upon the same feature, and they end up overriding each other (this is particularly dangerous in case the last script to fire sets the custom error message to the empty string, thus marking the element as valid while suffering from other custom errors).

    In order to sustain my request I should prove that there are a lot of pages using several scripts in order to manage different custom errors. I guesse there will be at least some, as custom validation API is easy to use and, as said elsewhere, authors are meant to do it.

    点赞 评论 复制链接分享
  • weixin_39861734 weixin_39861734 4月前

    Yeah, I certainly see value in the proposal. But that doesn't mean it will be implemented by browsers, and if it isn't there is not much point putting it where developers will read it and assume it works :)

    点赞 评论 复制链接分享
  • weixin_39754831 weixin_39754831 4月前

    Closing as it should be incubated

    点赞 评论 复制链接分享
  • weixin_40001048 weixin_40001048 4月前

    I suppose there was an error, 251275a solves #53 and it has nothing to do with this :)

    点赞 评论 复制链接分享
  • weixin_39861734 weixin_39861734 4月前

    Yes. I think I understand your use case, as making it easier for two different scripts to run over the same form, potentially providing two types of validation on the same form element.

    Is that correct? If so, I think this is a feature request. It probably makes sense to do it within the HTML spec, but we will look for tests that show something works in browsers before making the changes to the official spec, which means a bit more work is required here.

    Is the AlternativeRequired the polyfill you mentioned? Showing that a lot of authors use this or equivalent scripts might be a good argument that the feature is important to developers…

    点赞 评论 复制链接分享

相关推荐