rangeOverflow and rangeUnderflow handling currently assumes that the field value is a number, as it is with the number and range input types; however these validations also exist for several date-related input types—date, datetime-local, month and week.
How these end up being handled probably needs some thought. Should messaging customisation options be provided for all date-related types as a whole ("Pick a more recent/less recent date"), specific for each type (different ones for date, week, etc.), or should it do nothing at all, and expect implementors to use the data-* overrides in instances where customisation is necessary?
Should the interpolation string passed through to the customiser attempt to localise the date format, or pass the raw ISO value through? How would this work in cases like week, where the raw value is pretty user unfriendly (e.g. 2021-W14) and there is no clear convention on how to localise such a format?
rangeOverflowandrangeUnderflowhandling currently assumes that the field value is a number, as it is with thenumberandrangeinput types; however these validations also exist for several date-related input types—date,datetime-local,monthandweek.How these end up being handled probably needs some thought. Should messaging customisation options be provided for all date-related types as a whole ("Pick a more recent/less recent date"), specific for each type (different ones for
date,week, etc.), or should it do nothing at all, and expect implementors to use the data-* overrides in instances where customisation is necessary?Should the interpolation string passed through to the customiser attempt to localise the date format, or pass the raw ISO value through? How would this work in cases like
week, where the raw value is pretty user unfriendly (e.g. 2021-W14) and there is no clear convention on how to localise such a format?