On Mon, Jul 25, 2016 at 3:35 PM, Nils Dagsson Moskopp
> Eitan Adler <li...@eitanadler.com> writes:
>> On 25 July 2016 at 14:59, Nils Dagsson Moskopp <
>> n...@dieweltistgarnichtso.net> wrote:
>>> Eitan Adler <li...@eitanadler.com> writes:
>>> > See also the remainder of my email.
>>> I do not understand. What do you mean?
>> Please re-read the original email of the thread.
>> I am arguing that *neither*
>> <input type="text" pattern="\d*" />
>> <input type="number" .... />
>> are correct.
>> While I could understand a keyboard which only allows "allowed tokens" this
>> is entirely infeasible given modern regular expressions are Turing
>> complete. In fact, they are infeasible even as DFAs considering valid
>> values depend on future input.
> I massively doubt that a “regular” expression could be turing complete.
Real regexps (per the dictionary definition of them) are not TC,
they're regular. Perl regexps are TC, due to additions. Other
languages' regexps may or may not be TC, depending on how
Perl-compatible they are, but most of them recognize more than regular
That all said, this is irrelevant. Recognizing very simple patterns
like "just a \d or [0-9] with repetition" has nothing to do with
TCness or future-input prediction.
>> There is room for a "digits only" inputmode which is *already* a mode
>> supported by some mobile browsers. I'd only like to make this explicit and
> Could you qualify the attribute “magical” ?
Inferring from the pattern that a text input will be digits-only, and
altering the UI to accommodate that, is "magical" because it's not
specified - if there was a line in the spec that talked about
recognizing certain patterns, it might be different. We already have
a feature for hinting what kind of input is expected - the inputmode
attribute. It even has a "numeric" value, but that's for entering
actual numbers and per-spec allows for thousands separator,
plus/minus signs, etc. Eitan is asking for an inputmode specialized
to "digit strings" specifically, where the only allowed characters are
those recognized by /\d*/, so the intent can be made explicit, rather
than just hoping that browsers present a reasonable UI.
This seems reasonable to me, particularly since browsers already
present the desired UI in some cases.