Daniel Friesen's Blog - Latest Comments

Re: and iOS' numeric keypad

sakshi — Thu, 21 Dec 2023 05:30:32 -0000

what if i want to add - sign to allow negative numbers but not alphabets on iOS keyboard ?

Re: and iOS' numeric keypad

Daniel Friesen — Sun, 12 Aug 2018 06:05:24 -0000

That claim does not appear to be backed up by any facts when I actually look for it.

Relying on something as broken as the W3 validator to do search engine ranking would be idiotic. You'd penalize sites that are trying to do graceful fallbacks to support more browsers (something good websites should be doing). And you'd foolishly be de-ranking most of the top websites, given that every last one of the top 10 websites have W3 validator errors.

Re: and iOS' numeric keypad

António Lourenço — Sun, 12 Aug 2018 05:36:43 -0000

Yes, that's right, but it seems that some search engine rankings take into account the number of HTML errors provided by W3 validator, thus you cannot completely ignore them.

Re: and iOS' numeric keypad

Daniel Friesen — Thu, 02 Aug 2018 14:57:38 -0000

Ignore them, they don't take actual web considerations into account.

Remember that `input=number` was a new feature, in browsers that had not implemented `input=number` yet the input would actually be `input=text`. So the input you are creating is actually number in some browsers and text in some older ones, so it was still valid to apply a pattern attribute that will be read by the browsers that would treat it as `input=text`. Validators do not take fallback behaviours into account.

Re: and iOS' numeric keypad

António Lourenço — Thu, 02 Aug 2018 14:49:04 -0000

The problem is that according to HTML W3 validators, which follow the HTML strict rules attribute pattern is only allowed when the input type is email, password, search, tel, text, or url. Thus applying a pattern to input=number will give you a HTML validator error.

Re: and iOS' numeric keypad

Ophir Stern — Tue, 29 Mar 2016 16:05:33 -0000

Well having an Ionic product, and not finding a plugin that achieves the production level I was aiming for (nor in the UX or customisation aspect), I've created a new one currently used in our live mobile app. The number picker / spinner is implemented as an attribute directive, so stick to any DOM element, or your existing input fields (just remember to set their css to read only) and voila, solve a bunch of headaches (input verifications, user churn, etc.)

The directive acts as you'd expect it, with drag capability as in native devices, with a slick look, highly customizable and plenty additional functionality.

Check it out!

https://market.ionic.io/plu...

Re: and iOS' numeric keypad

Andy Edwards — Thu, 17 Dec 2015 11:46:16 -0000

Apple has really pissed me off as far as floating-point input. The only way to get a numeric keypad with a decimal point is to use type="numeric", but then if the user enters an invalid value (e.g. it allows multiple decimal points to be typed in) there's no simple way to get the invalid text and persist it so that it doesn't randomly disappear if you navigate away and back to it in a RIA.
I suppose one could use pattern="[0-9]*" and add a decimal point button to the right of the input or fixed at the bottom of the window so that the decimal point can be entered...

Re: and iOS' numeric keypad

schaep — Wed, 16 Sep 2015 09:32:21 -0000

I want almost full control over what is being displayed. Yes it should behave a certain way by default, but why can't a webapp maker specify a load of options? Show abc beneath the numbers or not, show decimal characters or not, show telephone like characters or not.
Or for the URL type why is there only a .com button? Why are there not 2 buttons: .Com and .whatever country the user is currently in? .com is mostly useless in "the rest of the world".
And I want the keypad to be responsive. For example when I make a type=text with a pattern for a postal code then the numbers should have numpad and as soon as the user reaches the position for characters it should display the keypad. And why doesn't the keypad read the regularexpression to determine which keys to allow?

No I don't want to make a gazillion native apps, I chose web for a reason.

Re: and iOS' numeric keypad

Aaron Gray — Fri, 24 Jul 2015 16:35:53 -0000

Best solution out there at this point - very nice!

Re: and iOS' numeric keypad

Daniel Friesen — Sun, 08 Mar 2015 23:23:44 -0000

No, changing the pattern won't work. Unfortunately iOS explicitly special cases the `[0-9]*` pattern (and one variant of that same pattern IIRC) so no other pattern works and doesn't seem to have a numpad containing a period (.). Also keep in mind that number inputs do not accept commas (,).

Re: and iOS' numeric keypad

Abul Hasan — Sun, 08 Mar 2015 22:20:56 -0000

How would you allow comma (,) and period (.) with the numpad. We want to use your technique for currencies. Can be done by changing pattern?

Re: and iOS' numeric keypad

Tanima — Wed, 31 Dec 2014 06:44:52 -0000

I want a keypad in device having 0 to 9 digits, dot and comma too.

Re: and iOS' numeric keypad

Mohini — Sat, 08 Nov 2014 06:24:35 -0000

How can I bring keypad shown in first figure with input type text?

Re: and iOS' numeric keypad

Daniel Friesen — Thu, 27 Mar 2014 18:15:57 -0000

Sorry, I've been to busy to test that. But I just came across something relevant on caniuse.
http://caniuse.com/#feat=in...

The known issues mentions that there's an open bug for Android 4.0 & 4.1 that it doesn't display placeholders on type=number elements.

Re: and iOS' numeric keypad

Don Woodlock — Fri, 14 Feb 2014 10:14:50 -0000

This mostly works but on android it is ignoring the placeholder attribute. Perhaps because this doesn't validate it's panicking a little bit. I would like everything that you are trying to solve (numeric keyboard on mobile devices) but would like the input field to have a placeholder. Any suggestions?

Re: and iOS' numeric keypad

Daniel Friesen — Tue, 29 Oct 2013 21:41:50 -0000

I'm not entirely sure what you're getting at in the last sentence. Though if you're talking about something like "11:22" not being accepted in <input type="number"> that's to be expected as that isn't really a number and the number input type is not intended to handle that.

Telling iOS not to use it's date/time functionality on a date/time input is a little different than forcing iOS to use the same type of numeric input as is standard on other mobile browsers. If you want to target a specific exception like that the best method would probably some JS specifically targeting iOS to swap input types for the time inputs.

Re: and iOS' numeric keypad

Teippi Viritykset — Tue, 29 Oct 2013 18:24:14 -0000

How about if you want to make a hh:mm time input, but don't want the ugly +slow to use spinner (or anything else than regular input) but do want to trigger the ios number keyboard (left pic) ? There seems not to be such thing because if input number and you run jquery for the field it clears! (for example change , and . to : )

Re: Numbered header using flexbox with fallback

Ed Melly — Mon, 23 Sep 2013 04:24:40 -0000

Yeah, I agree it is kind of gross. But if you just treat it as a way of laying things out (divorcing the name 'table' from any other meaning) it's actually a very handy tool. I'm just trying to justify it to myself, but these mental gymnastics work for me.

I'm sure I read somewhere (can't find it now) that omitting the table-row element is ok with the CSS version of tables. Even if it's not, it works perfectly everywhere I've tested it. Adding markup just to achieve a table-layout would be a step too far.

Re: Numbered header using flexbox with fallback

Daniel Friesen — Sat, 21 Sep 2013 07:39:44 -0000

Ah right, css table tricks. I usually avoid and and end up forgetting about them since personally I can't stand the idea of using css to declare that non-tabular data is a table. Not to mention even if it works the nesting is wrong (cells directly inside a table with no row in sight).

But yea, that could work too.

Re: Numbered header using flexbox with fallback

Ed Melly — Sat, 21 Sep 2013 07:16:11 -0000

Flexbox is very cool. I had to achieve something very similar recently and chose to use display: table instead. That has the added bonus of better browser support. Check out this jsFiddle: http://jsfiddle.net/cherryf... (not thoroughly tested, but with some work that's good to go down to IE8).

Re: css3 border-radius and vendor prefix fud

Stuart Suits — Wed, 17 Jul 2013 23:30:19 -0000

Just an update... Firefox and other Gecko browsers haven't required the -moz- prefix for border-radius since about version 4. The -moz- prefix has largely been phased out (although one instance I can think of where a prefix is still required is for placeholders). All of the opera prefixes are soon to be irrelevant as Opera 15 is officially released and sees adoption.

Re: css3 border-radius and vendor prefix fud

Jonas Hovmand — Tue, 11 Sep 2012 13:34:07 -0000

Awesome post, never thought about the order of the same properties. I think most people just puts the standard property above the others to indicate a section or something like that.

Re: A HTML5 Browser maze, oninput support

Grant Husbands — Tue, 11 Sep 2012 08:10:11 -0000

It's worth noting that IE9 can't detect text removal through the oninput or onpropertychange events, so feature detection may be insufficient.

Re: A HTML5 Browser maze, oninput support

J. Campbell — Thu, 28 Jun 2012 13:16:41 -0000

Please change your website design! This is too painful to read, despite the value of the information. And do you really need moving backgrounds?

Re: A HTML5 Browser maze, oninput support

John Cusak — Sun, 06 May 2012 00:36:17 -0000

You really need to consider a few improvements to this site, namely:
1) increase the font size - it is much too small and reading a huge block of text at this font size is horrendeous.
2) get rid of green on green - this is 2012 and we don't need another iteration of "yellow text" schemes.
3) don't use a horizontally fluid layout that aligns all the way to the left and right (view this on an hd screen to see why).